Derive rlp en-/decoding for Sealed<T>

[emhane]

Motivation

RLP encoding of Sealed<T>. Ref paradigmxyz/reth#11123.

Solution

Enables feature derive for alloy-rlp dep, to derive en-/decoding of Sealed<T>.

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[mattsse]

I don't think this is useful because the hash is usually never included in any rlp payload if it can be computed from the sealed element

[emhane]

valid, pls open an issue in reth then to remove it from SealedBlock and SealedHeader

[mattsse]

actually, I can see this being useful for decodeable where T: Sealable

[mattsse]

this is still problematic

we should treat this impl as a delegation:

https://github.com/paradigmxyz/reth/blob/093b1a16dfca2def7b1bf76cb12e554bbe7d967b/crates/primitives-traits/src/header/sealed.rs#L77-L100

if the seal is keccask(rlp) this would also allow us to specialize the decode impl but for this type we can't expect this to always be the case

[emhane]

this is still problematic

we should treat this impl as a delegation:

https://github.com/paradigmxyz/reth/blob/093b1a16dfca2def7b1bf76cb12e554bbe7d967b/crates/primitives-traits/src/header/sealed.rs#L77-L100

if the seal is keccask(rlp) this would also allow us to specialize the decode impl but for this type we can't expect this to always be the case

I see, the hash isn't rlp encoded in the buffer also, it's computed. to unblock this, we need to define a trait Seal, and an extension trait Keccak256Seal: Seal and update the sealed type to Sealed<T, S> + manual impl of rlp traits for Sealed<T, S: Keccak256Seal. proceed? I prefer this to cursing use of Sealed<T> to a wrapper type for rlp encoding impl, since most evm rollups will use the keccak256 seal.

[mattsse]

hmm, after thinking about this a bit, I actually leaning towards not using the struct Sealed in reth because this comes with a few limitations, like we can't implement foreign traits on Sealed and always need to push them in here if we need them.

from reth pov, I wonder if something like trait Sealed would be more useful

[emhane]

hmm, after thinking about this a bit, I actually leaning towards not using the struct Sealed in reth because this comes with a few limitations, like we can't implement foreign traits on Sealed and always need to push them in here if we need them.

from reth pov, I wonder if something like trait Sealed would be more useful

imo it's good to have as an inner type nonetheless, with the "ethereum autotraits" being implemented, like rlp. rather skip rlp impl than not linking alloy and reth via this type.