- Ethereum inventor Vitalik Buterin has proposed a cross-rollup solution which allows sending transactions between two rollups.
- The solution relies on an intermediary to allow sending transactions from A to B.
Ethereum inventor Vitalik Buterin has submitted a proposal that would allow communication between two protocols using second-layer scaling solutions known as rollups. Titled “Cross-rollup DEX with smart contracts only on the destination side” the proposal allows a user to send funds from one rollup to another in the event that only one of the two users has full smart contract support and the other can only use “simple transactions.”
According to Vitalik‘s own concept, rollups are a series of off-chain transactions that are aggregated into an Ethereum-compatible smart contract. This smart contract enables users to securely make transactions that are then aggregated into the main chain. However, the solution has complications.
Rollups have different types and can use unique smart contracts. For example, Optimistic Rollups (ORs) operate with a transaction aggregator that uses a small amount of information, others such as ZK-Rollups can operate under a zero-knowledge-proof scheme. Due to their characteristics, it is difficult for rollups to interact with each other.
How does Buterin’s solution work?
In his proposal, Buterin explains that one of the many implementations that his solution could have, in a decentralized exchange in which “Alice”, a user who wants to exchange coins using two different rollups, and Ivan, the intermediary, interact. Here, it is necessary for one of the two rollups to have a “memo field” or to allow the use of low denomination orders of the value sent in a transaction as a memo.
This intermediary must have funds in both rollups (A and B) smart contracts, therefore, the intermediary is called IVAN_A and IVAN_B. Alice will send funds from address (ALICE_A) to address IVAN_A using the first of the two second-layer solutions. In addition, rollup B must be able to follow Buterin’s proposed rule:
If anyone sends a transaction sending TRADE_VALUE coins to IVAN_A, containing an address DESTINATION as a memo, then after MIN_REDEMPTION_DELAY blocks they can send a transaction to IVAN_B containing a proof of the transfer, which queues a withdrawal of TRADE_VALUE coins to address DESTINATION.
The memos allow Alice to specify that she is the recipient of the funds that will come from IVAN_B to ALICE_B. This recipient will receive the funds after a specified period of time. Thus, transactions can be batched and indexed in such a way that they match the transactions made by rollup A. Buterin summarized the operation of his solution as follows:
Alice sends a transaction to IVAN_A with N coins and a memo ALICE_B. Ivan sends a transaction sending TRADE_VALUE * (1 – fee) coins through IVAN_B to ALICE_B.
Buterin explained that in a “worst-case scenario” the intermediary might not send the coins to ALICE_B’s address, but believes that the user can wait for rollup A to confirm the transaction to “find an alternative route” to send her funds to rollup B and “claim the funds herself.” Buterin concludes:
The main limitation of the scheme is that IVAN_B needs to hold a large amount of capital to ensure that all senders will be paid.