Cross-rollup Expansion Solution to achieve Mutual Communication between L2 projects

V God proposes a cross-rollup expansion solution to achieve mutual communication between L2 projects

Ethereum co-founder Vitalik Buterin proposed a specific type of cross-rollup expansion solution to cope with increasing transaction costs while creating a unified ecosystem.


This proposal outlines how two protocols using rollup can communicate with each other while maintaining interconnectivity and composability.

V God mutual communication between L2 projects

Rollup is an L2 expansion solution, essentially a smart contract network that processes and stores transaction data under the main chain.

However, there are many different rollup types, and each type uses unique smart contracts, such as “optimistic” and “zero-knowledge”.


Many DeFi projects have deployed L2 rollups

Although many DeFi projects have deployed L2 rollups, such as Loopring and Synthetix, different rollups mean that projects cannot directly communicate with each other on L2.


Buterin’s proposal assumes that one type of rollup can handle simple transactions, while the other type of rollup is fully supported by smart contracts. It has been proposed to use rollup to transfer between two protocols that support smart contracts.


To explain how this proposal works, Buterin provides an example of a hypothetical transaction intermediary he called “Ivan”-Ivan has a fully controlled account “IVAN_A” on rollup a, and a smart contract on rollup B some funds are deposited in “IVAN_B”.

Mutual communication between L2 projects

To ensure the security of future transactions, the smart contract will be programmed to accept a “memorandum”, which includes additional data sent to it by anyone.

The transaction creates a connection layer that will save deposits in all these separate contracts, allowing rollup a to be sent to rollup B through the connection layer.


Buterin believes that this behavior should work as follows:

“Alice sends a transaction to IVAN_A, which contains N tokens and a memo Alice_B. Ivan sends Trade_Value*(1-fee) tokens to Alice_B through Ivan_B.”

He added that the worst-case scenario is that Ivan did not send tokens to ALICE_B as expected.


When talking about the “worst case” that may occur using the proposed scheme, Buterin emphasized that Alice can still wait for the transaction confirmation on rollup A, find some alternative ways to obtain tokens on rollup B to pay for the fees, and then obtain funds on her own.


In response to this proposal, Alon Muroch pointed out that its working method is similar to the way banks clear transactions:


“It’s very interesting, just like the clearing of transactions between banks. There may be restrictions on allocating assets into separate “accounts” in batches. One solution might be to have a large pool at both ends and share them proportionally.”

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest

Leave a Comment

Your email address will not be published. Required fields are marked *