Skip to content

Transfer flow interoperability between l2 and heterogeneous chains

Jump to bottom
Aalavandhan edited this page Oct 18, 2021 · 2 revisions

L2 vs Heterogeneous integrations

It's important to distinguish the meter passport or other heterogeneous bridges and the Aribtrum or other l2 bridges.

In the case of arbitrum the relayers which propagate transactions between eth/l2 are the nodes which validate the transactions on the L2 chain. If the relayer network is compromised both the l2 chain and the bridge are compromised.

In the case of meter passport the meter relayers are different from the nodes which secure each connected chain. Either one of them can be compromised.

If the bridge is compromised, it means that only the escrowed funds on the main chain can be stolen. This would mean that the XC-AMPL on the satellite chains are not backed by actual AMPL on the main chain and can lead economic attacks on the defi protocols in the satellite chains (limited to ones using XC-AMPL).

If the satellite chain is compromised, it means that the escrowed funds on the main can be stolen as well as attacker can change the l2 ledger breaking any/all defi protocols (NOT limited to ones using XC-AMPL).

Cross chain transfer

Meter passport transaction flow

From ethereum:

  1. User approves the "token vault" contract to spend AMPL.
  2. User invokes the "deposit" funciton on the bridge contract
  3. Bridge calls back into "AMPLBridgeGateway" contract and invokes the "escrow" function
  4. On success bridge logs the corss-chain transfer to be picked up and transmitted off-chain

From satelltie chain:

  1. User approves the "XCController" contract to burn XCAmple.
  2. User invokes the "deposit" funciton on the bridge contract
  3. Bridge calls back into "BridgeXCAmpleGateway" contract and invokes the "burn" function
  4. On success bridge logs the corss-chain transfer to be picked up and transmitted off-chain

Arbitrum transaction flow

From ethereum: Mostly same as ethereum

From satellite chain:

  1. User invokes the "deposit" funciton on the bridge contract
  2. Bridge calls back into "BridgeXCAmpleGateway" contract and invokes the "burn" function
  3. On success bridge logs the corss-chain transfer to be picked up and transmitted off-chain

Major Difference: The default aribitrum erc20 cross chain transfer flow does not expect approvals from the end user when transferring from the arbitrum to ethereum.

What do approvals guard against?

In both flows the bridge contract callsback into the gateway with the address of the depositor. We trust that the depositor address specified on the bridge callback is indeed the EOA wallet which triggered the transaction.

In the case that the relayers are malicious, they could in theory "trick" our gateway contact by fudging the depositor address and stealing escrowed tokens (on the base chain) or burning tokens from wallets (on the satellite chain).

On the satellite chain, the approval requirement guards against the malicious relayers burning tokens from un-approved addresses. Say a lending pools / amms. eg) Malicious relayer can AMPL burn tokens from the AMPL/BNB pool distort the price and perform some sort of economic attack. The approval requirement protects downstream defi integrations.

Why is it okay not not approve on L2s?

In the arbitrum case, however since the security of the bridge and the l2 chain are tightly coupled if the relayer is compromised it means the chain is compromised too and no smart contract access control matters at this point.

Another way to think about it is that the erc20 token contract on arbitrum is "tightly" coupled with the bridge contract. As per the erc20 interface spec, if the user's balance is to be changed without the user directly interacting with the contract (ie user is msg.sender) then they need to approve their balance to be spent.

In the arbitrum case, though the user isn't directly invoking a function on the erc20 contract, they call a function on the bridge which callsback into the the token contract. Its not entirely wrong for the token to assume that when invoked by the bridge it's the same as the end user interacting directly with the ERC20 and approvals are not required.

(Looks like bad design. Fyi, Matic requires approvals on transfers from matic to eth so it might not be all L2s just arbitrum :/)

Path forward

  1. Get rid of the "approval" requirement for XCAmple contract versions on L2. This would require us deploying and maintaining different versions of the "XCAmple" contract, ie one for l2s and other for heterogeneous bridges.

  2. Keep the same standard cross-chain contracts on all chains.

    • Create our own aggregate bridge transfer UI
    • Fork the aribtrum UI and add the approval step to roll out on arb.

The broader question here is do we want maintain subtly different deployments and confirm to each bridge's implementation (so they can support us on their UI) or just create a standard AMPL deployment across all chains (ie build our own transfer UI).

Clone this wiki locally