Interoperability: Catch-all Discussion + Q&A

[tynes]

This is meant to act as an open discussion board for native OP Stack interoperability. This includes both the protocol layer message passing as well as the Superchain ERC20 token specification. Over time we will aggregate common questions and answers into the spec documents to scale knowledge about the OP Stack.

Media

• Interop Design Overview
• Modular Interoperability at SevenX Research Day ETHDenver 2024

FAQ

Is it a requirement that both chains are on each others dependency set?

It is not a requirement that chains are in each others dependency set. It is permissionless to define a dependency on a chain, so chain operators will be able to choose which chains their chains depend on. Optimism Governance is the arbiter of the dependency set of OP Mainnet.

New chains can add existing chains to their dependency set without their permission. This is because the nature of defining a dependency is one way. It is impossible for a chain to know of all of the chains that depend on it.

How will fault proofs work?

Read this early design doc

What additional infra do chain operators need to run in order to be part of the interoperable set?

The superchain-backend microservice will be a requirement for running an OP Stack chain that has interop enabled. This service is responsible for validating all cross chain messages and will need to have an RPC configured for each chain in the dependency set. Over time, we would like to remove the requirement of configuring this service with RPCs and instead rely on the P2P network and cryptographic schemes for validating cross chain messages.

How can the latency be so low (<2 seconds)?

Cross chain message can be optimistically accepted. The fork choice rule enforces eventual consistency, meaning that if an invalid cross chain message is accepted, it will be reorganized out eventually. The fault proof guarantees that all of the cross chain messages are accounted for from the perspective of handling withdrawals through the bridge to L1.

What is the latency/security tradeoff?

If a sequencer does not want to trust another sequencer at all, they can choose to only accept executing messages where the initiating message has been finalized with L1 levels of security. This demonstrates the difference in latency vs speed. The L2 data must be submitted to L1 and then the L1 block containing the transaction with the L2 data must be finalized. It takes about 15 minutes for an L1 block to finalize and higher throughput OP Stack chains like Base and OP Mainnet submit a batch about every 5 minutes. This means that it could take about 20 minutes for an L2 transaction to be considered final and be able to be trustlessly consumed by another chain. At lower latencies, the sequencer accepting the executing message takes on some amount of equivocation risk. It could be possible to build a bonding system to add economic security to prevent equivocation but that is not in the scope of the first release.

See this dune dashboard to see how often OP Stack chains submit batches.

What is stopping a sequencer from censoring a cross chain message?

There is nothing stopping a sequencer from censoring a transaction when it is sent directly to the sequencer. This does not mean the network has no censorship resistance, users can always send a deposit transaction for censorship resistance as strong as L1 guarantees. The tradeoff here is the latency, instead of being confirmed in ~2 seconds, the transaction can be confirmed at the rate of L1 block production. It may be possible to adopt something like EIP-7547 in the future to enable low latency censorship resistance.

Are callback style transactions possible?

If two blocks are being built at the same time with shared knowledge of their contents, it is possible to build blocks where a transaction calls to another chain, does compute and then a transaction calls back with the results. This requires no protocol level changes, it just requires more sophisticated block builder infrastructure.

What is stopping a shared sequencer from including just the executing message and not the initiating message?

The protocol enforces the fact that all executing messages are valid. It does this by reorganizing out executing messages that have invalid initiating messages. Running software that does not enforce this would be non-standard behavior and would leave yourself at risk of accepting an invalid executing message and therefore running on a forked chain.

What is the trust/verification model? Do Sequencers that opt into this interop system have to trust each other fully?

Sequencers only have to trust each other if they are accepting executing messages where the initiating message is unsafe. This is because the sequencer's ability to equivocate on unsafe data, ie batch submit something different than what they gossip over the p2p network. Once data is submitted to L1, it is considered final relative to the L2 and therefore there is no longer an equivocation risk.

Is interop different between chains with non fungible blockspace?

Chains that have non fungible blockspace are chains that have different features - it could be that they use Plasma for data availability, a custom gas paying token or have a large execution gas limit. As long as the chain can be fault proven, it can work with native interoperability. At the application layer, it is important for chains to have legibility into the type of chain that the message originated from. This ensures that applications do not accept messages from chains they consider not secure enough. See #121 for additional thoughts.

