Ethereum Layer-2 Ecosystem | Albaron Ventures

Introduction

The Ethereum rollup-centric roadmap represents the first blockchain solution that can scale for global adoption through the combination of rollups and data shards. To achieve this goal, Ethereum will transform itself into the settlement layer for rollups. This shift marks the separation between the security and execution layers, as a result, it will be possible to leverage a modular architecture to scale beyond the limits that are imposed by Layer-1 solutions.

Rollups are a type of Layer-2 scaling solution that increases Ethereum’s throughput by performing transaction execution off-chain and posting transaction data on Layer-1. Due to this, rollups inherit Ethereum’s security properties and optimize for execution. Rollups can be segmented into two different types, optimistic rollups, and zk-rollups. The main difference between both rollups lies in the method in which they are verified by the underlying Layer-1.

Optimistic rollups do not perform any computation by default. Instead, they post data to the Layer-1 base chain and assume that it is correct. To ensure that all transactions are legitimate, optimistic rollups rely on fraud proofs that challenge state changes and introduce high exit times that can vary between one day and a week.

Alternatively, zk-rollups generate validity proofs that are posted on Layer-1 with a given batch of transactions. Unlike optimistic rollups, these cryptographic proofs can be instantly confirmed, thereby, zk-rollups aren’t liable to high exit times. Despite this clear advantage, validity proofs have high confirmation costs that impose infrequent confirmations. Due to this cost-driven delay that is introduced by increased complexity, exit times from zk-rollups are not immediate.

Disregarding the tradeoffs that exist between both types of rollups (e.g. Performance versus EVM-compatibility), moving assets between rollups and the Layer-1 base chain involves high exit times and costs. For that reason, these limitations introduce new obstacles for Ethereum’s Layer-2 ecosystem, such as limited cross-rollup composability, and fragmented liquidity.

As such, interoperability bridges represent crucial infrastructure when it comes to overcoming these challenges and avoiding a siloed rollup ecosystem. By enabling users to directly move assets from rollup to rollup, these bridges reduce friction and enable fast and cost-effective transactions. Therefore, it is possible to retain cross-rollup composability for the application layer and a frictionless flow of liquidity from rollup to rollup.

Furthermore, it is essential to improve the liquidity that is present in these bridges in order to ensure optimal trade executions and avoid high price impacts within bridge AMMs that would ultimately undermine the flow of liquidity between rollups. For that purpose, liquidity infrastructure layers, such as Tokemak, can prove to be important components for the Layer-2 ecosystem by providing sustainable and reliable liquidity to interoperability bridges. Additionally, this approach removes the unsustainable and inflationary dependency from liquidity mining rewards.

Lastly, to complete the infrastructure stack, and to ensure an optimal user experience for the rollup ecosystem, it is equally necessary to adopt cross-chain bridge aggregators that will route users through the best bridge solution. This report addresses the present and future state of Ethereum’s Layer-2 ecosystem and it explores how rollups, interoperability bridges, and cross-chain aggregators will define the next evolutionary step of blockchain scaling powered by a sustainable liquidity layer that is based on a rollup-centric model.

Optimistic Rollups

For optimistic Rollups, Ethereum’s security layer assumes that a given batch of transactions is valid by default; this approach leads to large scalability improvements (up to x100). That batch of transactions will only be rejected if a participant that is monitoring the rollup submits a valid claim that demonstrates that the transaction is fraudulent, this is known as “fraud-proof”.

This time interval during which network participants can contest the legitimacy of the data that is included in a given batch of transactions constitutes a dispute period when anyone can submit fraud proofs. Once this period is over, the transactions processed by the rollup receive the final acceptance from the security base layer. This challenge interval introduces high exit times that create long withdrawal periods (generally one week).

The underlying security assumption that is made for optimistic Rollups is that there is at least one honest network participant. This implies that if that assumption holds true and one honest network participant submits a valid fraud-proof, the rollup will process transactions correctly.

In order to incentivize all network participants to process only legitimate batches of transactions, sequencers (block producers and transaction processors), and participants that submit fraud proofs, are required to bond tokens that are forfeit in the event of a lost dispute. This approach creates strong incentives that avoid spam attacks with false fraud proofs or fraudulent transactions.

The advantage that optimistic rollups currently offer when compared to zk-rollups, lies in the existing EVM-compatibility. This means that optimistic rollups are ideal for general purpose applications that enable the seamless migration of applications that create easier portability of native solidity contracts.

Optimism and Arbitrum

Optimism and Arbitrum are both Ethereum scaling solutions based on EVM-compatible optimistic rollups. Despite the existing similarities, each solution opted for different approaches regarding implementation, deployment of protocols, ordering of transactions, and dispute resolution models.

