Explore cross-chain communication from the perspective of rollup

Author: Lisa A., Taiko Labs; translation: Jinse Finance xiaozou

This article will discuss different L2 cross-chain messaging methods from the perspective of rollup, focusing on cross-chain communication without trust. We'll briefly look at the direct state read approach, the light client approach, and proof-of-storage. We will also cover the proof aggregation mechanism, trusted third-party cross-chain message transmission and core ZK cross-chain solutions. Finally, let's look at how different L2s implement cross-chain messaging today.

1. Introduction to cross-chain messaging

For cross-chain communication, all parties (L2, L3, etc.) must have direct access to the latest Ethereum state root.

All deposit layers have a "built-in" cross-chain mechanism that can be used to access the L1 state root, which will be passed to L2 as a deposit message.

1**.1** Two types of access to state root

Type 1: Read state root directly - can be done via opcode or precompiled. However, it has not been implemented so far, so no proof is required.

Brecht Devos describes a possible way to read state directly in a research article: “…we can expose a precompiled contract that can directly call a smart contract on the target chain. This precompiled directly in The source chain inserts and executes another chain’s smart contract code. This ensures that smart contracts always have access to the latest available state in an efficient and easily provable manner.”

· Also described in Optimism's RFP "Remote Static Invocation Proof of Concept".

Type 2: Proof Generation - i.e. proving a statement about one blockchain on another blockchain.

"Cross-chain messaging with proofs" has two approaches:

· Trustless cross-chain communication — that is, no trusted third parties (e.g., using light clients or proof-of-storage). The trustless approach can be used both for third-party generation of proofs and for cross-chain communication participants to generate proofs themselves.

Proofs are shared between different rollups to ensure cross-chain operations. This approach, which is not discussed much in this article, is currently in the research and exploration phase and is not considered a potentially widely applicable solution.

1**.2** “Cross-Chain Messaging with Proof” method

1.2.1 Light client cross-chain messaging

Prove the data on chain B

Obtain Merkle proof data from the full node of chain B (archive archiving node if storage proof for certain historical states is required);

Send the block header and proof data corresponding to the chain B block containing the state we want to verify to the prover contract on chain A as calldata;

The prover contract calculates the block hash value based on the block header data, queries the light client smart contract on chain A (tracks the block hash value of chain B), and checks whether the hash value is valid;

Proof data is verified against the bytes32 state root in the block header.

1**.2.2** Proof of storage

Proof of Storage has two "workflow" options:

· Generate proof of storage → use on-chain

· Generate proof of storage → generate zk proof → use on the chain

It is also possible for an entity to package multiple collections of proofs into a single proof (both proof of storage and proof of zk). This is an optional optimization step and is not discussed yet.

Let's take a look at the three main stages of the proof of storage "workflow": generating proof of storage, generating zk proof, and using it on the chain.

(1) Generate Storage Proof

· Proof of storage allows us to use a confidential commitment to prove that certain information exists on the blockchain and is true;

Proof-of-storage has been a part of the crypto space since the advent of Merkle trees in 1979. However, vanilla proofs of storage are usually quite large. The modern innovation lies in combining proof-of-storage with provable computation to create succinct proofs that can be verified on-chain.

To generate a Proof of Storage, a specific block of data and its associated Merkle or Verkle path in a Merkle tree must be provided. The path consists of the sibling hashes needed to reconstruct the root hash using the same hashing algorithm.

To verify a Proof of Storage, the recipient can use the provided data and the Merkle or Verkle path to recompute the root hash. If the recomputed root hash matches a known root hash, the recipient can be confident that the data is authentic and part of the submitted dataset.

(2) Generate ZKP (Zero-Knowledge Proof)

However, an Ethereum-type Proof of Storage is about 4kb - rather large for posting the entire Proof of Storage on the target chain, as proof verification would be very expensive. Therefore, it is reasonable to use ZKP (for example, ZK-SNARK) for compression, which can make the proof smaller and cheaper to verify.

（3）A****roll ZKP

After earning ZKPs, users on the target chain can unroll their earned proofs (e.g., access historical state via block headers or block hashes).

Unroll can be done as follows:

On-chain accumulation: The entire process of reconstructing block headers from proofs is performed directly on the blockchain. Disadvantages: high gas fee, consumes computing resources; advantages: no additional proof time, low latency, because there is no need to generate proofs outside the blockchain.

On-chain compression: Remove redundant or unnecessary information from data, or use data structures optimized for space efficiency. Compressed data is sent to the blockchain and can be decompressed when needed. Cons: Compressing and decompressing data may mean additional computation, but this latency may be negligible. The compression algorithm used may have a negative impact on the security of the data; advantage: reduce data costs.

