Interoperability in Ethereum Rollup Frameworks: Polygon CDK, OP-Stack, ZK-Stack

Key Takeaways

• This article discusses interoperability in Ethereum rollup frameworks and examines how major rollups interoperate with their L1, Ethereum, and their vision for interoperability for rollup frameworks.

• The rollup landscape is fragmented, with many projects launching on Ethereum and offering a rollup framework, each with its solution for cross-chain interoperability.

• To achieve seamless interoperability, shared resources are the direction to be pursued, such as shared sequencer/prover and shared standards.

• Interoperability within Ethereum rollup frameworks is an ongoing area of development and exploration.

1. The Rollup Landscape is Fragmented

Rollup projects are being launched on Ethereum, with many of them offering a Rollup Framework. This trend leads to a shared tech stack, enabling more customized and usable infrastructure along with widely used dev tools. Since OP-Stack launched its first Rollup framework, more than 10 projects have announced their rollups.

However, it can also lead to more fragmentation. Since there isn't a perfect solution for cross-chain interoperability, each Rollup framework is coming up with its solution, most of which are currently in the ideation stage.

To make interoperability more seamless between different Rollup frameworks, there needs to be a more thorough understanding not just of each framework's interoperability status and plan, but also of other projects' implementation and plan.

In this article, I will examine how major Rollups interoperate with their L1, Ethereum, and their vision for interoperability for Rollup frameworks.

The projects analyzed in this article are:

1. Polygon zkEVM (Polygon CDK) and its vision, Polygon 2.0

2. OP-Mainnet (OP-Stack) and its vision, Superchain

3. zkSync Era (ZK-Stack) and its vision, Hyperchain

2. Polygon zkEVM

Polygon zkEVM is a decentralized Ethereum Layer 2 solution that uses cryptographic zero-knowledge proofs to offer fast and secure off-chain transaction computation. Also known as a ZK-Rollup, it is designed to emulate the Ethereum Virtual Machine (EVM) and is compatible with existing Ethereum smart contracts.

Polygon zkEVM is the first zero-knowledge scaling solution that integrates smart contracts and developer tools, providing a Layer 2 scaling solution to Ethereum. It leverages zero-knowledge proofs to reduce transaction costs and increase scalability and transactions per second (TPS) for Ethereum. Polygon zkEVM is fully compatible with existing Ethereum smart contracts, developer tools, and wallets.

Due to its many advantages, including low cost, Ethereum security, and ZKP-powered scalability, Polygon zkEVM is gaining popularity.

2.1 Interoperability with L1 (Ethereum)

2.1.1 L2 → L1

1. To bridge assets from L2 to L1 Mainnet, users must first call the Bridge function of the PolygonZkEVMBridge.sol contract on Layer 2. If the Bridge request is valid, the contract appends an exit leaf to the L2 Exit Tree and computes the new L2 Exit Tree Root. The L2 Global Exit Root Manager (PolygonZkEVMGlobalExitRootL2.sol) then appends the new L2 Exit Tree Root to the Global Exit Tree and computes the Global Exit Root.