Optimism decided to follow an approach based on a permissioned contract deployment, as such, the platform partnered with the Synthetix ecosystem and Uniswap to test its network prior to its launch. Contrastingly, Arbitrum decided to provide open access for all protocols that wished to deploy on its platform. This distinct approach allowed Arbitrum to create stronger network effects when compared to Optimism through a more diverse ecosystem of applications. Table 1 contains the current ecosystem metrics for Arbitrum and Optimism.

Metric	Arbitrum	Optimism
Total Value Locked	$1.98B	$150.50M
Nº of Dapps	35	4
Dominance	SushiSwap (18.93%)	Synthetix (60.87%)

Table 1 – Optimistic Rollups Ecosystem Metrics
(source: DefiLlama)

With respect to the existing implementation, Optimism adopted Geth’s codebase with minimal changes. Alternatively, Arbitrum decided to build its own implementation, ArbOS. As a result, it is possible to conclude that Optimism prioritized stability, whereas Arbitrum optimized its implementation for Layer-2. Furthermore, Arbitrum runs a sequencer that is responsible for ordering transactions, while Optimism auctions the existing MEV to other parties for a given period of time.

Lastly, the major difference between Optimism and Arbitrum lies in the dispute resolution model. When a challenge is submitted on Optimism, the network runs the whole transaction through the EVM, on the other hand, when a challenge is submitted on Arbitrum, the network uses an off-chain dispute resolution method that requires only a single step of the transaction. Therefore, it is possible to conclude that Optimism’s approach to dispute resolutions is simpler and faster, while Arbitrum’s approach is more complex but less expensive due to lower transaction costs on the underlying Layer-1.

Currently, Optimism and Arbitrum are throttled while in beta, as the throttle is lifted, fees will decrease on both networks. It is worth noting that the lower transaction costs offered by optimistic rollups are particularly evident for transactions that require higher levels of complexity, the following table 2 depicts this relationship and provides a transaction cost comparison for both networks.

Network	ETH Transfer	ERC20 Transfer	Swaps
Arbitrum	$2.10	$2.31	$3.63
Optimism	$1.85	$1.85	$2.57
Ethereum	$7.19	$16.44	$35.87

Table 2 – Transaction Costs for Optimistic Rollups and Mainnet
(source: l2fees.info)

As expected, transactions that are more complex have higher costs that are intrinsic to the transaction type. Additionally, it is also possible to conclude that the decrease in transaction costs that is achieved by rollups is larger for complex types of transactions (e.g. swaps versus ETH transfers).

Zk-Rollups

Zk-rollups bundle batches of transactions off-chain and generate cryptographic zero-knowledge proofs which are used to record the validity of the block on the Ethereum base chain. This verification method creates validity proofs that can be immediately confirmed and thereby verify the correctness of a given batch of transactions. Such an approach implies that Ethereum only accepts batches of transactions that can be cryptographically verified, in contrast with optimistic rollups where transactions are valid by default, zk-rollups assume that transactions are invalid until proven otherwise. Furthermore, zk-rollups aren’t liable to the trust assumptions that optimistic rollups are subject to (i.e. at least one honest network participant). Due to this, zk-rollups are able to provide better security than their optimistic counterparts.

Ultimately, zk-rollups offer lower fees and faster transactions when compared to optimistic rollups because confirmation times are immediate and less data is included while validating a block (this can be further improved by representing an account by an index rather than an address on Layer-2). Additionally, they are also able to avoid the week-long exit times that are imposed by optimistic rollups. Despite seeming inherently superior to optimistic rollups, the lack of EVM-compatibility remains a short-term obstacle for the adoption of zk-rollups as the leading Layer-2 scaling solution. Execution layers such as zkSync 2.0 are addressing this limitation through the zkEVM engine which will provide Ethereum’s security and solidity smart contract support to zk-rollups.

The zk-rollup architecture contemplates two distinct types of users that are given as follows:

Transactors – This user creates the transaction transfer and signs it with his private key before sending the transaction to the relayer and broadcasting it to the network;
Relayer – The relayer collects and verifies several transactions that are then bundled into a batch. This batch has a validity proof associated with it that is generated by the relayer. Finally, the relayer submits the essential transaction data, the validity proof, and the root (one for accounts, and another for balances) of the new user state to the chain’s smart contract. This service is provided in exchange for a fee that incentivizes the relayer and covers the gas that is consumed by the validity proof’s submission and the transaction data to the chain.

zkSync 2.0

zkSync is an EMV-compatible Layer-2 scaling solution based on zk-rollups. As such, zkSync inherits Ethereum’s security (i.e. funds are held by a smart contract on Layer-1), while computation and storage are performed off-chain. Similar to other zk-rollups, zkSync generates validity proofs (SNARK) for each state transition within a rollup block. These validity proofs are then verified by the base chain smart contract.

