validation: autodetect, store and continuously validate Data Availability mode.

[geoknee]

The Data Availability mode (Ethereum vs non Ethereum) and provider (Celestia, etc) are important pieces of information to attach to each chain in the registry.

We are not able to infer the DA mode from rollup.json -- there are some environment variables for op-node and op-batcher which have useful information, but will not be able to reliably scrape these, either. We have a config field PlasmaConifg but it is not clear if this is actually the whole story with alt DA.

The remaining options are to:

• ask and trust the chain contributor to declare the information
• go on chain to detect and verify it.

We will go with the second option.

Definition of done:

• add-chain tooling uses an L1 RPC client to scrape the latest batcher transaction* for the chain being added. It decodes that and infers if the chain is using alt DA (i.e. the DA mode boolean)
  • IF the chain is using alt DA, we require them to have set an "ALT_DA_PROVIDER_BYTE`
• a new field is added to the superchain.ChainConfig type to record the boolean from the previous step, as well as the identifier byte if the DA mode is not ethereum. For now, the identifier byte can be stored in a field SelfCertifiedDAProviderByte to emphasise that it is not yet validated on chain.
• a validation check is added, which again scrapes the latest batcher transaction*, decodes the DA mode, and
  • for all chains checks it is consistent with the declared value now stored in the chain config
  • for standard chains (and standard candidate chains), ensures the DA mode is Ethereum
• This list of bytes is represented in the superchain-registry ethereum-optimism/specs#135 as an enum

---

 *Scraping latest batcher transaction
This is likely a useful reusable module for many validation checks, as well as the add-chain tooling. The idea is to do a binary search on the batcher signing account's nonce. This is a very quick way of finding the latest batcher transaction. The initial lookback window could be just the sequencing window.

---

EDIT: cutting some things from scope, these will be dealt with in a follow up ticket

[bitwiseguy]

@sebastianst as a first step, should we just check whether the BatchSubmitter address for a chain has sent a tx in the last SequencerWindow l1 blocks?

As an improvement to that check, how can we ensure the BatchSubmitter's tx actually posted l2 tx data and wasn't an unrelated tx coming from that address? How does the batch_inbox_address in the chain's config come into play?

Draft PR here for current implementation: #421

[sebastianst]

Yes, although we should already check that the batcher sends it's txs to the batcher inbox address.

To confirm that a batcher tx really contains valid data for that chain, you would need to have a synced node for that chain and import the batches. But then you'd effectively already run a node 😅 Given that this is just a one-off check at an arbitrary point in time, not sure if we'd get any more meaningful guarantees from this.

Checking for the sequence window is a good default, because a live chain would post with at most this duration between batcher txs.