Off-chain storage: Store data off-chain, and put specific data blocks on-chain on demand. This is relevant for solutions that need to store large amounts of data for some reason (e.g. Ethereum archive nodes from the genesis block). Cons: Same as on-chain compression; Pros: Further reduce data costs.

1**.2.3** Trusted Third Party

A complete cross-chain solution should also involve cross-messaging solutions with trusted third parties (such as oracles, centralized bridges, etc.).

1**.2.4** “Universal” Proof System

In the case of a shared proof-of-aggregation platform mechanism, messaging can be speeded up by receiving block hashes that are settled within the aggregation platform, and the settlement here will also handle messaging (but if there is a problem with the aggregation platform what to do?).

1**.2.5 Some unknown issues of ZK****cross-chain messaging**

Is cross-chain messaging feasible without a trusted third party (which can be a single entity or multiple entities)? What is an efficient mechanism for cross-chain message passing? In general, for Ethereum L2 (with direct access to block hashes of L1) and Ethereum itself, if one chain can run a light client etc. , which is sufficient for trustless cross-chain messaging.

Is the ZK circuit used for cross-chain proof generation properly scaled? In some cases, especially when the consensus layer (which needs to be verified for cross-chain operations) is very large, the circuit used for ZK cross-chain message passing can be orders of magnitude larger than rollup and on-chain storage, and the computational overhead is also very large. big. Presumably this problem can be overcome with a more centralized approach.

2**、Example of cross-chain messaging solution**

· Su****ccinct Labs uses a light client to verify the consensus from the source chain to the target chain consensus layer. The idea is that there exists a light client protocol to ensure that nodes can synchronize the block headers of the final blockchain state. ZKP is used to generate consensus proofs.

· La****grange Labs builds a non-interactive cross-chain state proof. Lagrange proves that the network is responsible for creating the state root. Each Lagrange node contains a portion of a shard's private key, which attests to the state of a particular chain. Each state root is a threshold signed Verkle root that can be used to attest to the state of a particular chain at a particular time. The state root is completely general and can be used in a state proof to prove the current state of any one contract or wallet in the chain.

· He****rodotus uses ZKP proof of storage to provide smart contracts and access data on the chain of other Ethereum layers synchronously. For validation, it uses native L1<>L2 messaging to synchronize block hashes between Ethereum rollups.

=nil; Foundation (Mina, L1) allows smart contracts on Ethereum to verify the validity of the Mina state. Generate special-purpose proof-of-state, cheap to verify on Ethereum (local Mina proofs on Ethereum are expensive). Hypothetically (sometime in the future) applications can directly use Mina's proof generation tool to check the validity of cross-chain transactions. =nil; Foundation also has a Proof Market where users/projects can primarily buy/sell SNARK proofs that allow trustless data access.

Axiom: If Axiom has generated a ZKP for the ledger so far - it does not need to generate a ZKP for a specific block - it can pass this ZKP to the chain (as a relayer), or even Provides access to this ZKP.

3. L2 cross-chain messaging

*Disclaimer: Cross-chain messaging is still evolving for most of L2. All analysis below is based on open source information. That said, the solutions mentioned in the article may be in the exploration and testing stage, and rollup may eventually adopt other methods. *

**（1）**Taiko

Taiko stores block hashes for each chain. For each pair of chains, it deploys two smart contracts that store each other's hashes. In the example of L2←→L1, every time an L2 block is created on Taiko, the hash values of the peripheral blocks on L1 are stored in the TaikoL2 contract. Also in the case of L1←→L2, the operation mode is the same.

The latest known Merkle root stored on the target chain can be obtained by calling getCrossChainBlockHash(0) on the TaikoL1/TaikoL2 contract and get the value/message to verify. The sibling hash of the latest known Merkle root can be obtained by calling the eth_getProof request using a standard RPC on the "source chain".

Then, simply send them to be verified against the latest known block hashes stored in a list on the "target chain". The validator will take a value (a leaf on the Merkle tree) and sibling hashes to recompute the Merkle root and check that it matches the root stored in the target chain's list of block hashes.

**（2）**Starknet

Starknet uses Proof of Storage for trustless cross-chain messaging.

L2→L1 Messaging Protocol

· During the execution of a Starknet transaction, a contract on Starknet sends an L2→L1 message.

The message parameters (containing the receiver contract and related data on L1) are then appended to the relevant state update (main storage tree).

· L2 messages are stored on L1 of the smart contract.

· Issue an event on L1 (store message parameters).

Receiver addresses on L1 can access and use the message as part of an L1 transaction by re-providing message parameters.

· Cross-chain messages are stored in the trunk tree.

L2 → L1

L1 → L2

**（3）**Optimism

The communication between L1 and L2 is implemented by two special smart contracts called "messengers".

· For Optimism (L2) to Ethereum (L1) transactions, it is necessary to provide a Merkle proof of the message on L1 after the state root is written. After this proof transaction becomes part of the L1 chain, the error challenge period begins. After this waiting period, any user can "finalize" the transaction by triggering a second transaction on Ethereum, sending a message to the target L1 contract.

· Cross-chain messages are stored in the trunk tree.

（4）Ar****bitrum

Retryable tickets are the canonical method Arbitrum uses to create L1 to L2 messaging, i.e. L1 transactions that initialize messages to be executed on L2. A Retryable can be submitted on L1 for a fixed fee (depending only on its calldata size). The main state tree is used for cross-chain communication of custom data formats in smart contracts. Submitting a retryable ticket on L1 is separable/asynchronous from execution on L2. Retryables provide atomicity between cross-chain operations. If the L1 transaction request is submitted successfully (i.e. without rollback), then the Retryable execution on L2 has a strong guarantee that it will eventually succeed.

Arbitrum has two trunks: The Nitro chain is maintained in Ethereum's state tree format, a Merkle tree. The Assertion Tree stores the state of the Arbitrum chain confirmed on Ethereum via "assertion". The rules that advance the Arbitrum chain are deterministic. This means that given the state of a chain and some new input values, there is only one valid output. Therefore, if the proof tree contains multiple leaves, at most one leaf can represent a valid chain state.

Arbitrum's Outbox system allows any contract call from L2 to L1, that is, a message is initiated from L2 and finally executed on L1. L2 to L1 messages (aka "outgoing messages") have a lot in common with Arbitrum's L1 to L2 messages (Retryable), although there are some notable differences. Part of the L2 state of an Arbitrum chain—that is, the part attested in each RBlock—is the Merkle root of all L2 to L1 messages in the chain's history. After the proven RBlock is confirmed (usually about a week after the proof), the Merkle root is included in the Outbox contract and published to L1. The Outbox contract then allows users to execute their messages.

**（5）**Polygon zkEVM

· The Bridge SC of this zkEVM uses a special Merkle tree called Exit Tree for each network participating in communication or asset transaction.

It uses Merkle roots (in a separate state tree), a bridge architecture diagram can be found on github.

The deployment of zkEVM Bridge SC has made several changes based on the Ethereum 2.0 deposit contract. For example, it uses a specially designed append-only Merkle tree, but uses the same logic as the Ethereum 2.0 deposit contract. Other differences relate to base hashes and leaf nodes.

The main feature of the Polygon zkEVM Bridge smart contract is the use of the Exit Tree and the global Exit Tree, where the root of the global Exit Tree is the main source of the truth state. Therefore, L1 and L2 have two different global exit root managers, and Bridge SC has a separate logic.

（6）S****croll

· Bridge contracts deployed on Ethereum and Scroll allow users to pass arbitrary messages between L1 and L2. On top of this messaging protocol, we also built a trustless bridging protocol to allow users to bridge ERC-20 assets between L1 and L2. To send a message or funds from Ethereum to Scroll, a user calls the sendMessage transaction on the Bridge contract. Relayers will index this transaction on L1 and send it to the orderer for inclusion in L2 blocks. On the L2 bridge contract, the process of sending a message from Scroll back to Ethereum is similar.

· Cross-chain messages are stored in regular message queues. The orderer ingests cross-chain messages from this queue and adds them to the chain as regular transactions.

**（7）**zksync Era

*Disclaimer: The content of this section is only about zksync Era, which may be different from the cross-chain messaging on ZK Stack, which is a modular framework for building a sovereign ZK superchain. *

· Each transaction package has a single L2->L1 message.

· It is not possible to send transactions directly from L2 to L1. However, you can send messages of any length from zkSync Era to Ethereum, and then process the received messages on Ethereum using the L1 smart contract. zkSync Era has a request proof function that will return a boolean parameter indicating whether the message was successfully sent to L1. Retrieve the Merkle proof contained in the message by observing Ethereum or using the zks_getL2ToL1LogProof method of the zksync-web3 API.

· For L1→L2, the zkSync Era smart contract allows the sender to request a transaction on Ethereum L1 and pass the data to zkSync Era L2.

· Bridge contract:

4 Conclusion

Cross-chain communication is integral to "must-have" applications for blockchain mass adoption (e.g., the cross-chain social recovery wallet described in the Vitalik article). Most of the cross-chain solutions currently in use are designed for L1←→L2 to cover the withdrawal function. These solutions can be extended to more blockchains. But at the same time, more advanced cross-chain communication solutions can be implemented, such as "direct read state" without proof at all or "proof of storage" without trust. For most L2s, there is still room for improvement in cross-chain communication.