Support Execution Layer syncing #164
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mininny
force-pushed
the
feature/mininny/staged-sync
branch
from
a4af987
to
cfc21a0
Compare
mininny
force-pushed
the
feature/mininny/staged-sync
branch
from
cfc21a0
to
6148445
Compare
|
Resolved in previous PRs |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for execution layer syncing through the op-node. Instead of deriving every block through the op-node, EL sync allows the execution client to retrieve blocks from other P2P peers to speed up the process of syncing. This leverages the existing staged sync infrastructure and require very minimal diff on op-erigon compared to the upstream erigon.
Changes
Add bootnodes
Add OP bootnodes. See op-geth for existing set of bootnodes for reference.
Fixed an issue where NewPayload will return
VALIDwithout validatingWhen the op-erigon and op-node is performing execution-layer syncing, op-erigon performs existing p2p sync logic while op-node sends l2 payloads to drive EL sync. This NewPayload and ForkchoiceUpdated informs op-erigon where to begin syncing, and the response for these engine apis are used to determine whether the EL sync is complete.
When op-erigon is first initialized from genesis, it downloads the block headers from gensis to the latest chain head in order to retrieve ancestor data when it's not known. After downloading the block headers, because the amount of headers downloaded is too large, erigon skips validation of the downloaded blocks (see this commit). Instead, it just returns
VALIDas a response for the NewPayload, even though erigon client hasn't completely synced or validated the blocks.However, this VALID signal incorrectly informs op-node that the EL sync is complete. op-node then retrieves the current head of the op-erigon, which pretended to be the chain head, while there actually isn't any validated blocks.
In order to fix this, the engine server now attempts to validate the chain at the head block, and returns
SYNCINGif the block validation was skipped. The engine will returnVALIDonly after initial sync is complete and actually validated the chain.Update TTD calculation for bedrock
For OP-stack chains, we use bedrock activation number for op-stack for determining when TTD has been reached.
Tested on op-sepolia(about 3 hours for complete sync) and will be tested on mainnet as well.