Layer2 Interoperability: StarkEx Vs. Loopring Vs. Hermez Vs. Connext

With L2 scaling solutions such as Polygon and Arbitrum coming online, the Ethereum L2 ecosystem is growing much faster. At the same time, more and more DeFi protocols are announcing cooperation with L2 solutions to deploy or migrate their protocols to L2. Different DeFi protocols have different needs for expansion and may choose different L2 solutions. Therefore, it becomes a matter of how to interact between L1 and L2 or transfer funds efficiently between different L2s.

For example, if a user needs to transfer funds between dYdX and DeversiFi, both of which are based on L2, he/she needs to withdraw funds from dYdX to L1 and then deposit funds from L1 to DeversiFi. Thus, the user will have to pay gas fees twice and spend a lot of time waiting. For L2 solutions with fraud-proof, the withdrawal to L1 can even take days.

For this reason, it is necessary to achieve interoperability between L2s. StarkWare has introduced the concept of L2 interoperability, i.e., transferring funds between L2s with as little friction as possible on L1 during the transfer. Different L2 solutions have different interoperability methods. Below is a brief comparison between the interoperability methods of StarkEx, Loopring, Hermez, and Connext.

StarkEx

StarkEx defined a primitive called Conditional Transaction[a][b], where a transaction is validated or not depending on whether its preconditions for that transaction are met.

Conditional transactions use the Fact Registry contract to monitor on-chain events. An event must first be "registered" with the Fact Registry contract before a conditional transaction can be used. For example, if Alice transfers 1 ETH to Bob directly via Ethereum without registering the Fact Registry contract, there will be no on-chain event that can be used as a conditional transaction.

The Fact Registry contract has two functions, i.e., transfer() and isValid().

If Alice needs to transfer 1 ETH to Bob, she will send Bob's address as a parameter to the transfer() function, which then does two things. First, it transfers 1 ETH to Bob; second, it keeps a record of the transfer, for example, it saves information about the sender, the recipient, and the hash of the transfer amount.

The isValid() function accepts a hash as a parameter and returns True if the input hash is equal to a hash previously recorded in the Fact Registry contract so that the hash recorded in the contract can be treated as a "Fact", which means that an event has occurred. This process is often called "Fact Registration".

A signed on-chain event in a conditional transaction contains two fields (hashes): the address of the Fact Registry contract and the "Fact" that should be registered before the conditional transaction is executed.

The diagram above shows the workflow of conditional transactions in the Fact Registry contract. In StarkEx's zkRollup solution, if a conditional transaction is included in a batch of transactions, it will ensure that its associated Fact is registered, otherwise, the entire batch will be rolled back.

In L1/L2 interoperability, there are two use cases for conditional transactions.

StarkEx (L2) → Ethereum (L1) — Fast Withdrawal

There are two actors in this use case, where Alice needs to withdraw 1 ETH from L2 to L1 and the Liquidity Provider (LP) has a certain amount of funds on L1. First, Alice initiates a conditional transaction to LP, promising to pay 1 ETH on L2 to LP's address on the condition that LP pays 1 ETH on L1 to Alice's address. Then, Alice receives 1 ETH on L1 and the conditions of this conditional transaction are satisfied. At this point, LP sends this conditional transaction to the Operator on L2 and waits for it to be packaged into the next batch of proven transactions. After the proof of the conditional transaction is submitted to L1 for verification and approval, the LP's address in L2 will be increased by 1 ETH, which is the amount of money received from Alice. (For fast withdrawals in this way, Alice needs to pay a fee to LP.)

Since LP's funds on L1 continue to decrease and funds on L2 continue to increase when the withdrawal service is provided, LP needs to periodically withdraw funds from L2 to L1 to rebalance the funds.

StarkEx (L2) → StarkEx (L2)

Use case 2 is similar to use case 1, i.e., Alice initiates a signed conditional transaction to LP, promising to pay 1 ETH to LP's address on L2_1, conditional on LP paying 1 ETH to Alice's address on L2_2. (Alice and LP are also required to pay a fee and rebalance funds separately.)

