Rollup splits the Ethereum ecosystem, how do Vs, Matic, Celer, etc. want to solve it?

March will be the highlight of Rollup’s expansion plan. From the perspective of progress, the various Rollup plans are ready to go. Some plans have been confirmed to be launched in March, and the launch of the Rollup expansion plan will have a significant impact on the industry.

However, due to the difficulty of intercommunication between Rollups, this has caused the fragmentation of the Ethereum ecosystem, it is difficult to achieve synergy between different protocols, and the composability that is very important to DeFi will also be fragmented. Is there a way to solve this problem?

Today, I will talk about several solutions that want to solve the cross-Rollup interaction problem, and see how to connect different Rollup Layer2 expansion solutions to maintain the composability and synergy between the protocols.

1. Rollup is ready to go

We have already introduced the four main Rollup expansion solutions, Optimism, ZkSync, Arbitrum, and StarkEx. Here we will briefly describe them as a background.

Choice of different Rollup schemes and DeFi protocols

At present, the four main Rollup expansion plans have attracted a group of ecological users, including:

Optimism attracted the attention of Uniswap and Compound, and after the pre-launch of the main network, it received the in-depth participation of Synthetix, a synthetic asset trading platform.

Curve, StablePay, and GitCoin adopt or plan to adopt Matter Labs’ zkSync solution as expansion options.

Arbitrum, created by Offchain Labs, has several DeFi projects that have been tested or planned to use, including Bancor, Bounce, DODO, Maizi Wallet, Burgerswap, Hop, MCDEX, and Swapr.

On the StarkEx side, there is no shortage of comrades. The decentralized contract trading platform dYdX will use the Layer2 network supported by StarkEx, as well as applications such as Paraswap and DeversiFi, and will also use StarkEx’s solutions.

How are the rollup expansion plans progressing?

Optimism announced the completion of its Series A financing in February, led by Andreessen Horowitz (a16z), which will be launched on the mainnet in March.

Arbitrum was started by an academic research project, and when the plan entered the commercialization stage, it applied for a patent. The team recently stated that after obtaining the consent of Princeton University, considering that the project has entered the mature stage of the community, it will give up the patent. Arbitrum also announced that the mainnet is in the upcoming stage.

Matter Labs, the founding team of the zkSync project, also disclosed information about the A round of financing. “Union Square Ventures (USV) led the round. Previous investors Placeholder, 1kx and Dragonfly continued to participate in this round. In addition, there is also zkSync. Ecological partners of the company participated in the investment, including Aave, Balancer, 1inch, Curve, Binance, Coinbase Ventures, Huobi, Loopring, Argent, MYKEY, imToken, Flexa, MoonPay, ripio, ZKValidator, CoinGecko”. Matter Labs said that zkSync will support Turing’s complete smart contract (Solidity) this year.

2. Rollup leads to ecological fragmentation

Most DeFi protocols are created based on smart contracts. These smart contracts are deployed on Layer 1’s Ethereum and connect to their own Layer 2 network in their own way.

For users, deposit funds in smart contracts and start using these Layer 2 networks. Smart contracts will record all transaction changes. Users can use Layer 2 networks to improve efficiency and reduce costs.

But if Synthetix and Uniswap exist on different Layer 2 networks, they may be in separate islands, and how to interact will become a problem.

How to connect different expansion solutions to maintain the best-known composability and collaboration of the DeFi protocol?

In an online AMA of the Bihu community, Vitalik mentioned two problems that currently need to be solved in Layer 2 solutions such as Rollup:

Many applications in the Ethereum community like to call smart contracts, such as DeFi projects. However, the current ZK Rollup does not support smart contracts, and only supports simple applications such as issuing coins and trading coins. This is the first question. When we have Rollup that supports full EVM, I think more users will move to Rollup.

There are not many infrastructure ecosystems related to Rollup. For example, we have not resolved the issue of transactions between different Rollups. If I have some coins in ZKsync, how do I move the coins to Loopring? First, the coins need to be extracted from the second layer of ZKsync to the bottom layer of Ethereum, and then transferred to the second layer account of Loopring. If this is done, will the transaction fee be particularly high?

There are many user experience challenges (problems) on Ethereum now. But I think many of these problems will be resolved in 6 months.

So how to solve it?

3. Vitalik proposal: how to realize cross-Rollup transfer

A few days ago, Ethereum co-founder Vitalik Buterin proposed an idea to connect different second-layer scaling solutions so that they can “talk” to each other to maintain the composability and synergy of the DeFi protocol.

Suppose there are two Rollups: A and B. User Alice wants to exchange some tokens on Rollup A for other tokens on Rollup B. Suppose there are two situations:

Both Rollup A and Rollup B can support contracts

Only one Rollup supports smart contracts, and the other Rollup only supports simple transfers.

In the first case, the community also has a proposal called “Hop: Send Tokens Across Rollups”, the address is: across-rollups/8581.

Vitalik’s proposal addresses the second scenario, that is, if RollupA only supports simple transfer transactions, and Rollup B supports smart contracts.

