Cross Layer Transfer — Hop Protocol

Note: This article is part of our cross-layer transfer series, and I have prepared the list below, which helps the reader navigate easily through the articles.

1. An Introduction to Cross Layer Transfer
2. Fast Withdrawals In Optimistic Rollups — Part 1
3. Fast Withdrawals In Optimistic Rollups — Part 2
4. Standardising Cross-Domain Asset Transfer
5. Cross Layer Transfer — Hop Protocol

INTRODUCTION

So far, you might have read our previous articles and understood the need for cross-layer transfer and why it is essential for the massive adoption of Ethereum. Some numerous projects and protocols enable cross-layer transfer at the moment. We will discuss each project in separate articles to keep the article length minimum and readable. This article will discuss Hop Protocol, which has a pretty good reputation in the layer-2 ecosystem. This protocol helps users to trustlessly and quickly swap layer-2 canonical tokens with the help of an intermediary asset known as Hop Tokens. Let’s try to dissect and understand the internals of the Hop protocol in this post.

Before starting with the Hop Protocol, let’s first know about the different techniques used by the projects to implement the cross-layer transfer mechanism. The list is not exhaustive since the scale of research on this area happens at a rapid pace.

1. Proof of Authority Bridges

POA is a very straightforward technique where a set of authorities attest that a token is locked in its native environment and then mints a representation of the same in the destination environment. When it comes to L2<->L2 transfer, this approach requires the user to trust the authorities/custodian to mint representation on the destination rollup.

2. Hash Time Locked Contracts

CELR cBridge, implements cross-layer transfer using HTLC based smart contracts. It is nothing but an atomic swap mechanism where users can trustlessly swap one asset for another even if those assets are on separate Blockchains.

3. Conditional Transfers or Conditional Transactions

StarkEx, a product of Starkware, is a solution that supports fast withdrawals from L2 to any L1 address in blockchain time. It uses conditional transactions to perform atomic swaps when swapping between a rollup and its layer-1 network. The conditional transaction/transfer reduces the time it takes to exit a rollup, but the rollup-to-rollup transfers must go individually through the layer-1 network. As a result, there is no reduction in the transaction cost of moving tokens from one rollup to the next. Also, please be aware that conditional transfers do not help perform atomic swaps across unconnected networks because an action on one of the networks cannot trigger an action on the other.

Hop protocol, in a nutshell, takes a different approach. It proposes a general token bridge that creates a cross-network bridge token(Hop Tokens) that can be moved across rollup to rollup or claimed on L1 for its underlying asset. Also, AMM’s convert Hop tokens to the canonical version of the token on L2 and vice versa.

IMPORTANT PROPERTIES FOR A CLT PROTOCOL

Every CLT protocol strives to achieve all or some of the properties described below.

1. Fast Transfer

The protocol should enable users to fastly transfer assets across L1<->L2 and L2<->L2. There shouldn’t be any bottleneck related to rollup’s exit time which hinders user experience.

2. Minimum L1 interaction and Less Fees

A protocol that can enable fast transfer but still incur high fees for the operation will also get less user attention. For example, interaction with L1 for all individual L2<->L2 transfers would result in high fees. However, hop Protocol does minimal interaction with L1 through the Transfer root mechanism (explained later in this post).

3. Minimum trust assumptions

The recent Polynetwork hack has given a nightmare for institutional investors and high liquidity providers. Cross-Domain messaging, so crucial for L2s, just became a new attack vector.

4. Proper incentive mechanism for Liquidity providers

A proper incentive scheme for providing upfront liquidity is needed for the liquidity providers.

We will explore how each protocol/project adheres to these properties.

HOP PROTOCOL

The Whitepaper describes the working of Hop Protocol as a two-step process.

1. Create a cross-network bridge token that can be quickly and economically moved from Rollup to Rollup or claimed on layer-1 for its underlying asset.
2. Use Automated Market Makers to swap between each bridge token and its corresponding Canonical Tokens on each rollup in order to dynamically price liquidity and incentivize the rebalancing of liquidity across the network.

First, let’s understand the type of token bridges across Rollups and the version of tokens they mint on Layer 2.

NATIVE TOKEN BRIDGE

