An analysis of Ethereum Layer 2 Asset Bridge Solutions: Arbitrum, zkSync, and DeGate Bridge

Summary: As the Ethereum Layer 2 ecosystem matures, how best to communicate between Layer(2) solutions and with Layer 1(L1) may become a core issue. We analyze three potential solutions, including the DeGate Bridge.

Since its birth in 2015, Ethereum has grown rapidly to become the most active blockchain. It is currently the undisputed king of public chains in terms of richness of applications, the scale of assets on the chain, transaction volume, security, and other indicators. With the rapid development of the Ethereum ecosystem, especially the burgeoning of DeFi, the originally designated throughput is seriously insufficient. According to the daily transaction data statistics of Etherscan.io , the current Ethereum transactions per second (TPS) is around 17 (the number is lower if the proportion of contract operations is higher). The gas fee of tens or even hundreds of dollars and the long waiting time for transactions have become the main factors that limit the further development of the Ethereum ecosystem and its entry into the mainstream consciousness.

The entire Ethereum community has long been grappling with throughput and high fees. One of the main solutions is Ethereum 2.0, which will dramatically increase the number of transactions per second and will be released as soon as the end of 2021. EIP-1559, for example, would adjust the method of calculating transaction fee billing method, which will, in turn, achieve the reduction of gas fees.

In the meantime, one obvious question arises: is it really necessary to have all transactions calculated and processed on the main chain?

Introduction to Layer2

In a class of solutions termed Ethereum Layer 2 (L2), transactions that should be processed on the main chain, or Layer 1 (L1), are transferred to Layer 2 (L2), and the results are then transferred from L2 back to L1 for confirmation. L2 has a theoretical TPS of 2000–4000, which already exceeds Visa’s processing power of 1700 transactions per second. As a result, many believe that the L2 solution is the key to winning over mainstream users to Ethereum.

The existing L2 solutions include the following:

• Optimistic Rollups: data on-chain and fraud proofs. Notable teams using this method include Optimism, Off-chain Labs Arbitrum rollup, Fuel Network;
• ZK Rollups: data on-chain and zero-knowledge proofs. Teams include Loopring, Starkware, Matter Labs zkSync, Aztec 2.0;
• Validium: data storage off-chain and zero-knowledge proofs. Teams include Starkware, Matter Labs zkPorter;
• Plasma: data storage off-chain and fraud proofs. Teams include OMG Network, Polygon(Matic), Gazelle, Leap DAO;
• State Channels: Teams using this method include Connext, Raiden, Perun.

It is important to note here that sidechain solutions are not considered to be L2 solutions as they do not inherit L1 consensus security.

Rollups are gaining market acceptance as the most reliable scaling solution for Ethereum, as they directly inherit the consensus mechanism and security features of L1, without compromising on security and sovereignty. Vitalik Buterin has been outspoken in saying that rollups will be one of the fastest long-term scaling solutions that can be implemented for Ethereum. The main difference between Optimistic Rollups and ZK rollups is that they use fraud proofs and validity proofs respectively to ensure the correctness of the post-state root in batches.

For the rollups solutions, how to transfer assets from L1 to L2 and back again, and how to extract them from one L2 network to another, is a core issue. The infrastructure responsible for this is termed the bridge.

Native Bridge Implementation

To understand the workings of the bridge, we examined the principles behind the native bridge implementations of the current mainstream rollup solutions and selected a representative example from each of the Optimistic and ZK solutions for comparison.

Arbitrum

The Arbitrum protocol takes advantage of its ability to communicate between L1 and L2 to theoretically transfer any form of Ethereum asset (including Ether, ERC20, ERC721, etc.) between L1 and L2 in a trustless way. When transferring assets from L1 to L2, the assets are deposited into an Arbitrum bridge contract on L1, after which an equal amount of assets are minted on L2 and deposited at the specified address. When transferring assets from L2 back to L1, the assets are destroyed on L2, after which an equal amount of assets become available in a bridge contract on L1. In addition, a key difference when redeeming assets from L2 to L1 is that after sending a transaction, the user must wait for the end of a challenge period before it can finally be executed on L1. This is determined by the Optimistic rollup security model.

It is worth noting that the official recommendation is to use the ‘Retryable Tickets’ mechanism for communication between L1 and L2. The Retryable Ticket works roughly as follows: a transaction initiated by L1 to L2 is first stored in the inbox with transaction parameters such as call data, call value, gas info, etc. In the unlikely event that the trade fails to execute for the first time, it is placed in L2’s “retry buffer”, which means that within a period (usually a period of about a week) anyone can redeem the ticket by executing the trade again. There is no time limit on retry transactions from L2 to L1, which can be done at any point after the end of the dispute period.

This mechanism is designed to deal with such a scenario where a user wishes to deposit a token from L1 to L2 by first depositing the token in the bridge contract on L1 and creating an equal number of tokens on L2. Suppose the transaction on L1 has been completed, but the transaction on L2 failed due to insufficient fees. This leads to a serious problem: the user’s token on L1 is transferred, but the token is not received on L2 and is effectively locked in the L1 contract. With the retryable ticket mechanism, the user (or anyone else), can re-execute the transaction with sufficient fees and eventually receive the token on L2 within a week.