When it comes to chains that have different gas limits that are interoperable, it creates a set of transactions that can execute on one chain but not the other. This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain. At 2024 usages levels, these sorts of transactions are very rare. In the future it may be the case that these transactions become more common, it will be up to the chain operators to ensure quality of service for their users.

[roberto-bayardo]

"...This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain."

Could we enforce a max gas limit per tx instead of per block for chains interested in scaling the block gas limit, but also interested in remaining interoperable?

[tynes]

Interesting idea - I don't see any truly inherent problems with allowing chains with different gas limits to be interoperable. There are other cases in which execution isn't fungible between chains, for example one chain may have state that another chain doesn't have. The free market should be able to solve the problem where a transaction consumes more than the gas limit on one chain but within the gas limit on another chain. Either the smaller chain increases its gas limit to compete for fees the tx provides or the tx specializes towards executing on the chain with the larger gas limit.

If we did enforce a max gas limit per tx it would ensure that all transactions can execute everywhere but 1) this limits possible future use cases where large amounts of gas are required and 2) still doesn't solve the state is only on one chain issue. I think that there is some inherent non fungibility of execution due to state and we should accept that gas limit is another variable between chains. As long as this non fungibility can be made legible at the application layer, we can ensure that applications can be built securely between non fungible block space.

[victoraranguren]

There are already interoperability solutions, e.g. my NFTs in OP can I send them to Polygon and/or Avalanche and vice versa?

[tynes]

This interoperability solution is specifically for OP Stack based chains. It will not work for Polygon or Avalanche or any other non OP Stack based chain.

[sandman2797]

GM @tynes

Thanks for the FAQs.

1. Regarding callback style transactions, say it is chain A -> B -> A. In this setup, rollup B's block cannot be marked safe unless rollup A's block is marked safe, but rollup A's block is dependent on B's block, which can't be marked safe. How is this handled practically?
2. If rollup nodes are the ones to mark a block as unsafe -> cross-unsafe -> safe -> finalized, are we trusting the rollup node to act in good faith? What if they don't act in good faith? Since you mentioned that this can be handled using fraud proofs, do rollup nodes have to put up a bond?

In the current setup (without interop specs), there are no trust assumptions from the rollup nodes, are there? They get a block full of transactions signed by the sequencers and all they have to do is execute them and publish the state root to Ethereum. In the new design, there seems to be some trust assumptions introduction if I'm understanding it correctly.

Thank you.

[tynes]

Hey @sandman2797. Good questions

1. In practice, it is possible to view cross chain messages as a directed graph. Progressing safety involves observing the entire graph. If you can observe all initiating messages and at least one of them is still unsafe, then you can progress the block to cross-unsafe.
2. The point of running a full node is to have the node protect you. It is in your incentive to run software that follows the rules of the protocol and does not lie to you. This same security model applies to any blockchain node and has been talked about since the early Bitcoin days. If your node is lying to you then you are using the wrong software and you should use the software that doesn't lie to you. Rollup nodes do not need to put down a bond as part of this. The bond has to do with withdrawals, anybody that makes a claim about the L2 state has to put down a bond. This is a costly signal, its basically saying "trust me because I know I will lose this money if I am lying"

[kamescg]

There is a lot of commits to the interop feature branch.

Would be awesome to also have a small bullet point list of files that are worth diving into.

[tynes]

We are actively working on reducing the size of diffs when shipping features so its easy to understand directly what is going on. I recommend checking out contracts-bedrock/src/L2 for implementations of the predeploys mentioned in the spec for now.

[tynes]

Only EOA Invariant + EIP 3074

Edit: latest information can be found here

EIP 3074 is CFI for the Prague hardfork. This EIP renders the "only EOA" invariant impossible to enforce, meaning that it is no longer possible to statically analyze the transactions that call the CrossL2Inbox. To ensure that the block builder still has the ability to determine if the Identifier corresponds to the msg (serialized log), a new event must be added to the CrossL2Inbox that emits this information. To simplify the block builder implementation, the semantic is added such that transactions that make calls to CrossL2Inbox.executeMessage with an invalid Identifier/msg are allowed if the top level transaction reverts. This means that the call traces do not need to be inspected for reverting transactions as no logs are emitted for reverting transactions. The semantic now can be framed less about calls to the executeMessage function and more about the values that are emitted from the event as the source of truth.

