Security model of cross-chain bridges

Intro

A cross-chain bridges were recently implemented connecting Callisto chain to Binance smart-chain and Ethereum mainnet.

For this time we followed a centralized approach where Callisto team will hold a set of servers as “authorities” that sign cross-chain transactions (and forward data from one chain’s contract to another). In this system security is critical because an attack vector would allow a hacker to print unlimited quantity of funds on behalf of the contract.

A conception of layered security was used when designing the system and access restrictions model.

Cross-chain Bridges in a nutshell

Cross-chain bridge allows users to swap assets from one chain to another. In fact it’s a pair of two contracts at two different chains. One contract accepts a selected asset at the first chain and freezes it. At the same time this contract emits a signal for the second contract to create the same quantity of “wrapped” tokens at the second chain.

The problem here is that contracts can not transfer data from one chain to another and there must be a relay that will take the signal from one contract and deliver it to another telling it that some action needs to be performed.

Contract modes

The contract system may operate in different modes.

  • Setup Mode — some “risky” functions are only available in setup mode. Only ‘Owner’ can enable the setup mode but it will be enabled after 24 hours since the moment of the function invocation.
  • Frozen — the contract is not actively processing cross-chain swaps in this mode. Special accounts with “Freeze” permissions can freeze the contract immediately in case of anomaly detection. Returning the contract to the normal mode requires ‘Owner’ permission and “Setup Mode”.
  • Upgrading — it is possible to switch this contract to a newer version deployed at a new address. Upgrading requires ‘Owner’ permission and can be performed in 72 hours after the function invocation.

Authorities — low trust / minimal permissions

Callisto Bridges rely on “Authorities” as relays. Every Authority is a special account (with its own private key) which is governed by a script at its dedicated server. Storing private keys on a server is not secure — that’s why Authorities are not trusted and only given a minimal set of privileges.

Every Authority is located at its own server.

Authority should only sign transfers. A minimal of 3 Authority signatures from different Authorities are required to consider that the transfer is valid. Every Authority has freeze permission so it can stop the contract if it observes the misbehavior of other authorities.

It is considered that an Authority can be malfunctioning or compromised during the workflow.

There is one “required” authority that must sign every transfer — without this signature the transfer can not be validated even if it has sufficient signatures from other authorities.

Freezers —emergency stop permissions

There can be special accounts with “Freeze” permission that do not have a permission to sign transfers. These accounts are only used to observe the authorities.

Owner — governance permissions

A special account is granted “Owner” permissions to debug the contract or punish malfunctioning authorities in the event of misbehavior.

Owner can remove authorities immediately.

Owner can enable “setup mode” to gain access to debugging functions of the contract but the setup mode will be enabled after 24 hours since the function call.

In setup mode the owner can:

“Owner” is a multisig account with its own internal logic under the hood. A consensus model of (50% + 1) is used which means that 3 owners of 5 total engaged accounts must approve an action in order to execute it.

The “Owners multisig” will be used to set up the contract which means that the owner keys are sometimes used to sign transactions and possibly exposed to some services. Owner keys are initially given to 5 different persons.

Founders — the least exposed keys

There is an additional special account called “Founders multisig”. This account has no permissions but to replace an “Owners” multisig with a new one in case Owners keys are compromised.

This action can be effective immediately which means that the “founders multisig” can replace Owners before it can enable the Setup mode.

Founders have no other permissions and these keys will never be exposed during the normal contract workflow unlike Owners multisig.

Founders multisig consists of 5 accounts (different from those at Owners multisig) and a consensus model of (50%+1) is used.

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Proof-of-Stake on Cosmos Network, explained to my dog.

CRODO : IDO AND Significantly MORE:

Neo Founder Da Hongfei on the Future of the Digital Economy with Blockchain.News

Behind the scenes at 🚀 ODIN Blockchain

BlockTalks x Base Protocol 2nd AMA Transcript!

Blockchain: Everything you need to know

Authoreon launches the A-ID, the World’s First Machine-Readable Optical Label on the Blockchain

Entering the Fray: NFT Promotional Models for SMBs, Sustainable Brands and B Corp Marketing

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Dexaran

Dexaran

More from Medium

How Virgo Ledger plans to solve the Blockchain Trilemma

NEXT SMART Chain, MAIN NET release v1.0 (Orion)

What is Avalanche and why do we use it? 🅰️🏔️

Bribe — A governance marketplace