You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We currently do not have test coverage for syncing a verifier. This is a pretty big hole! To my knowledge, we would not be able to detect an error in the transaction batch submitter that causes verifiers to sync incorrectly. For instance, I don't think we'd detect it if the batch submitter submitted junk data for all transactions in our integration tests -- that's not good! Or if there was an error in the DTL or Geth, we similarly would not detect it!
Describe the solution you'd like
One quick way to solve this problem is by adding sync tests. These tests would behave in the following way:
Perform a few transactions on L2 with an L2 sequencer.
Wait until batches are submitted
Record the final state root in the sequencer.
Spin up a verifier which syncs the chain that was recently created
Check the final state root in the sequencer vs the verifier, ensure equality.
Adding these tests would allow us to catch a lot of common-sense errors in both the batch submitter and Geth's sync service. Long term we can have sync tests which sync mainnet & compare state roots, but even syncing a few blocks will catch a wide class of errors.
Note on adding a fork detection service
Note that this relates to a service that we should have but currently do not: the fork detection service. The fork detector service is a simple node script which takes a set of web3 URLs & repeatedly queries them to verify that they all have the same state root. It can then be queried to check the status of the network as: in consensus or forked. It should list out all of the head state state roots for all of the nodes that it is polling and if the network is forked it should be easy to spot which nodes are in the majority vs minority. Theoretically, this service can be used in the sync tests, but that might be overkill.
The text was updated successfully, but these errors were encountered:
Got a report of someone syncing, it stopping before it got to the tip, and then it was accepting transactions. Need to document / create a repro case for this.
Is your feature request related to a problem? Please describe.
We currently do not have test coverage for syncing a verifier. This is a pretty big hole! To my knowledge, we would not be able to detect an error in the transaction batch submitter that causes verifiers to sync incorrectly. For instance, I don't think we'd detect it if the batch submitter submitted junk data for all transactions in our integration tests -- that's not good! Or if there was an error in the DTL or Geth, we similarly would not detect it!
Describe the solution you'd like
One quick way to solve this problem is by adding sync tests. These tests would behave in the following way:
Adding these tests would allow us to catch a lot of common-sense errors in both the batch submitter and Geth's sync service. Long term we can have sync tests which sync mainnet & compare state roots, but even syncing a few blocks will catch a wide class of errors.
Note on adding a
fork detection service
Note that this relates to a service that we should have but currently do not: the
fork detection service
. The fork detector service is a simple node script which takes a set of web3 URLs & repeatedly queries them to verify that they all have the same state root. It can then be queried to check the status of the network as:in consensus
orforked
. It should list out all of the head state state roots for all of the nodes that it is polling and if the network isforked
it should be easy to spot which nodes are in the majority vs minority. Theoretically, this service can be used in the sync tests, but that might be overkill.The text was updated successfully, but these errors were encountered: