Apply timer lock to massive funds cross-chain transfer.
Cross chain channels can be automatically paused by forged proof detection.
Cross chain channels can be paused by any validator in an emergency.
2. Motivation
A full in-depth security review of BSC cross-chain bridge and Cosmos related codebase is done after the bridge exploitation. The community is still really concerned there could be potential security issues in the cross chain module. This BEP aims to:
Share the same security level as CosmosHub by upgrading the old IAVL lib to the latest ICS23 implementation. The two teams(BNB-Chain and Cosmos) can consistently transmit security updates, best practices, and revised standards for secure operations.
Exploitation automatic detection, quick action without human intervention.
Increase the cost of the attack, like timer lock.
3. Specification
3.1 ICS23 Upgrade
ICS23 attempts to define a generic, cross-language, binary representation of merkle proofs, which can be generated by many underlying merkle tree storage implementations and validated by many client libraries over various languages. Currently, ICS23 provides a standard representation for proofs that accompany IBC (inter-blockchain communication) packets as defined in the cosmos specification. This BEP will abandon the stale raw IAVL merkle proof verification and upgrade to ICS23 specification.
3.2 Timelock
If the value of the cross chain transfer is larger than a predefined threshold, the funds will be locked in TokenHub for a fixed period before they can be withdrawn to the target account.
The default threshold of BNB is 10K, and the default lock period is 6 hours, both of them are governable. However, it is hard to set a proper threshold for other BEP20 tokens. We will grant the token owner permission to decide a proper threshold. The interface to set transfer threshold is as follows:
function setLargeTransferLimit(address bep20Token, uint256 largeTransferLimit) external onlyTokenOwner(bep20Token);
Once the funds are unlocked, anyone is able to withdraw the funds to the target account. The whitelist relayers will send the unlock withdrawal transaction by default to provide better user experience.
3.3 Exploitation Automatic Detection
The forged cross chain transaction shares the same channel and sequence with the real cross chain transaction, and both of them can be successfully verified by its merkle proof, while the payload of two transactions are different, such a trait can be used to detect forged cross chain packages.
3.3.1 Challenge
Anyone is allowed to submit a transaction to challenge the verified cross chain package on BSC. The interface is shown as below:
Once the challenge passes the merkle proof verification, the cross chain contract will compare the hash of current payload0 and payload1. If the two payloads are different, it means one of the challenge packages is invalid, the cross chain communication will be suspended automatically.
3.3.2 Suspension in case of Emergency
The cross chain contract will be suspended if anyone succeeds in the challenge. Cabinet validators could also suspend the cross chain contract by sending a suspension transaction to the cross chain contract in case of emergency. After that, all cross chain channels will be suspended. The interface of this suspension transaction is shown as below:
function emergencySuspend() onlyCabinet whenNotSuspended external;
Withdrawals of large transfers will also be suspended during the suspension of cross chain. The cross chain contract could reopen through the validators by using the interface below:
function reopen() onlyCabinet whenSuspended external;
3.4 Cancel Cross Chain Transfer
The attacker's cross-chain transfer can be canceled by cabinet validators. The interface is shown as below:
function cancelTransfer(address receiver) onlyCabinet external;
The funds of this account in the timer lock will be returned to TokenHub to prevent someone minting tokens from nothing.
BEP-171: Security Enhancement for Cross-Chain Module
1. Summary
This BEP introduces several security enhancements for the cross-chain bridge between BNB Beacon Chain and BNB Smart Chain.
To further eliminate the pervasive effects of potential issues in cross chain module, it proposes the following enhancements:
2. Motivation
A full in-depth security review of BSC cross-chain bridge and Cosmos related codebase is done after the bridge exploitation. The community is still really concerned there could be potential security issues in the cross chain module. This BEP aims to:
3. Specification
3.1 ICS23 Upgrade
ICS23 attempts to define a generic, cross-language, binary representation of merkle proofs, which can be generated by many underlying merkle tree storage implementations and validated by many client libraries over various languages. Currently, ICS23 provides a standard representation for proofs that accompany IBC (inter-blockchain communication) packets as defined in the cosmos specification. This BEP will abandon the stale raw IAVL merkle proof verification and upgrade to ICS23 specification.
3.2 Timelock
If the value of the cross chain transfer is larger than a predefined threshold, the funds will be locked in TokenHub for a fixed period before they can be withdrawn to the target account. The default threshold of BNB is 10K, and the default lock period is 6 hours, both of them are governable. However, it is hard to set a proper threshold for other BEP20 tokens. We will grant the token owner permission to decide a proper threshold. The interface to set transfer threshold is as follows:
Once the funds are unlocked, anyone is able to withdraw the funds to the target account. The whitelist relayers will send the unlock withdrawal transaction by default to provide better user experience.
3.3 Exploitation Automatic Detection
The forged cross chain transaction shares the same channel and sequence with the real cross chain transaction, and both of them can be successfully verified by its merkle proof, while the payload of two transactions are different, such a trait can be used to detect forged cross chain packages.
3.3.1 Challenge
Anyone is allowed to submit a transaction to challenge the verified cross chain package on BSC. The interface is shown as below:
Once the challenge passes the merkle proof verification, the cross chain contract will compare the hash of current payload0 and payload1. If the two payloads are different, it means one of the challenge packages is invalid, the cross chain communication will be suspended automatically.
3.3.2 Suspension in case of Emergency
The cross chain contract will be suspended if anyone succeeds in the challenge. Cabinet validators could also suspend the cross chain contract by sending a suspension transaction to the cross chain contract in case of emergency. After that, all cross chain channels will be suspended. The interface of this suspension transaction is shown as below:
Withdrawals of large transfers will also be suspended during the suspension of cross chain. The cross chain contract could reopen through the validators by using the interface below:
3.4 Cancel Cross Chain Transfer
The attacker's cross-chain transfer can be canceled by cabinet validators. The interface is shown as below:
The funds of this account in the timer lock will be returned to TokenHub to prevent someone minting tokens from nothing.
4. Reference
ICS23 spec: https://github.com/cosmos/ibc/tree/main/spec/core/ics-023-vector-commitments
5. License
All the content are licensed under CC0.