V God proposed that there is a simple way to connect these isolated contract networks.

The basic scenario of cross-Rollup transfer

“Suppose there is a trading intermediary named Ivan (of course there are many intermediaries to choose from, here is just an example). Ivan has an account IVAN_A on Rollup A (he has full control of the account). Ivan also has some funds deposited on Rollup B In the smart contract IVAN_B.”

Imagine the following operations:

Alice initiates a transaction to the IVAN_A account on Rollup A and transfers it to the account on Rollup B: ALICE_B. (Alice transferred to IVAN on Rollup A)

What can Ivan do? He will send a transaction through the IVAN_B account, and send the number of tokens after deducting the handling fee to the ALICE_B account.

After the first step, the second step can be carried out immediately. If Ivan proves that the difference between the second transaction and the first transaction is very small, then you can even set rules in the contract to allow higher fees.

The “worst case” is that Ivan did not send tokens to ALICE_B as expected. In this case, Alice can wait for the transaction confirmation on Rollup A, and then obtain the tokens on Rollup B through other channels to pay for the cross-Rollup transfer fees, and then she can claim and obtain funds by herself.

According to V God’s explanation, user Alice can do it directly on Rollup B. Just let Rollup B obtain the corresponding hash record on L1 before the previous batch of Rollup records, and then Rollup B can record the Merkle branch, which can be verified in Rollup.

In layman’s terms, technical methods can ensure that after the user Alice confirms the transaction on Rollup A, he can safely receive the corresponding funds on Rollup B (after paying the handling fee), avoiding one or several transactions. There was a problem with the intermediary, which resulted in damage to the funds.

No matter who this transaction intermediary Ivan is and why others choose to transfer tokens to him, these can be ignored temporarily; the meaning here is that there is a connection layer that allows the funds deposited in various isolated Layer 2 smart contracts to be synchronized and realized The function of cross-Rollup transfer.

For specific implementation details, you may need to understand the rules of the contract IVAN_B on Rollup B. Follow the settings below (removed for ease of understanding):

If anyone initiates a transaction and sends a certain amount of Bitcoin to the account of IVAN_A (stored on Rollup A), the memo contains the information of the target address. Then, after a certain amount of time, they can send a transaction to the contract IVAN_B. The transaction contains a proof of the transfer, which can mention the corresponding amount of Bitcoin to the target address on Rollup B.

Withdrawal has to go through some delay (for example, 1 day) to ensure that the corresponding transfer batch and index can be recorded in the Layer 2 network of Rollup A.

When Ivan receives funds in IVAN_A, he can send the tokens to the target address by himself. He can send transactions through the IVAN_B contract.

In this case, Ivan acts as a settlement provider and can charge a certain transfer fee so that Rollup A, a Layer 2 network that only supports simple transfer transactions, and Rollup B, which can support smart contract transactions, can be connected. And through the transfer certificate, Merkle index and other methods, it is also ensured that the user’s assets will not encounter losses during the transfer process.

The settlement provider acts as a collaborative role for cross-Rollup transfers

Ivan also needs to conduct internal settlements, after all, it is possible to run out of funds on a certain Rollup. For example, the user has been transferring money through Rollup A to Rollup B, and needs to transfer Ivan’s reserve funds on Rollup B to the address specified by the user. At this time, transaction intermediaries such as Ivan need to conduct internal settlements. Therefore, the restriction of this proposal will require intermediaries such as Ivan to hold a large amount of funds in the account in order to serve user needs.

Let us give examples with fiat currency, which may be better understood. If you transfer from the ICBC to the CCB card, although the ATM display has changed immediately, the actual settlement process is carried out once a day. Only after ICBC settles the actual funds will the actual funds be transferred to CCB. More specifically, It is done between the settlement accounts of the central bank.

Similarly, initiating a transfer transaction from Rollup B, which supports smart contracts, to Rollup A, which only supports ordinary transfers, is a similar operation.

Alice sends tokens to the contract account IVAN_B, and attaches the target address;

After a certain period of time, Alice can retrieve the funds;

However, if the intermediate IVAN can provide proof to the smart contract IVAN_B, attach the transfer record on the chain and other information to prove that he has transferred the funds to Alice on Rollup A, then Alice can no longer retrieve the funds. At this time, the cross-Rollup transfer is complete.

At this point, we have roughly understood the principle of cross-Rollup transfer mentioned in the Vitalik proposal, and only need one of the Rollups to support smart contracts to achieve it. IVAN is mainly introduced as a middleman to support cross-Rollup transfer.

As for how to set limits, avoid insufficient funds and waste in the intermediate settlement layer, and how to set up the Memo for transfer, you can check Vitalik’s proposal: -with-smart-contracts-only-on-the-destination-side/8778.

Fourth, Hop’s cross-Rollup transfer scheme

In the above, we also mentioned another scenario: two Rollups, such as ZKSync and Optimism, both support smart contracts, so how to achieve cross-Rollup interaction?

Hop team member chris whinfrey posted a post on the ETH Research forum on January 24, introducing how Hop conducts decentralized token transfers across Rollup.