Every rollup usually supports a native token bridge that is used to move assets from Layer 1 to Layer 2 network. Suppose a user uses the native token bridge contract to transfer Token A from Layer-1 to Laye-2. The L1 contract escrows the token, and the bridge contract on the L2 side mints a similar representation of Token A in Layer 2. These tokens, which are minted on Layer-2, are usually known as the Canonical Tokens. Every application deployed in the Layer 2 rollup prefers the canonical tokens and is likely to be the version that the end-users want. The below figure helps you understand how ETH is transferred to Optimistic Rollup A from L1, and the native bridge creates a canonical version of ETH on Rollup A.

APPLICATION SPECIFIC BRIDGE

Apart from Native Token bridge, some applications may also provide custom bridges for their tokens and these are known as Application- Specific bridges.

GENERAL TOKEN BRIDGE (eg- Hop Bridge)

At the core, Hop protocol has Hop bridge, a general token bridge provided by a third party, and bridge tokens generically. Hop bridge creates Hop tokens which are used for cross-rollup transfers. Each Hop bridge token has an underlying asset locked in the layer-1 contract. Please note that the layer-2 representation created by the Hop bridge is not a canonical version of the layer-1 token since the Hop bridge is nothing but a general token bridge rather than a native token bridge of any L2 solution.

For example, if you deposit 1 ETH to the layer-1 Hop Bridge contract, 1 Hop ETH(hETH) can be minted from the layer-2 bridge contract.

HOP BRIDGE CONTRACTS (Github Link)

1. Accounting.sol — Abstract contract that encapsulates the logic of _credit and _debit balance of bonder.
2. Bridge.sol — Extends the Accounting system and encapsulates the logic that is shared by both the L1 and L2 bridges.
3. L1_Bridge.sol — This bridge is responsible for the bonding and challenging of TransferRoots. All TransferRoots originate in the L1_Bridge through ‘bondTransferRoot’ and are propagated up to the destination L2s.
4. L2Bridge.sol — L2 bridge is responsible for aggregating pending transfers into TransferRoots. Each newly created transferRoot is then sent to the L1_Bridge. The L1_Bridge may be the TransferRoot’s final destination or the L1_Bridge forward the TransferRoot to its destination L2_Bridge.

You may also refer to our previous article Standardizing Cross-Domain asset transfer. We discuss how multiple bridges present for a Rollup would result in the non-fungibility of tokens on Layer 2. It also discusses a proposal that aims to standardize the bridge implementation.

INTERMEDIATE ASSET

When users want to perform a cross-rollup transfer, in most cases, they expect to transfer their canonical token from the origin rollup to a similar canonical representation in the destination rollup. Thus, a very naive approach is to withdraw the token from the origin rollup to Layer 1 and transfer it to the destination rollup. However, the rollups exit time and L1 interaction for every individual transfer (incur high fees) make this approach irrelevant.

Hop Protocol takes a different approach. The canonical version of the token in origin rollup is converted to an intermediate asset called Hop tokens (we will explain later how this conversion happens). The Hop bridge architecture supports the transfer of the Hop tokens from rollup-to-rollup by burning the Hop token on origin Rollup and minting them on the destination rollup. The liquidity on the destination rollup is provided by an entity known as Bonder.

SWAP CANONICAL TOKEN<-> HOP TOKEN

Though Hop tokens have valid collateral locked up in the Layer 1 contract, third parties in the Rollup may only accept the canonical version of the tokens(unless it is an application-specific bridge token). So Automated Market Makers are used to swap the Hop tokens to their canonical counterpart on the Rollup (hETH <-> Canonical ETH on Rollup). Please note that these AMM’s in each Rollup require liquidity providers to contribute to the passive liquidity to the AMM’s liquidity pool. As a result, these liquidity providers get fees for each swap they support.

HOP TRANSFER

Before starting with the transaction flow, we need to know about two important concepts:

1. First, what is the information included in a Hop Transfer?
2. Second, how the Hop Transfers are propagated through the L1 network?

A Hop transfer includes the following information:

1. Destination Chain ID — The chain ID of the rollup or layer-1 destination
2. Recipient — The address receiving the transfer at the destination
3. Amount — The amount of token being transferred

Apart from this information, a transfer may include details regarding relayerfee, swapdata, bonder address, etc.

TRANSFER ROOT

