Skip to content

Latest commit

 

History

History
69 lines (38 loc) · 5.28 KB

security.md

File metadata and controls

69 lines (38 loc) · 5.28 KB
Raw

Bridge Security and Crisis management

Audits

Gravity Bridge has been audited by four separate organizations at different times during it's development.

  • Code4rena
  • LeastAuthority
  • Informal Systems
  • Certik

Security strategy

Generally there are three ways bridges are compromised or disrupted, in rough order of frequency

  1. Direct compromise of bridge contract
  2. The bridge is tricked into signing a message or approving an invalid withdraw
  3. Normal bridge operations rely on too few keys and these keys are compromised
  4. A signing key with access to a permissioned role (upgrading the smart contract) is compromised

Preventing solidity vulnerabilities

In order to minimize the attack surface Gravity.sol is less than 700 lines of code total and this solidity code has undergone 3 distinct audits. The code for Gravity.sol is immutable so there is no way to introduce new Solidity vulnerabilities either by accident or intentionally.

Because of this the only practical attacks on Gravity.sol will require the validators Ethereum signatures.

Preventing off-nominal operation

An attacker could for example create false representations of wrapped Ether and then use the bridge to redeem these false tokens for actual WETH. Preventing legitimate holders from redeeming their own.

Gravity Bridge relies on a Cosmos SDK concept called invariants to prevent this. Chain invariants are consistently checked by the validator set and larger community.

Gravity also has bridge specific invariants that confirm integrity within the bridge logic itself.

In the case of an invariants failure the validators can respond by halting the chain, preventing theft of assets and allowing time for the community to develop a response.

Preventing compromise of validator / routine operation keys

All validators currently active on Gravity Bridge are participating in Gravity.sol signing, meaning the difficulty of compromising Gravity.sol is the same as compromising the validator set itself. Given the diverse and rotating nature of validator set membership this is far more difficult than a fixed signer set.

All validator signatures for bridge operations are stored on chain. Meaning an attacker has no way of communicating with signers except through consensus actions.

If the validator set in Gravity.sol is detected to have diverged from a value generated by the chain the chain will automatically halt

If a validator is detected to have signed any Ethereum message not created by the GB chain, they can be slashed when that signature is submitted in an evidence transaction. Slashing the validator will immediately generate an update to the Ethereum copy of the validator set, removing them from the bridge.

These three protections, combined with a general policy of halting the chain if unusual behavior is detected means that it's especially hard to trick the validators into signing an attackers withdraw or validator set replacement.

Compromise of permissioned role

Gravity Bridge is unique among Ethereum bridges in the Cosmos ecosystem in that there are no permissioned roles in any capacity.

An example of a permissioned role relating to safety would be a core team multisig for upgrading the bridge.

An example of a permissioned role relating to liveness would be a core team relayer that is the only key allowed to interact with the bridge on Ethereum.

The Gravity Bridge community has strived for the same level of permissionless security and decentralization as IBC and we observe that most bridge compromises historically come from permissioned bridge roles or excessive centralization.

The Gravity Bridge contract Gravity.sol has no developer backdoor to facilitate upgrades. Instead it is extremely compact, heavily audited, and immutable. This means that no attacker can replace the contract with different code to steal the funds, or compromise core developer machines to access upgrade keys. In order to steal funds from the bridge access to the Ethereum signing keys of validators representing >2/3 voting power is the only path.

Relaying on Gravity Bridge is a market that anyone, even MEV bots can participate in. All oracle info coming from Ethereum is submitted by each individual validator.

Crisis Management

Given that the Gravity core team has no special powers, all crisis response for Gravity Bridge has been built directly into the protocol itself or is based on the validator set taking action.

It is the policy of the Gravity Bridge community to halt the chain if out of the ordinary behavior is detected, automatically if at all possible. The many tools and systems used for detecting abnormal behavior have been discussed in the previous section.

Once the chain has halted the community can evaluate the situation and implement an appropriate response and if needed remediation