The content is as follows:

Hop protocol provides a trustless and scalable cross-Rollup communication bridge. Committed to:

Fast and easy cross-Rollup token transfer

Can quickly exit from Rollup

Finally realize the function of cross-Rollup contract call

From the perspective of the Hop team, they provide a wide range of solutions to solve the cross-Rollup composability problem, which is achieved through a two-pronged approach:

Create a cross-network bridge token, which can be quickly and economically moved from one Rollup to another Rollup, or created on Layer1 to support the collection of corresponding underlying assets.

Use an automated market maker (AMM) to trade between each bridge token on each Rollup and its corresponding token for dynamic pricing and rebalance the liquidity of the entire network.

In other words, with the help of an anchor token (such as Bridge), it can be deployed on multiple Rollups, and it can also be deployed on the Ethereum network of Layer 1 and support Layer 1 and Layer 2 of the Bridge token on Rollup 1: 1 Anchored exchange.

If a user wants to transfer 100 BTC from Rollup A to his or another person’s account on Rollup B, then the process is as follows:

First, on Rollup A, the 100 ETH will be exchanged for Bridge_A tokens through AMM, that is, bridge tokens;

After the transaction is confirmed, Bridge_B tokens will be exchanged for 100 ETH tokens on Rollup B through AMM, and then transferred to the corresponding address on Rollup B specified by the user;

Since Bridge_A and Bridge_B are the same tokens, they only serve as a bridge across Rollup, and their ratio is anchored at 1:1. If the value fluctuates, arbitrageurs will carry out risk-free arbitrage, moving bricks and moving the price difference.

Hop currently has a testnet online

5. Are there any other plans?

In addition to the above solutions, we also talked about the direction of Celer and Matic Network.

Celer’s Layer 2 solution: in-situ expansion

The domestic DeFi project Celer proposed a new idea, called “in-situ expansion”. In-situ means that the DeFi project can continue to be in Layer1, and there is no need to go to Layer2 to deploy a special version, and you can pass Celer’s, to achieve expansion.

According to the introduction of the Celer team, in this scenario, the user’s assets are stored on the Layer 2 chain (Celer starts from the Optimistic Rollup-based solution, and then expands and upgrades to support ZK Rollup), and then the user sends instructions to tell the protocol of its own Operational requirements, specify how much of your own funds and which DeFi protocols are deposited, such as Curve, AAVE, Compond and other DeFi protocols located on the Ethereum Layer 1 network.

In this way, Layer2 acts as a command agent, users can store assets + send instructions, and the specific business logic is still handed over to the DeFi protocol on Layer1 for execution. The commands of different users can interact with the Layer1 contract more economically by merging transactions.

The program is expected to go online in March.

Matic Network rebranding: Polygon

Polygon was originally called Matic Network, but it took another path and set the tone as a Layer 2 aggregator, which achieved expansion in two ways:

Rely on the Ethereum network, with the help of validators on the corresponding network, and support Matic Plasma, zkRollups, Optimistic Rollups, Validium and other solutions.

Establish your own sub-chain system and independent verification nodes, and be responsible for your own security. In this direction, the Matic PoS chain is currently online.

After the Matic Network upgrade, the plan goes further. In addition to relying on the existing ecosystem, it needs to build its own ecosystem independently, and it will take more efforts. According to statistics, there are currently more than 80 DApps deployed on Polygon, covering DeFi, NFT, games and other fields.

According to the current progress, the Matic Pos chain and Matic Plasma solutions have been launched, but zk Rollup and Optimistic Rollup are not currently supported. These solutions will be launched in the future. Due to space limitations, Polygon will not be expanded anymore. For Polygon link:

Six, summary

March will be very lively. The mainnets of Arbitrum and Optimism will be launched, marking that we are currently on the eve of the outbreak of Layer 2 solutions such as Rollup. The Layer2 solution’s competition for users will become a major motif in March and the first half of the year.

How can different Layer 2 (specifically Rollup) be compatible to avoid destroying the collaboration of DeFi? The several plans I have seen so far are actually crossing the river by feeling the stones. Vitalik’s proposal, the realization of Hop, and Celer’s creativity may be able to solve the problems in their respective ideas, but the implementation of DeFi call combination across Rollup is still a big problem ahead.

On the other hand, the recent deployment of protocols such as Sushi on multiple chains may indicate another possibility, similar to the one mentioned in the Hop plan. With the help of the AMM+ protocol’s own tokens, perhaps many DeFi The agreement will first try to open up the barriers between different Layer 2 networks and Layer 1 internally to form a closed loop.

Perhaps in the future, as more DeFi joins the ranks of Layer2, a broader DeFi aggregator giant will appear. It is just the beginning. Readers and friends may wish to think about it.

Author/ Translator: Jamie Kim
Bio: Jamie Kim is a technology journalist. Raised in Hong Kong and always vocal at heart. She aims to share her expertise with the readers at Kim is a Bitcoin maximalist who believes with unwavering conviction that Bitcoin is the only cryptocurrency – in fact, currency – worth caring about.