Sui Bridge

[longbowlu]

Sui Bridge

Motivation

Bridges serve a critical role in blockchain ecosystems. They’re the glue that enable digital assets in one ecosystem to have utility in other ecosystems.

Bridges are especially important in early stage chains with promising technology and value propositions, in that they let chains “borrow” well-developed digital assets and experienced users from other chains into their own native dApps. Down the line, this effect is multiplicative since successful dApps foster a healthy environment for native asset issuance.

Thus, a bridge is a key enabler in the growth flywheel: bridges enable existing digital assets to drive native dApps, native dApps drive the growth of native assets, native assets bridge over to other chain ecosystems providing more utility for the native chain’s ecosystem.

To empower more types of cross chain communication and diversify bridging experiences on Sui, we introduce Sui Bridge, a trustless native bridge leveraging Sui’s security model.

This bridge will take a pre-eminent position relative to other, third-party, bridges because it relies on the same security assumptions as Sui’s core network and is developed by the same developer team that built Sui. Hence, trusting Sui Bridge requires the same security assumptions as trusting Sui itself, and this is the Sui Bridge’s strongest value proposition.

Sui Bridge will start as a fungible token bridge between Sui and Ethereum, while making it highly extensible to support new assets, message types and more chains in the future.

Traditionally, Ethereum is the hub of the vast majority of blockchain digital assets and, in practice, most of the assets bridged into Sui have come from Ethereum. Hence, creating a direct connection to the world’s main digital asset hub, together with Sui’s security assumptions, delivers a trustworthy Sui Bridge aimed at further bootstrapping Sui’s digital asset ecosystem.

Bridge Committee

• The bridge committee has the responsibility to authenticate cross chain transfers/messages, upgrading Move/Solidity code and emergency handling. Authentication is explained in Architecture section and the remaining is explained in Security & Risks section.
• Inheriting security characteristics of Sui blockchain, the bridge committee is identical to the active Sui validator set. Namely, every currently active validator is in bridge committee and holds corresponding voting power.

We discuss more about committee management below. In this proposal we use “committee” and “validators” interchangably.

Architecture

The core of Sui Bridge consists of the following components:

1. Off Chain Bridge Node
2. Move Package on Sui
3. Solidity Program on Ethereum

Bridge Node

Every committee member runs a Bridge Node. It observes, verifies, signs BridgeEvents and submits them to Sui.

Bridge Orchestrator, as a part of Bridge Node, monitors BridgeEvents emitted from both Sui and Ethereum. This is done by having access to trusted Full nodes. Upon a new BridgeEvent, Bridge Orchestrator queries all Bridge Nodes and collects their signatures. Once there are over 1/3 verified signatures by stake, it submits them to Sui.

When asked to authenticate a transfer or message, Bridge Node verifies it through trusted fullnodes, and responds with their signatures.

Bridge Node also signs Solidity contract upgrade approvals and emergency mitigation requests.

Move Package

Functionalities of Move code:

1. escrow bridged assets
2. verify committee signatures and store them on chain
3. mint/release assets that are bridged from Ethereum
4. committee management
5. upgradable by committee approval

Solidity Program

Functionalities of Solidity code:

1. escrow bridged assets
2. verify committee signatures
3. mint/release assets that are bridged from Ethereum
4. committee management (passive mirroring that on Sui)
5. upgradable by committee approval

Bridge Flow

Below we present the fungible token bridge flow.

Ethereum → Sui

1. User submits bridge transaction to Sui Bridge contract on Ethereum. The assets-to-bridge is locked and escrowed in the contract, or burned if it’s non native
2. The transaction is executed on Ethereum and emits a BridgeEvent
3. Bridge committee independently observes the finalized BridgeEvent from a trusted Ethereum Full node
4. Bridge committee attests to it by signing the BridgeEvent
5. The signatures are aggregated by Bridge Node and then submitted on Sui, verified by Bridge package. The assets are minted/released and marked as claimable.
6. User, in fact anyone, can claim the assets and deliver to the right address.

Sui → Ethereum

1. User submits bridge transaction on Sui. The assets-to-bridge is locked and escrowed in a shared object, or burned if it’s non native
2. The transaction is executed on Sui and emits a BridgeEvent
3. Bridge committee independently observes this BridgeEvent from a trusted Sui Fullnode
4. Bridge committee attests to it by signing the BridgeEvent
5. The signatures are submitted and verified on Sui
6. User, or anyone, grabs the aggregated signature on Sui
7. Then they submit the signatures to Ethereum. Bridge contract verifies the signatures and deliver the assets to destination address.