This enables smart contract wallets or 4337 bundlers to submit executing messages which is a huge win for UX. It should now be possible to create a paymaster for sending particular types of executing messages.

This also increases the cost of a block builder and the architecture of the block builder needs to be resilient to denial of service. Previously, no execution was required to know if an executing message was invalid, it could be determined statically by simply observing the calldata. Now execution is required to determine if any transaction is valid. The particular denial of service that we want to avoid is forcing the block builder to do a lot of work to ultimately not be able to include a transaction. Block builders can likely find heuristics that eliminate these denial of service attacks while still processing all normal usage. We also want to avoid execution in the mempool. We could leverage the superchain-backend with a built in "forking execution" feature similar to foundry's EVM to be able to horizontally scale the validation of transactions, or we could save executing message validation until the blockbuilding step and "assume true" at the mempool.

[tynes]

See specs PR that addresses these concerns: #149

[tynes]

Some follow up design thoughts on how we can safely handle deposits while removing the only EOA invariant are here: ethereum-optimism/design-docs#13

[mrice32]

Is there more information about the superchain ERC20 specification?

Does this mean that the intention is to have canonical ERC20s be movable via burn-mint between superchains over this interop layer?

[tynes]

The superchain ERC20 standard is being iterated on in the following PR: #71

We would like to spike what it would look like to use xERC20 vs yet another standard that we create before moving forward with it.

[dmarzzz]

Where does the code for the superchain-backend live? A quick search on the feature branch linked above didn't yield any results.

[tynes]

A prototype can be found in ethereum-optimism/optimism#9612 with some additional work in ethereum-optimism/optimism#10044. Since #128 (comment) the superchain-backend requires execution for validity checking. This can be done with debug_traceCall or could also be built using the foundry forking EVM

[tynes]

See the design doc for the superchain backend here: ethereum-optimism/design-docs#9

[tynes]

The superchain backend is now called op-supervisor and is actively being developed

[maurelian]

Is it possible to assign varying degrees of safety requirements to chains in the dependency set?

Clearly there is good reason to limit the dependency set form which unsafe messages are accepted, but it seems reasonable that a chain might want to allow messages from any other OP chain once finalized.
Can a chain somehow reject messages from another chain even after that chains are finalized?

[tynes]

We purposefully do not add this complexity to the protocol itself and leave it to the block builder to develop a policy in which they are comfortable with. When accepting an executing message, there is inherent risk tied to the finality of the initiating message. There may be some chains that are known to have better finality properties than others (ie fast batch submission). It is up to the sequencer (who is the block builder) to choose when to include messages and they have the right to treat different chains differently.

This needs to be handled in a special case for deposit transactions that are executing messages, since those are force include. We will need special logic to handle those, likely the rule will be a sequencer window must pass on top of the initiating message for the deposited executing message to be considered valid, otherwise you could force reorgs or chain splits via deposits.

[gitpusha]

Hey everyone, looking forward to contribute here from Gelato's side. Would love to have further feedback sessions with your team here, given our long experience building on-chain systems that rely on Relayers or Keepers. We learnt many things along the way regarding efficiency and MEV protection.

For example, saw in the spec somewhere that Relayer permissioning should not be enabled and, instead, a fee to tx.origin should be paid as MEV to open up the Relayer role to anyone.

Problem with that is that this might lead to malicious sniping/frontrunning of legit Relayer txs. We had this issue with Connext early on, which lead to super high MEV costs for us that were paid in reverted txs and the frontrunner took the profit.

Also, I understand that currently the spec only allows for EOAs to execute the messages. I understand this has smth to do with static analysis of calldata. This is quite restrictive though and our current Relay system usually routes via Gelato smart contract middleware, to take care of things like our decentralized relayer consensus protocol (making sure Gelato nodes dont collide with each other on executions), but also about important oracle-like tasks, such as reporting a fair gas price and token conversion rate on-chain, for dealing with messages that pay the relayer synchronously for gas expenditure in tokens. Gelato's system passes this price info in calldata too, but it is ratified by a smart contract off-chain signature first.

