✖️Cross-Chain Bridges Security Model
Last updated
Last updated
Cross-chain bridges were recently implemented connecting the Callisto chain to the Binance smart-chain and Ethereum mainnet.
For this time, we followed a centralized approach where the 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 an unlimited quantity of funds on behalf of the contract.
A conception of layered security was used when designing the system and access restrictions model.
A Cross-chain bridge allows users to swap assets from one chain to another. 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.
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 from 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 72 hours after the function invocation.
Callisto Bridges rely on “Authorities” as relays. Every Authority is a special account (with its own private key) that 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 minimum of 3 Authority signatures from different Authorities are required to consider that the transfer is valid. Every Authority has freeze permission to 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.
One “required” authority must sign every transfer — without this signature, the transfer can not be validated even if it has sufficient signatures from other authorities.
There can be special accounts with “Freeze” permission that does not have permission to sign transfers. These accounts are only used to observe the authorities.
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:
unfreeze the contract
set authorities threshold, which is required to validate a cross-chain transfer and mint new tokens
set the address that receives fees from cross-chain transfers (if fees are enabled)
disable setup mode immediately
“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.
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.