Based on the above analysis, both systems that use proof of validity (zkRollup) and systems that use proof of fraud (Optimistic Rollup) can adopt the method of conditional transactions. Of course, there is a disadvantage in the funding efficiency of LPs using Optimistic Rollup compared to those using zkRollup, which has faster withdrawal confirmation.

Withdrawing funds from L2 to L1 in any L2 solutions requires finalizing the status update of L2, which includes the withdrawal itself. For proof-of-validity, users typically need to wait a minimum of 10 minutes. In a fraud-proof system, it may take several days. The use of conditional transaction-based fast withdrawals frees withdrawals from reliance on L2 status updates and enables the transfer of funds at the "blockchain-time" level.

StarkEx proposes conditional transactions to achieve L2 interoperability, and the idea is very similar to Rollup. That is, the multiple fees for each user's withdrawals are converted into a single fee for LPs to withdraw from L2 to L1 when rebalancing funds. Compared with the high gas fee, it is obviously more cost-effective for users to pay a small amount of fee to LPs.

Loopring

Loopring has proposed Ethport[c], a Bridge product across L1, L2 and CEX, by fusing components of its existing toolkit.

Regarding the interaction between L1 and L2, Loopring's solution is to batch multiple L1 transactions as a way to share the cost of L1 gas. Close to the above idea, Loopring also sets up the role of liquidity provider on L2. However, considering the funding efficiency of the liquidity provider, Loopring proposes the Single Phase Converter (SPC).

The single-phase converter uses the Flash Minting feature of L2[d]. That is, Flash Minting is used to mint all tokens that users want to buy so that all transactions can be completed on L2 (at the expected token conversion rate). Afterward, all the tokens sold by the users are withdrawn to L1, where token transactions are executed and users get the tokens that they actually want to buy (which have been previously distributed to them through Flash Minting). Finally, these tokens are repaid to Flash Minting.

This is an idealized situation. In reality, the token conversion rate may change and there is a possibility that the transaction on L1 may fail. This creates the risk of not being able to repay the Flash Minting, meaning that all previous transactions on L2 will be rolled back.

In view of this problem, Loopring then proposed the Double Phase Converter (DPC).

The double-phase converter divides the transaction into two phases. In the first phase, the converter collects all the users' funds in a Vault (for a specific token) and gives them a token indicating their share in the Vault, instead of converting the token directly. This is followed by a transaction on L1, which determines the conversion rate. In the second phase, the converted token can be distributed to all users proportionally, thus solving the problem of an unstable conversion rate.

In addition, the Bridge mechanism enables users to deposit funds in bulk into Loopring via smart contracts on L1, rather than joining the L2 network individually. This design brings together multiple deposit transactions into a single transaction, reducing gas spend. With the Bridge, centralized exchanges can also use the standard L1 infrastructure to support Loopring's L2 network.

Ethport, based on the above components, first uses the liquidity on L2 as much as possible in practice. If the converter is available, it is used to pool L1 transactions and reduce transaction costs. If the above conditions are not met then the Bridge mechanism is used.

Hermez

Hermez was introduced by the iden3 team and the proposed solution for L2 interaction is Massive Migrations[e].

The idea is that first, the smart contract responsible for making L1 fund transfers has an address on L2_1. When a cross-L2 transfer is needed, the user will transfer funds to that address. After that, the Hermez protocol will group and extract a batch of L2 transfers with the same L2_2 address, and call the standard Hermez function to withdraw the total amount of funds from this batch of L2 transfers to L1 and deposit it to L2_2.

The Hermez protocol includes the information needed to reconstruct the original L2_1 transfers on L2_2 and the corresponding account information when performing the aggregated withdrawal transactions described above. There is a coordinator role on L2_2 that handles the withdrawal transactions from L1 and decomposes the flow of funds from the transaction information before transferring to the L2_2 address that corresponds to the user's L2_1 address.

Connext

