magi icon indicating copy to clipboard operation
magi copied to clipboard

feat(driver): fast sync

Open ncitron opened this issue 1 year ago • 2 comments

Follow chain head using derived data, but perform the initial sync by reading the L2 output oracle on L1 to find the current head hash and use the engine's built in sync mechanism to sync to that head.

ncitron avatar Mar 08 '23 18:03 ncitron

I'd like to try this! Just a few questions:

  1. 0x47bBB9054823f27B9B6A71F5cb0eBc785692FF2E is the right L2 output oracle contract for eth-goerli, correct?
  2. how can I find the current head hash from the L2 output? I don't see this field in the OutputProposal struct

If I understood correctly, the main change then is in initializing the Driver: instead of calling db.read_head() we would get the HeadInfo from the L2OutputOracle contract. Does this make sense?

merklefruit avatar Apr 20 '23 23:04 merklefruit

One issue we have is that the L2 output root is the hash of a couple values, block hash included. Eventually we will be able to connect to the P2P network and be able to fetch and verify these ourselves, but maybe in the meantime its best just to have a sort of checkpoint sync where the user provides a checkpoint hash to use.

I don't think we will be able to start as normal with this block though here. Instead, we want to use the engine to just call a single forkchoice updated call on the engine API with no attributes supplied. From there, the execution client will try to sync to this block using its own p2p networking. We can check if the sync is done using the L2 rpc's eth_syncing method. After than, we need to then start the normal sync process, but at the latest finalized block it just synced to on its own.

To do this last restart part, we will need to use something similar to #82, so you may want to wait for that to be implemented so that you can reuse that code.

ncitron avatar Apr 21 '23 01:04 ncitron