chore: Move optimism root checks into crates/optimism

[garwahl]

WIP for #10713

Moves calculate_receipt_root_no_memo_optimism and associated usages from crates/primitive to crates/optimism

[garwahl]

Hey @mattsse where should Receipts::optimism_root_slow() be moved to? Do you have a preference?

[emhane]

make sense for it to live next to this function

reth/crates/optimism/consensus/src/proof.rs

Lines 8 to 37 in 000b412

	/// Calculates the receipt root for a header.
	pub(crate) fn calculate_receipt_root_optimism(
	receipts: &[ReceiptWithBloom],
	chain_spec: &ChainSpec,
	timestamp: u64,
	) -> B256 {
	// There is a minor bug in op-geth and op-erigon where in the Regolith hardfork,
	// the receipt root calculation does not include the deposit nonce in the receipt
	// encoding. In the Regolith Hardfork, we must strip the deposit nonce from the
	// receipts before calculating the receipt root. This was corrected in the Canyon
	// hardfork.
	if chain_spec.is_fork_active_at_timestamp(OptimismHardfork::Regolith, timestamp) &&
	!chain_spec.is_fork_active_at_timestamp(OptimismHardfork::Canyon, timestamp)
	{
	let receipts = receipts
	.iter()
	.cloned()
	.map(|mut r| {
	r.receipt.deposit_nonce = None;
	r
	})
	.collect::<Vec<_>>();
	return ordered_trie_root_with_encoder(receipts.as_slice(), |r, buf| {
	r.encode_inner(buf, false)
	})
	}
	ordered_trie_root_with_encoder(receipts, |r, buf| r.encode_inner(buf, false))
	}

[emhane]

although, @garwahl, this is a method on Receipts. Ideally we need to implement it on an op receipts type. this issue is likely blocked by bigger sdk issue #7649. The problem by defining a trait inside of the reth-primitives crate with trait method root_slow, is that we won't be able to implement it in reth-optimism-consensus on an alloy type, and the end goal is to use alloy primitive data types throughout the codebase, injected via top level node builder.

[garwahl]

although, @garwahl, this is a method on Receipts. Ideally we need to implement it on an op receipts type. this issue is likely blocked by bigger sdk issue #7649. The problem by defining a trait inside of the reth-primitives crate with trait method root_slow, is that we won't be able to implement it in reth-optimism-consensus on an alloy type, and the end goal is to use alloy primitive data types throughout the codebase, injected via top level node builder.

To clarify, is there any benefit in continuing to extract things out into crates/optimism/* given you think ultimately these will move into alloy types? Am I understanding that correctly that the rollup specific code will be shifted into Alloy?

[emhane]

although, @garwahl, this is a method on Receipts. Ideally we need to implement it on an op receipts type. this issue is likely blocked by bigger sdk issue #7649. The problem by defining a trait inside of the reth-primitives crate with trait method root_slow, is that we won't be able to implement it in reth-optimism-consensus on an alloy type, and the end goal is to use alloy primitive data types throughout the codebase, injected via top level node builder.

To clarify, is there any benefit in continuing to extract things out into crates/optimism/* given you think ultimately these will move into alloy types? Am I understanding that correctly that the rollup specific code will be shifted into Alloy?

not quite, just that this pr will be blocked at some point. either the whole consensus auto seal code has to move into op crate + needs to be used via the op crate too, or we need to do smthg like #10997 and add a trait method receipt_root_slow to an alloy receipt trait. things that still need design.

[garwahl]

although, @garwahl, this is a method on Receipts. Ideally we need to implement it on an op receipts type. this issue is likely blocked by bigger sdk issue #7649. The problem by defining a trait inside of the reth-primitives crate with trait method root_slow, is that we won't be able to implement it in reth-optimism-consensus on an alloy type, and the end goal is to use alloy primitive data types throughout the codebase, injected via top level node builder.

To clarify, is there any benefit in continuing to extract things out into crates/optimism/* given you think ultimately these will move into alloy types? Am I understanding that correctly that the rollup specific code will be shifted into Alloy?

not quite, just that this pr will be blocked at some point. either the whole consensus auto seal code has to move into op crate + needs to be used via the op crate too, or we need to do smthg like #10997 and add a trait method receipt_root_slow to an alloy receipt trait. things that still need design.

No worries at all, let me know if I can lend a hand, would love to jump into the alloy repo as well if you see anything

[mattsse]

sorry for not reviewing this in time...

this has since been done and wasn't that easy