An architecture based on zk-rollups guarantees that validators cannot corrupt state transitions (unlike optimistic rollups), and users can always retrieve their funds through the underlying Layer-1 (zkPorter is an exception where funds can be frozen). This is possible due to the existence of validity proofs that replace trust assumptions related to validators.

zkSync 2.0 was designed to maximize all components of the blockchain trilemma with an added characteristic, programmability. To achieve this purpose zkSync 2.0 combines two novel elements, zkPorter, and zkEVM. zkPorter is an off-chain data availability (DA) system that maximizes the scalability that can be offered by zk-rollups. The zkEVM, on the other hand, is the engine that powers zkSync’s EVM-compatible zk-rollup. Due to the zkEVM virtual machine, zkSync is able to support solidity smart contracts. Both solutions are fully composable and interoperable with each other.

zkSync 2.0 – State Architecture

The transaction costs that are associated with zk-rollups are two orders of magnitude smaller than the transaction costs that exist within Ethereum. Regardless, considering that both vary linearly, it is necessary to mitigate the effect of induced demand which dictates the linear rise of transaction costs on zk-rollups when compared to the base chain. To address this issue, zkSync 2.0 developed zkPorter which enables stable transaction costs through an exponential gain in throughput that is achieved through off-chain data availability.

In zkSync 2.0 the Layer-2 state is divided into two separate components, zk-rollups, and zkPorter. The main distinction between both components lies in the data availability. Zk-rollups maintain all data availability on-chain (thus stored in Ethereum’s DA layer), while zkPorter maintains all data availability off-chain. As such, each component offers distinct levels of security and costs.

On a zk-rollup, the state root is held off-chain and it is represented as a Merkle tree where the leaves are zk-rollup accounts. The root hash of the Merkle tree constitutes the cryptographic commitment to the state root and it is stored on the rollup’s smart contract on Ethereum. To guarantee the required data availability, all state updates are published to the Ethereum network as calldata.

Whenever a state change occurs in a given account within a block, the final state of that account is sent to Ethereum as a state update which is propagated through the entire network. This approach guarantees that users have access to that data and it is always possible to fetch funds through Ethereum where validity proofs ensure that the published data corresponds to the state transition. Due to this, zk-rollups provide the same security as the underlying base chain.

In order to overcome the throughput bottleneck that is imposed by Ethereum’s block size, zkSync developed zkPorter as an off-chain data availability solution. While zk-rollup accounts publish both the calldata and the root hash to Ethereum, zkPorter accounts only publish the root hash to the base chain. The transaction calldata, which is associated with zkPorter accounts, is published on a separate network. It is important to note that both types of accounts remain fully composable and interoperable with each other (e.g. zkPorter accounts can interact with DeFi protocols deployed on zk-rollup accounts). Figure 2 illustrates the architecture of zkSync 2.0 subtrees separated by type of account.

To secure the data availability of zkPorter, zkSync designed the Guardian network. This network relies on zkSync token holders (named Guardians) that stake their tokens and store data on behalf of zkPorter users in exchange for a fee. Guardians participate in zkSync’s Proof of Stake consensus and they are required to sign all blocks with a supermajority of signatures to confirm data availability for zkPorter accounts. If they fail to do so, the existing stake is slashed. As a result, it is possible to conclude that zkPorter’s data availability is preserved through cryptoeconomic guarantees.

Considering that a supermajority of guardians is malicious, it would be possible to freeze the zkPorter state. By doing so, guardians would freeze the funds that are associated with zkPorter accounts (due to the denial of data availability), and their own stake. As such, there is no cryptoeconomic incentive to attack the network. Regardless, no funds would be stolen under these circumstances and zk-rollup accounts would be unaffected by this lack of data availability within zkPorter.

Table 3 contains the projected transaction costs and throughput for both rollup modes that are supported by zkSync, it is worth noting that this projection doesn’t contemplate Ethereum’s sharding upgrade which will dramatically increase its data-availability.

Rollup	Calldata Storage	Hash Root	Transaction Cost	Throughput
zkRollup	Ethereum	Ethereum	1/100th of L1 Fees	<2000 TPS
zkPorter	Guardian Network	Ethereum	$0.01$ (±fixed)	+20,000 TPS

Table 3 – zkRollup versus zkPorter on zkSync

Sync zkEVM

The zkEVM is zkSync’s EMV-compatible virtual machine that runs zkSync smart contracts based on SNARK logic. This virtual machine provides efficient execution of zero-knowledge proofs in a circuit and it is able to run Solidity smart contracts while maintaining its behavior.

In order to create a functional virtual machine based on zero-knowledge proofs, it was necessary to develop an instruction set of the zkEVM for circuit and execution environments. The circuit environment is responsible for proof generation (which is slow), while the execution environment is an implementation of the zkEMV in Rust that provides simple execution and allows instant settlements of transactions on zkSync. Using recursion both between blocks and within blocks, the zkEVM is able to post one single proof for N blocks, and it can also aggregate subproofs for different logical parts of the block.