This would not be an issue for our 1balance sponsoredCall, which uses Gelato 1Balance to handle all Relayer payments off-chain (super neat feature for multi-chain Relayer payment automation and efficiency btw).

Anyways, have you considered such more complex Relayer systems that involve synchronous on-chain relayer payments support by smart contract middleware intercepting the message execution?

[tynes]

Hey @gitpusha, thanks for checking out the spec. I would like to clarify that the "only EOA" invariant is being removed as the possible inclusion of 3074 removes the ability to enforce such an invariant. You can see an update here: #128 (comment). We can prioritize merging #149 and capture its considerations in a follow up task to ensure that up to date information is in the specs.

Anyways, have you considered such more complex Relayer systems that involve synchronous on-chain relayer payments support by smart contract middleware intercepting the message execution?

This sounds like your expertise, I am just interested in building simple yet powerful abstractions that can enable these more complex relayer systems :) Given the spec changes to remove the "only EOA" invariant, do you have any other considerations?

[tynes]

#149 has been merged so now the specs should be up to date with the removal of the "only EOA" invariant

[gitpusha]

Awesome, thx @tynes !

Given the spec changes to remove the "only EOA" invariant, do you have any other considerations?

A further consideration would be any opinions about Relayer payments or permissioning in your spec/code. I am not sure right now and dont have time to check, but I believe I saw somewhere that you were considering enforcing something there, or is all relayer payment handling left to the Relay system and not part of this spec?

[gitpusha]

Cant wait to slap Gelato Relay on top of this btw!

[tynes]

is all relayer payment handling left to the Relay system and not part of this spec?

This is the case, the lowest level abstractions are not opinionated and are also payable so that ether can be sent with the calls

[hamdiallam]

Suggestion: Expand the L1Block.sol predeploy to also emit an event with the updated values including the L2 block hash (previous block).

This way the predeploy can be the canonical method to permissionlessly consume the state of a remote chain without requiring a 3rdparty initiating message

[tynes]

Working on this diagram to visualize the flow of the system. The block builder and the sequencer can be the same entity but they do not need to be.

sequenceDiagram
    User->>Block Builder: Sends executing message
    Block Builder->>Superchain Backend: Checks validity of message
    Superchain Backend->>Block Builder: Yes is valid
    Block Builder->>Block Builder: Create block
    Block Builder->>Sequencer: Commit to this block
    Sequencer->>Ethereum: Publish Data

Loading

[ricott1]

Hello @tynes thanks for these FAQs, I have a couple questions:

1. About the new cross-unsafe label: If I understand correctly, now a block can be published to the DA layer but still considered cross-unsafe (and in particular not safe) if at least one message in the dependency graph has not been posted yet to the DA layer. This means that posting a block to the L1 is not enough for it to become safe. Is this correct?
2. About updates to fault proofs: the section in the specs is still WIP, but I have a question about a concrete example. Let's imagine again that a block is posted to the DA layer but is not safe yet because the block containing one of the initiating messages from another rollup has not been posted yet.
   1. How would you produce a fault proof for the block in case it contained an executing message without a corresponding initiating message (so that the executing message and the block would be invalid)? I imagine one could ask the sequencer to produce the proof that the initiating message was indeed emitted by pointing to the data posted by the source chain (a sort of multi-chain proof). Does this impose restrictions on how often chains have to post to the DA layer so that other chains can produce such proofs?
   2. Kinda of a follow-up: What happens if the block is still cross-unsafe after the challenge period has elapsed? Can this happen at all?

thanks!

[tynes]

Hey @ricott1, thanks for checking out the spec.

1. You are correct that posting the block data to the DA layer is no longer enough for the block to be considered safe if the block contains executing messages that are not also safe. Cycles can be detected and handled if two blocks depend on each other and can be marked safe at the same time.
2. Fault proofs are about invalidating claims made to the bridge about L2 state. There isn't a need to run the fault proof against arbitrary blocks. It would be wise to only make a claim about the L2 state based on safe data. Claims that made on L2 state that is not yet safe are subject to being fault proven out. A user that wants to withdrawal will make a claim to the bridge saying "I claim this is the L2 state at this height" and the bridge will consider that claim canonical if the fault proof cannot prove that it is not correct after the finalization period elapses. This is in contrast to a validity proof (zkp) where you upfront prove that the claim about the L2 state is correct.

