This bounty is no longer available
Web3 DAO | Optimism Logo

Data transport layer syncing with local L1 - reliability of discovering StartingL1BlockNumber - .queryFilter topic

Organization

Optimism

Deadline

N/A

Status

ENDED

INSTRUCTIONS

Describe the bug When booting, the DTL sometimes struggles to determine the correct StartingL1BlockNumber, due to problematic query filtering of this.state.contracts.Lib_AddressManager.queryFilter.

To Reproduce Steps to reproduce the behavior:

  1. Configure the DTL like this:
DATA_TRANSPORT_LAYER__SYNC_FROM_L1: 'true'
DATA_TRANSPORT_LAYER__SYNC_FROM_L2: 'false'
  1. Spin up the system: docker-compose up --renew-anon-volumes
  2. DTL quits with Unable to find appropriate L1 starting block number

Expected behavior Regardless of L1 data origin (local L1, Infura,...), the DTL, when configured to sync from L1, should reliably determine the starting L1 block based on the deployment of the AddressManager

Analysis The DTL is looking for topic 0x188466739ff00cc68bfb2367d23ae4b855264264fe1624caa8884399af23454c aka AddressSet(), which may or may not be present/available to this.state.contracts.Lib_AddressManager.queryFilter. A more reliable topic to filter for might be 0x8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e0 aka ownershipTransferred, which should be a good indicator of the first L1 block? In testing, filtering for ownershipTransferred rather than AddressSet has reduced Unable to find appropriate L1 starting block number errors.

Why does this matter Anything that depends on L1 data, including the Sequencer and Verifier, need the DTL to be able to discover the L1 starting block for correct subsequent function.