The zkEVM compiler is built using the LLVM framework. This compiler relies on Zinc, which is a Rust-based language for smart contracts and general-purpose zero-knowledge proof circuits, and Yul, which is a Solidity representation that can be compiled to bytecode for different backends. As a result, the zkEVM offers developers the possibility to program smart contracts in native Rust.

StarkWare

Starkware is a company that is focused on improving scalability and privacy for blockchains by using STARK technology to deploy and verify zero-knowledge proofs. For the scope of this report, the two following products developed by StarkWare will be addressed: StarkEx, and StarkNet.

StarkEx

StarkEx is an Ethereum Layer-2 scalability solution developed by StarkWare that relies on validity proofs (STARKs) and is able to operate in two different modes: zkRollup or Validium. These modes of operation vary in terms of data-availability, due to this, they represent tradeoffs between security and costs.

While using the zk-rollup mode, the required data that is necessary to recover Layer-2 balances (stored within the state Merkle Tree), is published on-chain as calldata. This process is enforced by the Cairo program (a general and Turing complete language developed for STARKs), which provides as an output the complete list of differences of the user’s balances from the previous states. As a result, the zk-rollup mode is trustless and all the required data that is necessary to access funds through Ethereum is available on-chain.

Alternatively, while using the Validium mode, the data that is necessary to recover Layer-2 balances is published off-chain to trusted parties that are known as committee members. New state updates are only accepted as valid if the availability verifiers reach a quorum and sign the state update. The main advantage of Validium when compared to the zk-rollup mode is that there are no gas costs associated with transaction calldata; as such, a state update only spends gas to verify the corresponding proof. Similar to zkPorter, the off-chain actors that are responsible for all data availability can freeze (but not steal) the user’s funds if the majority colludes.

All applications built on StarkEx, define their own business model and run on the StarkEx Service thus creating a diverse design space for the application layer. In fact, applications such as ImmutableX, go to the extent of not charging minting fees on NFTs. Table 4 shows the applications that are currently live on StarkEx and their respective metrics.

Application	Category	StarkEx Mode	Total Value Locked
dYdX	Derivatives	Zk-rollup	$926M
DeversiFi	DEX	Validium	$44.57M
ImmutableX	NFT Marketplace	Validium	$16.48M
Sorare	Sports NFT Game	Validium	$18.08M

Table 4 – Applications deployed on StarkEx

Zk-Rollup Mode

On zk-rollup mode, users submit transactions that are batched by the StarkEx Service (off-chain component responsible for batching and coordination). Upon creating a batch of transactions, this service sends the batch to a shared proving service termed SHARP. The proving service is then able to generate a validity proof for the batch.

Once the proof for the batch is generated, SHARP sends the STARK proof to the STARK Verifier for verification. The service then sends an on-chain state update transaction to the StarkEx Contract, which will be accepted only if the verifier finds the proof valid.

Figure 4 – StarkEx Architecture on Zk-rollup Mode

Valium Mode

On Valium mode, users submit transactions that are batched by the StarkEx Service. Upon creating a batch of transactions, the StarkEx service sends the batch to SHARP thus generating the validity proof for the batch.

Akin to the zk-rollup mode, the proving service sends the STARK proof to the STARK Verifier for verification, however, instead of sending an on-chain state update transaction to the StarkEx Contract, the StarkEx service sends the state update.

Figure 5 – StarkEx Architecture on Valium Mode

Volitions

Volitions break the Validium versus zk-rollup dichotomy by creating a hybrid solution that allows each user to pick one of both modes at an individual transaction level. As such, the volition approach creates a spectrum of data-availability that grants flexibility to all shareholders according to their priorities.

With Volitions, users that prioritize low costs can use the Validium mode, while DeFi protocols that prioritize security can deploy contracts on zk-rollup mode. Furthermore, exchanges such as DeversiFi may opt to rely on off-chain data-availability solutions, such as Validiums to protect the privacy of its customers (e.g. professional traders), while other users prioritize security and therefore use the zk-rollup mode.

System Components

The StarkEx scalability solution relies on the following components:

StarkEx Service – This off-chain component is responsible for batching and coordinating transactions. The service sends the batch of operations to the proving service which generates the correspondent validity proof. Once the proof is verified, it publishes the new state;
SHARP – Shared proving service for Cairo programs that receives proof requests from different applications and outputs proofs to attest to the validity of Cairo executions;
Stark Verifier – On-chain component that receives a validity proof associated with an update and verifies that the proof is valid;
StarkEx Contract – Responsible for state updates and the non-custodial management of deposits and withdrawals;
Cairo – A Turing-complete language for generating STARK proofs for general computation;

StarkNet

