Standardising Cross-Domain Asset Transfer

Note: We have written several articles related to cross-layer transfer, and the below list will help the readers to navigate through them quickly.

An Introduction to Cross Layer Transfer

Fast Withdrawals In Optimistic Rollups — Part 1

Fast Withdrawals In Optimistic Rollups — Part 2

Standardising Cross-Domain Asset Transfer

One of our previous blog post discussed the various layer-2 solutions, their associated challenges and given a sense of the pace at which the system is evolving. More Layer-2 solutions and sidechains within the ecosystem would demand asset representation and asset transfer across each of these solutions. A new challenge in the layer-2 domain is the presence of different token versions (eg-: DAI-a, DAI-b) in the child chain due to multiple token bridges.

NON-FUNGIBILITY OF TOKENS IN CHILD CHAIN

Token Bridges helps users to deposit and withdraw tokens between different environments. Each bridge may have different functionality and security models, ranging from fully permissionless, non-upgradable bridges, where its behaviour is formally defined and verified. In a permissionless blockchain, anyone can deploy a Bridge, and users will have more than one bridge to choose from a list. Multiple bridges for the transfer of the same asset type could pose a new problem: the non-fungibility of these new tokens.

Let’s understand more about it with the diagram below.

L2 solutions with centralised operators such as Loopring and dYdX have only a single way to deposit and withdraw tokens. But, platforms such as Optimism and Arbitrum (Permissionless L2s) would enable anyone to deploy a bridge for the asset transfer. In the diagram, you can see that Bridge A and Bridge B create their own version of DAI on a child chain. These different versions of DAI are not fungible (similar to wBTC vs renBTC). A user who deposited DAI using Bridge A needs to use the same bridge during withdrawal. Eventually, the users would end up with different non-fungible versions of the DAI in their wallet, creating confusion, which in turn affects user experience.

Take a look at this site to see different versions of the same token on Ethereum-Fantom Bridge.

Two versions of Chainlink in Ethereum-Fantom Bridge :

Two versions of DAI in the Ethereum-Fantom Bridge:

It is ultimately up to the community to reach a social consensus on what is their “true” token on the child chain. The community can either create and support their own bridge or endorse one of the existing bridges. There are also efforts to standardise the cross-domain ERC20 transfers. The community widely discussed the proposal by Maruelian and Ben Jones for the cross-domain ERC20 transfers. Inspired by the proposal, Arbitrum Rollup has adopted similar standards in their Token Bridge.

STANDARD INTERFACE FOR CROSS-DOMAIN ERC-20 TRANSFER

The primary impulse behind this proposal is:

1. To define an interface for seamless movement of assets between two asynchronous state spaces
2. To introduce a domain agnostic semantics for future combination of Rollups,shards and different L1s.

The two interfaces include a Registry interface and a Gateway interface. Gateway interface is used to define a pairing of gateway contracts(one on each domain, say L1 and L2) which accepts a canonical token address (main L1 contract) on one domain and expresses the L2 representation of the same token on the other domain. The registry is used to map the token addresses to the correct gateway contract that should be used for a cross-domain transfer. Please view the proposal to see the suggested definition for these two interfaces. In the later section of this post, we will also see how Arbitrum Rollup adopted these ideas.

An important point to note in the interface definition is the use of domain-agnostic terminology. A deposit and withdrawal function in the standard optimism bridge is shown below.

function depositERC20To (
     address _l1Token,        
     address _l2Token,        
     address _to,        
     uint _amount,        
     uint32 _l2Gas,        
     bytes calldata _data   
 )        
    external;
function finalizeERC20Withdrawal (
        address _l1Token,
        address _l2Token,
        address _from,
        address _to,
        uint _amount,
        bytes calldata _data
    )
        external;

The proposal suggests using domain agnostic terms that are more future proof instead of using words such as “deposit” and “withdrawal”. Look at the below functions suggested in the interface definition.

function outboundTransferTo(
         address _to,
         uint _amount,
         bytes calldata _data
     )
         external;
function finalizeInboundTransfer(
         address _to,
         uint _amount
     )
       external
       returns
     (
         address _from,
         bytes memory _data
     )

The important properties aimed in the proposal are:

CANONICALITY OF TOKEN PAIRINGS

Given a token on L1, there should be a straightforward way to define the source of truth about the address of the token on L2. We also need to avoid situations where there is confusion about the correct address for the L2 counterpart to an L1 token. The registry keeps track of all the gateways (including custom), which helps to avoid using a monolith contract that handles deposits for all token types in the same way.

COMPOSABILITY

The proposal takes a turn from the usual transferToAndCall pattern. Instead of executing a call to the receiver’s address on cross-domain, it passes the address from and bytes data fields through deposits. A separate transaction is initiated to verify the data and from field against the state of the recipient domain. This would ensure passing call data around without the security risk of unexpected external calls.

ARBITRUM BRIDGE ARCHITECTURE

Arbitrum Token Bridge architecture has adopted similar standards from the above proposal. The three main goals of their bridging system include:

1. Custom Gateway Functionality

The bridge architecture allows custom gateways to be added dynamically over time. For many ERC20 tokens, the standard bridging functionality is sufficient, but many tokens require custom Gateways that are hard to generalise.

2. Canonical L2 Representation per L1 Token contract

There shouldn’t be a situation where a single L1 token that uses the Arbitrum Bridge can be represented at multiple addresses/contracts on L2. Thus, there is a need to track which L1 token uses which gateway, and in turn, to have a canonical address oracle that maps the tokens addresses across the Ethereum and Arbitrum domains.

3. Domain Agnostic

Over time, Gateways will be developed to transfer assets between any combination of Rollups, Shards, and other L1s. It inspired them to follow domain-neutral semantics like “outBoundTransfer” over things like “deposit” and “withdraw”.

The architecture consists of three types of contracts:

You can find the UML of the Arbitrum Token Bridge here.

All Ethereum to Arbitrum token transfers are initiated via the L1GatewayRouter contract. L1GatewayRouter forwards the token’s deposit-call to it’s appropriate L1ArbitrumGateway contract. L1GatewayRouter is responsible for mapping L1 token addresses to L1Gateway, thus acting as L1/L2 address oracle and ensuring that each token corresponds to only one gateway. The L1ArbitrumGateway communicates to an L2ArbitrumGateway.

Example Scenario — Standard Arb-ERC20 Bridging In Arbitrum

Some of the terms related to Arbitrum Rollup might be new to you. Please refer to this link to learn more about them.

DEPOSIT

STEPS

1. A user calls GatewayRouter.outBoundTransfer (with SomeERC20Token’s L1 address as an argument).
2. GatewayRouter looks up SomeERC20Token’s gateway, and finding that it’s Standard ERC20 gateway (the L1ERC20Gateway contract).
3. GatewayRouter calls L1ERC20Gateway.outBoundTransfer, forwarding the appropriate parameters.
4. L1ERC20Gateway escrows tokens, and creates a retryable ticket to trigger L2ERC20Gateway’s finalizeInboundTransfer method on L2.
5. finalizeInboundTransfer mints the appropriate amount of tokens at the arbSomeERC20Tokencontract on L2.

WITHDRAWAL

STEPS

1. On Arbitrum, a user calls L2GatewayRouter.outBoundTransfer, which in turn calls outBoundTransfer on arbSomeERC20Token’s gateway (i.e., L2ERC20Gateway).
2. This burns arbSomeERC20Token tokens, and calls ArbSys(ArbSys is a precompiled contract that exists in every Arbitrum chain) with an encoded message to L1ERC20Gateway.finalizeInboundTransfer, which will be eventually executed on L1.
3. After the dispute window expires and the assertion with the user’s transaction is confirmed, a user can call Outbox.executeTransaction, which in turn calls the encoded L1ERC20Gateway.finalizeInboundTransfer message, releasing the user’s tokens from the L1ERC20Gateway contract’s escrow.

REFERENCES

1. https://stonecoldpat.medium.com/a-note-on-bridges-layer-2-protocols-b01f8fc22324
2. https://forum.makerdao.com/t/a-multichain-strategy-and-roadmap-for-maker/8380
3. https://developer.offchainlabs.com/docs/bridging_assets
4. https://ethereum-magicians.org/t/outlining-a-standard-interface-for-cross-domain-erc20-transfers/6151