[ricott1]

Thanks for your answer 🙏

With my second question I meant something different, I'll try to rephrase and split it into sub-questions.

1. Given that now the rollup data can be published to the DA layer without making it automatically safe (because as we agree you also need all the blocks in the dependency graph to be available), I assume that one could indeed try to post a fault proof for data that is only cross-unsafe as in my understanding there is no way to distinguish on-chain between cross-unsafe and safe data. Is this correct?
2. Can a block remain in the cross-unsafe state for the whole challenge period (regardless of its actual validity)? I think this can happen if other chains in the dependency graph don't post to the DA layer often enough. To avoid this kind of scenario, do you impose restrictions on how often chains have to post to the DA layer?
3. You further mention: "It would be wise to only make a claim about the L2 state based on safe data. Claims that made on L2 state that is not yet safe are subject to being fault proven out.". I agree, but what if, as in the example I was trying to give, a malicious sequencer actually posts an executing message without corresponding initiating message? This L2 state will never be labeled as safe as per assumption there is no corresponding initiating message. On the other hand, it should be deemed invalid, and in particular it should be possible to provide a fault proof of this.
   1. Is my understanding of this scenario correct?
   2. If so, how would such a proof work technically: Do you ask the sequencer to produce the proof that the initiating message was indeed emitted? If so, how do you distinguish the case 'the message has not been emitted' vs 'the source chain data is not available yet'?

[ricott1]

Hey @tynes, did you have time to go over these other questions?

[tynes]

1. The fault proof is able to distinguish on chain between cross-unsafe and safe because all of the proofs become coupled to one another. You could imagine running fault proofs in parallel for each chain in the transitive dependency set and using data that was produced by one as input to the others. If a single one is cross-unsafe, then someplace not all the data was published that it depends on.
2. The finality of blocks is different from finality of the bridge - they are decoupled processes. The bridge operates on claims about the L2 state. You can make any claim about any block height but the fault proof will disprove any data that has not been finalized due to the data not being fully available so that the execution can be recreated. Chains can govern their dependency sets however they want, but a slowly finalizing chain will make the entire transitive dependency set slow.
3. If the sequencer posts a block that contains an invalid executing message, the block is reorg'd out by the fork choice rule. Since you can make any claim about the L2 state from the pov of the bridge, its possible to claim that the reorg never happened, but the fault proof will be able to disprove that claim.
   ii. If the source chain data is not available yet, it is the same as the message has not yet been emitted

[tynes]

Given #128 (comment) and ethereum-optimism/design-docs#13, there is no longer a need for static analysis on the transactions that trigger executing messages. This means that the CrossL2Inbox no longer needs to be the entrypoint, it was previously required to be the entrypoint because of the static analysis requirement on the executing messages.

The following function proposed by @skeletor-spaceman may be useful for developers building applications on top of interop. We need to be mindful of feature bloat, but we could certainly add this function if it makes the lives of app devs easier.

function validateMessage(Identifier calldata _id, bytes calldata _message) external {
        if (_id.timestamp > block.timestamp) revert InvalidTimestamp();
        if (!IDependencySet(Predeploys.L1_BLOCK_ATTRIBUTES).isInDependencySet(_id.chainId)) {
            revert InvalidChainId();
        }

        emit ExecutingMessage(abi.encode(_id), _message);
    }

[tynes]

What if we modified the spec such that including an invalid executing message doesn't result in an entire block being reorg'd out but instead the transaction that triggered the executing message is mapped into a noop transaction? The exact semantics of a noop transaction need to be defined (they were explored in ethereum-optimism/design-docs#13). This would either require a diff to the EVM or some sort of magic by the L1 attributes transaction. The problem with the L1 attributes transaction approach is that it would be modifying the transaction based on execution that comes after it, so we would need to follow an approach where the L1 attributes transaction now includes information about the execution of the previous block.

The whole idea of mapping executing messages to noops if they are invalid is to derisk large reorgs. It may lighten the dos vector on the sequencer, but they would still need to double check the executing messages before including them because any reorg is a quality of service issue, even if its a relatively small one. It seems generally more simple to just call the entire block invalid when there is a single executing message that is invalid.