StarkNet is a decentralized and permissionless Validity-Rollup that relies on STARK technology (e.g. provers and verifiers) to scale Ethereum on Layer-2. This ZK-Rollup solution (which is currently under development) supports general computation over Ethereum and is based on the Turing-complete Cairo language.

Furthermore, StarkNet will expand beyond Rollups and it will become a Volition that supports Validium mode for off-chain data-availability. As such, users will be offered a hybrid solution that allows them to opt between security and cost tradeoffs at an individual transaction granularity.

StarkEx was an important step towards the development of StarkNet, oversimplifying its structure, it is possible to claim that StartNet has a similar architecture to StarkEx with the exception that it supports arbitrary contract execution and additional bridges. Furthermore, StarkEx represents a standalone system for exchanges that uses the STARK proof system in order to provide scalability. Contrastingly, StarkNet is a general-purpose system for the deployment and interaction of contracts just like Ethereum.

Akin to StarkEx, all transactions on StarkNet will be periodically batched with their validity proven in a STARK proof which is verified on Ethereum. Considering that all StarkNet state transitions will be STARK-proven, only valid transactions will be accepted on Ethereum. Initially, all the required data to reconstruct the full StarkNet state will be published on-chain (zk-rollup mode), furthermore, anyone will be able to run a StarkNet node thus ensuring that StarkNet is permissionless and secure. It is important to note that contrary to the present Layer-1 paradigm, StarkNet will decrease its cost per transaction as the network scales.

StarkNet’s roadmap is given as follows:

Single-App Rollups – This represents the first step of StarkNet’s roadmap. At this stage each StarkNet instance will support and run single applications;
Multi-Apps Rollups – At this point, each StarkNet instance will be able to run multiple applications thus supporting cross-application interoperability by accessing the same global Layer-2 state;
Decentralized Rollup – This constitutes the final stage of StartNet’s development where the platform becomes fully decentralized and permissionless;

StarkNet Alpha was released on a public testnet in June 2021, since then, the testnet has been upgraded twice. The Alpha 1 release included on-chain data-availability and a cross-layer messaging protocol. As such, powered by validity proofs, new forms of interoperability between Layer-1 and Layer-2 are now possible. The Alpha 2 release, on the other hand, enabled composability, as a result, StarkNet Alpha is now able to support interaction between smart contracts.

The next stage for StarkNet’s development starts with the Alpha release on Mainnet. Similar to Optimism, StarkNet will follow a permissioned approach to smart contract deployments where an initial whitelisting will take place. Additionally, new ecosystem efforts such as Warp, a Solidity to Cairo compiler, standardized contracts (developed by Open Zeppelin), and a StarkNet explorer termed Voyager are currently under development.

Interoperability Bridges

Ethereum’s rollup-centric roadmap represents the next evolutionary step in terms of scalability; however, to preserve composability and mitigate fragmented liquidity, Layer-2 solutions will require interoperability bridges. These bridges are essential to establish cross-rollup transfers, communication, and to avoid the high exit times that are inherent to optimistic rollups.

Different bridge designs offer different tradeoffs (e.g. security, speed, and capital efficiency), due to this, each use case needs to be adapted and contextualized with the existing tradeoffs. Given the scope of this report on EVM-focused solutions, Hop protocol and Connext will be addressed due to the trustless characteristics that grant them the same security as the underlying base layer.

Connext

Connext is an interoperability bridge based on a trustless network of state channels that enables cross-chain transactions of value and calldata. Due to its design, all transactions conducted on Connext have the same security as the underlying chain.

Within this network, there are state channel nodes, termed routers, that act as liquidity providers and front liquidity on the receiving end whenever a transaction takes place. Unlike other interoperability bridges, Connext doesn’t create representative assets nor does it incur any Layer-1 costs while conducting cross-rollup transactions.

Connext routers can be seen as state channel nodes that automatically forward all in-channel transfers that are sent to it. As such, for a cross-chain transaction, the Connext router will be responsible for transferring funds in-channel to the destination chain in exchange for funds on the origin chain. In order to incentivize routers and to cover the existing expenses (e.g. server and transaction costs), there are fees (static or dynamic) that are applied to all transactions.

Considering that Connext relies on state channels, transfers are atomic and therefore trustless. Furthermore, the protocol also supports arbitrary conditionality, as such, it is possible to pass calldata in order to execute contract interactions. Figure 6 represents an oversimplified architecture of Connext’s network.

To illustrate how cross-chain transactions work on Connext consider the following example where user A wants to transfer 1000 DAI from Arbitrum to Optimism:

User A is matched with a Connext router (that will front liquidity on the destination rollup) thus opening a state channel between both on the origin rollup;
The router verifies that user A has opened a state channel on the origin rollup and proceeds to open another state channel by locking the same amount of funds (minus fees) on the destination rollup;
User A signs a commitment transaction and shares it with the router off-chain thus ensuring that it has the secret without revealing it, this ensures the router that it is possible to unlock funds on the origin chain with the correct secret;
The router proceeds to create a commitment transaction that unlocks funds on the destination rollup with user’s A secret;
User A unlocks funds on the destination rollup using its secret and the router’s commitment transaction, by doing so, the user reveals its secret on-chain;
The router can now unlock the funds on the origin rollup with the user’s secret and the commitment transaction thus settling the transaction;

The previous example can be summarized by stating that the Connext router provides funds on the destination rollup in return for the same funds plus a fee on the origin rollup. The only bottleneck that exists within this architecture is the available liquidity.

Considering that a given router has mainly unidirectional transactions, it is possible to conclude that the available liquidity will quickly become unbalanced. To mitigate this issue, Connext developed virtual AMMs that incentivize arbitrageurs to make transactions in the direction that rebalances the existing liquidity within Connext’s network of routers.

Lastly, it is important to note that Connext was started in 2017 and its team has been a core part of the Layer-2 research community since the deployment of the first general-purpose payment system in 2018. As such, the work that has been developed by the team on state channel systems reflects several years of experience and iterations that ultimately led to Connext’s current bridge design for cross-rollup interactions.

Hop Protocol

Hop protocol is a cross-rollup general token bridge that enables fast and cost-effective transactions between different rollups and the Ethereum base chain. Structurally, the protocol can be segmented into three different parts: Bonders, cross-network bridge tokens, and Hop’s Automatic Market Maker.

Bonders are third-party entities that provide upfront liquidity for swaps at the destination chain, the cross-network bridge token is used to transfer assets between different rollups (or to claim the underlying asset on the Ethereum mainnet), and the AMM is used to swap between bridge tokens and the rollup token representation. Furthermore, Hop’s AMM enables a dynamic pricing of liquidity and its respective rebalancing across the network.

Bridge Tokens

Hop bridge tokens (i.e. hAssets) are intermediary assets that exist within Hop Protocol to facilitate cross-rollup transactions. In order to mint hAssets, it is necessary to deposit the corresponding asset into the Layer-1 Hop bridge contract (e.g. 1000 USDC deposit on Layer-1 can mint 1000 hUSDC on a Layer-2 Hop bridge contract). As a result, hAssets have a 1:1 collateralization. While redeeming hAssets the same logic is applied. The Hop bridge token is burnt on Layer-2 and the underlying asset is unlocked on Layer-1.

Bonders

Liquidity Bonders provide upfront liquidity on the destination rollup in exchange for a fee. To do so, Bonders are required to run full verifier nodes on rollups in order to facilitate cross-rollup transactions. This technical requirement allows Bonders to check if users burn the necessary hAssets on the origin rollup. Once that criteria is met, Bonders proceed to lock up collateral that makes them eligible to mint and use hAssets on the destination rollup.

Rollup-to-Rollup Transfers

While exchanging Hop bridge tokens between different rollups, Hop protocol mints a hAsset on the destination rollup and burns it on the origin rollup. In order to execute a quick cross-rollup transfer of assets, the protocol relies on a third-party called “Bonder” that provides upfront liquidity on the destination rollup in exchange for a fee. Once the transfer is propagated through Layer-1, the Bonder’s liquidity is returned.

To illustrate how cross-rollup transfers work on Hop protocol consider the following example:

USDC is swapped for hUSDC through Hop’s AMM on Rollup 1;
Using the Hop Bridge, the protocol sends hUSDC from Rollup 1 to Rollup 2;
The Bonder provides upfront liquidity for hUSDC on Rollup 2;
hUSDC is swapped for USDC through Hop’s AMM on Rollup 2;

Connext versus Hop Protocol

Hop protocol and Connext are trustless interoperability bridges that adopt 1:1 swaps instead of any-to-any swaps; as such, both protocols optimize for capital requirements and sacrifice flexibility for users. This approach ensures that Connext and Hop have bridge designs that allow them to remain highly scalable.

In terms of capital efficiency, Connext is better positioned than Hop protocol, this is due to the fact that Hop requires active liquidity for Bonders and passive liquidity for its AMM pools that are distributed among all chains that are connected by the protocol.

Furthermore, Hop protocol leverages arbitrary messaging bridges (AMBs) to send funds between chains, due to this, Bonders are required to lock their liquidity while the transaction is passed through the AMB (rollups require 1 day). Connext routers, on the other hand, only require exit liquidity with no lockups, as such, Connext is more capital efficient. It is worth noting that passive liquidity can be easily sourced by incentivizing AMM pools with liquidity mining programs.

