BEP(idea) Introduce built-in security at the chain level

BEP
1

To enhance blockchain security, Builders/Validators should incorporate a security prioritization mechanism that prioritizes the inclusion of “rescue transactions” in blocks while delaying or rejecting “attack transactions.”

This involves:

  1. Accurate identification of transaction types:
    Leveraging machine learning models to analyze transaction features (e.g., gas price, target address).
    Utilizing community-driven identification systems and oracle-assisted methods.
    In oracle-assisted methods, it allow multiple certified organizations to submit information on-chain simultaneously (information includes which transactions hash are attack transactions), for Builders/Validators to make comprehensive judgments. Here, we can design a voting mechanism.

    Based on our understanding, there are already many mature systems for real-time online identification of attack transactions, such as Ancilia, Blocksec, Cyvers, TenAromr, etc.

  2. Application integration:
    DApps can use security mechanisms in two modes: active and passive, corresponding to actively sending “rescue transactions” and passively rejecting “attack transactions.”

    In active mode: DApps need to provide a pause interface in advance within the application contract code (as we can see in Radiant Capital attack cases) and choose their security partners in the market. These partners assist in completing the “Accurate identification of transaction types,” i.e., when a security risk is detected, they send “rescue transactions,” call the pause interface, suspend the protocol, and avoid attacks.

    In passive mode: DApps only need to leave contact information or written authorization for third parties to help. The third parties complete the monitoring and reject “attack transactions.” Then, DApps receive immediate notifications and handle the situation promptly.

  3. Priority sorting algorithm:
    Assigning different priority levels to “rescue transactions” and “attack transactions.”
    Dynamically adjusting priorities based on network conditions and attack patterns.
    Incentive mechanism:
    Rewarding users submitting “rescue transactions.”
    Penalizing those submitting “attack transactions.”

    A possible implementation of passive mode is:
    In oracle-assisted methods, when multiple security institutions jointly vote consistently, we reject “attack transactions.”

    A possible implementation of active mode is:
    For specific marked “rescue transactions” sent by the contract owner (from and to addresses satisfying the owner relationship), prioritize them over other transactions for Block building, not limited by gas fees.

  4. Community-driven/fair transaction monitoring and inspection:
    third-party organizations like AvengerDAO need to organize security institutions to jointly participate in the review of all TXs by Builders/Validators before Block building. This process needs to ensure neutrality and fairness while avoiding TX leakage.

1 Like