BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement

[forcodedancing]

  BEP: 255
  Title: Beacon Chain Asset Reconciliation for Security Enhancement
  Status: Draft
  Type: Standards
  Created: 2023-07-04

BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement

• BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement
  • 1. Summary
  • 2. Motivation
  • 3. Specification
    • 3.1 Asset Reconciliation
    • 3.2 Halt on Reconciliation Error
  • 4. License

1. Summary

This BEP proposes implementing on-chain asset reconciliation on BNB Beacon Chain to improve security.

2. Motivation

As a beacon chain, the BNB Beacon Chain plays a vital role in securing the BNB chain ecosystem. Although some
enhancements have been made to improve cross-chain security, such as BEP171, the security of assets on the BNB Beacon
Chain itself should also be guaranteed, especially after the bridge exploitation. Therefore, this BEP proposes implementing on-chain asset reconciliation.

Specification

3.1 Asset Reconciliation

There are many tokens issued on the BNB Beacon Chain, and they are highly valued assets to users. Therefore,
reconciliation mainly focuses on the balances of all users. However, with millions of users on the BNB Beacon Chain, it
is impossible to review all accounts and reconcile their balances. Therefore, the following approach is proposed, by
only reconciling the accounts changed in each block:

• Firstly, the IAVL store is updated to track the storage keys that have been updated in a block. For example, if there
  is a transfer transaction in a block, the related sender and receiver's storage keys will be tracked.

• Secondly, in each EndBlocker, changes in account balances (e.g., transfers) will be calculated as balance changes for
  all related accounts, and the related token supply changes (e.g., minting) will be calculated as token supply changes,
  by comparing the related values in the current state and previous state with the IAVL trees, which are versioned.

$$ \Delta_{balance} = \sum ( balance_{current\ state} - balance_{previous\ state} ) $$

$$ \Delta_{token\ supply} = \sum ( token\ supply_{current\ state} - token\ supply_{previous\ state} ) $$

• Thirdly, asset reconciliation is conducted by comparing whether the balance changes and token supply changes are
  equal. If there is a reconciliation error (i.e., unbalanced asset changes), the height will be written to the chain
  state, and the blockchain will panic.

$$ reconciliation\ error\ \iff\ \Delta_{balance} \neq \Delta_{token\ supply} $$

3.2 Halt on Reconciliation Error

If a reconciliation error occurs, the blockchain will stop producing new blocks, impacting downstream services such as
bridges, deposits, and withdrawals on exchanges. This drastic action is necessary to protect the chain and its users, so
core developers and community members should investigate the issue as soon as possible. Validators and node operators
should contact the core developers or be prepared to resume the network.

To bring the blockchain back online, a hard fork is needed. In the fork, the reconciliation error must be addressed
correctly; for example, if exploitation exists, related accounts should be blacklisted or corrected. Once the blockchain
is resumed, downstream services can be brought back up as well.

License

The content is licensed under the CC0 license.

[rondales]

Regarding 3.4 APIs
All sub title numbers are incorrect.
3.1.1 should be 3.4.1 etc

[rondales]

BEP: 255
Title: Beacon Chain Asset Reconciliation for Security Enhancement
Status: Draft
Type: Standards
Created: 2023-07-04

BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement

• BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement

  • 1. Summary

  • 2. Motivation

  • 3. Specification

    • 3.1 Asset Reconciliation
    • 3.2 Halt on Reconciliation Error

  • 4. License

1. Summary

This BEP proposes implementing on-chain asset reconciliation on BNB Beacon Chain to improve security.

2. Motivation

As a beacon chain, the BNB Beacon Chain plays a vital role in securing the BNB chain ecosystem. Although some enhancements have been made to improve cross-chain security, such as BEP171, the security of assets on the BNB Beacon Chain itself should also be guaranteed, especially after the bridge exploitation. Therefore, this BEP proposes implementing on-chain asset reconciliation.

Specification

3.1 Asset Reconciliation

There are many tokens issued on the BNB Beacon Chain, and they are highly valued assets to users. Therefore, reconciliation mainly focuses on the balances of all users. However, with millions of users on the BNB Beacon Chain, it is impossible to review all accounts and reconcile their balances. Therefore, the following approach is proposed, by only reconciling the accounts changed in each block:

