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

Author: DeGate.

Since its inception in 2015, Ethereum has rapidly grown to become the most active and busy blockchain. Whether measured by the richness of applications, the scale of on-chain assets, or indicators such as transaction volume and security, Ethereum is the undisputed king of public chains today. However, with the rapid development of the Ethereum ecosystem, especially the explosive growth of DeFi, the originally designed throughput has proven to be severely inadequate. According to daily transaction data from etherscan.io, the current Ethereum TPS is around 17 (the high proportion of contract operations has significantly lowered this value), leading to gas fees often reaching tens or even hundreds of dollars and extremely long transaction wait times, which are the main reasons limiting the further flourishing of the Ethereum ecosystem and its entry into the mainstream world.

For a long time, the entire Ethereum community has been working to solve the issues of throughput and high transaction fees. One of the main solutions is Ethereum 2.0, which is expected to significantly increase the number of transactions per second and is set to be released as early as the end of 2021. Proposals like EIP-1559 aim to adjust the transaction fee charging mechanism to indirectly reduce gas costs.

Meanwhile, a question has arisen: is it really necessary to process all transactions on the main chain?

Introduction to Layer 2

Transferring transactions that should be processed on the Ethereum main chain, or Layer 1 (L1), to Layer 2 (L2) for processing, and then returning the results from L2 to L1 for confirmation, is what we refer to as Ethereum Layer 2. The theoretical TPS of L2 reaches 2000-4000, surpassing Visa's processing capacity of 1700 transactions per second. Therefore, many believe that L2 solutions are key for Ethereum to win mainstream users.

Currently, the existing L2 solutions mainly include the following:

• Optimistic Rollups: Data on-chain, fraud proofs. Application teams include Optimism, Offchain Labs Arbitrum rollup, Fuel Network;

• ZK Rollups: Data on-chain, zero-knowledge proofs. Application teams include Loopring, Starkware, Matter Labs zkSync, Aztec 2.0;

• Validium: Data off-chain storage, zero-knowledge proofs. Application teams include Starkware, Matter Labs zkPorter;

• Plasma: Data off-chain storage, fraud proofs. Application teams include OMG Network, Matic Network, Gazelle, Leap DAO;

• State Channels: Application teams include Connext, Raiden, Perun.

It is important to note that sidechain solutions do not inherit the consensus security of L1, so we do not consider sidechains to be part of L2 solutions.

Among the various solutions, Rollups are gradually gaining market recognition and becoming the most reliable scaling solution for Ethereum. On one hand, this solution directly inherits the consensus mechanism and security features of L1; on the other hand, it does not compromise the security and sovereignty of L1. In fact, Vitalik has openly stated that Rollup is the fastest implementable long-term scaling solution for Ethereum. The two types of Rollups, Optimistic Rollups and ZK Rollups, differ mainly in that they use fraud proofs and validity proofs, respectively, to ensure the correctness of the post-state root in batches.

For Rollups, a core issue is how to deposit assets from L1 to L2 and then withdraw them back to L1, and further, how to transfer assets from one L2 network to another. The infrastructure responsible for this is referred to as a bridge.

Native Bridge Implementation

We studied the principles of native bridge implementations for the current mainstream Rollup solutions and selected one representative from both Optimistic and zkSync solutions for comparison.

Arbitrum

The Arbitrum protocol utilizes its communication capabilities between L1 and L2 to theoretically transfer any form of Ethereum assets (including Ether, ERC20, ERC721, etc.) between L1 and L2 without trust. 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 is minted on L2 and deposited into a specified address. When transferring assets from L2 back to L1, the assets are destroyed on L2, and an equal amount of assets becomes available in the bridge contract on L1. Additionally, when redeeming assets from L2 to L1, there is a key difference: after the user sends the transaction, they must wait for the end of a challenge period before the transaction can be executed on L1. This is determined by the security model of Optimistic Rollup.

It is worth noting that the official recommendation is to use the "Retryable Tickets" mechanism for communication between L1 and L2. The operation of retryable tickets is roughly as follows: transactions initiated from L1 to L2 are first stored in an inbox, along with parameters such as calldata, callvalue, and gas info. If the transaction fails on its first execution, it is placed in L2's "retry buffer," meaning that for a period of time (usually a challenge period of about a week), anyone can redeem the ticket by re-executing the transaction. There is no time limit for retry transactions from L2 to L1; they can be executed at any point after the challenge period ends.

This mechanism is primarily designed to address scenarios where a user wishes to deposit a token from L1 to L2. They will first deposit these tokens into the L1 bridge contract while simultaneously minting an equal amount of tokens on L2. If the transaction on L1 is completed but the transaction on L2 fails due to insufficient gas fees, this creates a serious problem: the user's tokens have already been transferred out on L1, but they have not received tokens on L2; in fact, these tokens are locked in the L1 contract. Through the retryable tickets mechanism, the user (or anyone else) can re-execute the transaction within a week using sufficient gas fees and ultimately receive the tokens on L2.