A transfer root is nothing but a bundle of Transfers with minimal data. Each Transfer root is composed of:

1. A merkle root of the Transfers
2. An array of each unique destination represented by its chain ID
3. An array of total amounts being sent to each unique destination

A Transfer Root can contain thousands of Transfers yet be accounted for on layer-1 as a single bundle. This alleviates the layer-1 bottleneck and allows a large number of transfers to be passed through layer-1 to their destination rollups in a scalable way.

TRANSFER FLOW — Rollup A TO Rollup B

The below gif and the steps explained will help you understand how a cross-rollup transfer is done using Hop Protocol. Notice that the below gif doesn’t show how the L1 Ethereum is used as the settlement layer. It will be explained later.

In this example, we will see how Alice transfers her Canonical Eth in Rollup A and then receives canonical Eth in Rollup B.

1. Alice should first swap her Canonical ETH in Rollup A to Hop tokens using the AMM. The attemptSwap function in the AMMWrapper helps to do this conversion.
2. Alice then uses the L2 Hop bridge contract to send her Hop ETH from Rollup A to Rollup B. The send function in the L2 Bridge contract is invoked to achieve this functionality. The user passes the address of the bonder who should bond the transfer at the destination. Please note that the Bridge contracts do not enforce the bonder functionality.
3. Bonder can verify the transaction made on the origin rollup by running a verifier node for the rollup. Once verified, Bonder interacts with the L2 Hop bridge contract in Rollup B and invokes bondWithdrawalAndDistribute function. This function performs three major steps:

a. Increase the debit balance of the Bonder (collateral at stake), and then emits an event Withdrawal Bonded.

b. Mark the transferID as spent.

c. Finally, mint new Hop tokens using the _distribute function and then swap the hop tokens to Canonical ETH in Rollup B using the attemptSwap function (AMMWrapper on Rollup B) and finally send it to the recipient address.

While invoking the send function, the user also mentions the bonderFee, and it is given to the bonder as a reward for providing the upfront liquidity on Rollup B. Note that the bonderFee is given as Hop Tokens to the Bonder address.

HOW THE BONDER’S FUNDS ARE RESTORED?

The Bonder’s liquidity is returned when the transfer eventually propagates through layer-1 as part of a larger bundle called a “Transfer Root”.

First, the Transfer Roots needs to be set on the destination Rollup for the Bonder to get the collateral back. Two scenarios can arise here:

1. Bonder can distribute the Transfer Root to the destination Rollup by submitting the root hash to the L1 contract along with a bond for their claim. Once the Transfer Root is set on the Destination Rollup, the Bonder can execute the appropriate settle method (bondTransferRootAndSettle,settleBondedWithdrawals) on the destination Rollup to get the funds restored. In this scenario, please note that anyone can challenge Bonder’s claim of Transfer Root on the L1 Bridge contract by putting a stake. The challenge can be settled once the L2 bridge confirms the Transfer root on the L1 bridge.
2. When the L2 bridge confirms the Transfer Root on the L1 Bridge, it verifies whether it was bonded before. If the Transfer Root was not bonded, the L1 bridge would invoke the function to distribute the Transfer Root to the destination chain.

The below gif and steps explained will help you understand how the second scenario works.

1. The transfer root we discussed earlier is calculated from a bundle of transfers. A mapping variable pendingTransferIds keeps track of all the pending transfers on a Rollup. There is a threshold limit for the maximum pending transfers, and once it reaches the maximum limit, the send function invokes the _commitTransfers function. A bonder can also force-commit Transfer roots to L1 by invoking the commitTransfers function on the L2 contract.
2. The _commitTransfers function calculates the Transfer root of pending transfers for the destination chain ID and bonder address. The calculated Transfer root is then propagated to the L1 contract through a cross-domain call. The cross-domain call invokes confirmTransferRoot on L1 contract and sets the Transfer root on the destination chain(Rollup B) if the Transfer Root was not bonded before.
3. Finally, the function settleBondedWithdrawals on Rollup B can be invoked to refund the Bonder for all the withdrawals they bonded in a transferRoot for the destination chain(Rollup B).

REFERENCES

1. https://hop.exchange/whitepaper.pdf
2. https://github.com/hop-protocol/contracts/tree/master/contracts/bridges