Taking into account that Connext relies on off-chain state channels, the protocol is able to settle transactions directly on Layer-2, as a result, while transacting assets between Layer-2 solutions, the system only spends gas on Layer-2. Conversely, all transactions on Hop protocol are required to be bonded on the Ethereum Layer-1. Considering that the protocol bundles a high number of transactions, it is still highly gas efficient.

With regard to liquidity rebalancing and the pricing of swaps, Hop protocol relies on its AMM pools to determine swap rates and to reallocate liquidity within the network through arbitrage incentives that counteract unidirectional flows of liquidity. Alternatively, Connext Bonders charge a flat fee for each transaction and rebalance liquidity within the network manually. This system will be upgraded with the introduction of a Virtual AMM that allows routers to price cross-chain transactions based on the available liquidity. As a result, arbitrageurs will be incentivized to profit by reallocating liquidity within Connext’s network of routers.

Both Connext and Hop protocol are trustless and non-custodial bridges that prioritize security. Connext relies on state channels that do not publish data on the base layer, due to this, the main trust assumption that is made by the protocol is data availability. This liability can be mitigated by storing off-chain states and monitoring the underlying base layer in order to solve withdrawal disputes if one party is dishonest. In Hop’s case, the protocol inherits the security of rollups (e.g. Arbitrum), and therefore, the security of the underlying Ethereum Layer-1. For transactions between sidechains, users are liable to weaker security when compared to the Ethereum Layer-1, regardless, this vulnerability is contained within that network without compromising the system as a whole.

In summary, both interoperability bridges prioritize security, fast swaps, and short tail assets. Due to its design, Hop protocol is optimal for rebalancing liquidity and smart contract applications, on the other hand, Connext is more capital efficient. Lastly, it is important to note that Hop transfers can be initiated by smart contracts (this isn’t possible with Connext), therefore, Hop’s use cases can be expanded to cross-chain DEXs and other multi-chain applications.

Liquidity Layer – Tokemak

Interoperability bridges are the solution to the high exit times and costs that are intrinsic to optimistic rollups, however, the liquidity that is available for cross-chain transactions remains a limiting factor for the mainstream adoption of the Ethereum Layer-2 ecosystem.

This aforementioned limitation is particularly evident while transferring assets using Hop protocol. As a matter of fact, for each cross-chain transaction, a large part of the fees can be attributed to the price impact that is associated with the trade size. This occurs due to the limited liquidity that is available within Hop’s pools. For that reason, it is still unfeasible to conduct large cross-rollup transactions.

In order to overcome this limitation it is necessary to increase the liquidity that is available in interoperability bridges, this will provide cheaper cross-chain transitions for end users and catalyse the development of the Layer-2 ecosystem through improved trade execution, better composability, and unified liquidity.

As a decentralized market-maker, Tokemak is uniquely positioned to solve this obstacle and provide liquidity to interoperability bridges. With new liquidity mining programs being rolled out to incentivize the migration of capital from Layer-1 to Layer-2, there is an opportunity to establish symbiotic relationships that target long-term sustainable liquidity between cross-chain bridge solutions and Tokemak.

In the particular case of Hop protocol and Connext these are the following sources of demand for Tokemak’s liquidity:

Bridge Reactors – These hypothetical reactors can provide liquidity to Hop’s AMM pools with a minimized impermanent loss risk (i.e. unlikely deviation of hAsset:Asset peg). Furthermore, Tokemak can also provide liquidity to Hop Bonders and Connext Routers under the same assumption of no impermanent loss risks;
Arbitrage Reactors – With liquidity deployed on multiple layers, Tokemak is uniquely positioned to create arbitrage reactors that rebalance liquidity in exchange for profit, this would be particularly useful to correct unidirectional imbalances of liquidity within the Connext network of Routers;

Cross-Chain Liquidity Aggregators

The growing number of interoperability bridges that connect Layer-2 solutions, and the overall EVM ecosystem, creates a new demand for the best quotes over a vast spectrum of assets that exist on different platforms. Due to this, cross-chain liquidity aggregators that route users through the best interoperability bridges become necessary to ensure optimal quotes for cross-chain swaps. Additionally, by aggregating cross-chain DEXs, these liquidity aggregators enable any-to-any swaps. Projects such as MOVR Network and Li.Finance are cross-chain liquidity aggregators that offer this value proposition and facilitate the mass adoption of Layer-2 solutions by promoting user abstraction.

MOVR Network

MOVR Network is a cross-chain liquidity aggregator that allows users to move funds between different chains through optimal routes. The protocol achieves this value proposition by aggregating all DEXs and DEX aggregators within its architecture, by doing so, MOVR abstracts the decision making process from end users and optimizes transfers according to the following parameters:

Maximum output (ETH) on the destination chain;
Minimum GAS fee for swap and transfer;
Lowest Bridging Time;

