connext, blockchain, bridge, research,

Connext Bridge Research

Stefan Liu Stefan Liu Follow Apr 23, 2022 · 4 mins read
Connext Bridge Research
Share this

Recently, I did some researches on some existing popular cross chain bridges, here to dump them on the blog with three pages, for Celer Bridge, Connext, MultiChain respectively.

Here’s the original doc:

Connext Research

April.2022 / stefan liu

About

Connext is the interoperability protocol of L2 Ethereum.

​​In general, Connext adopts the same core security model as other locking systems such as HTLCs. Unlike other systems, Connext is less vulnerable to free options as all interactions across chains are with 1:1 assets (e.g. ETH on Optimism to ETH on Arbitrum).

Note that the current version of Connext cannot be used pass arbitrary event data between chains (i.e. prove to chain B that something occurred on chain A) as this cannot be done in a trust-minimized way in the evm except by incurring the 1-week exit window of existing rollup bridges.

https://connextscan.io/

NXTP

Noncustodial Xchain Transfer Protocol.

  1. Route Auction: User broadcasts to our network signalling their desired route. Routers respond with sealed bids containing commitments to fulfilling the transaction within a certain time and price range.
  2. Prepare: Once the auction is completed, the transaction can be prepared. The user submits a transaction to TransactionManager contract on sender-side chain containing router's signed bid. This transaction locks up the users funds on the sending chain. Upon detecting an event containing their signed bid from the chain, router submits the same transaction to TransactionManager on the receiver-side chain, and locks up a corresponding amount of liquidity. The amount locked on the receiving chain is sending amount - auction fee so the router is incentivized to complete the transaction.
  3. Fulfill: Upon detecting the TransactionPrepared event on the receiver-side chain, the user signs a message and sends it to a relayer, who will earn a fee for submission. The relayer (which may be the router) then submits the message to the TransactionManager to complete their transaction on receiver-side chain and claim the funds locked by the router. A relayer is used here to allow users to submit transactions with arbitrary calldata on the receiving chain without needing gas to do so. The router then submits the same signed message and completes transaction on sender-side, unlocking the original amount.

Bridge Fees

  • Router fee currently 0.05% of transaction size
  • ReceiverChain GasFee If a user sends it themselves, then the costs are in the native asset of the receiving chain (the gas fee associated with any onchain transaction). If the transaction is sent via relayers, then the cost comes out of the asset you receive (i.e. the USDC relayer fee is deducted from the amount the router put up for you on the destination chain)

Contracts

TransactionManager

https://etherscan.io/address/0x31eFc4AeAA7c39e54A33FDc3C46ee2Bd70ae0A09#code

https://github.com/connext/nxtp/tree/main/packages/contracts

        Prepare

        Fulfill

        AddLiquidity

        RemoveLiquidity

Routers

https://github.com/connext/nxtp/tree/4153114acca33b2e914d17f6cc974e607152f28d/packages/router

  • Listen for user swap requests.
  • Submit bids to fulfill user swap requests.
  • Monitor TransactionManager contract events across all chains for TransactionPrepared events where router matches the configured router's signer address, and sendingChainId matches the chain of the event.
  • Call prepare on the receiving chain with amount = amount - calculatedFees where calculatedFees are a combination of the AMM-based swap rate, flat 0.05% fee, and any gas fees that will be reimbursed by the user.
  • Monitor TransactionManager contract events across all chains for TransactionFulfilled events where router matches the configured router's signer address and receivingChainId matches the chain of the event.
  • Call fulfill on the sending chain with the signature emitted from the TransactionFulfilled event.

Auction: https://github.com/connext/nxtp/blob/4153114acca33b2e914d17f6cc974e607152f28d/packages/router/src/handler.ts#L176

Risks

DoS and Griefing In the short term, there is a whitelist for routers in the core contracts which the Connext team has the ability to update. The Connext team expects to work closely with an initial set of pilot routers that are trustworthy and reputationally disincentivized to attempt to grief users.




 

 

PV
Stefan Liu
Written by Stefan Liu Follow
Coding with ideas