Enables snap sync with untrusted parties by supplying a data source for DepositNonces.
Prior to Canyon Hard Fork, Deposit Nonces were not cryptographically verified. This PR supplies the Deposit Nonce data for most Superchain Registered Chains for the affected time period, and implements a correction function.
Why
We want Snap Sync to work without concern about trusting your peers. Today, a user could supply blocks with incorrect Deposit Nonces, and Snap Sync would not have a way of verifying. With this PR, nodes will be able to repair blocks with incorrect data, closing the attack vector.
How
Deposit Nonces for the applicable time ranges (Bedrock or Regolith to Canyon) were collected via a new Receipt Reference Tool in the Optimism Monorepo.
Each resulting dataset was saved as a gob, go binary format for data compression
All gobs are located in a data directory, which is compiled into the binary using //go:embed directive
Receipts which are going to be committed from snap sync are evaluated against the data, which is keyed by ChainID, and then by BlockNumber. The values in the data structure are only the Deposit Nonces for User Deposits in the block, in the order they appear.
If at any point the deposit nonces are not as expected, warnings are emitted to logs. More detailed activity is emitted to Trace Logs.
Testing
A unit test set is included to demonstrate that Nonces are Corrected when they are wrong.
I also Snap Synced Goerli with this code (a version with louder logs), and observed that over the range of blocks, Deposit Nonces were all checked.
Extending
This PR includes the required data for [OP, Base, Lyra, Mode, Orderly, Zora] Mainnet, as well as OP Goerli. To extend this correction to more chains, all that is required is that a new gob be checked into the data directory.
The file format created by the receipt reference tool should be used, as each gob is prefixed by its chainID, which is used to only load required files, keeping memory low.
What
Enables snap sync with untrusted parties by supplying a data source for DepositNonces.
Prior to Canyon Hard Fork, Deposit Nonces were not cryptographically verified. This PR supplies the Deposit Nonce data for most Superchain Registered Chains for the affected time period, and implements a correction function.
Why
We want Snap Sync to work without concern about trusting your peers. Today, a user could supply blocks with incorrect Deposit Nonces, and Snap Sync would not have a way of verifying. With this PR, nodes will be able to repair blocks with incorrect data, closing the attack vector.
How
gob, go binary format for data compression//go:embeddirectiveIf at any point the deposit nonces are not as expected, warnings are emitted to logs. More detailed activity is emitted to Trace Logs.
Testing
A unit test set is included to demonstrate that Nonces are Corrected when they are wrong.
I also Snap Synced Goerli with this code (a version with louder logs), and observed that over the range of blocks, Deposit Nonces were all checked.
Extending
This PR includes the required data for
[OP, Base, Lyra, Mode, Orderly, Zora] Mainnet, as well asOP Goerli. To extend this correction to more chains, all that is required is that a newgobbe checked into the data directory.The file format created by the receipt reference tool should be used, as each gob is prefixed by its chainID, which is used to only load required files, keeping memory low.