Upon ordering all available routes according to the aforementioned parameters, the user is able to decide between the fastest or cheapest routes according to personal preferences. Furthermore, the protocol also enables zero-cost cross-chain transfers through its peer-to-peer settlement layer which is incorporated in the system’s architecture.

The following example illustrates a costless peer-to-peer transaction executed on the MOVR Network:

User A wants to transfer 1000 USDC from Rollup 1 to Rollup 2;
User B wants to transfer 500 USDC from Rollup 2 to Rollup 1;
MOVR settles 500 USDC between user A and B;
MOVR transfers the remaining 500 USDC from Rollup 1 to Rollup 2;

Figure 8 – Cross-chain Transfer with MOVR

Li.Finance

Li.Finance is a cross-chain aggregator of liquidity networks that aims to facilitate the adoption of Layer-2 solutions by routing DeFi users through optimal cross-chain bridges. Structurally, the protocol can be segmented into three aggregation layers: cross-chain liquidity networks, lending protocols, and decentralized exchanges.

The cross-chain liquidity network layer creates the required backend and frontend infrastructure to aggregate existing interoperability bridge solutions (e.g. Connext and Hop protocol), the lending protocol layer allows users to access more funds and leverage existing cross-chain arbitrage opportunities with flash loans (e.g. Aave and HiFinance), and the decentralized exchange layer enables cross-chain any-to-any swaps (e.g. Uniswap and ParaSwap).

The protocol’s architecture prioritizes trustless and secure swaps thus allowing its users to find the fastest and most cost-effective routes for cross-chain swaps. For that purpose, Li.Finance splits transactions if required and it falls back to alternative liquidity networks if the best protocol isn’t available. Figure 9 shows Li.Finance architecture.

As illustrated above, Li.Finance serves the following purposes:

Aggregate cross-chain liquidity (e.g. stablecoin and native currency swaps);
Connect to DEXs to enable any-to-any swaps;
Connect to money markets to enable any-to-any loans;
Make that liquidity mesh available through different layers and integrations;

Conclusion

The Ethereum rollup-centric roadmap marks the technological transition into a sustainable scalability model that outperforms all monolithic Layer-1 solutions and inverts the blockchain trilemma without compromising neither security nor decentralization. This can be achieved by adopting a modular architecture that segregates security, data-availability, and execution into different layers.

As a result, Ethereum is now focused on becoming a platform for smart contract platforms that prioritizes both security and data-availability, and delegates the execution layer to an open design space where Layer-2 solutions can compete. For this vision to come to fruition there is an extensive infrastructure stack that needs to be developed. As such, it is necessary to prioritize the development and adoption of optimistic rollups, zk-rollups, interoperability bridges, and cross-chain liquidity aggregators.

For the short term, optimistic rollups (e.g. Arbitrum and Optimism) represent the leading scaling solutions for the Ethereum ecosystem due to the existing advantages in terms of general-purpose EVM computation. This characteristic provides the composability that is required by the application layer. However, for the long-term, zk-rollups will prove to be superior for all use cases once general-purpose computation is supported on mainnet. This transition to zk-rollups will naturally occur due to the higher throughput, inferior transaction costs, and lower withdrawal periods (without any trust assumptions), that characterize this type of rollup.

Furthermore, zk-rollups will support composability and interoperability with off-chain data-availability solutions such as Validium and zkPorter. This approach constitutes a hybrid system that empowers users with an off-chain data-availability option that represents a tradeoff between security and costs. It is worth noting that with this solution users can still interact with the zk-rollup mode that inherits Ethereum’s security and data-availability. Additionally, this solution is still far more secure than sidechains due to the fact that funds can be frozen (with a supermajority collusion) but never stolen.

To ensure that Layer-2 preserves cross-rollup composability, and a seamless flow of liquidity, it is necessary to adopt trustless interoperability bridges that prioritize security and connect siloed rollups. In this sector, Hop protocol and Connext represent the leading EVM-focused interoperability bridges that are non-custodial and therefore deemed as sufficiently secure to be adopted. Moreover, cross-chain liquidity aggregators that enable any-to-any swaps and aggregate liquidity among different bridges will also become progressively more important as abstraction tools for end users.

The capital migration from Layer-1 to Layer-2 will be incentivized with liquidity mining programs. Both interoperability bridges and rollups will launch native tokens in order to promote adoption and incentivize liquidity, as such, the next stage of incentives within DeFi will catalyse the transition to an ecosystem that is free from the limitations of the Ethereum Layer-1.

In summary, a modular architecture is the only sustainable approach to address scalability limitations. By separating the execution layer from the data-availability and security layers, it is possible to invert the blockchain trilemma and reduce transaction costs with an increasing adoption. Furthermore, to create a functional ecosystem at a Layer-2 level, it is necessary to develop and adopt a core infrastructure stack that will be composed of rollups, interoperability bridges, cross-chain liquidity aggregators, and a unified liquidity layer.