2. Next, the Aggregator generates a ZK-proof attesting to the computational integrity in the execution of sequenced batches (where one of these batches includes the user's bridging transaction). The Aggregator sends the ZK-proof and all relevant batch information that lead to the new L2 Exit Tree Root to the Consensus Contract (PolygonZkEVM.sol) for verification purposes. If valid, the Consensus Contract sends the new L2 Exit Tree Root to the Global Exit Root Manager SC (PolygonZkEVMGlobalExitRoot.sol) to update the Global Exit Tree.

3. Finally, to complete the bridging process on the L1 network, users must call the Claim function of the Bridge SC, providing a Merkle proof that the correct exit leaf was included in the computation of the Global Exit Root. The Bridge SC retrieves the Global Exit Root from the L1 Global Exit Root Manager SC and verifies the validity of the Merkle proof. If the proof is valid, the Bridge SC successfully completes the bridging process. Otherwise, the transaction is reverted.

2.1.2 L1 → L2

To bridge assets from L1 Mainnet to L2 (in this case, Polygon zkEVM), it goes through below process:

1. Invoke the Bridge function of the zkEVM Bridge SC PolygonZkEVMBridge.sol on the L1 network. If the Bridge request is valid, the Bridge SC appends an exit leaf to the L1 Exit Tree and computes the new L1 Exit Tree Root.

2. Append the new L1 Exit Tree Root to the Global Exit Tree and compute the Global Exit Root using the Global Exit Root Manager PolygonZkEVMGlobalExitRoot.sol.

3. Fetch the latest Global Exit Root from the Global Exit Root Manager using the Sequencer.

4. At the start of the transaction batch, store the Global Exit Root in special storage slots of the L2 Global Exit Root Manager SC PolygonZkEVMGlobalExitRootL2.sol, allowing L2 users to access it.

5. Call the Claim function of the Bridge SC as a user and provide a Merkle proof that the correct exit leaf was included and represented in the Global Exit Root to complete the bridging process.

6. Obtain the L2 Global Exit Root Manager SC's Global Exit Root and validate the user's Merkle proof of inclusion. If the Merkle proof is valid, the bridging process succeeds; otherwise, the transaction fails.

2.2 Vision: Polygon CDK and Polygon 2.0

Polygon CDK is an open-source framework designed to deploy Polygon zkEVM on Ethereum. It enables developers to create and customize application-specific chains on the Ethereum network with high modularity, scalability, liquidity, independent data availability, and interoperability. It also offers privacy options for creating private appchains, compliance-oriented features.

Polygon 2.0 is a new blueprint for the Polygon ecosystem that aims to reshape blockchain infrastructure by providing scalability, interoperability, and liquidity across multiple chains in its ecosystem. Its design principles include independent data availability, composable interoperability, near-instant finality, and unified liquidity. It aims to provide a high-performance Layer 2 scaling solution with enhanced scalability and a user-centric approach. Developers can customize chains according to their needs, such as the execution environment and gas tokens.

The Interop Layer in Polygon 2.0 is built upon the LxLy protocol design used by Polygon zkEVM rollup with implementing Message Queues. Each Polygon chain maintains an outbound message queue in a specific format included in ZK proofs generated by the chain. Once the ZK proof referring to a particular queue is verified on Ethereum, its recipient chain and address can safely consume any message from the queue.

An LX-LY bridge is a smart contract that facilitates asset transfers between two layers, LX and LY. The L1 and L2 contracts in zkEVM are identical except for their deployment location. The Bridge L1 Contract is on the Ethereum mainnet to manage asset transfers between rollups. At the same time, the Bridge L2 Contract handles asset transfers between the mainnet and the rollup(s) on a specific rollup.

Polygon 2.0 proposes the introduction of an Aggregator component to improve cross-chain transactions, making them faster and more efficient. The Aggregator operates between Polygon chains and Ethereum, accepting ZK proofs and Message Queues' representations and aggregating ZK proofs into a single proof submitted to Ethereum for verification. Once the Aggregator accepts ZK proofs, the recipient chains can start optimistically accepting inbound messages, making cross-chain interactions seamless.

3. OP-Mainnet

OP-Mainnet is a layer 2 scaling solution for Ethereum that reduces transaction fees and speeds up Ethereum transactions. It is built on top of the Ethereum blockchain and powered by a technology called Optimistic rollups, which bundle large amounts of transaction data into digestible batches. Transactions occur on OP-Mainnet, while the transaction data and output root are posted on Ethereum. This allows challengers to check for incorrect computations. However, note that the challenge system is currently centralized.

3.1 Interoperability with L1 (Ethereum)

3.1.1 L2 → L1

1. The L2CrossDomainMessenger function is used on L2 for cross-domain messaging. It takes three parameters, and _sendMessage is called by this function.

2. The _sendMessage function then calls initiateWithdrawal on L2ToL1MessagePasser, which uses the raw withdrawal fields to calculate the hash, mark it as a sent message in sentMessages, and emit the fields with the hash in a MessagePassed event.

3. Finally, when a new output is proposed by op-proposer, the output root is included in the block by op-node, committing to the state of the sentMessages mapping in the L2ToL1MessagePasser contract's storage on L2 and proving the presence of a pending withdrawal within it.

4. The output root is then stored to L2OutputOracle by op-proposer

3.1.2 L1 → L2

1. An L1 entity sends deposit transaction to L1CrossDomainMessenger using sendMessage function. This function accepts three parameters: target, message, and minGasLimit.

2. The L1CrossDomainMessenger calls its own _send function. It uses parameters: to, gasLimit, value, and data.

3. _sendMessage calls the Optimsimportal depositTransaction function.

4. The op-node component looks for TransactionDeposited events on L1. If it sees any such events, it parses them.

5. Next, op-node converts those TransactionDeposited events into deposit transactions.

6. In most cases, user deposit transactions call the relayMessage function of L2CrossDomainMessenger.

7. relayMessage runs a few sanity checks and then, if everything is good, calls the real target contract with the relayed calldata.

3.2 Vision: OP-Stack and Superchain

Optimism Superchain is a unified network of chains built using the OP Stack, which aims to address some of the most significant challenges facing blockchain networks, such as scalability and transaction fees, but without fracturing the ecosystem. The Superchain introduces a unified user experience, where Optimism and Base increasingly feel like one chain.

The goal of the Superchain is to address some of the most significant challenges facing blockchain networks, such as scalability and transaction fees, without fracturing the ecosystem.

4. zkSync Era

zkSync Era is a Layer-2 protocol that leverages advanced ZK technology to scale Ethereum in an efficient manner. Developed by Matter Labs, it is a versatile zk-rollup solution that strives for near-full EVM compatibility within its zk-friendly custom virtual machine.

As an upgraded version of zkSync, zkSync Era delivers the same Ethereum functionality while also offering faster and more cost-effective transactions. It supports a standard Web3 API and retains crucial EVM features such as smart contract composability, while also introducing new concepts like native account abstraction.

4.1 Interoperability with L1 (Ethereum)

4.1.1 L2 → L1

1. In L2 -> L1 communication, information is transferred without transaction execution on L1, unlike L1 -> L2 communication.

2. On the L2 side, a special zkEVM opcode saves the l2ToL1Log in the L2 block.

3. When sending an L2 block to L1, a validator sends all l2ToL1Logs (see ExecutorFacet). Later, users can read their l2ToL1logs on L1 and prove that they sent them.

4. On the L1 side, a Merkle root is calculated for each L2 block with its corresponding logs in the leaves. Therefore, a user can provide a Merkle proof for each l2ToL1Log.

5. The contract on L1 accepts all sent messages and requires that the preimage of value be provided if the message came from this system contract.

4.1.2 L1 → L2

1. Users can save transaction data in a queue on L1 by calling a function on the L1 contract.

2. Validators process the data on L2 and mark it as processed on the L1 priority queue. (This method is currently used for sending information from L1 to L2 or implementing multi-layer protocols.)

3. It is important to note that for every executed L1 -> L2 transaction, the system program sends an L2 -> L1 log.

4. Users can verify the execution status using proveL1ToL2TransactionStatus.

4.2 Vision: ZK-Stack and Hyperchain

The ZK Stack is a framework for creating ZK-powered L2s and L3s, or hyperchains, that offers sovereignty and seamless connectivity.

Matter Labs is developing the ZK Stack to provide developers with a permissive open-source license and scalability afforded by zero-knowledge proof technology. The creator of ZK Stack has full rights to customize every aspect of the chain.

The Hyperchain vision of the zkSync Era aims to create a hyperscalable unified liquidity network that prioritizes interoperability and composability. To remain trusted and fully interoperable, each Hyperchain must be powered by the same zkEVM engine available on the ZK Stack.

The Hyperbridge itself will consist of a set of smart contracts that verify Merkle proofs of transactions occurring on other chains. The original asset will be locked in the shared bridge contract on L1, which means liquidity is unified across the ecosystem. Hyperbridges will be technically similar to L2→L1 bridges, in that they will be asynchronous and not atomic.

5. Final Thoughts

5.1 Limitations

It is too early to discuss interoperability within the rollup frameworks, as it has not been explored well yet. Due to the urgency to improve the overall proof system, it is not a high priority at this time. The current limitations of the rollup framework are as follows:

• Operated by a single entity: All rollups are operated by a single sequencer and prover, although Polygon zkEVM has more decentralized features. This also means that interoperability between the chains is done by a single entity.

• No special interoperability solution within the same framework: For example, Base and OP-Mainnet are operated with the same framework but currently do not have an advantage in interoperability, whether from OP-Mainnet to Base or OP-Mainnet to Arbitrum One. This is similar for zkSync Era and Polygon zkEVM. However, since the contract structure is shared among those tech stacks, it will be more seamless to integrate with each other when the framework is more mature.

5.2 Future: Shared Resource

To achieve seamless interoperability, shared resources seem to be the direction to be pursued. If all these frameworks are present, there can't be a single standard like HTTP to conquer interoperability. I believe shared resources will make this ecosystem flourish.

• Shared sequencer/prover:

  • By utilizing a shared sequencer or prover, interoperability can become atomic. This means a single transaction in the source chain guarantees the execution of the transaction in the destination chain. This can make interoperability more seamless and secure in a decentralized sense.

• Shared standards:

  • The same framework shares almost the same bridge contract in each network. This can make integration among chains built upon the same framework easier. Also, there can be a shared proxy contract or a shared token standard for other rollup chains built with different frameworks to be interoperable.

• Third-party solutions:

  • Interoperability solutions within the rollup framework are and will be focused on safety. This means they can be slow but also rigid. Third-party solutions like Polymer, LayerZero, Axler, Hyperlane, etc. can provide more features and flexibility, while also providing fast execution.

5.3 Conclusion

In conclusion, interoperability within Ethereum rollup frameworks is an ongoing area of development and exploration. While there are some limitations to the current rollup frameworks, such as being operated by a single entity and lacking special interoperability solutions within the same framework, there are also potential solutions, such as shared resources and third-party solutions. As the framework continues to mature, interoperability will likely become more seamless and secure in a decentralized sense, allowing for a more flourishing ecosystem of rollup chains.

Thanks to Kate for designing the graphics for this article.