The following are the basic steps of the Arbitrum native bridge:

L1 ->L2

1. A user initiates a Deposit transaction from L1
2. The assets are deposited into the L1 contract and the transaction is deposited in bulk in the Inbox
3. The transaction is executed in L2 and the cast assets are transferred to the specified address
4. If the transaction fails, it is deposited into the retry buffer of L2 and the user can initiate a retry within a dispute period

L2 -> L1

1. A user initiates a Withdraw transaction on L2
2. L2 chain packs the transactions collected within a certain period, generates a Merkle tree, and publishes the root node as an OutboxEntry in the Outbox of L1
3. Users or anyone can perform Merkle verification on the root node and transaction information
4. After the dispute period, the user can complete the transaction in L1, and if the transaction fails, the user can initiate a retry

For more details, please refer to the official documentation.

zkSync

In terms of bridge implementation, the main difference between zkSync and Arbitrum is that when withdrawing, the validation of the transaction is based on a zero-knowledge proof rather than fraud-proof, with the basic steps being:

L2 ?L1

1. User initiates a Withdraw transaction at L2: encodes the transaction data into a byte string, signs the byte string with the correct zkSync private key, generates an Ethereum signature for the transaction description or provides an EIP-1271 signature, and sends the transaction via the corresponding JSON RPC method
2. Send the transaction to L1: the transaction enters the block created by the zkSync operator and is published to the zkSync smart contract on L1
3. Validate the block: after a few minutes, a ZK proof proving the correctness of the block will be generated and published to L1 via a validation transaction until the validation transaction is completed and the Withdraw transaction is complete

For more details, please refer to the official documentation.

As you can see, the zk Rollup solution outperforms the Optimistic Rollup solution in terms of exit time. However, since it will take time for zk Rollup to achieve full EVM compatibility, it is expected that Optimistic Rollup will still become the mainstream L2 scheme in the near future. Therefore, some teams have set out to use a third-party bridge to solve the problem of long exit periods of Optimistic Rollup and bring a better user experience.

DeGate

The goal of DeGate Bridge is to help minimize the threshold of Ethereum asset migration in the early stages of the Rollup ecosystem, and to serve the large-scale implementation of applications based on Ethereum Rollup’s Layer 2 infrastructure. We believe that a good and sufficient liquidity solution at this stage of the infrastructure needs to have:

Firstly, the ability to automatically adjust the distribution of liquidity across the different layers through a market-based approach.

Secondly, a non-prepayment solution with zero capital freeze to maximize capital efficiency.

Thirdly, minimal Gas consumption and an optimal user experience are also essential.

The DeGate Bridge is based on and optimizes upon existing stablecoin AMM curves and trading markets to enable a fast track cross-layer asset transfer. Due to the shortcomings of current Oracles serving L2, the first phase of the DeGate Bridge will be implemented using centralized escrow. DeGate Bridge will move to a decentralized approach to bridging assets when a mature oracle service becomes available on Ethereum L2.

For more details on the design of the DeGate Bridge, please refer to the article: Cross-rollup liquidity solution based on low slippage AMM algorithm.

Bridge Solution Comparison

In this sub-section, we will conduct a real-world test of a Native Bridge and a DeGate Bridge on a live production or testnet, looking at the following metrics:

• The gas fees of getting on and off Bridges;
• The timeliness of getting on and off Bridges;
• Operational complexity;

In the test, we used ERC20 tokens instead of ETH (does not require approval and the fees are cheaper) and we assumed an ETH price of $4000 and a gas price of 100 Gwei throughout.

In our comparison, the results were as follows:

In this comparison, we note the following:

• Optimism (SNX): Withdrawal operations aggregate multiple transactions and are calculated by dividing the total fee by the number of transactions
• Arbitrum (Testnet): Layer 2 costs are not included. Only the Gas fee is calculated for the Layer 1 transactions
• zkSync: Fees are paid in multiple tokens on Layer 2 and the approximate cost is calculated from the transactions that arrive on Layer 1
• DeGate Bridge: Fees are paid in multiple tokens on Layer 2 and the approximate cost is calculated from the transactions that arrive on Layer 1

The comparison shows that:

• Effectiveness: Optimistic rollup (including Optimism and Arbitrum) generally takes between 2 days and 1 week to get off the bridge and performs poorly, while DeGate Bridge performs better and instantly;
• Gas fee: Optimism consumes the most gas fees, while DeGate Bridge consumes the least amount of fees, in particular, saving on approve fees;
• Operational complexity: DeGate Bridge is more user-friendly as it allows direct trading without the need for user to approve;

Conclusion and Outlook

In this comparison of the various Ethereum Layer 2 Bridge solutions, we have shown the viability, strengths, and weaknesses of the different solutions. We believe that Layer2 and Ethereum 2.0 will have the opportunity to be the second growth curve for Ethereum, allowing it to evolve into an economic “bandwidth” that can carry trillions of dollars in assets. The L2 Bridge will play an important role in this process as part of the emerging blockchain infrastructure, and DeGate will keep on building at the forefront of this important and exciting technological frontier.