Connext is a state channel-based L2 scaling solution that supports fast transactions between EVM-compatible public chains and L2 systems. Earlier this year, Connext released version 0.1.0 of Vector, an instant cross-L2 transfer product designed to connect liquidity between L2 solutions and enable cross-L2 fund transfers. In March, Connext launched the beta version of xDai-Polygon Bridge, which allows users to use the state channel to transfer xDai to Dai on Polygon or Dai on Polygon to xDai using a state channel.

Connext enables cross-L2 fund transfers via a router[f]. The Connext router is actually a state channel node that automatically forwards transactions sent to it within the state channel. For cross-chain transactions, the router is equivalent to a liquidity provider by transferring funds to the user within the state channel on chainB in exchange for the user's funds on chainA, which is similar to the ideas of StarkEx and Loopring.

For example, if Alice wants to send 100 USDC from Polygon to Arbitrum, she needs to use a router to deposit 100 USDC into a state channel on Polygon. Alice then sends a transfer to that router within the state channel, provided that Alice receives the transfer in the corresponding state channel on Arbitrum, which relies on hashlock (Hashlock)[g]. These transfers are unlocked in an atomic manner, allowing for trust-free implementation. The router is able to earn the fee paid by Alice during the cross-L2 process.

However, cross-L2 solutions under the help of liquidity providers face the problem of funding efficiency. Connext proposes Virtual AMMs (Virtual AMMs) to solve this problem.

On Uniswap, the more unbalanced the conversion ratio of the pool, the greater the price difference. This also creates a consistently growing arbitrage opportunity. Virtual AMMs draw on the core concept of Uniswap to price fund transfers between L2s.

Consider a situation where at some point the amount of ETH in the Arbitrum pool for an LP is greater than its ETH in the Optimism pool, and the system wants to balance the amount of ETH in both pools. According to the above equation in the diagram, if 0.99 ETH on Optimism can be exchanged for 1 ETH on Arbitrum, there will be an arbitrage opportunity. In this way, for LPs, the number of ETH in the Optimism pool becomes larger and the number of ETH in the Arbitrum pool becomes smaller, thus the liquidity is balanced through arbitrage activities.

Also, anyone on Connext can initiate their own router to provide liquidity, so liquidity will not be aggregated as some routers may be overloaded and some routers may not be used at all. Connext then came up with the concept of Liquidity Auctions, which dynamically find the router that offers the lowest cost.

When a transfer is made, the user broadcasts to the network the liquidity to be sent or received. The router submits “Sealed Bids” directly to the user to complete the transfer at the lowest price. This is somewhat similar to Uber matching users with the lowest-priced drivers.

Conclusion

The four projects mentioned above use a similar method to solve the cross-L2 and L1 and L2 interoperability problems by introducing a liquidity provider to aggregate multiple transactions into a single transaction. As for the funding efficiency problem of liquidity providers, each project proposed different solutions and has its own advantages and disadvantages. With the adoption rate remaining low, it’s a matter of time to tell which solution will prevail.

References

a. The Road to L2 Interoperability. StarkWare. https://medium.com/starkware/the-road-to-l2-interoperability-718ff69ec822.

b. Conditional Transfers - The Key to Interoperability. StarkWare. https://medium.com/starkware/conditional-transfers-the-key-to-interoperability-2e1de044fb65 c. Ethport: Loopring L1/L2/CEX.

https://medium.com/loopring-protocol/ethport-loopring-l1-l2-cex-8bb83c9032e3

d. Flash-Mintable Asset-Backed Tokens. OpenZeppelin. https://blog.openzeppelin.com/flash-mintable-asset-backed-tokens

e. Introducing the First L2 Interoperability Mechanism with Hermez Massive Migrations. Hermez Network. https://blog.hermez.io/hermez-massive-migrations-mechanism/

f. Solving the Liquidity Problem. https://medium.com/connext/solving-the-liquidity-problem-88bde201501

g. Hashlock. https://en.bitcoin.it/wiki/Hashlock

Note: This is an article jointly written by Sin7Y and the ZKSwap tech team.