Optimism finality

[panoel]

Optimism nodes run in one of two different modes:

1. sync from L1
2. sync from L2
   In mode 1), one can use the rollup_getInfo() RPC call to obtain the latest L2 block number and the related L1 block number. This allows one to observe the stream of finalized L1 blocks and when a particular L1 block is finalized, then the related L2 block(s) are, also, finalized.
   In mode 2), one needs to call getTotalElements on the ctc smart contract to request the latest finalized L2 block number.

The current implementation uses mode 1.

When the Bedrock release of Optimism comes out in Q1 2023, the rollup_getInfo() RPC call will no longer be available. Also, this issue sheds some light on why all current node providers sync from L2: (ethereum-optimism/optimism#3974)

The proposal is to scrap the current implementation and use the call to getTotalElements.

[panoel]

@hendrikhofstadt What do you think?

[hendrikhofstadt]

Good catch that they are deprecating the old method!

Does syncing from the L2 involve more trust into the sequencer or the node you are syncing from?
Is there a way to check that the latest finalized block queried using getTotalElements actually equals the one verified on the local node?

[panoel]

@hendrikhofstadt In that same abi there is a getLastBlockNumber query available, which returns the associated L1 block number. So, it is possible to record that L1 <=> L2 relationship and then see if that L1 block has been finalized.

[hendrikhofstadt]

Perfect, it would be even better if we could compare some kind of hash (check that the L2 has we've seen is actually committed on the L1) because here we probably assume that both nodes we're querying are consistent (i.e. L1 node we're querying and the L1 node connected to the L2 node).

[tbjump]

I read through the Optimism documentation and here is an attempt of a summary of the relevant pieces that are applicable to the Wormhole integration, as well as some options for doing the integration with different trade-offs:

Background on Optimism

Optimism is an Ethereum scalability project. Meaning that it is designed to run alongside Ethereum, called the L1, and has some native interactions with Ethereum.

The next big release will be “Bedrock”, announced for Q1 2023, which will change quite a few things.

L1 interactions

• All transaction data is submitted to L1
  • Pre-Bedrock this is in a smart contract, called CanonicalTransactionChain (CTC)
  • Post-Bedrock this will be just CALLDATA to an invalid address. Format: https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md#batch-submission-wire-format
• State commitments are also periodically published to L1 and apps running on the L1 can make use of them.
• Fraud proofs: Fraud proofs to challenge state commitments are currently not implemented. They may be implemented some time after the Bedrock release. But that's not directly relevant for the Wormhole integration, since Wormhole does not rely on state commitments.

Block production

• Users can submit their transactions to central infrastructure, called "sequencer", which will bundle transactions and post them to L1
• Or can submit directly to L1
• Pre-bedrock, block interval is sporadic
• Post bedrock, block interval will be 2 seconds. Block IDs will change slightly.

Full nodes

• Can run in one of two modes
  • "sync from L1", also called Verifiers
  • "sync from L2", also called Replicas
• Consists of two components:
  1. The Data Transport Layer (https://github.com/ethereum-optimism/optimism/tree/develop/packages/data-transport-layer), which fetches blocks either from the L1 blockchain or the L2 network
  2. The client, which is geth with a few modifications

Docs: https://community.optimism.io/docs/developers/build/run-a-node/#hardware-requirements

Trust model of Wormhole Integration

• In Wormhole the Guardians are trusted with running a full Optimism node and validating all Optimism transactions. Therefore, Wormhole does not need to make use of the state commitments and therefore does not rely on Fraud Proofs. It is therefore OK that the Bedrock milestone and Fraud Proofs have not been implemented yet. Even when Fraud Proofs are implemented in the future, Wormhole won’t need to wait the 7-day challenge period, making it much faster than other bridges to Optimism.
• The Optimism sequencer is not trusted by Wormhole, except for (consistency_level=200) messages.
  • It is not trusted for liveness, since users can also submit transactions directly to the L1 (at an additional gas cost), and
  • it is not trusted for safety either, since Guardians only ingest transactions that have been finalized on the L1 (except for consistency_level=200) and verify all transactions themselves.

Wormhole Integration

Senders of Wormhole messages should be able to specify whether messages should be relayed instantly (consistency_level=200), or wait for finality. But that feature doesn’t necessarily be supported on day one.

Option 1) Guardians sync from L1 until Optimism Bedrock release. After Bedrock, guardians sync from L2 and utilize a new API to get the finalization status from the Optimism node.

• Pro: Easiest to implement. Similar to other chain integrations.
• Con: Wormhole will not support instant messages (consistency_level=200) on Optimism until the Bedrock release. Instead, messages will take ~12 minutes. This wouldn’t affect the Token Bridge because it would be using only finalized messages, but could affect other integrators.
• For the new API in Bedrock c.f. https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md#output-method-api https://community.optimism.io/docs/developers/build/run-a-node/#source-of-synchronization. According to https://community.optimism.io/docs/developers/build/run-a-node/#source-of-synchronization, one will also be able to query for “finalized”
• The confirmations setting in the DTL should be kept at 35 (https://github.com/ethereum-optimism/optimism/blob/develop/packages/data-transport-layer/src/services/l1-ingestion/service.ts#L66), or we could suggest an upstream patch to change this polling the ETH RPC for “finalized” instead https://github.com/ethereum-optimism/optimism/blob/develop/packages/data-transport-layer/src/services/l1-ingestion/service.ts#L224
• Wormhole should provide public documentation for Guardians on how to configure their Optimism node.

Option 2) Guardians run two Optimism nodes: One syncing from L1 and one syncing from L2

• Pro: Wormhole can support instant messages (consistency_level=200).
• Con:
  • Double hardware overhead and marginal operational overhead for Guardians.
  • Optimism watcher code would need to be changed to consume from two different RPCs

Option 3) Guardians sync from L2 and separately check L1 for finality status.

• Pro:
  • Wormhole can support instant messages (consistency_level=200).
  • Guardians only need to run one node.
• Con:
  • Unsure how to implement. May require additional research and engineering work. The CTC Contract (https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L1/rollup/CanonicalTransactionChain.sol) has functions for retrieving the latest block number, but there doesn’t seem to be any function for retrieving block hashes.
  • Will be obsolete with Bedrock release.
• A first attempt at implementing this is done in https://github.com/wormhole-foundation/wormhole/pull/2037/files, but this uses the block height instead of the block hash, which isn’t secure.

[hendrikhofstadt]

Option 1 seems like the best choice. It appears to provide most flexibility and strongest safety guarantees in the long run. Also the short-term solution can be implemented with minimal changes to the existing codebase. It essentially looks like Option 3 but instead of reimplementing the logic in the guardian Wormhole relies on the reference implementation.
The fact that there will be no support for instant messages in the short-term seems like a sacrifice worth making.

Given Option 1 puts full trust into the Optimism node, we should make sure there is full coverage of their bug bounty program on the parts of the code we're exercising and it's sufficient in size.

[panoel]

Conclusion: Going with Option 1. The Guardians will sync from L1. This will be re-evaluated after Bedrock is released.

[panoel]

This discussion addresses issue #2163 and should be considered closed. But, since there is no way to close a discussion in GH, here we are.

[aadam-10]

now there is a way!