These two flows are almost symmetrical, except that we store signatures of both directions on Sui, to make use of Sui’s efficient computation & storage.

Economics

Initially, users do not need to pay fees for using Sui Bridge, except for the gas fees to initiate bridge transfer and claim the assets. As mentioned in Products Integration section below, front ends may be incentivized to subsidize the cost of claiming assets on behalf of the users, making it even cheaper.

As Sui Bridge matures, the economics may change with committee approvals. In particular, Sui validators are incentivized to do run the bridge as a requirement of the Sui Foundation’s delegation program. At some point in the future, however, as the Sui Foundation progresses towards full decentralization, this governance framework will need to be upgraded to ensure the bridge is sustainable on its own in the long-run.

Security & Risks

Bridge Finality

To reduce of the risk of reorganization, an Ethereum transaction is not considered valid and attested by the committee until its block is finalized (≥2 epoch). This means an Ethereum → Sui bridge takes ~13 minutes to settle. A Sui → Ethereum bridge is finalized in seconds and can be claimed on Ethereum within seconds.

Replay Protection

Each bridge transaction is associated with a nonce. The nonce is part of the BridgeEvent emitted on chain and covered in committee’s signed messages. It has two purposes:

1. replay protection. On both Move and Solidity code, a claim attempt will fail if nonce is already used.
2. track status. The bridge transaction’s status can be looked up on chain with the nonce.

Committee Management

The committee management mostly happens on Sui such that we can make the best use of:

1. Sui’s security model and
2. Sui’s efficiency

As aforementioned, each active validator is part of the Bridge committee. Validators register a new ECDSA key as the key to sign attestations/approvals and as the account key to submit transactions. Bridge committee is refreshed every epoch along with Sui epoch change. Validators can rotate their ECDSA key and bridge network address, which takes effect in the next epoch.

Committee info is stored in Ethereum contract. At the beginning of each Sui epoch, Bridge Orchestrator collects signatures from all that attest to the latest committee state, and submit to Ethereum to refresh it. A refresh requires more than one third voting powers.

Package/Contract Upgrade

Sui Bridge Package is part of Sui framework, therefore every upgrade needs 2/3 validators to upgrade to the new binary.

On the Solidity side, it takes at least 1/2 validators to approve a package upgrade.

Safety and Liveness

Safety

All critical operations discussed in this proposal need at least 1/3 voting power to make effects. This is the base trust model of Sui blockchain, making Sui Bridge generally trustless as it does not involve additional trust assumptions.

Liveness

Assets claiming is permissionless: anyone can run a Bridge Orchestrator, or their own script to collect validator signatures and claim the assets.

Contingency Red Buttons

Red buttons exist in Sui Bridge to stopgap unexpected catastrophic failures. For example, once pressed, all operations will cease until it’s unpaused, which is useful in stopping assets from flow outwards in a hack.

To press the red button, it takes at least two validators to collaborate. The exact voting threshold is TBD. The motivation for a small threshold is to stop bleeding very fast in case there is an emergency security issue.

To release the red button, at least 1/2 stake is required.

Curated List of Tokens

To reduce fraud risk and ease the burden of initial liquidity requirement, Sui Bridge will start with a curated list of token. Any bridge attempts with non-allowlisted tokens will cause the transaction to fail.

Products Integration

Composability

With Programmable Transaction, the flow is highly composable with various projects on Sui. For example, to encourage more liquidity inflows, Defi protocols can subsidize gas cost to claim the assets, deposit into a high yield vault, even with a small Sui airdrop for further transactions. This is especially user friendly when a new user starts to explore Sui.

Programmability

A front end widget allows easy integration of Sui Bridge in various protocols.

Phased Development - Sui Bridge V1

The development will happen in a few phases. In V1, we will simplify a few features without disruptively altering the security assumptions and other characteristics discussed above. Particularly, in V1, the bridge committee is static, namely not changing along with Sui active validators set every epoch. By analyzing historical validator set changes, the risk introduced by fixing the committee is small. In the meantime, we gain more confidence in dynamic committee implementation while allows Sui Bridge to have early feedback and integrate with other products.

Committee Blocklist

As a simplified governance policy In V1, in both Move and Solidity we keep a blocklist for byzantine committee members. When one is added to the blocklist, its signatures and votes are considered illegitimate instantaneously.

At least 1/2 voting power is required to add a committee member to or remove from the blocklist.

Open Source & Auditing

Core code, including Move, Solidity and Bridge Node, would be open sourced and thoroughly audited before launch on mainnet.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.