Here are the basic steps for the Arbitrum native bridge:

L1 -> L2

1. The user initiates a Deposit transaction from L1.

2. The assets are deposited into the L1 contract, and the transaction is batched into the Inbox.

3. The transaction is executed on L2, minting assets to the specified address.

4. If the transaction fails, it is stored in L2's retry buffer, and the user can initiate a retry during the challenge period.

L2 -> L1

1. The user initiates a Withdraw transaction on L2.

2. The L2 chain will package the transactions collected over a certain period, generate a Merkle tree, and publish the root node as an OutboxEntry to L1's Outbox.

3. The user or anyone can perform a Merkle verification on the root node and transaction information.

4. After the challenge period ends, the user can complete the transaction on L1; 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, zkSync differs from Arbitrum mainly in that it uses validity proofs based on zero-knowledge proofs for transaction verification during Withdraw, rather than fraud proofs. The basic steps are:

L2 -> L1

1. The user initiates a Withdraw transaction on L2: the transaction data is encoded into a byte string, signed with the correct zkSync private key, and an Ethereum signature or EIP-1712 signature is generated for the transaction description, which is sent via the corresponding JSON RPC method.

2. Sending the transaction to L1: the transaction enters a block created by the zkSync operator and is published to the zkSync smart contract on L1.

3. Verifying the block: A few minutes later, a ZK proof confirming the correctness of the block will be generated, and this proof will be published to L1 through a verification transaction. The Withdraw transaction will be completed once this verification transaction is finished.

For more details, please refer to the official documentation.

It can be observed that in terms of exit time, the zk Rollup solution is significantly superior to the Optimistic Rollup solution. However, since zk Rollup still needs time to achieve full compatibility with EVM, it is expected that Optimistic Rollup will remain the mainstream L2 solution in the early stages. Therefore, utilizing third-party bridges to address the long exit period of Optimistic Rollup to provide users with a better experience has become a goal for some teams.

DeGate Bridge Design Philosophy and Implementation Principles

The goal of DeGate Bridge is to help lower the migration threshold of Ethereum assets in the early stages of the Rollup ecosystem, facilitating the large-scale deployment of applications based on Ethereum Rollup's Layer 2 infrastructure. We believe that under the current infrastructure conditions, an excellent and sufficiently good liquidity solution needs to have:

First, the ability to automatically adjust the liquidity distribution across different layers through market mechanisms.
Second, a non-prepaid solution that maximizes capital efficiency with zero capital freeze.
Third, the lowest gas consumption and optimal user experience are also crucial.

DeGate Bridge implements a fast channel for cross-layer asset transfers based on optimized stablecoin AMM curves and trading markets. Due to the limitations of the oracle services providing L2 state, the initial phase of DeGate Bridge will be implemented through centralized custody of assets. Once mature oracle services appear on Ethereum L2, DeGate Bridge will transition to a decentralized approach for asset bridging.

For detailed design of DeGate Bridge, please refer to the article: Cross-Rollup Liquidity Solutions Based on Low Slippage AMM Curves.

Bridge Solution Comparison

In this section, we will conduct practical tests on the native bridges that are already live on production or test networks and the DeGate Bridge, focusing on the following indicators:

• Gas fees for bridging;

• Timeliness of bridging;

• Operational complexity;

We will use ERC20 tokens instead of ETH in our tests (ETH does not require approval and has lower fees), and we will fit the fees based on an ETH price of $4000 and a gas price of 100 Gwei.

The final comparison results are as follows:

Withdraw fee calculation method description:

• Optimism (SNX): Withdrawal operations aggregate multiple transactions, calculating the total fee divided by the number of transactions.

• Arbitrum (Testnet): Layer 2 fees are not counted; only Layer 1 transaction gas consumption is calculated.

• zkSync: Fees are paid in various tokens on Layer 2, and the approximate cost is calculated based on Layer 1 arrival transactions.

• DeGate Bridge: Fees are paid in various tokens on Layer 2, and the approximate cost is calculated based on Layer 1 arrival transactions.

From the comparison, we can see:

• Timeliness: The exit time for Optimistic Rollup (including Optimism and Arbitrum) generally requires 2 days to 1 week, performing poorly, while DeGate Bridge performs well, approaching instant.

• Gas Fees: Optimism performs the worst, while DeGate Bridge has the least fee consumption, especially saving on approval fees.

• Operational Complexity: DeGate Bridge allows direct trading without requiring user approval, making it more user-friendly.

Outlook

We believe that the successive implementation of Layer 2 and Ethereum 2.0 will have the opportunity to become a secondary growth curve for Ethereum, evolving it into an economic bandwidth capable of supporting trillions of dollars. L2 Bridge will play an important role as one of the blockchain infrastructures in this process.