• Firstly, the IAVL store is updated to track the storage keys that have been updated in a block. For example, if there
  is a transfer transaction in a block, the related sender and receiver's storage keys will be tracked.
• Secondly, in each EndBlocker, changes in account balances (e.g., transfers) will be calculated as balance changes for
  all related accounts, and the related token supply changes (e.g., minting) will be calculated as token supply changes,
  by comparing the related values in the current state and previous state with the IAVL trees, which are versioned.

Δbalance=∑(balancecurrent state−balanceprevious state)

Δtoken supply=∑(token supplycurrent state−token supplyprevious state)

• Thirdly, asset reconciliation is conducted by comparing whether the balance changes and token supply changes are
  equal. If there is a reconciliation error (i.e., unbalanced asset changes), the height will be written to the chain
  state, and the blockchain will panic.

reconciliation error ⟺ Δbalance≠Δtoken supply

3.2 Halt on Reconciliation Error

If a reconciliation error occurs, the blockchain will stop producing new blocks, impacting downstream services such as bridges, deposits, and withdrawals on exchanges. This drastic action is necessary to protect the chain and its users, so core developers and community members should investigate the issue as soon as possible. Validators and node operators should contact the core developers or be prepared to resume the network.

To bring the blockchain back online, a hard fork is needed. In the fork, the reconciliation error must be addressed correctly; for example, if exploitation exists, related accounts should be blacklisted or corrected. Once the blockchain is resumed, downstream services can be brought back up as well.

License

The content is licensed under the CC0 license.

[rondales]

Regarding 3.4 APIs All sub title numbers are incorrect. 3.1.1 should be 3.4.1 etc

[rondales]

BEP: 255
Title: Beacon Chain Asset Reconciliation for Security Enhancement
Status: Draft
Type: Standards
Created: 2023-07-04

BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement

• BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement

  • 1. Summary

  • 2. Motivation

  • 3. Specification

    • 3.1 Asset Reconciliation
    • 3.2 Halt on Reconciliation Error

  • 4. License

1. Summary

This BEP proposes implementing on-chain asset reconciliation on BNB Beacon Chain to improve security.

2. Motivation

As a beacon chain, the BNB Beacon Chain plays a vital role in securing the BNB chain ecosystem. Although some enhancements have been made to improve cross-chain security, such as BEP171, the security of assets on the BNB Beacon Chain itself should also be guaranteed, especially after the bridge exploitation. Therefore, this BEP proposes implementing on-chain asset reconciliation.

Specification

3.1 Asset Reconciliation

There are many tokens issued on the BNB Beacon Chain, and they are highly valued assets to users. Therefore, reconciliation mainly focuses on the balances of all users. However, with millions of users on the BNB Beacon Chain, it is impossible to review all accounts and reconcile their balances. Therefore, the following approach is proposed, by only reconciling the accounts changed in each block:

• Firstly, the IAVL store is updated to track the storage keys that have been updated in a block. For example, if there
  is a transfer transaction in a block, the related sender and receiver's storage keys will be tracked.
• Secondly, in each EndBlocker, changes in account balances (e.g., transfers) will be calculated as balance changes for
  all related accounts, and the related token supply changes (e.g., minting) will be calculated as token supply changes,
  by comparing the related values in the current state and previous state with the IAVL trees, which are versioned.

Δbalance=∑(balancecurrent state−balanceprevious state)

Δtoken supply=∑(token supplycurrent state−token supplyprevious state)

• Thirdly, asset reconciliation is conducted by comparing whether the balance changes and token supply changes are
  equal. If there is a reconciliation error (i.e., unbalanced asset changes), the height will be written to the chain
  state, and the blockchain will panic.

reconciliation error ⟺ Δbalance≠Δtoken supply

3.2 Halt on Reconciliation Error

If a reconciliation error occurs, the blockchain will stop producing new blocks, impacting downstream services such as bridges, deposits, and withdrawals on exchanges. This drastic action is necessary to protect the chain and its users, so core developers and community members should investigate the issue as soon as possible. Validators and node operators should contact the core developers or be prepared to resume the network.

To bring the blockchain back online, a hard fork is needed. In the fork, the reconciliation error must be addressed correctly; for example, if exploitation exists, related accounts should be blacklisted or corrected. Once the blockchain is resumed, downstream services can be brought back up as well.

License

The content is licensed under the CC0 license.