CONNEXTing the dot
11-12-2022
by chompk.eth
@cpkcpk3
List of Contents
🌉 Introduction to Bridges
🕓 History of Connext
⚖️ NXTPv1, Trustless Bridge
🐺 The Amarok Upgrade
🔑 Security of Amarok
💻 Technical Details
2
🌉 Introduction to Bridges
3
For Connext Network
🌉 What is Bridges?
4
Blockchain A
Blockchain B
Communication channel between two independent blockchains. The goal is to have a protocol that send messages between blockchains
Asset bridging
0x0Ab93eFD…
Message bridging
Bridge
What makes each bridge different despite having a similar functionality?
Verification Method
Categorizing Bridges Verification
Types of bridges verification:
5
Externally Verified
Natively Verified
Locally Verified
Example:
Multisig, PoS, LZ Oracle/Relayers
The bridge events data are verified by an external party. This bring a trust assumption on how external party relaying the data
The bridge events are natively verify using its own complex architecture. Communication are secured as long as both parties are in the same ecosystem
Example:
ETH<>L2*, Polkadot XCMP, Cosmos IBC
Data transfer are done via local communication between two individuals on both chains. The transfer protocol are economically adversarial, thus safe and secure
*Only ETH<>L2 communication, L2<>L2 is not natively verified
Example:
Hop, Connextv1
V1
Interoperability Trilemma
6
Generalizable
Extensible
Trustless
Don’t introduce any additional trust assumption. Trustless bridge should have equivalent security to the underlying domain
Easily expands to other domain with minimal development and deployment efforts
The bridge should be able to transfer any type of messages, not restricted to just assets with economic value
V1
Generalizable & Extensible
Trustless & Extensible
Trustless & Generalizable
Optimistic Bridges
Solving Interoperability Trilemma, introducing new tradeoffs
7
Optimistically Verified
Example:
Nomad Optimistic Bridge, Celo Optic Bridge
Transactions are submitted directly, but unfinalized. Watchers are incentivized to verify any malicious bridge events during a challenging period
watchers
⌛️
Extensible, Generalizable, Trust-minimized, High Latency
Generalizable
Extensible
Trustless
Low Latency
Optimistic Bridge introduce new tradeoffs on latency with minimal trust assumptions
Economic Securities of Bridges
Consider a verification systems that requires a total of N actors
8
Externally Verified
Optimistically Verified
Locally Verified
Natively Verified
It takes M out of N actors colluding to corrupt the system
It takes k out of N corrupts validators to corrupt the system
It takes the domain breach to corrupt the system
It takes all N actors colluding to corrupt the system
watchers
⌛️
Example of security breach:
Example of security breach:
Example of security breach:
Example of security breach:
🕓 History of Connext
9
History of Connext
10
Connext was founded with the goal of scaling blockchains and bring blockchain to broader consumer public
2017
2018
May 2020
Dec 2020
Became one of the first layer-2 (L2) R&D Team. Built the first layer-2 on Ethereum called the State Channel Networks designed for payments. Later, the team have worked with other L2 teams such as OmiseGO team, Matic team
Built a very first Arbitrum-Optimism bridge called Spacefold as a POC. This is the very first trust-minimized cross-chain bridge for rollups.
History of Connext
11
2021
2022
Launched NXTP, a locally verified liquidity protocol
Introducing the Amarok Upgrade 🐺, allowing cross-chain generalization and modular bridge design. In late 2022, the team launched beta launch of Amarok to the mainnet
⚖️ NXTPv1, Trustless Bridge
12
NXTPv1, Connext before Amarok 🐺
A trustless, locally verified bridge
13
Chain A
Chain B
1. Route Selection
2. Prepare
3. Fullfill
I want to transfer 1000 DAI from Chain A to Chain B
Routers bid offers using their liquidity provided on both Chain A and B
Routers
Chain A
Chain B
Routers
Router that win bid prepare liquidity on Chain B
User sign transaction to send 1000 DAI from Chain A to Chain B
🔒
🔒
Chain A
Chain B
Routers
🔓
🔓
🔑
User sign a message to unlock the funds on both side. Completing the bridge transaction
Users select the chains and assets and start an auction with the transfer information, and routers bid to complete the transfer with a time/price range
Users send a transaction to the nxtp contracts on the sending chain. Upon seeing the contract event, routers lock up liquidity on the receiving chain
Users provide a signature to unlock funds on the receiving chain, and routers use the revealed signature to claim the liquidity on the sending chain.
Problems with NXTPv1
14
Problems for End Users
Problems for Developers
Problems for Routers
⛽️ Gas Costs
🖋 Signing to Claim
🔐Fund Lockup Risk
⚡️ Speed
⛲️Liquidity Fragmentation
🛎 Offchain Auction
🖋 Signing to Claim
🤖 No Generalized Messaging
🔄 Rebalancing
💸 Unclear ROI
📜 Strict Liveliness
💩 Gas Griefing
Two phase txs (prepare/fullfill) is costly and hard to batch
Signing to release locked funds is bad in term of UX
Poor routers liveliness can freeze users’ funds for up to 72 hours
Poor routers liveliness can also affect transaction speed
Only one router can fullfill a transaction, low capital efficiency
Developer requires to run a client-side SDK for routers auction
Signing to claim adds complexity when design user journey
NXTPv1 allow cross-chain smart contract call only for a case that there’s economical value. Causing a bad developer UX.
Two-side liquidity requires asset rebalancing, reducing capital efficiency
ROI is hard to track with two-step transaction
Poor router liveliness cause users’ funds to be stuck. Making running routers difficult
Canceled transaction doesn’t provide reimbursement for users
🐺 The Amarok Upgrade
15
🐺 Amarok Upgrade
🦾 Solving Problems from NXTPv1
🔧 Introduce New Functionality
How? Let’s Explore
16
Connext enable interoperability to rollups, L1 using a Hub-and-Spoke model
Modular Bridge Design
17
Transport
Execution
Liquidity
Getting the right asset for users
This is handle by Connext AMM
Transport data from source_chain to dest_chain
Handle by off-chain infrastructure
Unpack and execute txn
This is handle by Connext’s backend
Verification
Data verification, ensure cross-chain data integrity
Can be varied: AMBs for L2, IBC for Cosmos,
Optimistic Bridge by Nomad, etc.
Monolithic Bridge
Monolithic bridges handle all functionalities by themselves
Connext’s modular bridge decompose functionalities, allowing easy composability
How it works?
18
Hub
Spoke
Bypass slow path with router’s fast liquidity
Fast path
Transaction fulfilled by off-chain agents (routers, relayers, sequencer)
Slow path
Executing the transaction on the verifier layer (AMBs, IBC, XCMP, etc.)
Verification Channel
(AMBs, IBC, XCMP, etc.)
Dest Chain
Smart Contract
xApps
Smart Contract
xcall
callbacks
Source Chain Smart Contract
A high-level Connext Transaction Flow
19
Underlying bridges
(AMBs, IBC, XCMP, Optimistic Bridge, etc.)
Slow messaging
Routers: Fast Liquidity
AMM
AMM
source_chain
dest_chain
Passive LPs
Active LPs
Passive LPs
DAI
NextDAI
NextDAI
DAI
Off-chain Actors
20
Routers
Sequencer
Service by Gelato
Relayers
Destination Chain
Smart Contracts
$
$
$
$
$
Decentralized network that execute smart contract transactions for users in exchange for a small fees
Collects bids from all chains and randomly select router(s) to fulfill them
Liquidity providers, enable instant liquidity for users. Also simulate a fast path transaction
Anybody can participate, no minimum liquidity required
A Detailed Connext Transaction Lifecycle
21
Bid txn
Transport
Execution
Liquidity
Verification
Hub
source_chain
dest_chain
Spoke
Spoke
Hub
Off-chain Agents
Off-chain Agents
Application
Smart Contracts
Smart Contracts
xApps Smart Contract
AMMs
Getting right assets for AMBs
*AMBs
txn event
Connext
Contract
Call AMBs and emit txn event
Routers observe txn event
xcall
*AMBs
Sequencer
Relayer
Routers
Routers
Simulate observed txn
xApps Smart Contract
AMMs
Catch bid txn
Get right assets from AMBS
Relayer execute smart contracts
Hashed params
Store
Slow *AMB message
goes through Spoke via Ethereum
Validate
Return funds to Routers
xreceive
*This component can be interchangeable, depends on underlying verification protocol (e.g. XCMP, IBC, etc.)
Connext
Contract
Spoke
Connector
MERKLE
Connext
Contract
Hub
Connext
Contract
Spoke
Connector
MERKLE
MERKLE
Routers
AMB
AMB
🔑 Security of Amarok
23
Economic Security of Connext
Depends on the verification protocol that Connext used, different protocol can have different economic security
24
Transport
Execution
Liquidity
Verification
AMBs - L2 to L2 Communication
Optimistic Bridges - General Cross-chain Communication
XCMP, IBC - For communication in Cosmos/Polkadot ecosystem
AMBs (Arbitrary Message Bridges), or a default ETH to Layer-2 bridges, is a natively verified bridge. Therefore, any L2 to L2 communication that utilized AMB as a verification layer have the same economic security as Ethereum mainnet
Optimistic bridge economic security depends on the number of watchers monitoring the bridge events. The cost to corrupt the system is equal to corrupting the whole watchers, which is very expensive
XCMP and IBC is also a natively verified bridge protocol. It have same economic security as their underlying domain
Risks of Amarok, and its Trust Assumption
What do we trust when using Connext?
25
Sequencer
Underlying Verification Security
The sequencer are capable of censorship and extracting MEV, but the transactions are fully secure and trustless. This problem can be mitigated by having a decentralized sequencer
The protocol relies on the underlying verification security such as AMBs, Optimistic Bridges, XCMP, IBC, etc. When using Connext, you’re trusting that the verification layer is safe economically
`
Verification
What’s $NEXT
Governance system for Connext Infrastructure
Powered by $NEXT Token
26
Let’s DAO 🏛
Phase 1 : Completed
Mainnet Launch
🚀
Phase 2 : Soon ser
Token
Launch
We are here! Testing Amarok upgrade on Mainnet!
Connext will pivoted to DAO structure powered by $NEXT
💻 Technical Details
27
EIP-2535: Diamonds, Multi-Facet Proxy
28
Immutable
Smart Contracts
Proxy Smart Contracts*
Multi-Facet Proxy Smart Contracts**
Immutable, unupgradable, limited contract size
Upgradable contracts using proxy pattern
Modular design pattern, multiple proxy to each contracts with each module
Implementation Contract
Proxy Contract
Delegate call
Delegate call
Module Contracts
(Facet)
Proxy Contract
(Diamond)
Smart Contract
💎 Connext Diamond
29
Click here for a full details:
https://louper.dev/diamond/0x8898B472C54c31894e3B9bb83cEA802a5d0e63C6?network=mainnet
delegate call
0x8898B472C54c31894e3B9bb83cEA802a5d0e63C6
Connext Diamond
Bridge Facet
Router Facet
Relayer Facet
Stable Swap Facet
Token Facet
0xe37d4F73ef1C85dEf2174A394f17Ac65DD3cBB81
0x0e93f1e9a44AF236186a8cBCdeb22e2E6564856c
0xBe8D8Ac9a44fBa6cb7A7E02c1E6576E06C7da72D
0xcCb64fDf1c0Cc1aac1C39E5968E82f89c1B8C769
0x9AB5F562Dc2aCcCd1b80d6564B770786e38f0686
Handle xcall, add/remove sequencers
Handle routers functionality (e.g. initialize, add, remove, etc.)
Handle relayers related functions
Handle liquidity swap for local assets
Handle Connext-based asset (e.g. NextDAI, NextUSDC, etc.)
Is Diamond Pattern an implementation risk?
30
NO.
Contracts are upgradable, does it means that Connext have a total control of pushing malicious code?
Connext smart contracts are:
After the token launched, the control will be given to Connext DAO, and timelock would still remains
🐺 Amarok
Connextv1
NO.
Connextv1 use a NO upgradability patterns. This means that the codes are immutable
But this prevent the teams to fix/improve the protocol which is crucial
Immutable
Contracts
📚 Reference
31
References
Special Thanks to
32
sanchaymittal#8853 Engineer @ Connext
arjun#0082 Founders @ Connext