Video Transcript:
Today I will explain in more detail what optimistic rollups are, what is the idea of rollup superchains, and then I will propose an alternative to the current direction of development of superchains.
To prepare this program I have used my conversations with Grok 3, and specifically DeepSearch and Think modes. So far it works rather well. I am not, of course, just going to read you the results of my queries. All the information went through my own brain, challenged and refined. However, I could still get things wrong, and I would appreciate if you let me know if I did.
First of all, I need to tell you what kind of Superchains I will be talking about. I am referring to the OP Superchain, where OP stands for Optimism. Optimism is a software platform for optimistic rollups using Ethereum as parent blockchain, in other words, as Layer 1, or L1, with the optimistic rollups themselves being Layer 2, or L2. The most well known instances of Optimism “stack” are OP Mainnet, and Base (run by Coinbase). Optimistic rollups have their own transactions, their own blocks, and their own state. Sequencers are the computers in the rollup networks that collect transactions from the users, form blocks, and calculate state modifications and state commitments. These sequencers periodically generate and submit transactions to L1. These transactions serve main 2 functions. Firstly, they invoke a special smart contract on L1, which is associated with the rollup, and insert an L2 state commitment (Merkle tree hash) into a structure of such smart contract. These L2 state commitments, existing in L1 data structures, allow the merkle proofs about elements of L2 state to be verified within L1 transactions. The most often cited use case for this is a withdrawal of some tokens from L2 into L1. In that case, what is being proven is the disposal of the tokens in L2, so the corresponding number of tokens can be released on L1. The second function of such periodic L1 transactions generated and submitted by the L2 sequencers, are batched blocks of L2. Why is this needed? There are two situations in which those batched blocks are useful. First situation may arise in both optimistic and non-optimistic rollups. Imagine L2 sequencers keep collecting transactions, and form blocks, and generate and submit L1 transaction with state commitments, but fail to distribute the blocks that they form (effective keeping them secret, or unavailable), and the state changes. If there were no batched blocks published in L1, no one except the L2 sequencer operators would be able to generate any correct Merkle proofs about L2 state – because without knowing the blocks, they cannot re-execute transactions and recalculate the state and its Merkle tree. The second situation where batched blocks are useful, can only theoretically arise in optimistic rollups. In optimistic rollups, when we look at it from the perspective of L1 user, for example, wishing to prove something in L2 state, let’s say for withdrawal, we assume that any L2 state commitment, posted by L2 sequencer, is initially correct. It may not be correct, because the correctness is not explicitly proven. Instead, for any such L2 state commitment, it may not be used for proving anything important for a certain period of time (currently 7 days). It is assumed that if the L2 blocks were executed incorrectly, and the L2 state commitment published corresponds to the incorrectly computed state, then someone will find out and initiate a fault proof procedure (used to be called fraud proof, but now probably changed for legal reasons). During this procedure, which happens in the form of transactions in L1, information from the batched blocks is used to interactively prove (or not) that the fault has occurred. This proving interaction can go down to the level of individual EVM opcodes. For this reason, it is a requirement that EVM instruction set on L1 is a superset of EVM instruction set of the L2 rollup. There are a lot of questions about practicality of this approach, but I will not discuss them now.
From the discussion of when the blob data submitted from rollups are useful, we can make an observation that in non-optimistic rollups, these blobs serve only as a mitigation from potential data unavailability. If such mitigation is removed, we arrive at a subset of non-optimistic rollup design, called Validium. What the L2 optimistic sequencer is claimed to be able to prove interactively, L2 non-optimistic sequencer proves non-interactively. An added consequence of this is that non-optimistic rollups may use any execution environment, or virtual machine, even not related to EVM. An example is StarkNet, which uses Cairo VM.
Let us now come back to optimistic rollups. Let us look at smart contracts on L1 and related smart contracts on L2. For example, these could be representing a token with the same ticker, but existing these two separate blockchains. In order to make such tokens move from L1 to L2 and back, one may employ some mechanism for reliable message passing between these smart contracts, so that tokens locked or destroyed in one blockchain, can release or create the same amount of tokens in another blockchain. This message passing needs to be reliable in the sense that it is possible to know when the action that generated the message is final. For optimistic rollups, such message passing mechanism consists of two mechanisms: one for L1 to L2 message passing, another for L2 to L1 message passing. In order to enable L1 to L2 message passing, L2 sequencer includes L1 block hashes into L2 blocks. These L1 block hashes serve as anchors for proofs. In order to pass a message from L1 to L2, one needs to invoke a smart contract that emits log event. Log events are added to the receipt of the L1 transaction where this invocation happened. In turn, receipts of all transactions in L1 are placed into a Merkle tree and its root hash is inserted into the block header. Therefore, any emitted event can be proven using L1 block hash as an anchor. This proof would need to happen within a transaction on L2. The message is considered to be locally-safe at this point. If L1 block that was used in the proof reverts, then the corresponding L2 block will also revert. Therefore, locally-safe messages can be relied upon only within L1-L2 system itself, by passing messages further within the same L2, or back to L1. But if one wants to rely on this message to perform an action outside L1-L2 system, then one either takes on the risk of reversion, or has to wait for L1 finality.
Passing messages back from L2 to L1 is more complex, it takes longer, and it costs more, at least for the optimistic rollups. This is, of course, due to the fault proof challenge period. The message is initiated by a transaction on L2 which records it within a special smart contract. Then, once the next L2 state commitment is submitted to L1 rollup contract, this state commitment (or any subsequent commitment) can be used as an anchor to prove that the message on L2 has been registered. It is done by a transaction on L1, which submits the merkle proof. The merkle proof has to include the path to the L2 messaging contract and then to the specific storage item containing the message. At this point, the message is considered locally-safe, only for the communication with that particular L2 rollup that sent it. Which means that L1 smart contracts can react and send the message back to that L2 rollup, which would also be locally-safe. However, the delivery can only be considered final once the fault proof challenge period elapsed (7 days), and the block in which the L2 state root was first submitted, is finalised. Usually, finalisation happens much earlier.
I noted before that message sent from L2 to L1 is locally-safe pretty soon, but only for responding to the same L2. If the message has to be relayed to a different L2 via L1, this locally-safe property is not very helpful, since we assume that different optimistic rollups generally experience faults independently of each other.
To summarise, there are two techniques for sending the messages between the blockchains, one of which is L1 and another is L2. The first technique is based on event logs, and it requires the receiving blockchain to incorporate all the block hashes of the sending blockchain. The second technique is based on contract storage used as an outbox, and it requires the receiving blockchain to incorporate the state commitments of the sending chain regularly, but not necessarily for each state change. If we look at the requirements on the receiving end, it becomes clearer why event log based technique is used for sending messages from L1 to L2, and the outbox technique is used for sending messages from L2 to L1. It is assumed that L2 blockchain progresses quicker, so it is considered more practical for L2 to incorporate all block hashes of L1, and not the other way around. Even though the second technique, the outbox-based technique, relies on the state root and not on the block hash to prove the existence of a message, there are still log events generated on the sending blockchain. This is a subtle point is it is to do with the problem of incomprehensible state of Ethereum. Observing the storage of the outbox contract does not generally make it possible to figure out what messages we are looking at. They would some kind of key-value mapping, but the keys are all scrambled by Keccak hashing when Solidity compiler spreads the mapping across the storage. So one either has to use retracing, which is problematic, or emit log events, containing the necessary information to find the correct location in the outbox storage without retracing.
What is then the superchain and what does it do? On the surface the idea is simple, but there are important nuances that are somewhat subtle. Several optimistic rollups, all based on the Optimism platform, join a common system, called Superchain, with the goal of making it possible for smart contracts on these rollups to pass messages between each other without intermediation of L1, and therefore, quicker. One of the example use cases is the same – transfer of tokens by locking or destroying them on the source rollup, then delivering the message to the destination rollup and then unlocking or creating the same amount of tokens there.
How is this done? The second technique is used here, based on the outbox contract. And, as mentioned above, there are log events that are important for anyone who wants to prove the receipt of the message, because those log events contain location of the message within the scrambled storage of the outbox contract. Given the second technique is used, we can see two requirements. Firstly, all rollup blockchains participating in the superchain, must regularly incorporate the state commitments of the other blockchains, from where they wish to be able to receive messages. To achieve this, the sequencers of the participating rollups form a p2p mesh network, where they exchange their state commitments, and incorporate those into their blocks. The configuration of such mesh network is governed by multisig smart contracts. Secondly, in order for anyone to be able to prove the receipt of the messages, they need to have access to the stream of log events from the sending blockchains. For manual, ad-hoc operation, this can be arranged by running an extra node of the sending blockchain. But for automations, the component called OP Supervisor has been developed. In order to operate, it needs to be connected to the nodes of the sending L2 rollups, to listen for relevant log events, and storing them in the database.
Superchain documentation introduces the term “cross-safe” to describe the status of the messages that were passed between two different optimistic rollups participating in the superchain, such that their dependencies are committed to L1. Is is similar to locally-safe we discussed before, but a bit more confusing. In order for this message to be relied upon with finality, one has to watch out not only for the fault proofs on the receiving chain, but also on the sending chain, because either of them can invalidate the message. Then, of course, the receipt the of the message may trigger another message to the third L2 chain (token transfer accross the superchain, for example), and so on. If cross-safe messages are generally trusted, and one of the participant chains experiences a fault, and this fault is challenged successfully, it may be that effects can be felt on many participating chains. This is different from trusting locally-safe messages, where fault leads to problems only within one chain.
All in all, superchains do bring this new functionality of cross-chain communication without the involvement of L1. The cost of such communication is in fact smaller, because there is no need for L1 transactions at all. The latency is also reduced, but not because the whole challenge period of 7 days is cut out. If one still wants the same assurance brought by waiting for the complete 7 days period, one still needs to wait for it. Cross-safe messages are only as safe as locally-safe messages before.
Now lets quickly discuss the infrastructure. As we saw, L2 sequencers needs to be connected via a special p2p mesh network. Supervisors have to be connected to RPC nodes from all participating networks. More likely than not, this means that the participating rollups will end up never implementing decentralised sequencers. Unless this infrastructure is changed. And this where my proposal comes in. In one of my previous programmes, I mentioned the Portal Network project. It has subnets that create content addressable distributed storage for headers, blocks, state, receipts, and so on. In other words, they can be used to provide the kind of information the superchain sequencers require from other another, and the information the Supervisors require from the sequencers. The proposal is to enable Portal Network clients to simultaneously participate in the subnets for multiple blockchains, in our example, in the subnets for all Superchain participants. I did not go into the details of such design though. Because I think it is unlikely that such design will ever be required.
Original video on the Akexey Akunov Monoblunt channel on Telegram: https://t.me/monoblunt/132
Original Video Transcript on the Akexey Akunov Monoblunt channel on Telegram: https://t.me/monoblunt/133
