Discussion topic for EIP-8333
Update Log
- 2026-07-06: initial draft
External Reviews
None as of 2026-07-13.
Outstanding Issues
None as of 2026-07-13.
2 Likes
Not against this, and it would be nice to clean this up. But two remarks:
- We are looking at implementing decoupled consensus (hopefully in I* subject to R&D, governance etc!) which would replace Casper FFG and make this moot. The work required should be considered in view of that.
- It marginally increases expected time to finality for a transaction at a time when we’re looking to reduce it. Granted not by a significant amount, but still a step the wrong way.
3 Likes
The problem with 2 is not the time to finality but which transactions are finalized. Part of the justification of the EIP is that the current checkpoint misleads finality. But actually after gloas, voting on the CL root for slot 64, epoch 2, finalizes every transaction included in epoch 1, and none from epoch 2.
However, with this change, the root that gets finalized is that of slot 63, and that cannot include the payload of 63, thus the transactions that are finalized are all during epoch 1 except those included in the last payload.
This may be weird for some users.
Thanks for engaging.
- […] decoupled consensus
Somehow I would expect the concept of a checkpoint (a chain at a point in time) to remain even after decoupled consensus. Interested to read more on this.
- […] marginally increases expected time to finality for a transaction
Yes, this should be conceded. Practically, we get one additional payload finalized in the current paradigm. The practical tradeoff with this EIP that it takes the expensive epoch transition and first-block timing off the path for voting correctly for target. And that the conceptual simplification / coherence helps with reasoning about the protocol.
the transactions that are finalized are all during epoch 1 except those included in the last payload.
I would say that this is reasonable considering payload 63 is only confirmed / processed in the next epoch, block 64. Which is to say, what you say is the final payload of an epoch is the first payload of the next epoch from a chain inclusion perspective.
payload 63 is only confirmed / processed in the next epoch,
To be able to finalize with 63 as target, the chain would be voting down the children. Except the attestations at 63, every other attestation will be supporting 63/full and the finalization could take this into account to finalize the full checkpoint and not just the blockroot. The change to the spec is actually minimal and we even considered adding this to 7732 originally.
1 Like
In this case, we would get the payload for slot 63 finalized sometime around epoch 2 (with votes from slot 64 onward).
Fair. Looks like the changes proposed on EIP-8333 would even favour the unrealized just/finalized rules. And the votes on the first slot end up not suffering from late blocks as much as they do nowadays.
Assuming my understanding of the mechanisms at play is correct, I don’t see a downside to this approach.
A couple of things I’d consider looking at:
- How the Beacon API would need to adapt to the “consensus block finalized/execution payload not” vs “consensus block AND execution payload finalized“ scenario.
- Any interaction of these changes with Fast Confirmation Rules (@Mikhail can probably say more)
“consensus block finalized/execution payload not” vs “consensus block AND execution payload finalized“ scenario.
If we wanted to go this route we would just change how the beacon node finalizes a checkpoint and count attestations for full or empty at the last slot of the epoch, so with this EIP, most of the time if the payload of 31 was present, we will finalize everything in that epoch, including the last payload as well. It’s a simple modification to justification and finalization, but those are core functions that haven’t changed since Altair.