primitives: use alloy Receipts

[tcoratger]

Ref #7238

[joshieDo]

this would break receipt pruning during staged sync

[joshieDo]

and the fact that all tests pass, probably means we should create a test to ensure this

[tcoratger]

so you mean that for this specific function we should keep Vec<Option<Receipt>> or does it affect also other methods? In summary you want to keep this behavior right? (Was thinking that this was equivalent to simply have no receipt)

If receipt is None, it has been pruned.

[tcoratger]

@joshieDo This means also that in ExecutionOutcome, we cannot use Receipts directly here no?

reth/crates/evm/execution-types/src/execution_outcome.rs

Line 44 in af5ae5a

pub receipts: Receipts,

Because with Receipts, we have a vec[vec[Receipt]] but here you mention the need for vec[vec[Option<Receipt>]] due to staged sync pruning flags no?

[joshieDo]

we should keep Vec<Option>

yes. im not sure on effects on other methods (cc @shekhirin )

But maybe we could just stick to the PR's goal of replacing the type and not touch anything else? Or is this somehow required?

[tcoratger]

Yes the initial goal of this PR was indeed to replace the Receipts type with its alloy equivalent but as discussed here alloy-rs/alloy#1247 (review), in alloy we no longer have an Option around the Receipt natively inside Receipts.

To try to do things little by little I just created another PR #12162 to minimize the changes with:

pub type Receipts = alloy_consensus::Receipts<Option<Receipt>>;

What I propose:

• We merge the first small PR that eliminates the implementation of Receipts in reth primitives: use alloy Receipts with Option #12162.
• We close this PR (where we are discussing right now) which will then become obsolete.
• We open other small issues to try to better prune and add unit tests according to consensus: add Receipts struct alloy-rs/alloy#1247 (review)
• Gradually we try to remove the Option from Receipts

cc @joshieDo @mattsse @shekhirin

[joshieDo]

I misread this as replacing Receipt and not Receipts, my bad.

Maybe we should tacke first the pruning rather the type replacement?

[tcoratger]

@joshieDo As you prefer, I think both ways are fine:

• We could maybe first merge primitives: use alloy Receipts with Option #12162 first so that we can play easier with the Option or not because the alloy Receipts<T> has the generic type T so that maybe we can replace step by step.
• Also it would maybe allow to directly focus on alloy and not cause additional regression on reth.
• But if you don't agree no worries, we can first fix the pruning and then merge primitives: use alloy Receipts #12059

[tcoratger]

@joshieDo @mattsse After rethinking about this, maybe this is simpler to merge #12162 first and then we can play with the new type at the required places, progressively, by doing, at choice:

• alloy::Receipts<Option<Receipt>>
• alloy::Receipts<Receipt>

depending on the locations.

In this way we could progress slowly, what do you think?

[tcoratger]

Closed with #12162