├── BEPs ├── BEP-225.md ├── BEP-229.md ├── BEP-230.md ├── BEP-293.md ├── BEP-299.md ├── BEP-311.md ├── BEP-312.md ├── BEP-319.md ├── BEP-334.md ├── BEP-335.md ├── BEP-336.md ├── BEP-341.md ├── BEP-342.md ├── BEP-343.md ├── BEP-344.md ├── BEP-345.md ├── BEP-346.md ├── BEP-362.md ├── BEP-363.md ├── BEP-364.md ├── BEP-366.md ├── BEP-381.md ├── BEP-402.md ├── BEP-404.md ├── BEP-410.md ├── BEP-414.md ├── BEP-439.md ├── BEP-440.md ├── BEP-441.md ├── BEP-466.md ├── BEP-496.md ├── BEP-497.md ├── BEP-520.md ├── BEP-524.md ├── BEP-525.md ├── BEP-536.md ├── BEP-543.md ├── BEP-563.md ├── BEP-564.md ├── BEP1.md ├── BEP10.md ├── BEP12.md ├── BEP126.md ├── BEP127.md ├── BEP128.md ├── BEP130.md ├── BEP131.md ├── BEP151.md ├── BEP153.md ├── BEP159.md ├── BEP171.md ├── BEP172.md ├── BEP173.md ├── BEP174.md ├── BEP18.md ├── BEP188.md ├── BEP19.md ├── BEP194.md ├── BEP2.md ├── BEP20.md ├── BEP206.md ├── BEP212.md ├── BEP216.md ├── BEP217.md ├── BEP221.md ├── BEP226.md ├── BEP227.md ├── BEP228.md ├── BEP231.md ├── BEP255.md ├── BEP294.md ├── BEP297.md ├── BEP3.md ├── BEP322.md ├── BEP323.md ├── BEP333.md ├── BEP39.md ├── BEP6.md ├── BEP64.md ├── BEP67.md ├── BEP70.md ├── BEP8.md ├── BEP82.md ├── BEP84.md ├── BEP86.md ├── BEP87.md ├── BEP89.md ├── BEP9.md ├── BEP91.md ├── BEP93.md ├── BEP95.md └── assets │ ├── BEP-188 │ ├── broadcast_without_limit.png │ ├── consensus_adaption.png │ ├── early_broadcast_with_limit.png │ └── mining_process_normal.png │ ├── BEP-225 │ ├── Complexity_Regression.png │ └── GQuad_Change.png │ ├── BEP-293 │ └── cross_chain.png │ ├── BEP-319 │ ├── 4.1-current-fee-distribution.png │ └── 4.2-new-fee-distribution.png │ ├── BEP-335 │ ├── 4-3-new-sp-graceful-exit-procedure.png │ └── 4.1.2-VGF.png │ ├── BEP-336 │ ├── blob_expire.png │ └── blob_gasprice.png │ ├── BEP-364 │ └── workflow.png │ ├── BEP-366 │ └── workflow.png │ ├── BEP-381 │ ├── benchstat_compare_test │ ├── ecrecover_benchmark_test │ └── p256Verify_benchmark_test │ ├── BEP-402 │ └── 4-1.png │ ├── BEP-404 │ └── 4-1.png │ ├── BEP-525 │ ├── 3-1-2.png │ └── 3-1.png │ ├── BEP-536 │ └── 3-2.png │ ├── BEP-564 │ └── image1.png │ ├── bep-1 │ └── workflow.png │ ├── bep-128 │ └── reward-distribution.png │ ├── bep-130 │ ├── 1_overview.png │ ├── 2_workflow.png │ ├── 3_pipeline.png │ ├── 4_init.png │ ├── 5_dispatcher.png │ ├── 6_stages.png │ └── 7_conflict_window.png │ ├── bep-131 │ ├── 5.1_overview.png │ ├── 5.2_workflow.png │ └── 5.5_election.png │ ├── bep-153 │ ├── 5.1_framework.jpg │ ├── 5.2_stake.jpg │ ├── 5.3_errorhandle.jpg │ └── SampleStakingContract.sol │ ├── bep-194 │ └── node_distribution.png │ ├── bep-206 │ ├── 1_components.png │ ├── 2_workflow.png │ ├── 3_epochTree.png │ ├── 4_epochKey.png │ ├── 5_trieMeta.png │ ├── 6_extendedBranchNode.png │ └── 7_snapshot.png │ ├── bep-294 │ ├── 5.1_framework.png │ ├── 5.2_stakehub.png │ └── 5.3_update_eligible_validators.png │ ├── bep-299 │ ├── asset_recovery_app.png │ └── asset_tree.png │ ├── bep-322 │ ├── block_timing.png │ ├── workflow_1round.png │ ├── workflow_2round.png │ ├── workflow_2round_proxy.png │ └── workflow_topology.png │ ├── bep-323 │ ├── bundle_encoding.png │ └── bundle_struct.png │ ├── bep-333 │ └── phases.png │ ├── bep-341 │ ├── 4.1-1.png │ ├── 4.1-2.png │ ├── 4.1-3.png │ ├── 4.1-4.png │ ├── 4.1-5.png │ ├── 4.1-6.png │ ├── 4.2.1.png │ ├── 4.2.2.png │ ├── 4.2.3.png │ ├── 4.2.5-1.png │ └── 4.2.5-2.png │ ├── bep-363 │ └── 4.1.1_framework.png │ ├── bep-414 │ ├── wallet-interact.png │ └── workflow.png │ ├── bep-439 │ ├── add_G1_bls.json │ ├── add_G2_bls.json │ ├── bench_vectors.md │ ├── fail-add_G1_bls.json │ ├── fail-add_G2_bls.json │ ├── fail-map_fp2_to_G2_bls.json │ ├── fail-map_fp_to_G1_bls.json │ ├── fail-mul_G1_bls.json │ ├── fail-mul_G2_bls.json │ ├── fail-multiexp_G1_bls.json │ ├── fail-multiexp_G2_bls.json │ ├── fail-pairing_check_bls.json │ ├── fast_subgroup_checks.md │ ├── field_to_curve.md │ ├── map_fp2_to_G2_bls.json │ ├── map_fp_to_G1_bls.json │ ├── mul_G1_bls.json │ ├── mul_G2_bls.json │ ├── multiexp_G1_bls.json │ ├── multiexp_G2_bls.json │ ├── pairing_check_bls.json │ └── test-vectors.md │ └── bep-520 │ └── 5-3.png └── README.md /BEPs/BEP-311.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 311
 3 |   Title: Implement EIP-3651: Warm COINBASE
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2023-10-30
 7 |
8 | 9 | 10 | # BEP-311: Implement EIP-3651 Warm COINBASE 11 | 12 | - [BEP-311: Implement EIP-3651 Warm COINBASE](#bep-311-implement-eip-3651-warm-coinbase) 13 | - [1. Summary](#1-summary) 14 | - [2. Abstract](#2-abstract) 15 | - [3. Motivation](#3-motivation) 16 | - [4. Specification](#4-specification) 17 | - [5. Rationale](#5-rationale) 18 | - [6. Backwards Compatibility](#6-backwards-compatibility) 19 | - [7. Security Considerations](#7-security-considerations) 20 | - [8. License](#8-license) 21 | - [9. Reference](#9-reference) 22 | 23 | 24 | ## 1. Summary 25 | As part of Shanghai upgrade, EIP-3651: Warm COINBASE is required to be implemented to BSC. 26 | 27 | ## 2. Abstract 28 | 29 | The `COINBASE` address shall be warm at the start of transaction execution, in accordance with the actual cost of reading that account. 30 | 31 | ## 3. Motivation 32 | 33 | Direct `COINBASE` payments are becoming increasingly popular because they allow conditional payments, which provide benefits such as implicit cancellation of transactions that would revert. 34 | But accessing `COINBASE` is overpriced; the address is initially cold under the access list framework introduced in [EIP-2929](./eip-2929.md). 35 | This gas cost mismatch can incentivize alternative payments besides ETH, such as [ERC-20](./eip-20.md), but ETH should be the primary means of paying for transactions on Ethereum. 36 | 37 | ## 4. Specification 38 | 39 | At the start of transaction execution, `accessed_addresses` shall be initialized to also include the address returned by `COINBASE` (`0x41`). 40 | 41 | ## 5. Rationale 42 | 43 | The addresses currently initialized warm are the addresses that should already be loaded at the start of transaction validation. 44 | The `ORIGIN` address is always loaded to check its balance against the gas limit and the gas price. 45 | The `tx.to` address is always loaded to begin execution. 46 | The `COINBASE` address should also be always be loaded because it receives the block reward and the transaction fees. 47 | 48 | ## 6. Backwards Compatibility 49 | 50 | There are no known backward compatibility issues presented by this change. 51 | 52 | ## 7. Security Considerations 53 | 54 | There are no known security considerations introduced by this change. 55 | 56 | ## 8. License 57 | 58 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 59 | 60 | ## 9. Reference 61 | 62 | William Morriss (@wjmelements), "EIP-3651: Warm COINBASE," Ethereum Improvement Proposals, no. 3651, July 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3651. -------------------------------------------------------------------------------- /BEPs/BEP-312.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 312
 3 |   Title: Announce EIP-6049: Deprecate SELFDESTRUCT
 4 |   Status: Review
 5 |   Type: Standards
 6 |   Created: 2023-10-30
 7 |
8 | 9 | # BEP-312: Announce EIP-6049 Deprecate SELFDESTRUCT 10 | 11 | - [BEP-312: Announce EIP-6049 Deprecate SELFDESTRUCT](#bep-312-announce-eip-6049-deprecate-selfdestruct) 12 | - [1. Summary](#1-summary) 13 | - [2. Abstract](#2-abstract) 14 | - [3. Motivation](#3-motivation) 15 | - [4. Specification](#4-specification) 16 | - [5. Rationale](#5-rationale) 17 | - [6. Backwards Compatibility](#6-backwards-compatibility) 18 | - [7. Security Considerations](#7-security-considerations) 19 | - [8. License](#8-license) 20 | - [9. Reference](#9-reference) 21 | 22 | 23 | ## 1. Summary 24 | As part of Shanghai upgrade, EIP-6049: Deprecate SELFDESTRUCT is required to be announced in the BSC community. 25 | 26 | ## 2. Abstract 27 | 28 | This EIP deprecates the `SELFDESTRUCT` opcode and warns against its use. A breaking change to this functionality is likely to come in the future. 29 | 30 | ## 3. Motivation 31 | 32 | Discussions about how to change `SELFDESTRUCT` are ongoing. But there is a strong consensus that *something* will change. 33 | 34 | ## 4. Specification 35 | 36 | Documentation of the `SELFDESTRUCT` opcode is updated to warn against its use and to note that a breaking change may be forthcoming. 37 | 38 | ## 5. Rationale 39 | 40 | As time goes on, the cost of doing something increases, because any change to `SELFDESTRUCT` will be a breaking change. 41 | 42 | The Ethereum Blog and other official sources have not provided any warning to developers about a potential forthcoming change. 43 | 44 | ## 6. Backwards Compatibility 45 | 46 | This EIP updates non-normative text in the Yellow Paper. No changes to clients is applicable. 47 | 48 | ## 7. Security Considerations 49 | 50 | None. 51 | 52 | ## 8. License 53 | 54 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 55 | 56 | ## 9. Reference 57 | 58 | William Entriken (@fulldecent), "EIP-6049: Deprecate SELFDESTRUCT," Ethereum Improvement Proposals, no. 6049, November 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6049. -------------------------------------------------------------------------------- /BEPs/BEP-319.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 319
 3 |   Title: Optimize the incentive mechanism of the Fast Finality feature
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2023-11-13
 7 |   Discussions(optional): https://forum.bnbchain.org/t/bep-319-make-rewards-for-fast-finality-governable/2174
 8 |
9 | 10 | # BEP-319: Optimize the incentive mechanism of the Fast Finality feature 11 | 12 | 13 | 14 | 15 | 16 | - [BEP-319: Optimize the incentive mechanism of the Fast Finality feature](#bep-319-optimize-the-incentive-mechanism-of-the-fast-finality-feature) 17 | - [1. Summary](#1-summary) 18 | - [2. Abstract](#2-abstract) 19 | - [3. Motivation](#3-motivation) 20 | - [4. Specification](#4-specification) 21 | - [4.1 Governable Rewards](#41-governable-rewards) 22 | - [4.1.1 Existing Allocation Logic](#411-existing-allocation-logic) 23 | - [4.1.2 Allocation Logic Moved to the Contract](#412-allocation-logic-moved-to-the-contract) 24 | - [4.1.3 Maintain Burn Ratio](#413-maintain-burn-ratio) 25 | - [4.2 Balancing Rewards](#42-balancing-rewards) 26 | - [4.3 Extending Submission Deadline for Malicious Voting Evidence](#43-extending-submission-deadline-for-malicious-voting-evidence) 27 | - [5. License](#5-license) 28 | 29 | 30 | 31 | 32 | 33 | ## 1. Summary 34 | This BEP proposes three optimizations to the incentive mechanism of the Fast Finality feature in BSC. 35 | 36 | ## 2. Abstract 37 | The proposal focuses on three key optimizations for the incentive mechanism of the Fast Finality feature: 38 | 1. Making Fast Finality rewards governable while maintaining the basic block transaction fee allocation ratio. 39 | 2. Ensuring a more balanced distribution of Fast Finality rewards between epochs. 40 | 3. Extending the submission deadline for malicious voting evidence. 41 | 42 | ## 3. Motivation 43 | The introduction of the Fast Finality feature in BSC significantly reduces the time required for transaction final confirmation. This feature represents a substantial advantage for BSC compared to other EVM-compatible chains. The purpose of this BEP is to solidify and enhance this advantage. 44 | 45 | ## 4. Specification 46 | ### 4.1 Governable Rewards 47 | Currently, the reward is approximately 1/16 of the block transaction fees, leading to a lack of incentive for some validators to participate in voting, thereby reducing the stability expectation of the Fast Finality feature. This BEP makes Fast Finality rewards governable, laying the groundwork for future reward enhancements. 48 | #### 4.1.1 Existing Allocation Logic 49 |
50 | 51 |
52 | The existing allocation steps are as follows: 53 | 54 | 1. Validators collect transaction fees from within the block. 55 | 2. In the client, if the balance of the SystemRewardContract is less than 100 BNB, 1/16 of the collected transaction fees is allocated as rewards for relayers and Fast Finality voting. The remainder is deposited into the ValidatorContract. 56 | 3. Within the ValidatorContract, 10% of the deposited amount is burned directly, and the remainder serves as potential earnings for validators and stakers. 57 | 58 | #### 4.1.2 Allocation Logic Moved to the Contract 59 |
60 | 61 |
62 | Due to the deposition of the SystemRewardContract being in the client, requiring hard forks for each change, and for ease of governance, it is moved to the smart contract. The adjusted allocation logic is as follows: 63 | 64 | 1. Validators collect transaction fees from within the block and deposit all into the ValidatorContract. 65 | 2. Deposit systemRewardRatio of transaction fees into the SystemRewardContract, where systemRewardRatio is governable, with an initial value of 1/16. 66 | 3. Within the ValidatorContract, 10% of the deposited amount is burned directly, and the remainder serves as potential earnings for validators and stakers. 67 | #### 4.1.3 Maintain Burn Ratio 68 | The real-time burning mechanism constitutes a pivotal element within the BNB deflationary strategy. With the inception of the burn mechanism in BEP-95, a fractional segment of the SystemRewardContract balance was earmarked for relayer incentive fees, while the burn ratio was calibrated to approximate 10% of the collected block transaction fees. 69 | The present BEP adheres to the consistency established in BEP-95, upholding a burn ratio of 10%. 70 | ## 4.2 Balancing Rewards 71 | Fast Finality rewards are unevenly distributed between epochs. Assuming the current balance of the systemReward contract is currentSystemRewardBalance, and the balance after award distribution in the previous epoch is previousSystemRewardBalance, the totalReward calculation formula is as follows: 72 | ``` 73 | if currentSystemRewardBalance > 100BNB 74 | totalReward = currentSystemRewardBalance / 100 75 | else 76 | totalReward = (currentSystemRewardBalance - previousSystemRewardBalance) * 0.5 77 | ``` 78 | This algorithm allocates a portion of the systemReward contract balance increment for each epoch, causing the systemReward contract balance to continuously grow. When it exceeds 100BNB, a reward exceeding 1 BNB is distributed at once, far more than other epochs. 79 | The new formula is as follows: 80 | ``` 81 | if currentSystemRewardBalance > 100BNB 82 | totalReward = currentSystemRewardBalance - 100BNB 83 | else 84 | totalReward = 0 // this rarely happens because validators keep depositing and relayers consume much less 85 | ``` 86 | This formula allocates the entire increment of the systemReward contract balance for each epoch, resulting in a more even distribution. 87 | 88 | ## 4.3 Extending Submission Deadline for Malicious Voting Evidence 89 | When rule-violating votes occur, the current requirement is to submit evidence within 256 blocks; otherwise, rewards cannot be obtained, and malicious validators are not penalized. 90 | This BEP proposes making the submission deadline governable, initialized to 3 days, for increased operability. 91 | 92 | ## 5. License 93 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP-334.md: -------------------------------------------------------------------------------- 1 | 
  2 |   BEP: 334
  3 |   Title: Greenfield CrossChain Permission Module
  4 |   Status: Draft
  5 |   Type: Standards
  6 |   Created: 2023-12-06
  7 |
8 | 9 | # BEP-334: Greenfield CrossChain Permission Module 10 | 11 | 12 | 13 | 14 | 15 | - [BEP-334: Greenfield CrossChain Permission Module](#bep-334-greenfield-crosschain-permission-module) 16 | - [1. Summary](#1-summary) 17 | - [2. Abstract](#2-abstract) 18 | - [3. Motivation](#3-motivation) 19 | - [4. Specification](#4-specification) 20 | - [4.1 Definitions](#41-definitions) 21 | - [4.2 Interface](#42-interface) 22 | - [4.2.1 Create Policy](#421-create-policy) 23 | - [4.2.2 Delete Policy](#422-delete-policy) 24 | - [5. License](#5-license) 25 | 26 | 27 | 28 | 29 | 30 | ## 1. Summary 31 | Currently, Greenfield supports creating buckets and groups from the smart contracts deployed on BSC/opBNB. This means that the owner of a bucket can be a contract address. However, contract addresses cannot upload objects or put policies under the bucket, resulting in empty buckets owned by smart contracts. 32 | To address this issue, we are going to introduce the cross-chain permission module. With this BEP, smart contracts can grant EOA addresses the ability to upload objects under their buckets, and even support additional functions. 33 | 34 | ## 2. Abstract 35 | Greenfield CrossChain Permission Module has several significant differences and improvements compared to current implementations: 36 | - BSC/opBNB account is allowed to put policy for Greenfield resources. 37 | - BSC/opBNB account is allowed to disable policy for Greenfield resources. 38 | 39 | ## 3. Motivation 40 | In the current framework, Users can use the "policy put [RESOURCE-URL]" command to assign read/write permissions to other accounts or groups (called principal) for GreenField resource, such as the permission to delete objects. 41 | Users could only change the permissions on Greenfield. The proposal allows Greenfield users to change the read/write permissions of GreenField resource directly on the BSC/opBNB network. 42 | 43 | ## 4. Specification 44 | ### 4.1 Definitions 45 | - PermissionHub Contract: A new middle-layer contract to request permission changes from BSC/opBNB to Greenfield 46 | 47 | ### 4.2 Interface 48 | #### 4.2.1 Create Policy 49 | The interface to create policy is as follows: 50 | **function createPolicy(bytes calldata _data, ExtraData memory _extraData) external;** 51 | `_data` is the protobuf encoded bytes of the struct MsgPutPolicy as follows: 52 | ```golang 53 | type Policy struct { 54 | Id Uint `protobuf:"bytes,1,opt,name=id,proto3,customtype=Uint" json:"id"` 55 | Principal *Principal `protobuf:"bytes,2,opt,name=principal,proto3" json:"principal,omitempty"` 56 | ResourceType resource.ResourceType `protobuf:"varint,3,opt,name=resource_type,json=resourceType,proto3,enum=greenfield.resource.ResourceType" json:"resource_type,omitempty"` 57 | ResourceId Uint `protobuf:"bytes,4,opt,name=resource_id,json=resourceId,proto3,customtype=Uint" json:"resource_id"` 58 | Statements []*Statement `protobuf:"bytes,5,rep,name=statements,proto3" json:"statements,omitempty"` 59 | ExpirationTime *time.Time `protobuf:"bytes,6,opt,name=expiration_time,json=expirationTime,proto3,stdtime" json:"expiration_time,omitempty"` 60 | } 61 | 62 | type Statement struct { 63 | Effect Effect `json:"effect,omitempty"` 64 | Actions []ActionType `json:"actions,omitempty"` 65 | Resources []string `protobuf:"bytes,3,rep,name=resources,proto3" json:"resources,omitempty"` 66 | ExpirationTime *time.Time `json:"expiration_time,omitempty"` 67 | LimitSize *common.UInt64Value `json:"limit_size,omitempty"` 68 | } 69 | ``` 70 | 71 | For `Policy`: 72 | `Id` is an unique u256 sequence for each policy. It also be used as NFT tokenID. 73 | `Principal` defines the roles that can grant permissions. Currently, it can be account or group. 74 | `Resource` defines a greenfield standard resource name that can be generated by GRN structure. 75 | `Statements` defines a list of individual statement which describe the detail rules of policy. 76 | `ExpirationTime` defines the whole expiration time of all the statements. 77 | 78 | For Statement: 79 | `Effect` define the impact of permissions, which can be `Allow`/`Deny`. 80 | `ActionType` defines the operation type you can act on. greenfield defines a set of permission that you can specify in a permissionInfo. see `ActionType` enum for detail. 81 | `ExpirationTime` defines how long the permission is valid. If not explicitly specified, it means it will not expire. 82 | `LimitSize` defines the total data size that is allowed to operate. If not explicitly specified, it means it will not limit. 83 | 84 | 85 | ExtraData is as follows: 86 | ```golang 87 | struct ExtraData { 88 | address appAddress; // callback app address 89 | address refundAddress; // refund callback gas fee 90 | bytes callbackData; // calldata for callback 91 | } 92 | ``` 93 | `appAddress` defines the callback contract after receiving the cross-chain ack package. 94 | `refundAddress` defines the refund address to receive the unspent callback gas fee. 95 | `callbackData` defines the calldata for the callback call. 96 | 97 | #### 4.2.2 Delete Policy 98 | The interface to delete policy is as follows: 99 | **function deletePolicy(uint256 policyId) external payable returns (bool);** 100 | 101 | `policyId` is generated while creating policy. Only the owner of the policy can delete it. 102 | The deletion of a nonexistent policy will fail on GreenField. 103 | 104 | ## 5. License 105 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 106 | -------------------------------------------------------------------------------- /BEPs/BEP-345.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 345
 3 |   Title: Implement EIP-7516: BLOBBASEFEE opcode
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2024-01-15
 7 |
8 | 9 | 10 | # BEP-345: Implement EIP-7516: BLOBBASEFEE opcode 11 | 12 | - [BEP-345: Implement EIP-7516: BLOBBASEFEE opcode](#bep-345-implement-eip-7516-blobbasefee-opcode) 13 | - [1. Summary](#1-summary) 14 | - [2. Abstract](#2-abstract) 15 | - [3. Motivation](#3-motivation) 16 | - [4. Specification](#4-specification) 17 | - [5. Rationale](#5-rationale) 18 | - [6. Backwards Compatibility](#6-backwards-compatibility) 19 | - [7. Security Considerations](#7-security-considerations) 20 | - [8. License](#8-license) 21 | - [9. Reference](#9-reference) 22 | 23 | 24 | ## 1. Summary 25 | As part of Cancun upgrade, EIP-7516: BLOBBASEFEE opcode is required to be implemented to BSC. 26 | 27 | ## 2. Abstract 28 | 29 | Add a `BLOBBASEFEE (0x4a)` that returns the value of the blob base-fee of the current block it is executing in. It is the identical to [EIP-3198](./BEP227.md) (`BASEFEE` opcode) except that it returns the blob base-fee as per [EIP-4844](./BEP-336.md). 30 | 31 | ## 3. Motivation 32 | 33 | The intended use case would be for contracts to get the value of the blob base-fee. This feature enables blob-data users to programmatically account for the blob gas price, eg: 34 | 35 | - Allow rollup contracts to trustlessly account for blob data usage costs. 36 | - Blob gas futures can be implemented based on it which allows for blob users to smooth out data blob costs. 37 | 38 | ## 4. Specification 39 | 40 | Add a `BLOBBASEFEE` opcode at `(0x4a)`, with gas cost `2`. 41 | 42 | | Op | Input | Output | Cost | 43 | |------|-------|--------|------| 44 | | 0x4a | 0 | 1 | 2 | 45 | 46 | `BLOBBASEFEE` returns the result of the `get_blob_gasprice(header) -> int` function as defined in [EIP-4844 §Gas accounting](./BEP-336.md#gas-accounting). 47 | 48 | ## 5. Rationale 49 | 50 | ### Gas cost 51 | 52 | The value of the blob base-fee is needed to process data-blob transactions. That means its value is already available before running the EVM code. 53 | The opcode does not add extra complexity and additional read/write operations, hence the choice of `2` gas cost. This is also identical to [EIP-3198](./BEP227.md) (`BASEFEE` opcode)'s cost as it just makes available data that is in the header. 54 | 55 | ## 6. Backwards Compatibility 56 | 57 | There are no known backward compatibility issues with this opcode. 58 | 59 | ## 7. Security Considerations 60 | 61 | The value of the blob base-fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this opcode. 62 | 63 | ## 8. License 64 | 65 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 66 | 67 | ## 9. Reference 68 | 69 | Carl Beekhuizen (@carlbeek), "EIP-7516: BLOBBASEFEE opcode [DRAFT]," Ethereum Improvement Proposals, no. 7516, September 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7516. -------------------------------------------------------------------------------- /BEPs/BEP-346.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 346
 3 |   Title: Streamline off-chain authentication on Greenfield
 4 |   Status: Candidate
 5 |   Type: Standards
 6 |   Created: 2024-03-14
 7 |
8 | 9 | 10 | # BEP-346: Streamline off-chain authentication on Greenfield 11 | 12 | - [BEP-346: Streamline off-chain authentication on Greenfield](#bep-346-streamline-off-chain-authentication-on-greenfield) 13 | - [1. Summary](#1-summary) 14 | - [2. Motivation](#2-motivation) 15 | - [3. Status](#3-status) 16 | - [4. Specification](#4-specification) 17 | - [5. License](#5-license) 18 | 19 | 20 | ## 1. Summary 21 | This BEP introduces GNFD2-EDDSA, a simplified off-chain authentication signature verification method. It streamlines the authentication process, reducing developer integration complexity and improving user interaction. 22 | 23 | ## 2. Motivation 24 | 25 | Greenfield is an object storage system with permission management. SP uses an off-chain authentication mechanism to authenticate users from the dApps. For more details, refer to [Greenfield Storage Provider Off-Chain Authentication](https://github.com/bnb-chain/greenfield-storage-provider/blob/master/docs/modules/authenticator.md). 26 | 27 | In the previous design, users first needed to request a Metamask signature to derive an EdDSA private key. Subsequently, registering this EdDSA public key with various SPs required another Metamask signature. We strive to simplify the off-chain authentication procedure by consolidating the two signatures into a single one. 28 | 29 | 30 | ## 3. Status 31 | This BEP is in progress. 32 | 33 | ## 4. Specification 34 | 35 | When maintaining security integrity, we recommend streamlining the off-chain authentication process as follows: 36 | 37 | 1. In a dApp frontend, a random EdDSA private key is generated without fetching a nonce from the service provider or requesting a user wallet signature, and this private key would be stored in the browser's local storage. The generation of a private EdDSA key is to use Ed25519 as the EdDSA curve. Here is the sample code: 38 | ``` 39 | // use js lib at https://github.com/paulmillr/noble-ed25519 40 | const privateKeyBytes = ed.utils.randomPrivateKey(); 41 | ``` 42 | 43 | 2. To register the user’s current EdDSA public key with SPs, users are required to sign the message. This step ensures SPs can verify the user's identity. The simplified content for signing is as follows: 44 | 45 | ``` 46 | https://www.yourwebsite.com wants you to sign in with your BNB Greenfield account:0xA4cFxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0af6 47 | Register your identity public key 280e1a3f143215c010db9c4f1bbd0675b39356a8ee8b4b3b6f965b5c7a42d3aa 48 | URI: https://www.yourwebsite.com 49 | Version: 1 50 | Chain ID: 1017 51 | Issued At: 2024-03-02T07:24:24Z 52 | Expiration Time: 2024-03-07T07:24:24Z 53 | ``` 54 | 55 | After users register their EdDSA public keys with the SPs, they can sign requested messages using the private key. This allows the SP to verify their identity based on the registered public key. This off-chain authentication signature doesn't require block chain network operations, so users can verify signatures without switching to the Greenfield network. 56 | 57 | 3. When a user initiates a request to the SP, they sign the request using the EdDSA private key generated in step one. The signature is then placed in the authorization field of the header. To ensure backward compatibility, this new signature verification method is labeled as GNFD2-EDDSA. While the previous signature verification method is no longer recommended, it is still supported. The new format is as follows: 58 | 59 | ``` 60 | Authorization = auth_type + "," + Signature 61 | string-to-sign = crypto.Keccak256(canonical) 62 | Signature = ed25519.Sign(privateKey, string-to-sign) 63 | 64 | Authorization: GNFD2-EDDSA, Signature=0a9d0e0c4778cdfbbc7d86f4aad2651d3c0140c15a80b4f80315dee58987c2a401877bfb05aef6f8a9c4137b8587a4f02536b3cb7e303c444edaacee476e7ad2 65 | ``` 66 | 67 | ## 5. License 68 | 69 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 70 | -------------------------------------------------------------------------------- /BEPs/BEP-402.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 402
 3 |   Title: Complete Missing Fields in Block Header to Generate Signature
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2024-06-28
 7 |
8 | 9 | # BEP-402: Complete Missing Fields in Block Header to Generate Signature 10 | 11 | - [BEP-402: Complete Missing Fields in Block Header to Generate Signature](#bep-402-complete-missing-fields-in-block-header-to-generate-signature) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Status](#3-status) 15 | - [4. Specification](#4-specification) 16 | - [4.1 Define ParentBeaconRoot](#41-define-parentbeaconroot) 17 | - [4.2 Encode Before Signing](#42-encode-before-signing) 18 | - [5. Backwards Compatibility](#5-backwards-compatibility) 19 | - [6. License](#6-license) 20 | 21 | ## 1. Summary 22 | Since the London upgrade on the BSC chain, 5 new fields have been added to the block header, but these fields are not used when generating the block signature. As a result, users cannot guarantee that these new fields have not been tampered with after only verifying the signature. This BEP aims to address this issue. 23 | 24 | ## 2. Motivation 25 | After a block producer mines a block, they first encode all fields in the block header along with the chainId, then sign it, and place the signature in the block header before broadcasting it. The receiver only needs to extract the signature and verify it to confirm whether the block has been tampered with. 26 | 27 | The BSC client, when signing the block header, omitted the 5 new fields. In most scenarios, this does not cause security issues, as the receiver will strictly validate these fields upon receiving the block. However, to adhere to best practices in blockchain and further enhance security, this BEP proposes to include these 5 new fields when generating the signature. 28 | 29 | ## 3. Status 30 | This BEP is in progress. 31 | 32 | ## 4. Specification 33 |
34 | 35 |
36 | 37 | ### 4.1 Define ParentBeaconRoot 38 | The ParentBeaconRoot is unnecessary for BSC and is retained for compatibility with Ethereum APIs. The value of this field will be changed from `nil` to `zero hash`, allowing the encoding stage for signing and verification to be based solely on the values of the fields in the header, independent of hard fork timing. Following Geth, the zero hash will be used as a placeholder. 39 | ```Go 40 | header.ParentBeaconRoot = new(Hash) 41 | ``` 42 | ### 4.2 Encode Before Signing 43 | The encoding logic will be determined based on whether `header.ParentBeaconRoot` is a zero hash. 44 | ```Go 45 | if header.ParentBeaconRoot != nil && *header.ParentBeaconRoot == Hash{} { 46 | encoding = rlp([chainId, 47 | header.ParentHash, 48 | header.UncleHash, 49 | header.Coinbase, 50 | header.Root, 51 | header.TxHash, 52 | header.ReceiptHash, 53 | header.Bloom, 54 | header.Difficulty, 55 | header.Number, 56 | header.GasLimit, 57 | header.GasUsed, 58 | header.Time, 59 | // signature will be put at the end of header.Extra, exclude it 60 | header.Extra[:len(header.Extra)-len(signature)], 61 | header.MixDigest, 62 | header.Nonce, 63 | header.BaseFee, 64 | header.WithdrawalsHash, 65 | header.BlobGasUsed, 66 | header.ExcessBlobGas, 67 | header.ParentBeaconRoot, 68 | ]) 69 | } else { 70 | encoding = rlp([chainId, 71 | header.ParentHash, 72 | header.UncleHash, 73 | header.Coinbase, 74 | header.Root, 75 | header.TxHash, 76 | header.ReceiptHash, 77 | header.Bloom, 78 | header.Difficulty, 79 | header.Number, 80 | header.GasLimit, 81 | header.GasUsed, 82 | header.Time, 83 | // signature will be put at the end of header.Extra, exclude it 84 | header.Extra[:len(header.Extra)-len(signature)], 85 | header.MixDigest, 86 | header.Nonce, 87 | ]) 88 | } 89 | ``` 90 | 91 | ## 5. Backwards Compatibility 92 | There are no known backward compatibility issues. 93 | ## 6. License 94 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/) -------------------------------------------------------------------------------- /BEPs/BEP-404.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 404
 3 |   Title: Clear Miner History when Switching Validators Set
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2024-07-01
 7 |
8 | 9 | # BEP-404: Clear Miner History when Switching Validators Set 10 | 11 | - [BEP-404: Clear Miner History when Switching Validators Set](#bep-404-clear-miner-history-when-switching-validators-set) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Status](#3-status) 15 | - [4. Specification](#4-specification) 16 | - [5. Backwards Compatibility](#5-backwards-compatibility) 17 | - [6. License](#6-license) 18 | 19 | ## 1. Summary 20 | After switching the validator set on the BSC chain, the previous block production record is still used to restrict some validators from producing blocks for the first few blocks after the switch, leading to brief network instability. This BEP aims to resolve this issue. 21 | 22 | ## 2. Motivation 23 | The validator set on the BSC chain switches at each epoch. 24 | 25 | Assume the number of validators in an epoch is validatorN. To ensure the consistency of the BSC chain, it is required that the chain must have at least validatorN/2+1 validators to continue advancing the chain. 26 | 27 | To achieve this constraint, a set called MinerHistory is defined, with a length of validatorN/2, recording the validators that produced the last validatorN/2 blocks. New block-producing validators are required to not be in MinerHistory. 28 | 29 | This BEP aims to enhance network stability by clearing MinerHistory when the validator set switches. 30 | 31 | ## 3. Status 32 | This BEP is in progress. 33 | 34 | ## 4. Specification 35 | In the previous specification, when the validator set switches at each epoch, MinerHistory is not cleared, causing some validators to be unable to produce blocks normally for the first few blocks after the switch. 36 |
37 | 38 |
39 | This BEP clarifies that MinerHistory should be cleared when switching the validator set to solve this issue. 40 | 41 | ```Go 42 | MinerHistory map[uint64]Address 43 | 44 | // The conditions for switching remain unchanged 45 | if BlockNum % EpochLength == (validatorN/2) { 46 | MinerHistory = Address{} 47 | } 48 | ``` 49 | 50 | ## 5. Backwards Compatibility 51 | There are no known backward compatibility issues. 52 | 53 | ## 6. License 54 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/) -------------------------------------------------------------------------------- /BEPs/BEP-410.md: -------------------------------------------------------------------------------- 1 | 
  2 |   BEP: 410
  3 |   Title: Add Agent for Validators
  4 |   Status: Draft
  5 |   Type: Standards
  6 |   Created: 2024-07-15
  7 |
8 | 9 | # BEP-410: Add Agent for Validators 10 | 11 | - [BEP-410: Add Agent for Validators](https://github.com/bnb-chain/BEPs/pull/410) 12 | - [1. Summary](#1-summary) 13 | - [2. Abstract](#2-abstract) 14 | - [3. Motivation](#3-motivation) 15 | - [4. Specification](#4-specification) 16 | - [5. Reference Implementations](#5-reference-implementations) 17 | - [6. License](#6-license) 18 | 19 | 20 | ## 1. Summary 21 | 22 | This BEP attempts to enhance the security of validator account management through account isolation by delegating some of the validator operator's permissions to other accounts. 23 | 24 | ## 2. Abstract 25 | 26 | Currently, validators need to manage the operator key, consensus key, and vote key. Among these, the operator key is used for operating a validator, including creating a validator, editing the information of a validator, and undelegating. 27 | When creating a validator, the operator key is also used for self-delegating with more than 2001 BNB. Since the operator key holds a large amount of staking, it is not suitable for daily management of the validator. 28 | Therefore, we have introduced a new `updateAgent` interface in the system contract. Through this interface, the operator can delegate another account to manage the validator. 29 | 30 | ## 3. Motivation 31 | 32 | Before this BEP, the consensus address, commission rate, validator description and vote address can only be changed by the operator which also manages staking for the validator. 33 | To reduce the usage of operator key and improve the security of operator key management, validators can set an agent to help them to take on the mentioned tasks below. 34 | 35 | ## 4. Specification 36 | ### Data Structure 37 | The current [`Validator`](https://github.com/bnb-chain/bsc-genesis-contract/blob/2dbebb57a0d436d6a30b78c1f123395035249035/contracts/BC_fusion/StakeHub.sol#L154) struct is as follows. 38 | ```solidity 39 | struct Validator { 40 | address consensusAddress; 41 | address operatorAddress; 42 | address creditContract; 43 | uint256 createdTime; 44 | bytes voteAddress; 45 | Commission commission; 46 | Description description; 47 | bool jailed; 48 | uint256 jailUntil; 49 | uint256 updateTime; 50 | uint256[20] __reservedSlots; 51 | } 52 | ``` 53 | 54 | 55 | The new `Validator` struct is as follows. This BEP adds a new field `agent` and reduce a slot of `__reservedSlots` in the `Validator` struct to keep 56 | the slot layer compatibility of upgradeable contracts. 57 | 58 | ```solidity 59 | struct Validator { 60 | address consensusAddress; 61 | address operatorAddress; 62 | address creditContract; 63 | uint256 createdTime; 64 | bytes voteAddress; 65 | Description description; 66 | Commission commission; 67 | bool jailed; 68 | uint256 jailUntil; 69 | uint256 updateTime; 70 | // The agent can perform transactions on behalf of the operatorAddress in certain scenarios. 71 | address agent; 72 | uint256[19] __reservedSlots; 73 | } 74 | ``` 75 | 76 | ### Interface 77 | 78 | The validator operator can set the agent address for the validator by calling the following function. 79 | The `newAgent` cannot be any operator address or any existing agent. 80 | Each validator can only have one agent assigned at a time. Updating to a new agent will override the previous one. 81 | 82 | ```solidity 83 | function updateAgent(address newAgent) external validatorExist(msg.sender); 84 | ``` 85 | 86 | ### Agent Permission 87 | 88 | The agent is allowed to edit the consensus address, commission rate, description and vote address of the validator. 89 | The methods that can be accessed are as follows: 90 | 91 | ```solidity 92 | function editConsensusAddress(address newConsensusAddress) external; 93 | function editCommissionRate(uint64 commissionRate) external; 94 | function editDescription(Description memory description) external; 95 | function editVoteAddress(bytes calldata newVoteAddress, bytes calldata blsProof) external; 96 | ``` 97 | 98 | It is notable that even after the agent is set, the operator retains the ability to edit the information listed below. 99 | 100 | ## 5. Reference Implementations 101 | See https://github.com/bnb-chain/bsc-genesis-contract/pull/568. 102 | 103 | 104 | ## 6. License 105 | 106 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 107 | -------------------------------------------------------------------------------- /BEPs/BEP-466.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 466
 3 |   Title: Make the block header format compatible with EIP-7685
 4 |   Status: Review
 5 |   Type: Standards
 6 |   Created: 2024-11-25
 7 |
8 | 9 | # BEP-466: Make the block header format compatible with EIP-7685 10 | 11 | - [BEP-466: Make the block header format compatible with EIP-7685](#bep-466-make-the-block-header-format-compatible-with-eip-7685) 12 | - [Abstract](#abstract) 13 | - [Motivation](#motivation) 14 | - [Specification](#specification) 15 | - [Block Header](#block-header) 16 | - [Copyright](#copyright) 17 | 18 | 19 | ## Abstract 20 | 21 | [EIP-7685](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7685.md) adds `requests_hash` to the block header. To achieve compatibility, this element must be defined in BNB Smart Chain (BSC). 22 | 23 | ## Motivation 24 | 25 | The goal is to make the block header format compatible with EIP-7685. This allows for shared codebases and APIs between implementations, promoting consistency and interoperability. 26 | 27 | ## Specification 28 | 29 | ### Block Header 30 | 31 | In line with EIP-7685, the header is extended with a new 32-byte commitment value, `requests_hash`. On BSC: 32 | 33 | 1. Collecting `requests` or validating their correspondence with `requests_hash` is not required. 34 | 2. After the Prague hard fork, `requests_hash` must not be nil to ensure compatibility with EIP-7685. 35 | 3. Include `requests_hash` in the computation when calculating the header signature. 36 | 37 | ## Copyright 38 | 39 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 40 | -------------------------------------------------------------------------------- /BEPs/BEP-536.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 536
 3 |   Title: Directed TxPool
 4 |   Status: Withdrawn
 5 |   Type: Standards
 6 |   Created: 2025-02-19
 7 |   Discussions(optional): https://forum.bnbchain.org/t/call-for-feedbacks-bsc-short-block-interval-validator-dedicated-network-and-direct-mempool/3348
 8 |
9 | 10 | # BEP-536: Directed TxPool 11 | - [BEP-536: Directed TxPool](#bep-536-directed-txpool) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Specification](#3-specification) 15 | - [3.1.Directed TxPool](#31directed-txpool) 16 | - [4.Rational](#4rational) 17 | - [5. Backwards Compatibility](#5-backwards-compatibility) 18 | - [5.1 MEV and PBS](#51-mev-and-pbs) 19 | - [6. License](#6-license) 20 | 21 | ## 1. Summary 22 | Transactions will be forwarded directly to a few validators who are most likely to produce the next block. 23 | 24 | ## 2. Motivation 25 | - For MEV protection: validators are the key role in the network, it is reasonable that validators have the highest priority to get the transactions. Directed txpool means transactions would be forwarded to a small subset of validators that are most likely to produce the next block. It could avoid exposing users transactions directly to public txpool, so users would less likely to face malicious MEV attacks. 26 | ## 3. Specification 27 | 28 | ### 3.1.Directed TxPool 29 | It is another key aspect of VDN, transactions that are broadcasted in VDN would no long be gossip based, on the opposite, they will only be broadcasted to next {N} validators which have the highest priority to propose the next block. The value of {N} is configurable, by default {N} could be three, which means one in-turn validator, one next-in-turn validator and first backup validator which has the highest priority to produce the block in case the in-turn validator failed to generate it in time. 30 | 31 | ![overview](./assets/BEP-536/3-2.png) 32 | 33 | ## 4.Rational 34 | TBD 35 | 36 | ## 5. Backwards Compatibility 37 | 38 | ### 5.1 MEV and PBS 39 | This BEP would have great impact to the Proposer-Builder-Separation(PBS) mechanism and MEV(Maximum-Extractable-Value) ecosystem. 40 | 41 | As the public txpool would be gradually replaced by directed txpool, which means transactions would be forwarded to validators directly, consequently: 42 | - MEV searchers would have to get the transactions from validators, which would be more difficult. 43 | - MEV builders can still act as a bridge between searchers and validators, but the impact to searchers would impact builders indirectly. 44 | 45 | The PBS architecture was introduced in [BEP-322: Builder API Specification for BNB Smart Chain](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP322.md), which tries to make MEV more transparent and fully competed. But due to the MEV impact by this BEP, current PBS mechanism would be weaken as well. PBS is useful, as none malicious MEV activities are good for the chain ecosystem, community will try to find a solution to sustain or upgrade the PBS mechanism, so builders will be less impacted. 46 | 47 | ## 6. License 48 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 49 | -------------------------------------------------------------------------------- /BEPs/BEP-564.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 564
 3 |   Title: bsc/2 - New Block Fetching Messages
 4 |   Status: Candidate
 5 |   Type: Standards
 6 |   Created: 2025-04-16
 7 |   Description: To accelerate block fetching for shorter block interval.
 8 |
9 | 10 | # BEP-564: bsc/2 - New Block Fetching Messages 11 | - [BEP-564: bsc/2 - New Block Fetching Messages](#bep-564-bsc2---new-block-fetching-messages) 12 | * [1. Summary](#1-summary) 13 | * [2. Status](#2-status) 14 | * [3. Motivation](#3-motivation) 15 | * [4. Specification](#4-specification) 16 | + [4.1 Block Fetching Message](#41-block-fetching-message) 17 | * [5. Rationale](#5-rationale) 18 | + [5.1 Why new block fetching messages](#51-why-new-block-fetching-messages) 19 | * [6. Forward Compatibility](#6-forward-compatibility) 20 | + [6.1 eth/69 protocol](#61-eth69-protocol) 21 | * [7. Backward Compatibility](#7-backward-compatibility) 22 | + [7.1 eth/68 protocol](#71-eth68-protocol) 23 | * [8. License](#8-license) 24 | 25 | ## 1. Summary 26 | 27 | This BEP introduces new block fetching messages to speed up the import of newly generated blocks, prevent nodes from lagging at subsecond block intervals, and especially improve validator consensus efficiency. 28 | 29 | ## 2. Status 30 | 31 | Draft 32 | 33 | ## 3. Motivation 34 | 35 | With the future activation of BEP-520 and BEP-524, BSC will achieve a subsecond block interval, which has higher requirements for faster block fetching. 36 | 37 | However, the eth/68 protocol is very inefficient when processing NewBlockHash messages, and it requires multiple queries before a new block can be imported. 38 | 39 | This BEP introduces a New Block Fetching Message, which greatly reduces the number of queries, supports fast fetching of newly generated blocks, avoids validators and full nodes from lagging behind in the subsecond block interval, and especially improves the validator consensus efficiency, which can produce the next block or send vote faster. 40 | 41 | ## 4. Specification 42 | 43 | ### 4.1 Block Fetching Message 44 | 45 | Current block querying is inefficient, requiring multiple requests for both block headers and block bodies. This BEP will add the following messages to reduce the delay in obtaining blocks. 46 | 47 | ```go 48 | const ( 49 | GetBlocksByRangeMsg = 0x02 // it can request (Head-n, Head] range blocks from remote peer 50 | BlocksByRangeMsg = 0x03 // the replied blocks from remote peer 51 | ) 52 | 53 | type GetBlocksByRangePacket struct { 54 | RequestId uint64 55 | StartBlockHeight uint64 // The start block height expected to be obtained from 56 | StartBlockHash common.Hash // The start block hash expected to be obtained from 57 | Count uint64 // Get the number of blocks from the start 58 | } 59 | 60 | type BlocksByRangePacket struct { 61 | RequestId uint64 62 | Blocks []*types.Block 63 | } 64 | ``` 65 | 66 | The peer can request a range of blocks, specifying the starting block using either StartBlockHeight or StartBlockHash. If StartBlockHash is not equal to the empty hash (0x0000000000000000000000000000000000000000000000000000000000000000), the starting block will be determined by StartBlockHash. Otherwise, it will default to StartBlockHeight. 67 | 68 | When specifying a StartBlockHeight or StartBlockHash and a Count, the blocks will be returned in reverse order, starting from the given block and going backward. 69 | 70 | This method is used to synchronize the latest small range of blocks quickly. Historical block synchronization still uses the eth/68 protocol. 71 | 72 | ![](assets/BEP-564/image1.png) 73 | 74 | ## 5. Rationale 75 | 76 | ### 5.1 Why new block fetching messages 77 | 78 | The eth/68 protocol fetches the block header and body from the remote separately and assembles them locally. These messages are also applicable to full sync and snap sync processes, and it can save bandwidth when fetching the fork or bad blocks. 79 | 80 | However, multiple queries will multiply the latency between nodes. After subsecond block interval, fetching the block quickly is the key. New block fetching messages simplify the process of fetching blocks and support requesting a range of blocks with only one round trip. 81 | 82 | ## 6. Forward Compatibility 83 | 84 | ### 6.1 eth/69 protocol 85 | 86 | The bsc/2 is completely independent of the ETH series of protocols, so future upgrades to eth/69 are fully compatible. 87 | 88 | ## 7. Backward Compatibility 89 | 90 | ### 7.1 eth/68 protocol 91 | 92 | There should be no impact on eth/68. When obtaining the block announced by NewBlockHash, bsc/2 can work simultaneously with eth/68. Due to the low efficiency of eth/68 fetch, bsc/2 will fetch the block first. After the client marks the current block as known, eth/68 will no longer continue to request. 93 | 94 | ## 8. License 95 | 96 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 97 | -------------------------------------------------------------------------------- /BEPs/BEP10.md: -------------------------------------------------------------------------------- 1 | # BEP-10: Registered Types for Transaction Source 2 | 3 | - [BEP-10: Registered Types for Transaction Source](#bep-10--registered-types-for-transaction-source) 4 | * [1. Summary](#1-summary) 5 | * [2. Abstract](#2-abstract) 6 | * [3. Status](#3--status) 7 | * [4. Motivation](#4-motivation) 8 | * [5. Specification](#5-specification) 9 | + [5.1 Transaction Data Structure](#51-transaction-data-structure) 10 | + [5.2 Register Process](#52-register-process) 11 | + [5.3 Registered Source types](#53--registered-source-types) 12 | * [6. License](#6-license) 13 | 14 | ## 1. Summary 15 | 16 | This BEP describes how to have a better understanding of the origin of a transaction with a special field in a transaction for recording its source. 17 | 18 | ## 2. Abstract 19 | 20 | By adding a field in each transaction message, the origin of any transaction could be tracked. 21 | 22 | ## 3. Status 23 | 24 | This BEP is already implemented. 25 | 26 | ## 4. Motivation 27 | 28 | BNB Beacon Chain is designed to connect with multiple service providers, such as different wallet providers and trading platforms. By adding an optional field in each transaction message, the origin of any transaction could be tracked. This proposal does not want to deal with assigning the values for various source types. The different sources will claim different value and such a proposition will be assigned afterwards. 29 | ## 5. Specification 30 | 31 | ### 5.1 Transaction Data Structure 32 | 33 | The transaction is a standard way to wrap a message with signatures. 34 | 35 | | Field | Type | Description | 36 | | ------ | --------- | ------------------------------------- | 37 | | Msgs | message | transaction message | 38 | | Sig | signature | signatures from the account holder | 39 | | Memo | string | some notes come with the transaction | 40 | | Source | int64 | where does this transaction come from | 41 | | Data | byte[] | transaction data | 42 | 43 | ### 5.2 Register Process 44 | 45 | - Service Provider choose their own source identifier 46 | - They have to create a PR to BEP-10 and add their identifier code in the form under section **5.3** 47 | - Maintainer review their PR 48 | - If the PR gets accepted, this new identifier will be recognized 49 | 50 | ### 5.3 Registered Source types 51 | 52 | These are the registered source types. 53 | 54 | All of these constant values shall be considered hardcoded in client implementations. 55 | 56 | 57 | 58 | | Identifier | Source Description | 59 | | ---------- | ---------------------------- | 60 | | 0 | Default source value, e.g. for BNB Beacon Chain Command Line, or SDKs | 61 | | 1 | BNB Beacon Chain DEX Web Wallet | 62 | | 2 | Trust Wallet | 63 | | 3 | CanWork.io Decentralised [Serviceplace App](https://github.com/canyacoin/canwork-web-ui)| 64 | | 4 | CanYaDAO [Decentralised Autonomous Organisation](https://github.com/canyacoin/canyadao)| 65 | | 5 | Math Wallet | 66 | | 6 | SafePal [Secure, simple, powerful hardware wallet for the masses](https://www.safepal.io)| 67 | | 7 | GoBNB [GoBNB Payments App](https://github.com/gobnb/) 68 | | 8 | [Magnum Wallet](https://magnumwallet.co)| 69 | | 9 | [Atomic Wallet](https://atomicwallet.io)| 70 | | 10 | [Equal Wallet](https://equal.tech/)| 71 | | 11 | [Infinito Wallet](https://www.infinitowallet.io/)| 72 | | 12 | Coinomi| 73 | | 18 | MEET.ONE [Blockchain Wallet Supports BNB Beacon Chain DEX](https://meet.one)| 74 | | 21 | Vision - [Portfolio & Multi-Chain Wallet](https://vision-crypto.com/)| 75 | | 68 | Trubi Wallet| 76 | | 82 | [Cosmostation Wallet](https://www.cosmostation.io)| 77 | | 91 | [Frontier](https://frontier.xyz/) | 78 | | 711 | [CoolWallet S](https://coolwallet.io/)| 79 | | 714 | Binance| 80 | | 777 | Guarda Wallet [Multi-currency, custody-free wallet](https://guarda.co/) 81 | | 888 | TrustToken: [Cross-chain, multi-currency fiat onramp+offramp](https://app.trusttoken.com)| 82 | | 999 | [TokenPocket Wallet](https://www.tokenpocket.pro/)| 83 | | 1014 | Binance OCBS service| 84 | | 1035 | Trubi Token Swap service| 85 | | 2048 | BNB Browser: [Metamask like wallet for BNB](https://chrome.google.com/webstore/detail/bnb-browser/eeflaanifildahldmpahjmgmgippmgne?hl=en)| 86 | | 800,000,000 ~ 1,600,000,000| reserved source code| 87 | 88 | 89 | ## 6. License 90 | 91 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 92 | -------------------------------------------------------------------------------- /BEPs/BEP12.md: -------------------------------------------------------------------------------- 1 | # BEP12: Introduce Customized Scripts and Transfer Memo Validation 2 | ## Summary 3 | This BEP describes a new feature that enables addresses to customize scripts, and introduces the a validation script for transfer transaction memo. 4 | ## Abstract 5 | In some circumstances, users may want to specify some additional functions or/and validations on some transactions. 6 | 7 | Taking exchange for example, for Bitcoin and Ethereum, exchanges create unique addresses for each client. It costs them too much effort to manage secret files and collect tokens to cold wallet. So now, for new blockchain platforms, exchanges tend to use a single address for client deposit and require clients to input memo (or call it “tag”) to identify client account information. 8 | 9 | However, this user experience change causes a lot of problems for both exchange customer support and clients. Clients may be panic if they forget to input the correct memo and exchange cannot allocate the fund to their account. The exchange support have to verify the client deposit in other ways. 10 | 11 | For all transfer transactions which are depositing tokens to exchanges, it would be nice if BNB Beacon Chain can reject those that have no valid memo. Thus clients won’t be panic for losing tokens and exchanges supports won’t suffer from the heavy working load. 12 | 13 | Here is a script model introduced into BNB Beacon Chain. Each address can add new functions by associating itself with one or more predefined scripts. The memo validation is the first type of script to be introduced here. 14 | ## Status 15 | This BEP is under implementation. 16 | ## Motivation 17 | This memo validation can be used for any membership based deposit/charge business model. 18 | 19 | This BEP also proposes an important infrastructure for customized scripts. In the future, more amazing features will be built on it. 20 | ## Specificaion 21 | ### Add Flags into Address Structure 22 | ``` 23 | type Account struct { 24 | auth.BaseAccount `json:"base"` 25 | Name string `json:"name"` 26 | FrozenCoins sdk.Coins `json:"frozen"` 27 | LockedCoins sdk.Coins `json:"locked"` 28 | Flags uint64 `json:”flags”` 29 | } 30 | ``` 31 | Each address represents an account. The account structure is shown as above. We will add a new field named “flags” into “Account”. Its data type is 64bit unsigned int. Each bit will represent a script, which means an account can specify at most 64 scripts. The flags of all existing accounts are zero. Users can send transactions to update their account flags. 32 | ### New Transaction: SetAccountFlags 33 | Parameters for Updating Account Flags 34 | 35 | | | Type | Description | 36 | |-------|----------------|-------------| 37 | | From | sdk.AccAddress | Address of target account | 38 | | Flags | uint64 | New account flags | 39 | 40 | With this transaction, users can set their account flags to any values. But setting a bit which has no bonded script will not have any effect, unless a new script is bonded to it in the future. 41 | 42 | By default, all accounts’ flags are zero which means no script is specified. Suppose there are two available scripts(marked as A and B), and the lowest bit is bonded to script A and the second lowest bit is bonded to script B. If an address set its account flags to 0x03, then two scripts are enabled. If only script B is expected, then account flags should be set to 0x02. 43 | 44 | Besides, the account flags changes will take effect since the next transaction. 45 | 46 | ### Memo Check Script for Transfer 47 | This script is aimed to ensure the transfer transactions have valid memo if the receivers require this. 48 | 49 | Firstly, this script will check the following conditions: 50 | 51 | - The transaction type is send. 52 | - The target address is the receiving address. 53 | 54 | Then this script will ensure that the transaction memo is not empty and the memo only contains digital letters. This is the pseudocode: 55 | 56 | ``` 57 | func memoValiation(addr, tx) error { 58 | if tx.Type != “send” { 59 | return nil 60 | } 61 | if ! isReceiver(tx, addr) { 62 | return nil 63 | } 64 | if tx.memo.length == 0 { 65 | return err(“tx memo is empty”) 66 | } 67 | if !isAllDigital(tx.memo) { 68 | return err(“tx memo contains non digital character”) 69 | } 70 | return nil 71 | } 72 | ``` 73 | 74 | ### Scalability 75 | In the future, more scripts will be supported and existing scripts might need to be updated, so we must take scalability into consideration in the implementation. 76 | 77 | ## License 78 | All the content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 79 | -------------------------------------------------------------------------------- /BEPs/BEP127.md: -------------------------------------------------------------------------------- 1 | # BEP-127: Temporary Maintenance Mode for Validators 2 | 3 | - [BEP-127: Temporary Maintenance Mode for Validators](#bep-99-temporary-maintenance-mode-for-validators) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [6. License](#6-license) 10 | 11 | ## 1. Summary 12 | This BEP introduces the **Temporary Maintenance** mode for validators on the BNB Smart Chain. 13 | 14 | ## 2. Abstract 15 | **Temporary Maintenance** is supposed to last one or a few hours. The validator seat will be temporarily dropped from the block producing rotation during the maintenance. Since long-time offline maintenance is not encouraged, the validator will still be slashed if the maintenance lasts too long. To lower the impact from poorly-operating validators who forget to claim its maintenance, they will be forced to enter **Temporary Maintenance** mode too. 16 | 17 | ## 3. Status 18 | This BEP is already implemented. 19 | 20 | ## 4. Motivation 21 | Due to the design of **Parlia** consensus, the absence of the validator, even if it is due to scheduled maintenance, will cause instability and capacity loss of BSC due to the extra waiting time and chain reorganization for other validators. Introducing **Temporary Maintenance** mode will stabilize the blocking rotation and maintain the capacity of BSC. 22 | 23 | ## 5. Specification 24 | 25 | ### Current Slash Mechanisms 26 | The [slash contract](https://bscscan.com/address/0x0000000000000000000000000000000000001001) will record the missed blocking metrics of each validator. 27 | - Once the metrics are above the predefined threshold, the blocking reward for validator will not be relayed to BC for distribution but shared with other better validators. 28 | - If the metrics remain above another higher level of threshold, the validator will be dropped from the rotation, and put as “in jail”. This will be propagated back to BNB Beacon Chain, where a predefined amount of BNB would be slashed from the self-delegated BNB of the validator. 29 | 30 | ### Temporary Maintenance Mode 31 | 32 | #### Proactive Maintenance 33 | Validator can claim itself to enter scheduled maintenance by sending a transaction signed by the consensus key. The validator can claim itself to exit maintenance by sending another transaction. The slash cleaning work will be done within the exit transaction: 34 | 35 | **SlashCount = (MaintenanceEndHeight - MaintenanceStartHeight)/len(currentValidatorSet)/Scale** 36 | 37 | **Scale** is a governable parameter, the initial setting is 2, usually it should be larger than 1. If **SlashCount** is larger than a predefined value, the validator will still be slashed. The validator can get more time to bring the node back before being slashed if it claims itself to enter maintenance. Validator is encouraged to claim itself to exit maintenance even if it will be put in jail, since it can send the unjail transaction earlier. 38 | 39 | #### Passive Maintenance 40 | Once the number of missed blocks is above a predefined threshold, the validator will enter maintenance automatically. The validator still gets a chance to catch up and claim itself online again. 41 | 42 | ### Limit 43 | 1. The number of maintained validators has an upper limit at the same time. Once exceeded, the following proactive/passive claim request will be rejected. 44 | 2. A validator can only enter maintenance once per day. 45 | 46 | ### ValidatorSet Change 47 | The validators election will repeat every 24 hours, the maintenance will end immediately once election happens. 48 | 49 | ### Impact to Validator Maintainers 50 | Validator maintainers can claim the validator to enter maintenance mode once the node runs into unexpected issues. Validator maintainers need to send transactions to exit maintenance mode even if the validator is enforced into maintenance, otherwise, the validator may be put in jail. 51 | 52 | ## 6. License 53 | 54 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 55 | 56 | 57 | 58 | -------------------------------------------------------------------------------- /BEPs/BEP128.md: -------------------------------------------------------------------------------- 1 | # BEP-128: Improvement on BNB Smart Chain Staking Reward Distribution 2 | 3 | - [BEP-128: Improvement on BNB Smart Chain Staking Reward Distribution](#bep-128-improvement-on-bnb-smart-chain-staking-reward-distribution) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Overall Workflow](#51-overall-workflow) 10 | - [5.2 Distribution Batch Size](#52-distribution-batch-size) 11 | - [5.3 User Impact](#53-user-impact) 12 | - [6. License](#6-license) 13 | 14 | ## 1. Summary 15 | This BEP describes a proposal to improve the BNB Smart Chain staking reward distribution mechanism on BNB Beacon Chain. 16 | 17 | ## 2. Abstract 18 | Instead of distributing BNB Smart Chain staking rewards in a single block for each day, this proposal suggests distributing staking rewards in many consecutive blocks, to minimize the burden on the specific block. 19 | 20 | ## 3. Status 21 | This BEP is already implemented. 22 | 23 | ## 4. Motivation 24 | Currently, the staking rewards of BNB Smart Chain are distributed in the first block of a day on BNB Beacon Chain (which is known as breath block). With the increasing number of delegators (more than 50,000 nowadays), it will lead to a heavy load to breath block, and users' transactions/requests could be affected. Meanwhile, it could also be a bottleneck for further evaluation of BNB Beacon Chain. Thus, this proposal provides a solution to fix the issue and benefit the evaluation of BNB Beacon Chain in the long term. 25 | 26 | ## 5. Specification 27 | ### 5.1 Overall Workflow 28 | ![overall workflow](./assets/bep-128/reward-distribution.png) 29 | 30 | The overall distribution processes work like this: 31 | - In breath block, validators' commission fee will be distributed, all delegators' rewards will be saved to a separate store. 32 | - Delegators' reward will be distributed in batches in the following blocks. 33 | 34 | ### 5.2 Distribution Batch Size 35 | 36 | Distribution batch size controls how many delegators will receive reward in a single block. It should be evaluated and adjusted to make sure: 37 | - The reward distribution must finish within one day, which means the batch size should not be too small. 38 | - It should not be too big to bring heavy load on a single block. 39 | 40 | At the same time, this batch size can also be governed. 41 | 42 | ### 5.3 User Impact 43 | 44 | The impact to general delegators is minimal, that their rewards will be delayed a bit after applying this proposal. However, the delay is relatively small and can be ignored compared to the whole staking process. Taking the current delegation volume as an example, about 50,000 rewards are distributed, then in the worst case the delay is 3~4 minutes (500 blocks) if the batch size is 100. 45 | 46 | ## 6. License 47 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 48 | 49 | -------------------------------------------------------------------------------- /BEPs/BEP151.md: -------------------------------------------------------------------------------- 1 | # BEP-151: Decommission Decentralized Exchange on BNB Beacon Chain 2 | 3 | ## 1. Summary 4 | This BEP proposes to securely and smoothly decommission the build-in decentralized exchange on BNB Beacon Chain. 5 | 6 | ## 2. Abstract 7 | BNB Beacon Chain’s primary focus, its native decentralized application ("dApp") BNB DEX, has demonstrated its low-latency matching with large capacity headroom. With the development of BNB Smart Chain and AMM-based decentralized exchanges running well on it, BNB DEX has less usage and liquidity. After implementing this BEP, the DEX module will be disabled, which will give Beacon Chain more computing power for the future computing and governance focuses. 8 | 9 | ## 3. Status 10 | This BEP is already implemented. 11 | 12 | ## 4. Motivation 13 | BNB Beacon Chain(BC) is a blockchain developed by the BNB Chain community that implements a vision of a decentralized exchange (DEX) for digital assets. The heart of Beacon Chain is a highly performant matching engine built on distributed consensus that aims to replicate the < 1 second trading efficiency of current centralized exchanges. 14 | 15 | Since BNB Smart Chain's(BSC) launch to mainnet in 2020, the AMM based decentralized exchanges gain great success on BSC which even steal the thunder of order-book based DEX on BC. BC and BSC is a dual chain structure, with the evolution of this structure, BC plays more like a Beacon Chain that helps to enhance the security of BSC as a staking and governance layer. It is not suitable for a Beacon Chain to sustain a high-performance DEX any longer, especially when there is another DEX with massive adoption in the same ecosystem. 16 | 17 | Decommissioning the DEX module will reduce the need for system resources significantly for both validators and full nodes. The demand for liquidation can be fulfilled by BNB Smart Chain or the upcoming zkBAS. 18 | 19 | ## 5. Specification 20 | After the implementation of this BEP, transactions related to DEX(including `NewOrderMsg`, `ListMsg`, `ListMiniMsg`) will return an error to disable listing new trading pairs or placing any new orders. 21 | All the existing orders will be canceled either by traders or by 3 days timeout(or 30 days for orders in the best 500 price levels, according to [BEP-67](https://github.com/bnb-chain/BEPs/blob/master/BEP67.md)). Thus there will be no more DEX transactions on Beacon Chain. 22 | 23 | ### 5.1 Safety 24 | After the implementation of this BEP, there will be no more new orders. 25 | The existing orders which are not matched yet will not be matched anymore. 26 | They can be canceled by the traders directly or by timeout automatically after a period of time, and refunded to the traders. 27 | All the funds are SAFU. 28 | 29 | ### 5.2 Impact 30 | Transactions `MsgSubmitProposal` with type of `ProposalTypeListTradingPair` or `ProposalTypeDelistTradingPair` are used for submitting proposals to list new trading pairs or delist trading pairs. 31 | 32 | They might be not useful any longer but still valid after the BEP. It's not encouraged to send these transactions anymore. 33 | 34 | ## 6. License 35 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 36 | -------------------------------------------------------------------------------- /BEPs/BEP171.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 171
 3 |   Title: Security Enhancement for Cross-Chain Module
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2022-10-28
 7 |   Author: cosinlink
 8 |
9 | 10 | # BEP-171: Security Enhancement for Cross-Chain Module 11 | 12 | - [BEP 171: Security Enhancement for Cross-Chain Module](#bep-171-security-enhancement-for-cross-chain-module) 13 | - [1. Summary](#1--summary) 14 | - [2. Motivation](#2--motivation) 15 | - [3. Specification](#3--specification) 16 | - [4. Reference](#4--reference) 17 | - [5. License](#5--license) 18 | 19 | ## 1. Summary 20 | 21 | This BEP introduces several security enhancements for the cross-chain bridge between BNB Beacon Chain and BNB Smart Chain. 22 | 23 | To further eliminate the pervasive effects of potential issues in cross chain module, it proposes the following enhancements: 24 | * Upgrade IAVL proof verification to [ICS23 spec](https://github.com/cosmos/ibc/tree/main/spec/core/ics-023-vector-commitments). 25 | * Apply timer lock to massive funds cross-chain transfer. 26 | * Cross chain channels can be automatically paused by forged proof detection. 27 | * Cross chain channels can be paused by any validator in an emergency. 28 | 29 | ## 2. Motivation 30 | 31 | A full in-depth security review of BSC cross-chain bridge and Cosmos related codebase is done after the [bridge exploitation](https://www.nansen.ai/research/bnb-chains-cross-chain-bridge-exploit-explained). The community is still really concerned there could be potential security issues in the cross chain module. This BEP aims to： 32 | * 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. 33 | * Exploitation automatic detection, quick action without human intervention. 34 | * Increase the cost of the attack, like timer lock. 35 | 36 | ## 3. Specification 37 | 38 | ### 3.1 ICS23 Upgrade 39 | 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. 40 | 41 | ### 3.2 Timelock 42 | If the value of the cross chain transfer is larger than a predefined threshold, the funds will be locked in [TokenHub](https://bscscan.com/address/0x0000000000000000000000000000000000001004) for a fixed period before they can be withdrawn to the target account. 43 | The default threshold of BNB is 10K, and the default lock period is 12 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](https://github.com/bnb-chain/BEPs/blob/master/BEP20.md#5116-getowner) permission to decide a proper threshold. The interface to set transfer threshold is as follows: 44 | 45 | function setLargeTransferLimit(address bep20Token, uint256 largeTransferLimit) external onlyTokenOwner(bep20Token); 46 | 47 | 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. 48 | 49 | ### 3.3 Exploitation Automatic Detection 50 | 51 | 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. 52 | 53 | #### 3.3.1 Challenge 54 | 55 | Anyone is allowed to submit a transaction to challenge the verified cross chain package on BSC. The interface is shown as below: 56 | 57 | function challenge(uint64 height0, uint64 height1, uint64 packageSequence, uint8 channelId, bytes calldata payload0, bytes calldata proof0, bytes calldata payload1, bytes calldata proof1) onlyInit blockSynced(height0) blockSynced(height1) channelSupported(channelId) external; 58 | 59 | 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. 60 | 61 | #### 3.3.2 Suspension in case of Emergency 62 | 63 | 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: 64 | 65 | function suspend() onlyCabinet whenNotSuspended external; 66 | 67 | 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: 68 | 69 | function reopen() onlyCabinet whenSuspended external; 70 | 71 | ### 3.4 Cancel Cross Chain Transfer 72 | 73 | The attacker's cross-chain transfer can be canceled by cabinet validators. The interface is shown as below: 74 | 75 | function cancelTransfer(address tokenAddr, address attacker) onlyCabinet external; 76 | 77 | The funds of this account in the timer lock will be returned to [TokenHub](https://bscscan.com/address/0x0000000000000000000000000000000000001004) to prevent someone minting tokens from nothing. 78 | 79 | ## 4. Reference 80 | 81 | ICS23 spec: 82 | 83 | 84 | ## 5. License 85 | All the content are licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 86 | -------------------------------------------------------------------------------- /BEPs/BEP172.md: -------------------------------------------------------------------------------- 1 | ``` 2 | BEP:172 3 | Title: Network Stability Enhancement On Slash Occur 4 | Status: Enabled 5 | Type: Standards 6 | Created: 2023-01-15 7 | Discussions: https://forum.bnbchain.org/t/bep-172-draft-improvement-on-bsc-validator-committing-stability/637/1 8 | ``` 9 | # BEP-172: Network Stability Enhancement On Slash Occur 10 | 11 | - [BEP-172: Network Stability Enhancement On Slash Occur](#bep-172-network-stability-enhancement-on-slash-occur) 12 | - [1. Summary](#1-summary) 13 | - [2. Abstract](#2-abstract) 14 | - [3. Motivation](#3-motivation) 15 | - [4. Specification](#4-specification) 16 | - [4.1 Overall workflow](#41-overall-workflow) 17 | - [4.2 Remove recentlySigned validators from the candidate set](#42-remove-recentlysigned-validators-from-the-candidate-set) 18 | - [4.3 Reduce minimum delay duration to be zero added to 3 seconds](#43-reduce-minimum-delay-duration-to-be-zero-added-to-3-seconds) 19 | - [5. License](#5-license) 20 | 21 | ## 1. Summary 22 | 23 | This BEP introduces an update for parlia consensus about the behavior when `slash` happened, so that the network will be more stable and efficient. 24 | 25 | ## 2. Abstract 26 | 27 | This BEP introduces an update for parlia consensus, which changes the `timestamp` and `delay` setting for `offturn` validators. When the validator `inturn` missed its turn to commit block, the block mined by the `offturn` validator selected randomly would be committed as soon as possible(4 or 3 seconds). 28 | 29 | ## 3. Motivation 30 | 31 | Before this BEP, a `slash` would happen when a validator missed its turn to commit a valid block. It would take some time longer than expected 3 seconds for the specific block mined with the `delay` mechanism, and even worse with the calculation algorithm deciding how long would be delayed when the block mined by `offturn` validator could be committed. And it took quit a long time (might be more than 1 minute) for the network recovering back to the expected block committing order with expected time duration(3 seconds). 32 | 33 | With this BEP we rewrite the calculation algorithm for the `offturn` validation `delay` time, so that it should be able to commit block in 4 seconds for the selected `offturn` validator when the `inturn` validator missed its turn. What's more, the `slash` will not have bad influence on the future blocks which means the network will recover to expected block producing duration in time. 34 | 35 | ## 4. Specification 36 | ### 4.1 Overall workflow 37 | ![backoffTime (3)](https://user-images.githubusercontent.com/26671219/202097706-d82347f1-fed0-49cb-be08-270d81f70f8b.png) 38 | 39 | 40 | ### 4.2 Remove recentlySigned validators from the candidate set 41 | - All validators would be involved to calculate the `delay` time when committing the block mined by themselves currently, and when the `inturn` validator missed its turn, the fastest-with the smallest `delay` duration equals to 4 seconds-`offturn` validator might be the one that had signed recently which led to some other `offturn` validator be the valid selected one to commit block. This is how we observed a block be committed in more than 4 seconds when the `slash` happened. In this BEP, we remove the `recently signed` validators off from the candidate set for calculating `delay` duration from 1 seconds(then the duration would be 3+1=4 seconds) up. 42 | ### 4.3 Reduce minimum delay duration to be zero added to 3 seconds 43 | - When a `slash` happened, things would go wrong for quite a long time later on. For example, when `inturn` validator_A was `slashed` on block_100 and `offturn` validator_B took its place to commit the block of number 100. However validator_B should be `inturn` for committing block_101, then it would fail to commit block_101 since it had committed block_100 `recently`. So although there was actually no `slash` happend(all validator worked appropriately), we still need to `delay` some time (1 second or more) to wait for the `offturn` validator committing the block since the `inturn` validator had `recently` committed some block earlier.In this BEP, we reduce the shortest duration to zero second for this specific scenario which means blocks should be able to committed in expected duration (3 seconds) when all validators workd propriately. 44 | 45 | ## 5. License 46 | 47 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP173.md: -------------------------------------------------------------------------------- 1 | 2 | # BEP-173: Introduce Text Governance Proposal for BNB Smart Chain 3 | 4 | - [BEP-173: Introduce Text Governance Proposal for BNB Smart Chain](https://github.com/bnb-chain/BEPs/pull/173) 5 | - [1. Summary](#1-summary) 6 | - [2. Status](#2-status) 7 | - [3. Motivation](#3-motivation) 8 | - [4. Specification](#4-specification) 9 | - [4.1 Introduction](#41-introduction) 10 | - [4.2 How to draft a text proposal](#42-how-to-draft-a-text-proposal) 11 | - [4.3 Governance stage](#43-governance-stage) 12 | - [4.3.1 Deposit stage](#431-deposit-stage) 13 | - [4.3.2 Voting stage](#432-voting-stage) 14 | - [4.3.3 Tallying stage](#433-tallying-stage) 15 | - [4.3.4 Execution stage](#434-execution-stage) 16 | - [5. License](#5-license) 17 | 18 | ## 1. Summary 19 | 20 | This BEP introduces a text governance proposal for BNB Smart Chain. 21 | 22 | 23 | ## 2. Status 24 | 25 | This BEP is already implemented. 26 | 27 | 28 | ## 3. Motivation 29 | 30 | In some scenarios, the community may need a proposal that does not directly cause any changes, like agreeing to a certain strategy, plan, commitment or other statement. 31 | 32 | 33 | ## 4. Specification 34 | 35 | 36 | ### 4.1 Introduction 37 | 38 | Right now, there are many system parameters that control the behavior of the BSC, e.g. slash amount, cross-chain transfer fees. All these parameters can be determined by the BSC Validator Set together through a proposal-vote process based on staking. The process executes on the BC and the new parameter values will be picked up by either the management module on the BC or corresponding system contracts via the cross-chain communication protocol. The proposals can be classified into two groups: 39 | 40 | 1. Param Change Proposal if the parameter takes effect on the Beacon Chain; 41 | 42 | 2. Cross Param Change Proposal if the parameter takes effect on the BNB Smart Chain. 43 | 44 | 45 | 46 | 47 | This proposal introduces a new kind of proposal to agree on a certain strategy, plan, commitment, future upgrade, or other statements. **Text proposals** are exclusively a signaling mechanism and focal point for future coordination - they do not directly cause any changes on-chain. 48 | 49 | 50 | ### 4.2 How to Draft a Text Proposal 51 | 52 | First, the proposer needs to determine which kind of proposal should be used. Be sure to review all the details of a specific proposal type. Aside from recording the proposal outcome on the BNB Beacon Chain, a text proposal has no direct effect on the BNB Chain. 53 | 54 | There are two key components: 55 | 56 | 57 | 58 | 1. Title - the distinguishing name of the proposal. 59 | 2. Description - the body of the proposal that further describes what is being proposed and the details surrounding the proposal. 60 | 61 | Here is a simple text proposal example: 62 | 63 | { 64 | 65 | "title": "Redesign the transaction ordering", 66 | 67 | "description": "Transactions with the same gas price are currently ordered by receive time. Since latency becomes critical after the update, nodes have less incentives to include light nodes and nodes located remotely as peers. Nodes are clustered and connected. This causes the nodes to become increasingly centralized and defeats the purpose of decentralization. Do we consider sorting with a noise value added so that order is sorted by T + N(0,sigma)?" 68 | 69 | } 70 | 71 | 72 | ### 4.3 Governance Stage 73 | 74 | 75 | #### 4.3.1 Deposit Stage 76 | 77 | Anyone can submit a text proposal on the BNB Beacon Chain for others to view. The only cost associated with submitting a proposal is the transaction fee which costs as little as 1 BNB. However, over the course of the voting period, a proposal must have at least 2000 BNB deposited to it in order for it to proceed to the voting stage. This period lasts for at most 2 weeks but if the minimum amount of 2000 BNB is reached sooner, the proposal will proceed to the voting stage immediately. Currently, there is no penalty for delegators and validators who do not participate in governance, though there is a risk to individuals who deposit BNB to a proposal if the proposal does not pass the voting stage, in such case the deposited BNB will be distributed to the validator set. 78 | 79 | 80 | #### 4.3.2 Voting Stage 81 | 82 | The next stage in the governance process is the voting stage which lasts a customized period. Rather than depositing BNB, validator operators in this governance stage are actually voting Yes, No, or Abstain. If a proposal reaches quorum or the minimum threshold defined by the protocol, it will proceed to the next stage for tallying. 83 | 84 | 85 | #### 4.3.3 Tallying Stage 86 | 87 | After the voting stage, the following conditions will be taken into consideration to determine if it passes or not: 88 | 89 | 90 | 91 | * Quorum: more than 50% of the total staked tokens at the end of the voting period need to have voted 92 | * Threshold: More than 50% or a majority of the tokens that participated in the vote, excluding "Abstain" votes must have voted "Yes" 93 | * Veto: Less than 33.4% of the tokens that participated in the vote, not counting "Abstain" votes, have vetoed the decision "No (With Veto)". 94 | 95 | If any of these conditions are not met, the deposit associated with the denied proposal will not be refunded. These funds will be sent to the validator set. 96 | 97 | 98 | #### 4.3.4 Execution Stage 99 | 100 | Once a text proposal is passed, it has no direct effect on the BNB Chain. Generic proposals such as a TextProposal must be reviewed by the BNB-Chain developers and the community for decisions on how to manually implement them. 101 | 102 | ## 5. License 103 | 104 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP188.md: -------------------------------------------------------------------------------- 1 | 
 2 | 	BEP: 188
 3 | 	Title: Early Broadcast Mature block for in-turn validators
 4 | 	Status: Withdrawn
 5 | 	Type: Standards
 6 | 	Created: 2022-01-12
 7 |
8 | 9 | # BEP-188: Early Broadcast Mature block for in-turn validators. 10 | 11 | - [BEP-188: Early Broadcast Mature block for in-turn validators.](#bep-188-early-broadcast-mature-block-for-in-turn-validators) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Specification](#3-specification) 15 | - [3.1 Broadcast strategy](#31-broadcast-strategy) 16 | - [3.2 consensus engine adaption](#32-consensus-engine-adaption) 17 | - [4. Backward Compatibility](#4-backward-compatibility) 18 | - [5. License](#5-license) 19 | 20 | ## 1. Summary 21 | 22 | This BEP introduces a new block broadcast strategy for validators to improve the network capacity and stability. 23 | 24 | ## 2. Motivation 25 | 26 | Currently, a mined block will not be broadcasted until the timestamp header.Time is reached, even though the mining process is finished. If an in-turn validator spends too much time in the importing phase, it may not have enough time to mine its own block. In extreme cases, it could generate an empty block or even miss its block. This could be a challenge to the stability of the blockchain.With this BEP, validators could begin to import a block earlier and have more time to mine a new block. 27 | 28 | ## 3. Specification 29 | 30 | ### 3.1 Broadcast strategy 31 | 32 | The current block production process is roughly shown in the figure below: 33 | 34 | ![mining_process_normal](./assets/BEP-188/mining_process_normal.png) 35 | 36 | 37 | 38 | As we can see, even though a block was mined before header.Time, it will delay to be broadcasted after header.Time. Then the next in-turn validator starts importing and mining after it receives the block. Actually, a block mined by the in-turn validator can be broadcast as soon as the mining process is finished to let other validators start importing in advance. 39 | But if we early broadcast without limit, the block production process may be like the figure below in case each validator finished mining very quickly because they ran out of gas. 40 | 41 | ![broadcast_withoutlimit](./assets/BEP-188/broadcast_without_limit.png) 42 | 43 | 44 | 45 | In this case, more than one block was mined in one block production cycle, which will break the current rule.Let’s see how it works if we limit the block broadcast time to after its parent’s header.Time under the same condition. 46 | 47 | ![early_broadcast_with_limit](./assets/BEP-188/early_broadcast_with_limit.png) 48 | 49 | Block N finished mining in advance because it ran out of gas and then broadcast without delay.Block N+1 also finished in advance and before blockN.header.Time, but it must delay broadcast to be after blockN.header.Time. In this way, the block production speed won’t be too quick to break the rule. 50 | In summary, when a block mined by an in-turn validator, if time is after its parent block’s header.Time, broadcast it without delay.time is before its parent block’s header, broadcast it when the parent block’s head.Time is reached. 51 | 52 | ### 3.2 consensus engine adaption 53 | 54 | The current consensus engine of the BNB chain does not accept future blocks, which means BSC nodes will reject the block if it is received earlier than its timestamp defined in header.Time. So we need to change the header’s verification logic in the consensus engine as well. 55 | As the broadcast strategy changes, the logic of verifyHeader must be changed accordingly.The new logic should be like this shown in the figure below. 56 | 57 | ![consensus_adaption](./assets/BEP-188/consensus_adaption.png) 58 | 59 | ## 4. Backward Compatibility 60 | 61 | In order to ensure the compatibility of the network, we should upgrade the changes with the strategy as follows: 62 | 63 | * Upgrading consensus changes with a hard fork first. 64 | 65 | * Then upgrading the broadcast strategy after the hard fork. 66 | ## 5. License 67 | 68 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP19.md: -------------------------------------------------------------------------------- 1 | # BEP-19: Introduce Maker and Taker for Match Engine 2 | 3 | - [BEP-19: Introduce Maker and Taker for Match Engine](#bep-19--introduce-maker-and-taker-for-match-engine) 4 | * [1. Summary](#1-summary) 5 | * [2. Abstract](#2-abstract) 6 | * [3. Status](#3--status) 7 | * [4. Motivation](#4-motivation) 8 | * [5. Specification](#5-specification) 9 | + [5.1 Price Determination](#51-price-determination) 10 | + [5.2 Execution Allocation](#52-execution-allocation) 11 | - [5.2.1 Definition of Maker and Taker](#521-definition-of-maker-and-taker) 12 | - [5.2.2 Execution Pricing](#522-execution-pricing) 13 | + [5.3 Match Time](#53-match-time) 14 | + [5.4 Publish](#54-publish) 15 | * [6. License](#6-license) 16 | 17 | ## 1. Summary 18 | 19 | This BEP describes a new on-chain match engine, Maker/Taker concepts are introduced to enhance the current periodic auction match algorithm. 20 | 21 | ## 2. Abstract 22 | 23 | The current match engine uses a periodic auction match algorithm. Matching will be executed once every block, all the candidate orders will be tried to be matched at the same time at the same price in every auction. 24 | 25 | Based on that algorithm, this specification introduces the concepts of maker and taker. The match is still executed only once in each block while the execution prices may vary for maker and taker orders. 26 | 27 | ## 3. Status 28 | 29 | This BEP is already implemented. 30 | 31 | ## 4. Motivation 32 | 33 | On not-so-liquid or highly volatile markets, the classic periodic auction match methodology would result in much worse average trade price to aggressive orders (i.e. Taker orders in the continuous match context), because all the trades would be marked with one final price, instead of the average price of all the waiting orders from the market. This is not friendly to active traders and amateur clients that are more familiar with continuous match markets. This causes extra effort to split aggressive orders and much confusion as BNB Beacon Chain DEX matches as fast as continuous matching exchange. 34 | 35 | ## 5. Specification 36 | 37 | An Auction Match comprises two steps, Price Determination followed by Execution Allocation. 38 | 39 | ### 5.1 Price Determination 40 | This BEP keeps the current algorithm to determine the single equilibrium match price, the following criteria shall be assessed in sequence: 41 | - Maximize the execution quantity 42 | - Execute all orders or at least all orders on one side that are fillable against the selected price. 43 | - Indicate the market pressure from either buy or sell and also consider to limit the max price movement 44 | let’s call this concluded price `P`. 45 | 46 | ### 5.2 Execution Allocation 47 | 48 | #### 5.2.1 Definition of Maker and Taker 49 | 50 | Among all the orders to be allocated, between buy and sell sides, this specification defines four concepts. 51 | 52 | | Name | Definition | 53 | | ----------- | ------------------------------------ | 54 | | Maker Order | order from the previous blocks | 55 | | Taker Order | new incoming order in the current block | 56 | | Maker Side | buy or sell side which has maker orders. May also have taker orders. | 57 | | Taker Side | buy or sell side which only has taker orders. | 58 | 59 | In each round of match, for all the orders that can be filled with the concluded price `P`, the algorithm ensures only one of the below two circumstances can happen, 60 | 61 | 1. Both buy and sell side are `Taker Side`, when there is no leftover orders from all the previous blocks; or, 62 | 63 | 2. One side is `Maker Side` that has orders from previous blocks (and may/may not have orders from this current block), and the other is `Taker Side` that only has orders from this current block. 64 | 65 | #### 5.2.2 Execution Pricing 66 | 67 | Among all the orders to be allocated, 68 | 69 | 1. For maker side, 70 | - all the maker orders are executed at their limit price 71 | - all the taker orders on the maker side are executed at the concluded price `P` 72 | 73 | 2. For taker side, all the orders are executed at the `average execution price` from the above #1 74 | 75 | If no maker side in this match, all the orders are executed at price `P`. 76 | 77 | ### 5.3 Match Time 78 | 79 | Candidates would be matched right after one block is committed. Each block has one round of match. 80 | 81 | ### 5.4 Publish 82 | 83 | In `OrderUpdates` messages, the trades generated in each block are published, either in json format or avro format. Here we can add a new field `TickType` to the `Trade` to indicate which side is the taker. 84 | 85 | 86 | | TickType Enum | Int value | Explanation | 87 | | ------------- | --------- | ----------- | 88 | | Unknown | 0 | For compatibility, all trades would use this before upgrade. 89 | | SellTaker | 1 | Sell order is the taker 90 | | BuyTaker | 2 | Buy order is the taker 91 | | BuySurplus | 3 | Both are taker, buy side has surplus. Market pressure is on the buy side 92 | | SellSurplus | 4 | Both are taker, sell side has surplus. Market pressure is on the sell side 93 | | Neutral | 5 | Both are taker, surplus is 0. 94 | 95 | When displaying the trade history, any client UI is suggested to show the above TickType in the below way: 96 | 97 | 1. Unknown in a neutral color 98 | 2. SellTaker/SellSurplus in downtick color 99 | 3. BuyTaker/BuySurplus/Neutral in uptick color 100 | 101 | ## 6. License 102 | 103 | All the content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP194.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 194
 3 |   Title: Node Discovery ENR filtering
 4 |   Status: Draft
 5 |   Type: Standards
 6 |   Created: 2023-02-01
 7 |   Author: Matus Kysel
 8 |
9 | 10 | # BEP 194: Node Discovery ENR filtering 11 | 12 | - [BEP 194: Node Discovery ENR filtering](#bep-194-node-discovery-enr-filtering) 13 | - [1. Summary](#1--summary) 14 | - [2. Motivation](#2--motivation) 15 | - [3. Specification](#3--specification) 16 | - [4. Reference](#4--reference) 17 | - [5. License](#5--license) 18 | 19 | 20 | ## 1. Summary 21 | 22 | This BEP introduces node discovery filtering based on ENR records on the BNB Smart Chain. 23 | 24 | ## 2. Motivation 25 | 26 | Current implementation of discovery protocol is chain agnostic and does not differentiate between different chains (ETH, BSC, ...). The discover protocol currently gossips peers from networks with different chain ids. This causes a pretty significant slowdown during peer discovery. 27 | 28 | ![node distribution](./assets/bep-194/node_distribution.png) 29 | *Figure 1: Current node distribution on BSC mainnet* 30 | 31 | From Figure 1 we can see, that new nodes have a 2x higher probability finding Ethereum nodes rather than BNB Smart Chain nodes. 32 | 33 | ## 3. Specification 34 | 35 | Node discovery protocol uses distributed hash tables (DHTs) that are exchanged between nodes via p2p. We will introduce a new filtering step that will filter out nodes before insertion to the table based on their ENR records. 36 | 37 | ``` 38 | // Record represents a node record. The zero value is an empty record. 39 | type Record struct { 40 | seq uint64 // sequence number 41 | signature []byte // the signature 42 | raw []byte // RLP encoded record 43 | pairs []pair // sorted list of all key/value pairs 44 | } 45 | ``` 46 | *Code 1: Current ENR record structure layout* 47 | 48 | 49 | ENR record consists of key-value pairs. One of these key-value pairs is the `eth` key which has a genesis hash value. Based on genesis hash we can filter out nodes that are running a different chain id. 50 | 51 | ``` 52 | func (eth *Ethereum) currentEthEntry() *ethEntry { 53 | return ðEntry{ForkID: forkid.NewID(eth.blockchain.Config(), eth.blockchain.Genesis().Hash(), 54 | eth.blockchain.CurrentHeader().Number.Uint64())} 55 | } 56 | ``` 57 | *Code 2: eth entry generation function* 58 | 59 | We would introduce new flag for `boot-nodes` : 60 | 61 | - `-network ` filters nodes by "eth" ENR entry 62 | 63 | 64 | ## 4. Reference 65 | 66 | ENR: 67 | 68 | Node Discovery Protocol: 69 | 70 | ## 5. License 71 | 72 | All the content are licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP216.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 216
 3 |   Title: Implement EIP-3855: PUSH0 instruction
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2023-3-30
 7 |
8 | 9 | # BEP-216: Implement EIP 3855 PUSH0 instruction 10 | - [BEP-216: Implement EIP 3855 PUSH0 instruction](#bep-216-implement-eip-3855-push0-instruction) 11 | - [1. Summary](#1-summary) 12 | - [2. Abstract](#2-abstract) 13 | - [3. Motivation](#3-motivation) 14 | - [4. Specification](#4-specification) 15 | - [5.Rationale](#5-rationale) 16 | - [6. Backwards Compatibility](#6-backwards-compatibility) 17 | - [7. Test Cases](#test-cases) 18 | - [8. License](#8-license) 19 | - [9. Reference](#9-reference) 20 | 21 | ## 1. Summary 22 | 23 | As part of the Shanghai upgrade, EIP-3855: PUSH0 Instruction is required to be implemented to BSC. 24 | 25 | ## 2. Abstract 26 | 27 | Introduce the PUSH0 (0x5f) instruction, which pushes the constant value 0 onto the stack. 28 | 29 | ## 3. Motivation 30 | 31 | **Original motivation from EIP-3855:** 32 | 33 | Many instructions expect offsets as inputs, which in a number of cases are zero. A good example is the return data parameters of CALLs, which are set to zeroes in case the contract prefers using RETURNDATA*. This is only one example, but there are many other reasons why a contract would need to push a zero value. They can achieve that today by PUSH1 0, which costs 3 gas at runtime, and is encoded as two bytes which means 2 * 200 gas deployment cost. 34 | 35 | Because of the overall cost many try to use various other instructions to achieve the same effect. Common examples include PC, MSIZE, CALLDATASIZE, RETURNDATASIZE, CODESIZE, CALLVALUE, and SELFBALANCE. Some of these cost only 2 gas and are a single byte long, but their value can depend on the context. 36 | 37 | Analysis has been conducted on ETH Mainnet (block ranges 8,567,259…8,582,058 and 12,205,970…12,817,405), and ~11.5% of all the PUSH* instructions executed push a value of zero. 38 | 39 | The main motivations for this change include: 40 | 41 | 1. Reducing contract code size. 42 | 2. Reducing the risk of contracts (mis)using various instructions as an optimisation measure. Repricing/changing those instructions can be more risky. 43 | 3. Reduce the need to use DUP instructions for duplicating zeroes. 44 | 45 | To put the “waste” into perspective, across existing accounts 340,557,331 bytes are wasted on PUSH1 00 instructions, which means 68,111,466,200 gas was spent to deploy them. In practice a lot of these accounts share identical bytecode with others, so their total stored size in clients is lower, however the deploy time cost must have been paid nevertheless. 46 | 47 | An example for 2) is changing the behaviour of RETURNDATASIZE such that it may not be guaranteed to be zero at the beginning of the call frame. This was proposed as a way to chain transactions (i.e. EIP-2733). 48 | 49 | ## 4. Specification 50 | 51 | The instruction PUSH0 is introduced at 0x5f. It has no immediate data, pops no items from the stack, and places a single item with the value 0 onto the stack. The cost of this instruction is 2 gas (aka base). 52 | 53 | ## 5. Rationale 54 | 55 | **Gas cost** 56 | 57 | The base gas cost is used for instructions which place constant values onto the stack, such as ADDRESS, ORIGIN, and so forth. 58 | 59 | **Opcode** 60 | 61 | 0x5f means it is in a “contiguous” space with the rest of the PUSH implementations and potentially could share the implementation. 62 | 63 | ## 6. Backwards Compatibility 64 | 65 | This introduces a new opcode which did not exist previously. Already deployed contracts using this opcode could change their behaviour after this EIP. 66 | 67 | ## 7. Test Cases 68 | 69 | * 5F – successful execution, stack consist of a single item, set to zero 70 | * 5F5F..5F (1024 times) – successful execution, stack consists of 1024 items, all set to zero 71 | * 5F5F..5F (1025 times) – execution aborts due to out of stack 72 | 73 | ## 8 License 74 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 75 | 76 | ## 9. Reference 77 | 78 | Most description of this BEP refer to [EIP-3855](https://eips.ethereum.org/EIPS/eip-3855): 79 | 80 | Alex Beregszaszi ([@axic](https://github.com/axic)), Hugo De la cruz ([@hugo-dc](https://github.com/hugo-dc)), Paweł Bylica ([@chfast](https://github.com/chfast)), "EIP-3855: PUSH0 instruction [DRAFT]," Ethereum Improvement Proposals, no. 3855, February 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3855. -------------------------------------------------------------------------------- /BEPs/BEP221.md: -------------------------------------------------------------------------------- 1 | 
 2 |    BEP: 221
 3 |    Title: CometBFT Light Block Validation
 4 |    Status: Draft
 5 |    Type: Standards
 6 |    Created: 2022-04-11
 7 |
8 | 9 | # BEP-221: CometBFT Light Block Validation. 10 | 11 | - [BEP-221: CometBFT Light Block Validation.](#bep-221--cometbft-light-block-validation) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Specification](#3-specification) 15 | - [4. License](#4-license) 16 | 17 | ## 1. Summary 18 | 19 | This BEP introduces a new precompiled contract to validate the [CometBFT](https://docs.cometbft.com/v0.37/introduction/) light blocks. 20 | 21 | ## 2. Motivation 22 | 23 | There are some cross-chain requirements between BSC and CometBFT-compatible blockchains, like the `BNB Greenfield` which 24 | is an important part of the BNB ecosystem, thus we need a gas-friendly solution to validate the light blocks from the 25 | CometBFT-compatible blockchains. 26 | 27 | ## 3. Specification 28 | 29 | ### 3.1 Consensus State 30 | 31 | To validate the light blocks from the CometBFT-compatible blockchains, there should be a light client of the blockchain 32 | on the BSC side, it could be implemented as a smart contract, and this light client should record the necessary 33 | current state which we call it **Consensus State** to validate the future light blocks. The consensus state is defined as: 34 | 35 | ```go 36 | type ConsensusState struct { 37 | ChainID string 38 | Height uint64 39 | NextValidatorSetHash []byte 40 | ValidatorSet *types.ValidatorSet 41 | } 42 | ``` 43 | 44 | The consensus state should be encoded as a part of the precompiled contract's input, and after applying the light block, 45 | the updated consensus state should be encoded as a part of the precompiled contract's output. The encoding format should be: 46 | ``` 47 | |--ChainID---|--Height---|--NextValidatorSetHash--|--[{validator pubkey, voting power, relayer address, relayer bls pubkey}]--| 48 | |--32 bytes--|--8 bytes--|--32 bytes--------------|--[{32 bytes, 8 bytes, 20 bytes, 48 bytes}]--------------------------------| 49 | ``` 50 | 51 | The `validator pubkey` and `voting power` are necessary for recovering the validator in the current validator set. The 52 | `relayer address` and `relayer bls pubkey` are extended to support some cross-chain infrastructure base on [BLS](https://en.wikipedia.org/wiki/BLS_digital_signature), 53 | we can just pad zero bytes if we don't use `relayer address` or `relayer bls pubkey`. 54 | 55 | ### 3.2 Light Block 56 | 57 | A light block of CometBFT-compatible blockchain contains a SignedHeader and a ValidatorSet, which can be imported into 58 | the [CometBFT Light Client](https://docs.cometbft.com/v0.37/spec/light-client/) and update the light client's consensus state accordingly. The light block is defined as: 59 | 60 | ```go 61 | type LightBlock struct { 62 | *SignedHeader `json:"signed_header"` 63 | ValidatorSet *ValidatorSet `json:"validator_set"` 64 | } 65 | ``` 66 | 67 | The light block itself has a **Marshal** method to convert it into a byte array, and it should be a part of the precompiled 68 | contract's input. Within the precompiled contract, use the **Unmarshal** method to recover it. 69 | 70 | ### 3.3 Validate Light Block 71 | 72 | The input of the precompiled contract should include the current consensus state and the future light block. The encoding 73 | format should be: 74 | ``` 75 | |--consensus state length--|--consensus state--|--light block--| 76 | |--32 bytes----------------|-------------------|---------------| 77 | ``` 78 | 79 | Here are the steps to validate the light block within the precompiled contract: 80 | 1. Decode the input to get the current consensus state and the light block. 81 | 2. Apply the light block into the current consensus state according to [CometBFT Light Client Verification](https://docs.cometbft.com/v0.37/spec/light-client/verification/). 82 | 3. Encode the updated consensus state and return it to the caller. 83 | 84 | The output of the precompiled contract should be encoded as follows: 85 | ``` 86 | |--validatorSetChanged--|--empty-----|--consensus state length--|--new consensus state--| 87 | |--1 byte---------------|--23 bytes--|--8 bytes-----------------|-----------------------| 88 | ``` 89 | 90 | ## 4. License 91 | 92 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 93 | -------------------------------------------------------------------------------- /BEPs/BEP226.md: -------------------------------------------------------------------------------- 1 | 
 2 |     BEP: 226
 3 |     Title: Enable EIP-1559 with base fee of 0
 4 |     Status: Enabled
 5 |     Type: Standards
 6 |     Created: 2023-04-17
 7 |
8 | 9 | # BEP-226: Enable EIP-1559 with base fee of 0 10 | 11 | - [BEP-226: Enable EIP-1559 with base fee of 0](#bep-226-enable-eip-1559-with-base-fee-of-0) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Specification](#3-specification) 15 | - [4. Backwards Compatibility](#4-backwards-compatibility) 16 | - [5. License](#5-license) 17 | 18 | 19 | 20 | ## 1. Summary 21 | This BEP introduces [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) headers and transactions to BSC but with base fee set to 0. 22 | 23 | 24 | ## 2. Motivation 25 | To keep up to date with the latest developments in EVM blockchains it is important to keep the block and transaction structures up to date. New features (such as account abstraction) being introduced 26 | to EVM chains already presuppose EIP-1559 type of block headers and transactions. Therefore, for compatibility reasons it is important that EIP-1559 constructs be enabled on BSC. 27 | 28 | EIP-1559 was introduced in Ethereum to improve the gas fee pricing mechanism and to make the ETH token more deflationary, as the base fee would be burnt after a transaction was completed. In BSC there is already a burning mechanism in place ([BEP-95](https://github.com/bnb-chain/BEPs/blob/master/BEP95.md)) so there is no need to burn the base fee. Therefore the base fee will be set to 0, and will 29 | not adjust based on network congestion like in the Ethereum EIP. 30 | 31 | 32 | ## 3. Specification 33 | 34 | Essentially the same gas fee mechanism will be kept in place but the extra `BaseFee` field will be enabled in the header (which will be required to be 0). In addition, the `GasTipCap` (a.k.a. `maxPriorityFeePerGas`) and `maxFeePerGas` fields will be enabled by using a dynamic transaction type instead of the legacy transaction types. Since `baseFee` will be 0, `maxPriorityFeePerGas = maxFeePerGas` . 35 | 36 | 37 | The code for EIP-1559 has already been merged from upstream go-ethereum codebase into BSC node codebase, but some custom modifications are still needed (to maintain a constant base fee of 0, and disable extra checks that keep track of the gas utilization over time ) and to ensure everything works correctly before a hard fork enabling this BEP on BSC network. 38 | 39 | 40 | ## 4. Backwards Compatibility 41 | Legacy transactions will still work and be included in blocks. This is due to the fact that upgrading from legacy transactions to new transactions results in the legacy transaction's `gas_price ` entirely being consumed either by the `base_fee_per_gas` and the `priority_fee_per_gas`. 42 | 43 | 44 | ## 5. License 45 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 46 | -------------------------------------------------------------------------------- /BEPs/BEP227.md: -------------------------------------------------------------------------------- 1 | 
 2 |     BEP: 227
 3 |     Title: Add BASEFEE opcode
 4 |     Status: Enabled
 5 |     Type: Standards
 6 |     Created: 2023-04-17
 7 |
8 | 9 | 10 | 11 | # BEP-227: Add BASEFEE opcode 12 | 13 | - [BEP-227: Add BASEFEE opcode](#bep-227-add-basefee-opcode) 14 | - [1. Summary](#1-summary) 15 | - [2. Abstract](#2-abstract) 16 | - [3. Motivation](#3-motivation) 17 | - [4. Specification](#4-specification) 18 | - [5. Gas cost](#5-gas-cost) 19 | - [6. Backwards Compatibility](#6-backwards-compatibility) 20 | - [7. Test Cases](#7-test-cases) 21 | - [7.1 Nominal case](#71-nominal-case) 22 | - [8. Security Considerations](#8-security-considerations) 23 | - [9. License](#9-license) 24 | 25 | 26 | 27 | ## 1. Summary 28 | Adds an opcode that gives the EVM access to the block's base fee. This BEP is dependent on BEP-226 (EIP-1559 with base fee of 0). 29 | 30 | ## 2. Abstract 31 | 32 | Add a `BASEFEE (0x48)` that returns the value of the base fee of the current block it is executing in. 33 | 34 | The code for this BEP has already been merged from upstream go-ethereum codebase into BSC node codebase. The work entails enabling EIP-3198 (this BEP) for BSC network configurations and performing a hard fork. 35 | 36 | 37 | ## 3. Motivation 38 | The intended use case would be for contracts to get the value of the base fee (introduced by EIP-1559 (BEP-226)). 39 | 40 | ## 4. Specification 41 | Add a `BASEFEE` opcode at `(0x48)`, with gas cost `G_base`. 42 | 43 | | Op | Input | Output | Cost | 44 | |:----: |:-----: |:------: |:----: | 45 | | 0x48 | 0 | 1 | 2 | 46 | 47 | 48 | 49 | 50 | ### 5. Gas cost 51 | The value of the base fee is needed to process transactions. That means it's value is already available before running the EVM code. 52 | The opcode does not add extra complexity and additional read/write operations, hence the choice of `G_base` gas cost. 53 | 54 | ## 6. Backwards Compatibility 55 | There are no known backward compatibility issues with this opcode. 56 | 57 | ## 7. Test Cases 58 | 59 | ### 7.1 Nominal case 60 | Assuming current block base fee is `7 wei`. 61 | This should push the value `7` (left padded byte32) to the stack. 62 | 63 | Bytecode: `0x4800` (`BASEFEE, STOP`) 64 | 65 | | Pc | Op | Cost | Stack | RStack | 66 | |-------|-------------|------|-----------|-----------| 67 | | 0 | BASEFEE | 2 | [] | [] | 68 | | 1 | STOP | 0 | [7] | [] | 69 | 70 | Output: 0x 71 | Consumed gas: `2` 72 | 73 | ## 8. Security Considerations 74 | The value of the base fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this opcode. 75 | 76 | ## 9. License 77 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 78 | -------------------------------------------------------------------------------- /BEPs/BEP228.md: -------------------------------------------------------------------------------- 1 | 
 2 |     BEP: 228
 3 |     Title: Prevent deploying contracts starting with 0xEF
 4 |     Status: Enabled
 5 |     Type: Standards
 6 |     Created: 2023-04-17
 7 |
8 | 9 | 10 | # BEP-228: Prevent deploying contracts starting with 0xEF. 11 | 12 | - [BEP-228: Prevent deploying contracts starting with 0xEF.](#bep-228-prevent-deploying-contracts-starting-with-0xef) 13 | - [1. Summary](#1-summary) 14 | - [2. Motivation](#2-motivation) 15 | - [3. Specification](#3-specification) 16 | - [3.1 Remarks](#31-remarks) 17 | - [4. Rationale](#4-rationale) 18 | - [5. Test Cases](#5-test-cases) 19 | - [6. Backwards Compatibility](#6-backwards-compatibility) 20 | - [7. Security Considerations](#7-security-considerations) 21 | - [8. License](#8-license) 22 | 23 | 24 | ## 1. Summary 25 | 26 | Disallow new code starting with the `0xEF` byte to be deployed. Code already existing in the account trie starting with `0xEF` byte is not affected semantically by this change. 27 | 28 | This BEP essentially enables Ethereum's EIP-3541. The code has been already ported from go-ethereum. What remains is for this BEP to be enabled in a BSC hard fork. 29 | 30 | ## 2. Motivation 31 | 32 | Contracts conforming to the EVM Object Format (EOF) are going to be validated at deploy time. In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. This will be achieved by choosing a byte sequence for the *magic* that doesn't exist in any of the already deployed contracts. To prevent the growth of the search space and to limit the analysis to the contracts existing before this fork, we disallow the starting byte of the format (the first byte of the magic). 33 | 34 | Should the EVM Object Format proposal not be deployed in the future, the *magic* can be used by other features depending on versioning. In the case versioning becomes obsolete, it is simple to roll this back by allowing contracts starting with the `0xEF` byte to be deployed again. 35 | 36 | ## 3. Specification 37 | 38 | After `block.number == HF_BLOCK` new contract creation (via create transaction, `CREATE` or `CREATE2` instructions) results in an exceptional abort if the _code_'s first byte is `0xEF`. 39 | 40 | ### 3.1 Remarks 41 | 42 | The *initcode* is the code executed in the context of the *create* transaction, `CREATE`, or `CREATE2` instructions. The *initcode* returns *code* (via the `RETURN` instruction), which is inserted into the account. See section 7 ("Contract Creation") in the Yellow Paper for more information. 43 | 44 | The opcode `0xEF` is currently an undefined instruction, therefore: *It pops no stack items and pushes no stack items, and it causes an exceptional abort when executed.* This means *initcode* or already deployed *code* starting with this instruction will continue to abort execution. 45 | 46 | The exceptional abort due to *code* starting with `0xEF` behaves exactly the same as any other exceptional abort that can occur during *initcode* execution, i.e. in case of abort all gas provided to a `CREATE*` or create transaction is consumed. 47 | 48 | ## 4. Rationale 49 | 50 | The `0xEF` byte was chosen because it resembles **E**xecutable **F**ormat. 51 | 52 | Contracts using unassigned opcodes are generally understood to be at risk of changing semantics. Hence using the unassigned `0xEF` should have lesser effects, than choosing an assigned opcode, such as `0xFD` (`REVERT`), `0xFE` (`INVALID)`, or `0xFF` (`SELFDESTRUCT`). Arguably while such contracts may not be very useful, they are still using valid opcodes. 53 | 54 | Analysis in May 2021, on `18084433` contracts in state, showed that there are 0 existing contracts starting with the `0xEF` byte, as opposed to 1, 4, and 12 starting with `0xFD`, `0xFE`, and `0xFF`, respectively. 55 | 56 | ## 5. Test Cases 57 | 58 | Each test case below may be executed in 3 different contexts: 59 | - create transaction (no account code) 60 | - `CREATE`, with account code: `0x6000356000523660006000f0151560165760006000fd5b` (Yul code: `mstore(0, calldataload(0)) if iszero(create(0, 0, calldatasize())) { revert(0, 0) }`), 61 | - `CREATE2`, with account code: `0x60003560005260003660006000f5151560185760006000fd5b` (Yul code: `mstore(0, calldataload(0)) if iszero(create2(0, 0, calldatasize(), 0)) { revert(0, 0) }`) 62 | 63 | | Case | Calldata | Expected result | 64 | | -------- | -------- | -------- | 65 | | deploy one byte `ef` | `0x60ef60005360016000f3` | new contract not deployed, transaction fails | 66 | | deploy two bytes `ef00` | `0x60ef60005360026000f3` | new contract not deployed, transaction fails | 67 | | deploy three bytes `ef0000` | `0x60ef60005360036000f3` | new contract not deployed, transaction fails | 68 | | deploy 32 bytes `ef00...00` | `0x60ef60005360206000f3` | new contract not deployed, transaction fails | 69 | | deploy one byte `fe` | `0x60fe60005360016000f3` | new contract deployed, transaction succeeds | 70 | 71 | ## 6. Backwards Compatibility 72 | 73 | This is a breaking change given new code starting with the `0xEF` byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with `0xEF` as the first byte is not executable anyway. 74 | 75 | While this means no currently executable contract is affected, it does rejects deployment of new data contracts starting with the `0xEF` byte. 76 | 77 | ## 7. Security Considerations 78 | 79 | The authors are not aware of any security or DoS risks posed by this change. 80 | 81 | ## 8. License 82 | 83 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 84 | -------------------------------------------------------------------------------- /BEPs/BEP255.md: -------------------------------------------------------------------------------- 1 | 
 2 |   BEP: 255
 3 |   Title: Beacon Chain Asset Reconciliation for Security Enhancement
 4 |   Status: Enabled
 5 |   Type: Standards
 6 |   Created: 2023-07-04
 7 |
8 | 9 | # BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement 10 | 11 | - [BEP-255: Beacon Chain Asset Reconciliation for Security Enhancement](#bep-255-beacon-chain-asset-reconciliation-for-security-enhancement) 12 | - [1. Summary](#1-summary) 13 | - [2. Motivation](#2-motivation) 14 | - [3. Specification](#3-specification) 15 | - [3.1 Asset Reconciliation](#31-asset-reconciliation) 16 | - [3.2 Halt on Reconciliation Error](#32-halt-on-reconciliation-error) 17 | - [4. License](#4-license) 18 | 19 | ## 1. Summary 20 | 21 | This BEP proposes implementing on-chain asset reconciliation on BNB Beacon Chain to improve security. 22 | 23 | ## 2. Motivation 24 | 25 | As a beacon chain, the BNB Beacon Chain plays a vital role in securing the BNB chain ecosystem. Although some 26 | enhancements have been made to improve cross-chain security, such as BEP171, the security of assets on the BNB Beacon 27 | Chain itself should also be guaranteed, especially after 28 | the [bridge exploitation](https://www.nansen.ai/research/bnb-chains-cross-chain-bridge-exploit-explained). Therefore, 29 | this BEP proposes implementing on-chain asset reconciliation. 30 | 31 | ## Specification 32 | 33 | ### 3.1 Asset Reconciliation 34 | 35 | There are many tokens issued on the BNB Beacon Chain, and they are highly valued assets to users. Therefore, 36 | reconciliation mainly focuses on the balances of all users. However, with millions of users on the BNB Beacon Chain, it 37 | is impossible to review all accounts and reconcile their balances. Therefore, the following approach is proposed, by 38 | only reconciling the accounts changed in each block: 39 | 40 | * Firstly, the IAVL store is updated to track the storage keys that have been updated in a block. For example, if there 41 | is a transfer transaction in a block, the related sender and receiver's storage keys will be tracked. 42 | 43 | * Secondly, in each EndBlocker, changes in account balances (e.g., transfers) will be calculated as balance changes for 44 | all related accounts, and the related token supply changes (e.g., minting) will be calculated as token supply changes, 45 | by comparing the related values in the current state and previous state with the IAVL trees, which are versioned. 46 | 47 | $$ \Delta_{balance} = \sum ( balance_{current\ state} - balance_{previous\ state} ) $$ 48 | 49 | $$ \Delta_{token\ supply} = \sum ( token\ supply_{current\ state} - token\ supply_{previous\ state} ) $$ 50 | 51 | * Thirdly, asset reconciliation is conducted by comparing whether the balance changes and token supply changes are 52 | equal. If there is a reconciliation error (i.e., unbalanced asset changes), the height will be written to the chain 53 | state, and the blockchain will panic. 54 | 55 | $$ reconciliation\ error\ \iff\ \Delta_{balance} \neq \Delta_{token\ supply} $$ 56 | 57 | ### 3.2 Halt on Reconciliation Error 58 | 59 | If a reconciliation error occurs, the blockchain will stop producing new blocks, impacting downstream services such as 60 | bridges, deposits, and withdrawals on exchanges. This drastic action is necessary to protect the chain and its users, so 61 | core developers and community members should investigate the issue as soon as possible. Validators and node operators 62 | should contact the core developers or be prepared to resume the network. 63 | 64 | To bring the blockchain back online, a hard fork is needed. In the fork, the reconciliation error must be addressed 65 | correctly; for example, if exploitation exists, related accounts should be blacklisted or corrected. Once the blockchain 66 | is resumed, downstream services can be brought back up as well. 67 | 68 | ## License 69 | 70 | The content is licensed under the [CC0](https://creativecommons.org/publicdomain/zero/1.0/) license. 71 | -------------------------------------------------------------------------------- /BEPs/BEP323.md: -------------------------------------------------------------------------------- 1 | 
  2 |   BEP: 323
  3 |   Title: Bundle Format for Greenfield
  4 |   Status: Enabled
  5 |   Type: Standards
  6 |   Created: 2023-11-16
  7 |
8 | 9 | 10 | # BEP-323: Bundle Format for Greenfield 11 | 12 | - [BEP-323: Bundle Format for Greenfield](#bep-323-bundle-format-for-greenfield) 13 | - [1. Summary](#1-summary) 14 | - [2. Motivation](#2-motivation) 15 | - [3. Specification](#3-specification) 16 | - [3.1 Bundle Format](#31-bundle-format) 17 | - [3.1.1 Encoding](#311-encoding) 18 | - [4. License](#4-license) 19 | 20 | ## 1. Summary 21 | 22 | This BEP proposes a solution for better on-chain storage efficiency and user experience in Greenfield by introducing 23 | a method to bundle small files together before uploading. The new system will reduce storage space and costs caused 24 | by small files while increasing the capacity of the entire network. 25 | 26 | ## 2. Motivation 27 | 28 | Storing small files in Greenfield is inefficient. The metadata stored on the blockchain can be larger than the files, 29 | leading to higher costs for users. Greenfield Blockchain has a capacity limit to process files simultaneously. 30 | 31 | To tackle this problem, we aim to design a bundle format specifically for Greenfield. This is because a specialized 32 | format will allow developers to build something that fits exactly with what Greenfield and its users need, without 33 | any unnecessary features. By introducing a bundle format, Greenfield can provide a better service to the users and 34 | make sure that Greenfield stays efficient and easy to use as it grows. 35 | 36 | ## 3. Specification 37 | 38 | ### 3.1 Bundle Format 39 | 40 | The bundle format specifies the structure and organization of the bundle that users create when packing files. 41 | This format is designed to pack flat files; hierarchical directory structures, or folders, are not supported. 42 | 43 | When dealing with a folder, users can simplify its structure by turning it into a series of individual files. 44 | As part of this process, it renames each file to include the folder path. For example, a file originally named 45 | `file.txt` inside the nested folders `dirA` and `dirB` would be renamed to `dirA/dirB/file.txt`. 46 | This approach allows us to maintain the organization of the folder while conforming to the requirement for flat files in the bundle. 47 | 48 | There are still constraints for the bundle format. The file names of the files in the bundle should be unique so that 49 | they can be indexed by the file name. 50 | 51 | The bundle format is structured into several key components as follows: 52 | 53 | * Version: This indicates the version number of the bundle protocol being used. 54 | * Meta Size: This specifies the size of the bundle's metadata, allowing the construction of the bundle structure without the need to read the entire bundle. 55 | * Metadata: This section contains information about the files within the bundle. It facilitates the ability to access files randomly, which means you can jump directly to any file within the bundle without going through all the files. 56 | * Data: This portion represents the actual content and is comprised of all the files in bytes. 57 | 58 | ![](./assets/bep-323/bundle_struct.png) 59 | 60 | The Meta structure is designed to include essential attributes for each file, outlined as follows: 61 | 62 | * Object Name: This is the name of the file within the bundle. 63 | * Offset: This attribute marks the starting point of the file's data within the bundle. 64 | * Size: This details the total length, in bytes, of the file. 65 | * Hash Algo: This specifies the algorithm used for the file's hash calculation. 66 | * Hash: This is the cryptographic hash result of the file's content. It serves as a tool for verifying the file's integrity. 67 | * Content Type: This denotes the MIME type of the file, describing the file's nature and format. 68 | * Tags: This is a map that holds various additional properties of the file like `owner` . 69 | 70 | #### 3.1.1 Encoding 71 | 72 | ![](./assets/bep-323/bundle_encoding.png) 73 | 74 | The bundle's encoding format is structured as follows: 75 | 76 | * Version: Serialized as an unsigned 64-bit integer, occupying 8 bytes. 77 | * Meta Size: Also an unsigned 64-bit integer, represented using 8 bytes, indicating the size of the metadata section. 78 | * Metadata: Encoded in bytes, this section utilizes Protocol Buffers (protobuf) for serialization. 79 | * Data: This consists of the actual file contents, represented as a sequence of bytes. 80 | 81 | The Meta structure will be serialized with protobuf: 82 | 83 | ```java 84 | enum HashAlgo { 85 | Sha256 = 0; 86 | } 87 | 88 | message Meta { 89 | repeated FileMeta meta = 1; 90 | } 91 | 92 | message FileMeta { 93 | string object_name = 1; 94 | uint64 offset = 2; 95 | uint64 size = 3; 96 | HashAlgo status = 4; 97 | bytes hash = 5; 98 | string content_type = 6; 99 | map tags = 7; 100 | } 101 | ``` 102 | 103 | ## 4. License 104 | 105 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP39.md: -------------------------------------------------------------------------------- 1 | # BEP-39: Add MEMO to Transfer WebSocket. 2 | 3 | - BEP-39: Add MEMO to Transfer WebSocket 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Websocket](#51-websocket) 10 | - [6. License](#6-license) 11 | 12 | ## 1. Summary 13 | 14 | This BEP describes an improvement to the Transfer Websocket. 15 | 16 | ## 2. Abstract 17 | 18 | BEP-39 requests that `MEMO` data field be added to the `/ws/userAddress` websocket. 19 | 20 | Currently the `MEMO` field is not being returned on the websocket, which means that services that rely on `MEMO` to set transaction specifications must then retrieve it from the Transaction API endpoint. 21 | 22 | This creates unnecessary burden on the API and slows down the transaction processing. 23 | 24 | The solution is to add it to the Transfer Websocket as a data field to stream. 25 | 26 | ## 3. Status 27 | 28 | This BEP is already implemented. 29 | 30 | ## 4. Motivation 31 | 32 | Wallets, exchanges, dApps and other services will set transaction state in the `MEMO` to allow them to be stateless. 33 | 34 | To improve the speed at which the `MEMO` field can be read and processed, it should be added to the websocket so it doesn't burden BNB Beacon Chain Node API endpoints, which are rate-limited. 35 | 36 | ## 5. Specification 37 | 38 | ### 5.1 Websocket 39 | 40 | The following is the update for the `/ws/userAddress` websocket with the added `MEMO` field: 41 | 42 | ``` 43 | { 44 | "stream": "transfers", 45 | "data": { 46 | "e":"outboundTransferInfo", // Event type 47 | "E":12893, // Event height 48 | "H":"0434786487A1F4AE35D49FAE3C6F012A2AAF8DD59EC860DC7E77123B761DD91B", // Transaction hash 49 | "M": "MEMO" // Memo 50 | "f":"bnb1z220ps26qlwfgz5dew9hdxe8m5malre3qy6zr9", // From addr 51 | "t": 52 | [{ 53 | "o":"bnb1xngdalruw8g23eqvpx9klmtttwvnlk2x4lfccu", // To addr 54 | "c":[{ // Coins 55 | "a":"BNB", // Asset 56 | "A":"100.00000000" // Amount 57 | }] 58 | }] 59 | } 60 | } 61 | ``` 62 | 63 | ## 6. License 64 | 65 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 66 | -------------------------------------------------------------------------------- /BEPs/BEP6.md: -------------------------------------------------------------------------------- 1 | # BEP-6: Delist Trading Pairs 2 | 3 | ## 1. Summary 4 | This BEP describes a proposal for delisting trading pairs from the BNB Beacon Chain DEX. 5 | ## 2. Abstract 6 | Listing new trading pairs is done via listing proposals. Suppose a token has a crediting issue or one of its trading pairs has little trading volume for a long time, the community might consider to drop related trading pairs to save network cost. This BEP proposes a method to delist trading pairs via governance. The below picture describes the overview of how delist logic works. 7 | 8 | ``` 9 | +----------+ +----------------+ +---------------+ +--------------------+ +--------+ 10 | | | | deposit period | | voting period | | cooling-off period | | | 11 | | Submit | | +--------+ | | +-----------+ | | +--------+ | | | 12 | | proposal |<--->| | 2 days | |<---->| | less than | |<---->| | 3 days | |<--->| delist | 13 | | | | +--------+ | | | 14 days | | | +--------+ | | | 14 | | | | | | +-----------+ | | | | | 15 | +----------+ +----------------+ +---------------+ +--------------------+ +--------+ 16 | ``` 17 | 18 | ## 3. Status 19 | This BEP is already implemented. 20 | ## 4. Motivation 21 | The purpose of delisting is to prioritise computing resources on healthy assets and provide a way to optimise trading markets on DEX. 22 | ## 5. Specification 23 | The delisting procedure can be divided into three steps: 24 | 25 | - Submit and voting on proposal 26 | - Cooling-off period 27 | - Check constraints and expire orders 28 | 29 | To delist a trading pair, users submit a DelistTradingPair proposal. If the proposal is passed, then step 2 and 3 will be triggered. If any of the steps fail, all subsequent steps will not be executed. 30 | ### 5.1 DelistTradingPair Proposal 31 | Firstly, users must propose by specifying which trading pair to delist and the corresponding justification. 32 | 33 | | Name | Type | Description | json field | 34 | | ------------------- | ----------- | ------------------------ | ------------------ | 35 | | BaseAssetSymbol | string | base asset symbol | base_asset_symbol | 36 | | QuoteAssetSymbol | string | quote asset symbol | quote_asset_symbol | 37 | | Justification | string | the reason to delist trading pair; the maximum length is limited by proposal total length, which is 2048 bytes | justification | 38 | 39 | These parameters will be json marshaled to strings and assigned to the Description field. 40 | 41 | The DelistTradingPair proposal is similar to a governance proposal. It requires other governance related parameters: 42 | 43 | | Name | Type | Description | 44 | | ----------------- | ----------- | ------------------------ | 45 | | Title | string | base asset symbol | 46 | | Description | string | Json marshals string of BaseAssetSymbol, QuoteAssetSymbol and Justification | 47 | | ProposalType | string | Type of proposal, here the type should be “DelistTradingPair” | 48 | | Proposer | Bech32_address | Address of the proposer | 49 | | InitialDeposit | coins | Initial deposit paid by sender. Must be strictly positive | 50 | | VotingPeriod | int | Length of the voting period| 51 | 52 | 53 | ### 5.2 Cooling-Off Period 54 | Once a `DelistTradingPair` proposal is passed, it will enter a cooling-off period. The cooling-off period lasts until the next UTC 00:00 after the 72-hour point of the proposal passing. As the name suggests, users should re-evaluate the market and take action on the proposed asset to be delisted. In this period, users can still create new orders and cancel orders on the trading pair. Once this period has ended, all outstanding orders will expire. 55 | ### 5.3 Delist 56 | Delisting happens on the next UTC 00:00 after the 72-hour point of the proposal passing. There are 2 steps to delist trading pairs as below. 57 | #### 5.3.1 Trading Pairs Constraint Check 58 | For BNB Beacon Chain, all listed tokens requires `BNB` as an initial base pair. Suppose there are three tokens on BNB Beacon Chain: `A`, `B` and `BNB`, and there is only one trading pair: `A_BNB`. If someone wants to create a new `A_B` trading pair, he must create the `B_BNB` trading pair first. 59 | 60 | In conclusion, a `non-BNB` trading pair `A_B` will depend on two other trading pairs: `A_BNB` and `B_BNB`, and any `BNB` related trading pair may be the dependency of other trading pairs. 61 | 62 | This constraint is checked before the removal of the trading pair. If the constraint is not satisfied, the trading pair won’t be removed. If the delister still wishes to delist the trading pair, he must propose a new `DelistTradingPair` proposal on this trading pair again. However, before doing that, the delister must delist all dependent trading pairs first. 63 | 64 | #### 5.3.2 Remove Trading Pair And Expire All Orders 65 | Once the trading pair constraint check has been passed, the clearance operation will be triggered and all related outstanding orders will expire. The locked tokens in the orders will be refunded to users and order expiration fee will be charged. 66 | 67 | After these 2 steps, the trading pair will be removed. The delisting process is complete. 68 | 69 | ## 6. License 70 | All the content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 71 | 72 | -------------------------------------------------------------------------------- /BEPs/BEP67.md: -------------------------------------------------------------------------------- 1 | # BEP-67: Price-based Order Expiration 2 | 3 | - [BEP-67: Price-based Order Expiration](#bep-67-price-based-order-expiration) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Order Expiration](#51-order-expiration) 10 | - [5.2 Change Impact](#52-change-impact) 11 | - [5.2.1 Impact on Trader](#521-impact-on-trader) 12 | - [5.2.2 Impact on BNB Beacon Chain](#522-impact-on-bnb-beacon-chain) 13 | - [6. License](#6-license) 14 | 15 | ## 1. Summary 16 | 17 | This BEP describes an enhancement of the Order Expiration. 18 | 19 | ## 2. Abstract 20 | 21 | Currently orders on BNB Beacon Chain will be expired after 3 days. Order cannot live long on the market even their price stays competitive, which is not convenient and incurs cost to traders. The solution is to keep orders in the best 500 price levels for 30 days rather than 3 days. 22 | 23 | ## 3. Status 24 | This BEP is already implemented. 25 | 26 | ## 4. Motivation 27 | 28 | Traders want to keep their open orders more than 3 days so that they do not need re-create their cancelled orders every 3 days. 29 | 30 | 31 | ## 5. Specification 32 | 33 | ### 5.1 Order Expiration 34 | By current implementation, in the first block after UTC 00:00 every day, orders which have been staying in order book for longer than 72 hours will be removed from order book and marked as 'expired'. 35 | After the implementation of BEP-67, those orders in the best 500 price levels on both ask and bid side will be expired after 30 days instead of 72 hours. Meanwhile, the expiration fee is unchanged. 36 | 37 | 38 | ### 5.2 Change Impact 39 | #### 5.2.1 Impact on Trader 40 | For those traders who follow current strict 3-day expiration time, they may need change their order placement strategy. 41 | #### 5.2.2 Impact on BNB Beacon Chain 42 | There could be more orders in node memory. So the compulsory expiration is introduced for the orders older than 30 days. 43 | ## 6. License 44 | 45 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 46 | 47 | 48 | 49 | -------------------------------------------------------------------------------- /BEPs/BEP70.md: -------------------------------------------------------------------------------- 1 | # BEP70: List and Trade BUSD Pairs 2 | 3 | - [BEP70: List and Trade BUSD Pairs](#bep70-list-and-trade-busd-pairs) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Proposing and Listing](#51-proposing-and-listing) 10 | - [5.1.1 Current Restriction](#511-current-restriction) 11 | - [5.1.2 Proposed Changes](#512-proposed-changes) 12 | - [5.2 Trading Fee Calculation](#52-trading-fee-calculation) 13 | - [6. License](#6-license) 14 | 15 | ## 1. Summary 16 | This BEP describes a proposal for listing and trading BUSD pairs without explicit dependency on the native token BNB. 17 | 18 | ## 2. Abstract 19 | BUSD, as one of the most influential stable coins worldwide and the most dominant stable coin on BNB Beacon Chain, is playing an important role for trading and communicating with fiat currencies. Listing and trading BUSD pairs on BNB Beacon Chain will facilitate token owners and exchange traders, making the markets more liquid and healthier. 20 | 21 | However, on BNB Beacon Chain now, if you want to trade between your token and BUSD , you must firstly list a trading pair between BNB and the token you have, which could be unnecessary sometimes. 22 | 23 | This BEP proposes the solutions for listing and trading BUSD pairs without explicit dependency on BNB. 24 | 25 | ## 3. Status 26 | This BEP is already implemented. 27 | 28 | ## 4. Motivation 29 | The purpose of this BEP are 30 | 1. Relaxing the restriction of listing, and 31 | 2. Providing another channel for exchanging stable coins, leading to more diversified choices for token owners and exchange traders. 32 | 33 | ## 5. Specification 34 | ### 5.1 Proposing and Listing 35 | #### 5.1.1 Current Restriction 36 | Currently, for listing a trading pair between AAA and BUSD, there are following prerequisites: 37 | + Existed trading pair between AAA and BNB 38 | + Existed trading pair between BUSD and BNB 39 | 40 | #### 5.1.2 Proposed Changes 41 | For proposing and listing BUSD trading pairs, BUSD must be the base asset or quote asset. It means the BaseAssetSymbol or QuoteAssetSymbol must be BUSD-BD1 on the mainnet, and QuoteAssetSymbol or BaseAssetSymbol does not have to be BNB. 42 | 43 | | **Name** | **Type** | **Description** | 44 | | ------------------- | ----------- | ------------------------ | 45 | | BaseAssetSymbol | string | base asset symbol, use BUSD symbol for BUSD pair | 46 | | QuoteAssetSymbol | string | quote asset symbol, use BUSD symbol for BUSD pair | 47 | 48 | With the proposed changes, for listing a trading pair between AAA and BUSD, the chain will not ask for the existence of any trading pair between AAA and BNB. The main restriction will be: 49 | + Existed trading pair between BUSD and BNB, which is already satisfied on mainnet now. 50 | 51 | ### 5.2 Trading Fee Calculation 52 | To calculate the trading fees, the price of BNB denominated in BUSD will be used if needed. 53 | 54 | ## 6. License 55 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -------------------------------------------------------------------------------- /BEPs/BEP82.md: -------------------------------------------------------------------------------- 1 | # BEP-82: Token Ownership Changes 2 | 3 | ## 1. Summary 4 | This BEP describes the changes related to the token owner who issued a token on BNB Beacon Chain. 5 | 6 | ## 2. Abstract 7 | Currently, many token-related transactions, such as token listing, minting, burning, etc., can only be proposed by the token owner who can not be changed once the token is issued on BNB Beacon Chain. 8 | 9 | This BEP proposes the solutions to provide more convenience and flexibility for these transactions. 10 | 11 | ## 3. Status 12 | This BEP is already implemented 13 | 14 | ## 4. Motivation 15 | To reduce the transaction's dependence on the related token’s owner and make the ownership of token changeable, we introduce those solutions as following: 16 | - Providing an entrance to transfer the ownership of a specific token. 17 | - Removing the owner verification when handling some token related transactions. 18 | 19 | ## 5. Specification 20 | ### 5.1 Transfer Ownership 21 | **TransferOwnership** transaction can transfer ownership of a specific token to another address, and only the original owner has the permission to send this transaction. 22 | 23 | A fee (a fixed amount of BNB) will be charged on **TransferOwnership** transactions. 24 | 25 | Parameters for TransferOwnership Operation: 26 | 27 | | **Field** | **Type** | **Description** | 28 | | ------------------- | ----------- | ------------------------ | 29 | | From | string | the address who wants to transfer the ownership to another address | 30 | | Symbol | string | the token symbol needs to be transferred ownership | 31 | | NewOwner | string | the address who is assigned to be the new owner of the token | 32 | 33 | ### 5.2 Token Owner Verification Changes 34 | Currently, some token-related transactions are restricted to being proposed by token owners while others are not. After the implementation of this BEP, any address can burn its own tokens. Here is the comparison below: 35 | 36 | | **Transaction Type** | **Verify Owner(Before)** | **Verify Owner(After)** | 37 | | ------------------------- | ------------------------- |---------------------------| 38 | | list token | yes | yes | 39 | | mint token | yes | yes | 40 | | burn token | yes | no | 41 | | freeze token | no | no | 42 | | set URI | yes | yes | 43 | | atomic swap related | no | no | 44 | | time lock | no | no | 45 | | time unlock | no | no | 46 | | time relock | no | no | 47 | | transfer | no | no | 48 | | cross transfer out | no | no | 49 | | cross bind | yes | yes | 50 | | cross unbind | yes | yes | 51 | 52 | 53 | ## 6. License 54 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 55 | 56 | -------------------------------------------------------------------------------- /BEPs/BEP86.md: -------------------------------------------------------------------------------- 1 | # BEP-86: Dynamic Extra Incentive For BSC Relayers 2 | 3 | - [BEP-86: Dynamic Extra Incentive For BSC Relayers](#bep-86-dynamic-extra-incentive-for-bsc-relayers) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Governable Parameter](#51-governable-parameter) 10 | - [5.2 Modify RelayerIncentivize Contract](#52-modify-relayerincentivize-contract) 11 | - [6. License](#6-license) 12 | 13 | ## 1. Summary 14 | 15 | This BEP proposes a reward mechanism to balance the gain and risk for BSC relayers, which will attract more relayers to engage in and improve the cross chain communication robustness between BC and BSC. 16 | 17 | ## 2. Abstract 18 | 19 | Now all bsc-relayers are suffering from BNB loss in relaying cross chain packages from BC to BSC. Besides, it would not be helpful to community development if common users have to pay more relay fees. To compensate relayers and avoid additional burden to common users, some dynamic extra reward will be granted to bsc-relayers from the [SystemReward Contract](https://github.com/bnb-chain/bsc-genesis-contract/blob/master/contracts/SystemReward.sol). 20 | 21 | ## 3. Status 22 | 23 | This BEP is already implemented. 24 | 25 | ## 4. Motivation 26 | 27 | Anyone can maintain a bsc-relayer by depositing 100BNB to the RelayerHub contract. If the relay reward can cover the relay cost, then more and more people will maintain their own bsc-relayer, which will improve the robustness of the cross chain communication between BC and BSC. Otherwise, no one is willing to maintain a bsc-relayer. Thus the communication between the BC and the BSC will be blocked. 28 | 29 | ## 5. Specification 30 | 31 | ### 5.1 Governable Parameter 32 | Import a governable parameter `dynamicExtraIncentiveAmount` to the [RelayerIncentivize Contract](https://github.com/bnb-chain/bsc-genesis-contract/blob/master/contracts/RelayerIncentivize.sol): 33 | 1. The `dynamicExtraIncentiveAmount` represents the amount of BNB which will be transferred from the SystemReward to the bsc relayer reward pool. 34 | 2. The `dynamicExtraIncentiveAmount` can be modified by sidechain governance on BC. 35 | 36 | ### 5.2 Modify RelayerIncentivize Contract 37 | Modify the `addReward` method in the RelayerIncentivize contract: 38 | 1. Try to claim `dynamicExtraIncentiveAmount` from the SystemReward contract. 39 | 2. Add the new claimed reward to the existing reward. 40 | 3. Add the total reward to the relayer reward pool. 41 | 42 | ## 6. License 43 | All the content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 44 | -------------------------------------------------------------------------------- /BEPs/BEP87.md: -------------------------------------------------------------------------------- 1 | # BEP-87: Token Symbol Minimum Length Change 2 | 3 | ## 1. Summary 4 | This BEP proposes to reduce the minimum length limit for token symbol on BNB Beacon Chain 5 | 6 | ## 2. Abstract 7 | Currently, the token symbol minimum length is limited to 3. After implementing this BEP, the users are allowed to issue a token with a symbol of 2 characters. 8 | 9 | ## 3. Status 10 | This BEP is already implemented 11 | 12 | ## 4. Motivation 13 | As many users have the requirements to issue a two-character token on BNB Beacon Chain, the minimum token symbol length will be changed to 2 in this BEP. 14 | 15 | ## 5. Specification 16 | 17 | ### Length Changes 18 | When the issuer sends an issue transaction for issuing BEP2/BEP8 token, the token symbol length must be between 2-8. Here is the comparison of the length check below: 19 | 20 | | **Token Type** | **Length Check(Before)** | **Length Check(After)** | 21 | | :------------- | :----------------------- | :---------------------- | 22 | | BEP2 | 3-8 | 2-8 | 23 | | BEP8 | 3-8 | 2-8 | 24 | 25 | After the implementation of this BEP, the token symbol length of BNB Beacon Chain would be between 2 and 8. 26 | 27 | ## 6. License 28 | 29 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 30 | 31 | -------------------------------------------------------------------------------- /BEPs/BEP89.md: -------------------------------------------------------------------------------- 1 | # BEP-89: Visual Fork of BNB Smart Chain 2 | 3 | - BEP-89: Visual Fork of BNB Smart Chain 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Fork Hash](#51-fork-hash) 10 | - [5.2 Vanity](#52-vanity) 11 | - [5.3 Vanity](#53-clients) 12 | - [5.4 Backwards Compatibility](#54-backwards-compatibility) 13 | - [6. License](#6-license) 14 | 15 | ## 1. Summary 16 | 17 | This BEP describes a proposal to enable the chain to display the whole view of validators that on different upcoming forks. 18 | 19 | ## 2. Abstract 20 | 21 | The four bytes of `Header.Extra[28:32]` will be fulfilled with `NEXT_FORK_HASH`. The `NEXT_FORK_HASH` indicates which fork the signer of this block is going to stay on. By analysing `N` (`N` is the amount of validators) continuous block headers, we are able to know which fork is supported by the majority of validators and exact which validator has not upgraded yet. 22 | 23 | ## 3. Status 24 | 25 | This BEP is already implemented 26 | 27 | ## 4. Motivation 28 | 29 | BNB Smart Chain will inevitably have some hard forks in the long run. During a hard fork, BNB Smart Chain risks halting if the validators cannot reach a consensus. A validator may be slashed if it is not on the canonical fork, which could be avoided if the maintainer receives alerts in time. A new protocol should be introduced to enable the chain to display the whole view of validators on different upcoming forks, so that any nodes/validators can decide to upgrade/fork or not accordingly. 30 | ## 5. Specification 31 | 32 | ### 5.1 Fork Hash 33 | 34 | Fork Hash is introduced in [EIP-2124](https://eips.ethereum.org/EIPS/eip-2124). It is a mechanism that can let ethereum nodes precisely identify whether another node will be useful. 35 | 36 | - `FORK_HASH`. IEEE CRC32 checksum ([4]byte) of the genesis hash and fork blocks numbers that already passed. E.g. Fork Hash for mainnet would be: `forkhash₂ = 0x91d1f948 (DAO fork) = CRC32( || uint64(1150000) || uint64(1920000))`. 37 | - `FORK_NEXT`. Block number (uint64) of the next upcoming fork, or 0 if no next fork is known. 38 | - `NEXT_FORK_HASH`, whose algorithm is same with `FORK_HASH`, but `FORK_NEXT` will be included as well if it is not 0. 39 | 40 | ### 5.2 Vanity 41 | 42 | Format of `Header.Extra`: 43 | 44 | ``` 45 | | 32 bytes | 20 * N bytes | 65 bytes | 46 | | extraVanity | validatorSetBytes | extraSeal | 47 | ``` 48 | 49 | `extraVanity` field is customized now, validator can use it to record `NEXT_FORK_HASH` of itself. The `NEXT_FORK_HASH` will only use the last 4 bytes of `extraVanity`. 50 | 51 | ### 5.3 Clients 52 | 53 | - For validator. It will fill in `Header.Extra` with `NEXT_FORK_HASH` during preparing block header. 54 | - For witness. It will log a warning message if the majority `NEXT_FORK_HASH` is different from local. 55 | - For light client. No impact. 56 | 57 | ### 5.4 Backwards Compatibility 58 | 59 | - This BEP itself is not a hardfork one, it breaks nothing of consensus. 60 | - Downstream service is completely compatible with this BEP. 61 | 62 | ## 6. License 63 | 64 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 65 | -------------------------------------------------------------------------------- /BEPs/BEP9.md: -------------------------------------------------------------------------------- 1 | # BEP-9: Time Locking of Tokens 2 | 3 | - [BEP-9: Time Locking of Tokens](#bep-9-time-locking-of-tokens) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [5.1 Transactions](#51-transactions) 10 | - [5.1.1 TimeLock](#511-timelock) 11 | - [5.1.2 TimeUnlock](#512-timeunlock) 12 | - [5.1.3 TimeRelock](#513-timerelock) 13 | - [5.1.4 QueryTimeLocks](#514-querytimelocks) 14 | - [5.1.4 QueryTimeLock](#514-querytimelock) 15 | - [6. License](#6-license) 16 | 17 | ## 1. Summary 18 | 19 | This BEP describes a proposal for a time-locking feature of tokens on the BNB Beacon Chain. 20 | 21 | ## 2. Abstract 22 | 23 | BEP-9 Proposal describes functionality to time-lock tokens on the BNB Beacon Chain. Such as: 24 | 25 | + TimeLock: TimeLock will transfer locked tokens to a purely-code-controlled escrow account. A purely-code-controlled escrow account is a kind of account which is derived from a hard-coded string in BNB Beacon Chain protocol. This kind of account has no private key and it's only controled by code in protocol. Before the lock time expires, the specific user will not be able to claim them back, including restrictions where they cannot use, transfer or spend these tokens. 26 | + TimeUnlock: TimeUnlock will claim the locked tokens back when the specified lock time has passed. 27 | + TimeRelock: TimeRelock can extend lock times, increase the amount of locked tokens or modify the description of an existing lock record. 28 | + QueryTimeLocks: QueryTimeLocks will query all lock records of a given address. 29 | + QueryTimeLock: QueryTimeLock will query a lock record of a given address. 30 | 31 | 32 | ## 3. Status 33 | 34 | This BEP is already implemented. 35 | 36 | ## 4. Motivation 37 | 38 | Some business plans decide to lock certain amount tokens for pre-defined periods of time, and only vest in the future according to the schedules. 39 | For example, some projects may lock some allocation of the issued tokens as a commitment by the founding team; some business scenarios also need to lock some tokens as collateral for value. 40 | 41 | ## 5. Specification 42 | 43 | ### 5.1 Transactions 44 | 45 | #### 5.1.1 TimeLock 46 | 47 | TimeLock transactions can lock tokens from the owner address for a specified time period. Any address can TimeLock its own tokens. 48 | 49 | A fee (a fixed amount of BNB) will be charged on TimeLock transactions. 50 | 51 | **Parameters for TimeLock Operation**: 52 | 53 | | **Field** | **Type** | **Description** | 54 | | :------------ | :-------- | :------------------------------------------------------------ | 55 | | Description | string | Description of the lock operation. Max length of description is 128 bytes. | 56 | | Amount | []Coin | A set of tokens to be locked | 57 | | LockTime | int64 | The time when these tokens can be unlocked. LockTime is a future timestamp(seconds elapsed from January 1st, 1970 at UTC) and max LockTime should be before 10 years from now. | 58 | 59 | TimeLock transaction will transfer locked tokens to a purely-code-controlled escrow account and will return a TimeLock record id. No one can transfer the tokens out of the escrow account, unless the owner of the tokens successfully runs “TimeUnlock” under the preset requirements. 60 | 61 | #### 5.1.2 TimeUnlock 62 | 63 | TimeUnlock transactions unlock tokens from a given TimeLock record. TimeUnlock transactions will fail if the operation time is prior to the LockTime specified in the respective TimeLock transaction or if the address is not the same as the tokens’ owner. 64 | 65 | If a TimeUnlock transaction succeeds, the locked tokens will be returned to the owner's account, and the related TimeLock record will be deleted. 66 | 67 | A fee (a fixed amount of BNB) will be charged on TimeUnlock transactions. 68 | 69 | 70 | **Parameters for TimeUnlock Operation**: 71 | 72 | | **Field** | **Type** | **Description** | 73 | | :------------ | :-------- | :------------------------------------------------------------ | 74 | | RecordId | int64 | `TimeLock` record id | 75 | 76 | #### 5.1.3 TimeRelock 77 | 78 | TimeRelock transactions update the amount of locked tokens or the lock time of a given TimeLock record. But users can only increase the amount of locked tokens and/or increase the lock time only. 79 | 80 | A fee (a fixed amount of BNB) will be charged on TimeRelock transactions. 81 | 82 | 83 | **Parameters for TimeRelock Operation**: 84 | 85 | | **Field** | **Type** | **Description** | 86 | | :------------ | :-------- | :------------------------------------------------------------ | 87 | | RecordId | int64 | `TimeLock` record id | 88 | | Description | string | Description of the lock transaction. If Description is empty, this operation will not change description of TimeLock record. Max length of description is 128 bytes. | 89 | | IncreaseAmountTo | []Coin | A set of tokens to be locked. If IncreaseAmountTo is empty, this operation will not change the amount in the TimeLock record. If Amount is not empty, amount should be more than the original amount. | 90 | | ExtendedLockTime | int64 | Time when these tokens can be unlocked. If ExtendedLockTime is zero, this operation will not change lock time of TimeLock record. If ExtendedLockTime is not zero, it should be after the original lock time. LockTime is a future timestamp and max LockTime should be before 10 years from now. | 91 | 92 | #### 5.1.4 QueryTimeLocks 93 | 94 | QueryTimeLocks will return all TimeLock records of a specific address. 95 | 96 | #### 5.1.4 QueryTimeLock 97 | 98 | QueryTimeLock will return TimeLock record of a given TimeLock record id of a specific address. 99 | 100 | ## 6. License 101 | 102 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 103 | -------------------------------------------------------------------------------- /BEPs/BEP91.md: -------------------------------------------------------------------------------- 1 | # BEP-91: Increase Block Gas Ceiling for BNB Smart Chain 2 | 3 | - [BEP-91: Increase Block Gas Ceiling for BNB Smart Chain](#bep-91-increase-block-gas-ceiling-for-BNB-smart-chain) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [6. License](#6-license) 10 | 11 | ## 1. Summary 12 | 13 | This BEP describes a proposal for the increment of **gasceil** of BSC. 14 | 15 | ## 2. Abstract 16 | 17 | BEP-91 Proposal describes a change of BSC node configuration, and suggests Validator operators should increase the value of the block `GasCeil`from `60000000` to `75000000`, and increase the value of the block `GasFloor`from `40000000` to `60000000` . 18 | 19 | ## 3. Status 20 | 21 | This BEP is already implemented. 22 | 23 | ## 4. Motivation 24 | 25 | The increasing adoption of BSC leads to a more active network. Blocks start hitting the gasceil daily. The increasing prevalence of blocks near the limit may lead to increased fees and delays in the processing of transactions in the future. This will undermine the core value of BSC as a fast and cheap network. 26 | 27 | img 28 | 29 | BSC network has once reached the 40M gas limit, it can handle more transactions according to the following screenshot. 30 | 31 | img 32 | 33 | Increased gasceil will lead to more transactions per block. It will be a direct solution to scale. 34 | 35 | ## 5. Specification 36 | 37 | According to the past laboratory tests, BSC can process real transactions with more than 70M Gas. Considering the complex network environment in mainnet and the different hardware of validators, 60M is a relatively reasonable value. If 60M is larger than expected, the miner module of BSC will adaptively adjust it to avoid network overloading. 38 | 39 | It is strongly recommended to raise the gasceil parameter as well as hardware. The validator may get less reward than expected if its hardware fails to validate enough tx. 40 | 41 | As the transaction volume continues to increase, more changes should be made to the internal logic on transaction execution, storage and P2P communication. 42 | 43 | ## 6. License 44 | 45 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 46 | -------------------------------------------------------------------------------- /BEPs/BEP93.md: -------------------------------------------------------------------------------- 1 | # BEP-93: Diff Sync Protocol on BSC 2 | 3 | ## 1. Summary 4 | 5 | This BEP introduces a new sync mode named diff sync on the BNB Smart Chain. 6 | 7 | ## 2. Abstract 8 | 9 | BEP-93 Proposal describes a fast block syncing protocol to lower the hardware requirement for running a BSC client. A BSC client can simply apply the execution result of a block securely without executing the transactions. 10 | 11 | Currently, BSC has three kinds of sync mode: 12 | 1. Snap sync; 13 | 2. Fast sync; 14 | 3. Full sync. 15 | 16 | Snap sync and fast sync are used for the initial synchronization, once the client has the entire state and all historical block data, it will switch to full sync automatically. 17 | 18 | It takes several steps to process a block when doing full sync: 19 | 1. Fetch/Receive blocks from other peers through p2p network. 20 | 2. Verify header and block body. 21 | 3. Execute transactions within EVM. 22 | 4. Calculate the root hash of MPT. 23 | 5. Commit MPT to memory DB, persist snapshot and MPT to disk if necessary. 24 | 25 | In most cases, step 3 occupied 70+% of the block processing time. 26 | 27 | This BEP proposes a diff sync protocol without executing transactions, in exchange, the security of a fullnode will degrade to a light client, but meanwhile the node can still keep the full state and blocks of the network. This will benefit the small node so that they can still be used as full nodes and participate in the light verification of the network. 28 | 29 | ## 3. Status 30 | 31 | This BEP is already implemented. 32 | 33 | ## 4. Motivation 34 | 35 | The increasing adoption of BSC leads to a more active network. Blocks on BSC start hitting the gasceil daily, and the BSC network will increase the capacity further. On the other hand, the node maintainer had a hard time keeping their node catching up with the chain. A light syncing protocol to lower the hardware requirement is an urgent need. 36 | 37 | ## 5. Specification 38 | ### 5.1 Diff Protocol 39 | 40 | A new protocol named diff will run on top of the p2p network besides eth and snap. Four kinds of packages are defined under the diff protocol: 41 | 42 | 1. **DiffCapMsg**. It is used to exchange whether the peer supports diff sync during the handshake. 43 | 2. **GetDiffLayerMsg**. It is used to request diff layers from other peers. 44 | 3. **DiffLayerMsg**. It is used to broadcast diff layers to other peers. 45 | 4. **FullDiffLayerMsg**. It is a response to GetDiffLayerMsg which contains the diff layers. 46 | 47 | Diff layer is the execution result of a block, it contains: 48 | 1. **BlockHash**. 49 | 2. **Number**. The height of the block. 50 | 3. **Receipts**. The receipts of the block. 51 | 4. **Codes**. The newly created smart contract code within the block. 52 | 5. **Destructs**. The destroyed accounts within the block. 53 | 6. **Accounts**. The account change within the block. 54 | 7. **Storages**. The storage change within the block. 55 | 56 | ### 5.2 Sync Diff Layer 57 | ![Untitled Diagram drawio](https://user-images.githubusercontent.com/7310198/132794555-e071232b-9d91-461e-b6ef-9589cd37f738.png) 58 | 59 | 60 | Workflow: 61 | 1. P2P nodes full sync a block and cache the generated diff layer. 62 | 2. (optional)The generated diff layer can be persisted if it is on the canonical chain. 63 | 3. P2P nodes may receive diff layers from other peers, will cache it in an untrusted diff layer set. 64 | 4. P2P node will broadcast diff layers to parts of connected peers. 65 | 5. P2P nodes will pick diff layers from the cache, disk, and untrusted set to respond to requests from other peers. 66 | 6. A full node can fetch diff layers from other peers 67 | 7. A full node can apply the diff layers to MPT and Snapshot without executing transactions, it is called light process. If the light process failed, the full node will fall back to full sync. 68 | 69 | ### 5.3 Security 70 | The diff sync protocol guarantees 1. Light client security; 2. State consistency. 71 | 72 | It sustains 1. Validator collusion 2. Short fork with an invalid state. 73 | 74 | For validator collusion, the full node will randomly full sync to prevent applying a false state caused by validator collusion. 75 | 76 | For short fork with an invalid state, it is highly recommended that at least 21 blocks are needed to reach finality for a diff sync client. 77 | 78 | ### 6. License 79 | 80 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 81 | -------------------------------------------------------------------------------- /BEPs/BEP95.md: -------------------------------------------------------------------------------- 1 | # BEP-95: Introduce Real-Time Burning Mechanism 2 | 3 | - [BEP-95: Introduce Real-Time Burning Mechanism](#bep-95-introduce-real-time-burning-mechanism) 4 | - [1. Summary](#1-summary) 5 | - [2. Abstract](#2-abstract) 6 | - [3. Status](#3-status) 7 | - [4. Motivation](#4-motivation) 8 | - [5. Specification](#5-specification) 9 | - [6. License](#6-license) 10 | 11 | ## 1. Summary 12 | 13 | This BEP introduces a real-time burning mechanism into the economic model of BSC. 14 | 15 | ## 2. Abstract 16 | 17 | To speed up the burning process of BNB and make BSC more decentralized, part of the gas fee will be burned. It includes two parts: 18 | 19 | + A fixed ratio of the gas fee collected by the validators will be burned in each block. 20 | + The burning ratio can be governed by the BSC validators. 21 | 22 | 23 | ## 3. Status 24 | 25 | This BEP is already implemented. 26 | 27 | ## 4. Motivation 28 | 29 | The burning of gas fees can speed up the burning process of BNB and improve the intrinsic value of BNB. 30 | 31 | The BNB holders will decide how to dispatch the gas reward of BSC. 32 | 33 | Though the staking reward of the validators and delegators may decrease in BNB amount, the reward value in dollars may increase in the long run with the increase of BNB value and a more active ecosystem. 34 | 35 | ## 5. Specification 36 | 37 | ### 5.1 Gas Fee Distribution 38 | 39 | As BNB is not an inflationary token, there will be no mining rewards as what Bitcoin and Ethereum networks generate, and the gas fee is the major reward for validators. As BNB is also utility tokens with other use cases, delegators and validators will still enjoy other benefits of holding BNB. The gas fee is collected each block and distributed to two system smart contracts: 40 | 41 | 1. [System Reward Contract](https://bscscan.com/address/0x0000000000000000000000000000000000001002). The contract can possess at most 100 BNB. 1/16 of the gas fee will be transferred to the system reward contract if it possesses less than 100 BNB. The funding within the reward contract is used as cross-chain package subsidies. 42 | 2. [ValidatorSet Contract](https://bscscan.com/address/0x0000000000000000000000000000000000001000). The rest of the gas fee is transferred to the ValidatorSet contract. It is the vault to keep gas fees for both validators and delegators. The funding within the contract will be transferred to BNB Beacon Chain and distributed to delegators and validators according to their shares every day. 43 | 44 | ### 5.2 Burning Mechanism 45 | 46 | A governable parameters: `burnRatio` will be introduced in the [ValidatorSet Contract](https://bscscan.com/address/0x0000000000000000000000000000000000001000). At the end of each block, the Validator will sign a transaction to invoke the `deposit` function of the contract to transfer the gas fee. The burning logic is implemented within the `deposit` function that: `burnRatio` * `gasFee` will be transferred to the [burn address](https://bscscan.com/address/0x000000000000000000000000000000000000dead); 47 | 48 | The initial setting: 49 | 50 | + burnRatio = 10% 51 | 52 | ### 5.3 Governance 53 | 54 | The change of `burnRatio` will be determined by BSC Validators together through a proposal-vote process based on their staking. 55 | 56 | This process will be carried on BNB Beacon Chain, every community member can propose a change of the params. The proposal needs to receive a minimum deposit of BNB (2000BNB on mainnet for now, refundable after the proposal has passed) so that the validator can vote for it. The validators of BSC can vote for it or against it based on their staking amount of BNB. 57 | 58 | If the total voting power of bounded validators that votes for it reaches the quorum(50% on mainnet), the proposal will pass and the corresponding change of the params will be passed onto BSC via cross-chain communication and take effect immediately. The vote of unbounded validators will not be considered into the tally. 59 | 60 | 61 | ## 6. License 62 | 63 | The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 64 | -------------------------------------------------------------------------------- /BEPs/assets/BEP-188/broadcast_without_limit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-188/broadcast_without_limit.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-188/consensus_adaption.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-188/consensus_adaption.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-188/early_broadcast_with_limit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-188/early_broadcast_with_limit.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-188/mining_process_normal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-188/mining_process_normal.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-225/Complexity_Regression.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-225/Complexity_Regression.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-225/GQuad_Change.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-225/GQuad_Change.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-293/cross_chain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-293/cross_chain.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-319/4.1-current-fee-distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-319/4.1-current-fee-distribution.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-319/4.2-new-fee-distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-319/4.2-new-fee-distribution.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-335/4-3-new-sp-graceful-exit-procedure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-335/4-3-new-sp-graceful-exit-procedure.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-335/4.1.2-VGF.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-335/4.1.2-VGF.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-336/blob_expire.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-336/blob_expire.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-336/blob_gasprice.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-336/blob_gasprice.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-364/workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-364/workflow.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-366/workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-366/workflow.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-381/benchstat_compare_test: -------------------------------------------------------------------------------- 1 | goos: darwin 2 | goarch: arm64 3 | pkg: github.com/ethereum/go-ethereum/core/vm 4 | │ compare_p256Verify │ compare_ecrecover │ 5 | │ sec/op │ sec/op vs base │ 6 | PrecompiledP256Verify/p256Verify-Gas=3450-8 57.75µ ± 1% 7 | PrecompiledEcrecover/-Gas=3000-8 50.48µ ± 1% 8 | geomean 57.75µ 50.48µ ? ¹ ² 9 | ¹ benchmark set differs from baseline; geomeans may not be comparable 10 | ² ratios must be >0 to compute geomean 11 | 12 | │ compare_p256Verify │ compare_ecrecover │ 13 | │ gas/op │ gas/op vs base │ 14 | PrecompiledP256Verify/p256Verify-Gas=3450-8 3.450k ± 0% 15 | PrecompiledEcrecover/-Gas=3000-8 3.000k ± 0% 16 | geomean 3.450k 3.000k ? ¹ ² 17 | ¹ benchmark set differs from baseline; geomeans may not be comparable 18 | ² ratios must be >0 to compute geomean 19 | 20 | │ compare_p256Verify │ compare_ecrecover │ 21 | │ mgas/s │ mgas/s vs base │ 22 | PrecompiledP256Verify/p256Verify-Gas=3450-8 59.73 ± 1% 23 | PrecompiledEcrecover/-Gas=3000-8 59.42 ± 1% 24 | geomean 59.73 59.42 ? ¹ ² 25 | ¹ benchmark set differs from baseline; geomeans may not be comparable 26 | ² ratios must be >0 to compute geomean 27 | 28 | │ compare_p256Verify │ compare_ecrecover │ 29 | │ B/op │ B/op vs base │ 30 | PrecompiledP256Verify/p256Verify-Gas=3450-8 1.523Ki ± 0% 31 | PrecompiledEcrecover/-Gas=3000-8 800.0 ± 0% 32 | geomean 1.523Ki 800.0 ? ¹ ² 33 | ¹ benchmark set differs from baseline; geomeans may not be comparable 34 | ² ratios must be >0 to compute geomean 35 | 36 | │ compare_p256Verify │ compare_ecrecover │ 37 | │ allocs/op │ allocs/op vs base │ 38 | PrecompiledP256Verify/p256Verify-Gas=3450-8 33.00 ± 0% 39 | PrecompiledEcrecover/-Gas=3000-8 7.000 ± 0% 40 | geomean 33.00 7.000 ? ¹ ² 41 | ¹ benchmark set differs from baseline; geomeans may not be comparable 42 | ² ratios must be >0 to compute geomean 43 | -------------------------------------------------------------------------------- /BEPs/assets/BEP-381/ecrecover_benchmark_test: -------------------------------------------------------------------------------- 1 | goos: darwin 2 | goarch: arm64 3 | pkg: github.com/ethereum/go-ethereum/core/vm 4 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23295 50034 ns/op 3000 gas/op 59.95 mgas/s 800 B/op 7 allocs/op 5 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23734 50558 ns/op 3000 gas/op 59.33 mgas/s 800 B/op 7 allocs/op 6 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23823 50586 ns/op 3000 gas/op 59.30 mgas/s 800 B/op 7 allocs/op 7 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23913 50049 ns/op 3000 gas/op 59.94 mgas/s 800 B/op 7 allocs/op 8 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23721 50299 ns/op 3000 gas/op 59.64 mgas/s 800 B/op 7 allocs/op 9 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23760 51160 ns/op 3000 gas/op 58.63 mgas/s 800 B/op 7 allocs/op 10 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23151 50818 ns/op 3000 gas/op 59.03 mgas/s 800 B/op 7 allocs/op 11 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23744 53451 ns/op 3000 gas/op 56.12 mgas/s 800 B/op 7 allocs/op 12 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 22837 50315 ns/op 3000 gas/op 59.62 mgas/s 800 B/op 7 allocs/op 13 | BenchmarkPrecompiledEcrecover/-Gas=3000-8 23823 50401 ns/op 3000 gas/op 59.52 mgas/s 800 B/op 7 allocs/op 14 | PASS 15 | ok github.com/ethereum/go-ethereum/core/vm 17.687s 16 | -------------------------------------------------------------------------------- /BEPs/assets/BEP-381/p256Verify_benchmark_test: -------------------------------------------------------------------------------- 1 | goos: darwin 2 | goarch: arm64 3 | pkg: github.com/ethereum/go-ethereum/core/vm 4 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20770 57970 ns/op 3450 gas/op 59.51 mgas/s 1560 B/op 33 allocs/op 5 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20899 57769 ns/op 3450 gas/op 59.71 mgas/s 1560 B/op 33 allocs/op 6 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20780 57343 ns/op 3450 gas/op 60.16 mgas/s 1560 B/op 33 allocs/op 7 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20870 57740 ns/op 3450 gas/op 59.74 mgas/s 1560 B/op 33 allocs/op 8 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20911 57411 ns/op 3450 gas/op 60.09 mgas/s 1560 B/op 33 allocs/op 9 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20874 58423 ns/op 3450 gas/op 59.04 mgas/s 1560 B/op 33 allocs/op 10 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20736 57552 ns/op 3450 gas/op 59.94 mgas/s 1560 B/op 33 allocs/op 11 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 19700 58235 ns/op 3450 gas/op 59.24 mgas/s 1560 B/op 33 allocs/op 12 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20814 57681 ns/op 3450 gas/op 59.80 mgas/s 1560 B/op 33 allocs/op 13 | BenchmarkPrecompiledP256Verify/p256Verify-Gas=3450-8 20736 58806 ns/op 3450 gas/op 58.66 mgas/s 1560 B/op 33 allocs/op 14 | PASS 15 | ok github.com/ethereum/go-ethereum/core/vm 18.491s 16 | -------------------------------------------------------------------------------- /BEPs/assets/BEP-402/4-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-402/4-1.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-404/4-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-404/4-1.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-525/3-1-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-525/3-1-2.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-525/3-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-525/3-1.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-536/3-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-536/3-2.png -------------------------------------------------------------------------------- /BEPs/assets/BEP-564/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/BEP-564/image1.png -------------------------------------------------------------------------------- /BEPs/assets/bep-1/workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-1/workflow.png -------------------------------------------------------------------------------- /BEPs/assets/bep-128/reward-distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-128/reward-distribution.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/1_overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/1_overview.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/2_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/2_workflow.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/3_pipeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/3_pipeline.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/4_init.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/4_init.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/5_dispatcher.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/5_dispatcher.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/6_stages.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/6_stages.png -------------------------------------------------------------------------------- /BEPs/assets/bep-130/7_conflict_window.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-130/7_conflict_window.png -------------------------------------------------------------------------------- /BEPs/assets/bep-131/5.1_overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-131/5.1_overview.png -------------------------------------------------------------------------------- /BEPs/assets/bep-131/5.2_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-131/5.2_workflow.png -------------------------------------------------------------------------------- /BEPs/assets/bep-131/5.5_election.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-131/5.5_election.png -------------------------------------------------------------------------------- /BEPs/assets/bep-153/5.1_framework.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-153/5.1_framework.jpg -------------------------------------------------------------------------------- /BEPs/assets/bep-153/5.2_stake.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-153/5.2_stake.jpg -------------------------------------------------------------------------------- /BEPs/assets/bep-153/5.3_errorhandle.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-153/5.3_errorhandle.jpg -------------------------------------------------------------------------------- /BEPs/assets/bep-194/node_distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-194/node_distribution.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/1_components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/1_components.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/2_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/2_workflow.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/3_epochTree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/3_epochTree.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/4_epochKey.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/4_epochKey.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/5_trieMeta.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/5_trieMeta.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/6_extendedBranchNode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/6_extendedBranchNode.png -------------------------------------------------------------------------------- /BEPs/assets/bep-206/7_snapshot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-206/7_snapshot.png -------------------------------------------------------------------------------- /BEPs/assets/bep-294/5.1_framework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-294/5.1_framework.png -------------------------------------------------------------------------------- /BEPs/assets/bep-294/5.2_stakehub.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-294/5.2_stakehub.png -------------------------------------------------------------------------------- /BEPs/assets/bep-294/5.3_update_eligible_validators.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-294/5.3_update_eligible_validators.png -------------------------------------------------------------------------------- /BEPs/assets/bep-299/asset_recovery_app.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-299/asset_recovery_app.png -------------------------------------------------------------------------------- /BEPs/assets/bep-299/asset_tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-299/asset_tree.png -------------------------------------------------------------------------------- /BEPs/assets/bep-322/block_timing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-322/block_timing.png -------------------------------------------------------------------------------- /BEPs/assets/bep-322/workflow_1round.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-322/workflow_1round.png -------------------------------------------------------------------------------- /BEPs/assets/bep-322/workflow_2round.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-322/workflow_2round.png -------------------------------------------------------------------------------- /BEPs/assets/bep-322/workflow_2round_proxy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-322/workflow_2round_proxy.png -------------------------------------------------------------------------------- /BEPs/assets/bep-322/workflow_topology.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-322/workflow_topology.png -------------------------------------------------------------------------------- /BEPs/assets/bep-323/bundle_encoding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-323/bundle_encoding.png -------------------------------------------------------------------------------- /BEPs/assets/bep-323/bundle_struct.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-323/bundle_struct.png -------------------------------------------------------------------------------- /BEPs/assets/bep-333/phases.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-333/phases.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.1-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.1-1.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.1-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.1-2.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.1-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.1-3.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.1-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.1-4.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.1-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.1-5.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.1-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.1-6.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.2.1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.2.1.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.2.2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.2.2.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.2.3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.2.3.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.2.5-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.2.5-1.png -------------------------------------------------------------------------------- /BEPs/assets/bep-341/4.2.5-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-341/4.2.5-2.png -------------------------------------------------------------------------------- /BEPs/assets/bep-363/4.1.1_framework.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-363/4.1.1_framework.png -------------------------------------------------------------------------------- /BEPs/assets/bep-414/wallet-interact.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-414/wallet-interact.png -------------------------------------------------------------------------------- /BEPs/assets/bep-414/workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-414/workflow.png -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-add_G1_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_g1add_empty_input" 6 | }, 7 | { 8 | "Input": "00000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a21", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_g1add_short_input" 11 | }, 12 | { 13 | "Input": "000000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a21", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_g1add_large_input" 16 | }, 17 | { 18 | "Input": "0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb00000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a2100000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a21", 19 | "ExpectedError": "invalid point: not on curve", 20 | "Name": "bls_g1add_point_not_on_curve" 21 | }, 22 | { 23 | "Input": "0000000000000000000000000000000031f2e5916b17be2e71b10b4292f558e727dfd7d48af9cbc5087f0ce00dcca27c8b01e83eaace1aefb539f00adb2271660000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a21", 24 | "ExpectedError": "invalid fp.Element encoding", 25 | "Name": "bls_g2add_invalid_field_element" 26 | }, 27 | { 28 | "Input": "1000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e100000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a21", 29 | "ExpectedError": "invalid field element top bytes", 30 | "Name": "bls_g1add_violate_top_bytes" 31 | } 32 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-add_G2_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_g2add_empty_input" 6 | }, 7 | { 8 | "Input": "000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be00000000000000000000000000000000103121a2ceaae586d240843a398967325f8eb5a93e8fea99b62b9f88d8556c80dd726a4b30e84a36eeabaf3592937f2700000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000f9e7ba9a86a8f7624aa2b42dcc8772e1af4ae115685e60abc2c9b90242167acef3d0be4050bf935eed7c3b6fc7ba77e000000000000000000000000000000000d22c3652d0dc6f0fc9316e14268477c2049ef772e852108d269d9c38dba1d4802e8dae479818184c08f9a569d878451", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_g2add_short_input" 11 | }, 12 | { 13 | "Input": "0000000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be00000000000000000000000000000000103121a2ceaae586d240843a398967325f8eb5a93e8fea99b62b9f88d8556c80dd726a4b30e84a36eeabaf3592937f2700000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000f9e7ba9a86a8f7624aa2b42dcc8772e1af4ae115685e60abc2c9b90242167acef3d0be4050bf935eed7c3b6fc7ba77e000000000000000000000000000000000d22c3652d0dc6f0fc9316e14268477c2049ef772e852108d269d9c38dba1d4802e8dae479818184c08f9a569d878451", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_g2add_long_input" 16 | }, 17 | { 18 | "Input": "00000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb800000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be00000000000000000000000000000000103121a2ceaae586d240843a398967325f8eb5a93e8fea99b62b9f88d8556c80dd726a4b30e84a36eeabaf3592937f2700000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000f9e7ba9a86a8f7624aa2b42dcc8772e1af4ae115685e60abc2c9b90242167acef3d0be4050bf935eed7c3b6fc7ba77e000000000000000000000000000000000d22c3652d0dc6f0fc9316e14268477c2049ef772e852108d269d9c38dba1d4802e8dae479818184c08f9a569d878451", 19 | "ExpectedError": "invalid point: not on curve", 20 | "Name": "bls_g2add_point_not_on_curve" 21 | }, 22 | { 23 | "Input": "000000000000000000000000000000001c4bb49d2a0ef12b7123acdd7110bd292b5bc659edc54dc21b81de057194c79b2a5803255959bbef8e7f56c8c12168630000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be00000000000000000000000000000000103121a2ceaae586d240843a398967325f8eb5a93e8fea99b62b9f88d8556c80dd726a4b30e84a36eeabaf3592937f2700000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000f9e7ba9a86a8f7624aa2b42dcc8772e1af4ae115685e60abc2c9b90242167acef3d0be4050bf935eed7c3b6fc7ba77e000000000000000000000000000000000d22c3652d0dc6f0fc9316e14268477c2049ef772e852108d269d9c38dba1d4802e8dae479818184c08f9a569d878451", 24 | "ExpectedError": "invalid fp.Element encoding", 25 | "Name": "bls_g2add_invalid_field_element" 26 | }, 27 | { 28 | "Input": "10000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be00000000000000000000000000000000103121a2ceaae586d240843a398967325f8eb5a93e8fea99b62b9f88d8556c80dd726a4b30e84a36eeabaf3592937f2700000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000f9e7ba9a86a8f7624aa2b42dcc8772e1af4ae115685e60abc2c9b90242167acef3d0be4050bf935eed7c3b6fc7ba77e000000000000000000000000000000000d22c3652d0dc6f0fc9316e14268477c2049ef772e852108d269d9c38dba1d4802e8dae479818184c08f9a569d878451", 29 | "ExpectedError": "invalid field element top bytes", 30 | "Name": "bls_g2add_violate_top_bytes" 31 | } 32 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-map_fp2_to_G2_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_mapg2_empty_input" 6 | }, 7 | { 8 | "Input": "0000000000000000000000000000000007355d25caf6e7f2f0cb2812ca0e513bd026ed09dda65b177500fa31714e09ea0ded3a078b526bed3307f804d4b93b040000000000000000000000000000000002829ce3c021339ccb5caf3e187f6370e1e2a311dec9b75363117063ab2015603ff52c3d3b98f19c2f65575e99e8b7", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_mapg2_short_input" 11 | }, 12 | { 13 | "Input": "000000000000000000000000000000000007355d25caf6e7f2f0cb2812ca0e513bd026ed09dda65b177500fa31714e09ea0ded3a078b526bed3307f804d4b93b040000000000000000000000000000000002829ce3c021339ccb5caf3e187f6370e1e2a311dec9b75363117063ab2015603ff52c3d3b98f19c2f65575e99e8b78c", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_mapg2_long_input" 16 | }, 17 | { 18 | "Input": "000000000000000000000000000000000007355d25caf6e7f2f0cb2812ca0e513bd026ed09dda65b177500fa31714e09ea0ded3a078b526bed3307f804d4b93b040000000000000000000000000000000002829ce3c021339ccb5caf3e187f6370e1e2a311dec9b75363117063ab2015603ff52c3d3b98f19c2f65575e99e8b7", 19 | "ExpectedError": "invalid field element top bytes", 20 | "Name": "bls_mapg2_top_bytes" 21 | }, 22 | { 23 | "Input": "0000000000000000000000000000000021366f100476ce8d3be6cfc90d59fe13349e388ed12b6dd6dc31ccd267ff000e2c993a063ca66beced06f804d4b8e5af0000000000000000000000000000000002829ce3c021339ccb5caf3e187f6370e1e2a311dec9b75363117063ab2015603ff52c3d3b98f19c2f65575e99e8b78c", 24 | "ExpectedError": "invalid fp.Element encoding", 25 | "Name": "bls_mapg2_invalid_fq_element" 26 | } 27 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-map_fp_to_G1_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_mapg1_empty_input" 6 | }, 7 | { 8 | "Input": "00000000000000000000000000000000156c8a6a2c184569d69a76be144b5cdc5141d2d2ca4fe341f011e25e3969c55ad9e9b9ce2eb833c81a908e5fa4ac5f", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_mapg1_short_input" 11 | }, 12 | { 13 | "Input": "0000000000000000000000000000000000156c8a6a2c184569d69a76be144b5cdc5141d2d2ca4fe341f011e25e3969c55ad9e9b9ce2eb833c81a908e5fa4ac5f03", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_mapg1_large_input" 16 | }, 17 | { 18 | "Input": "1000000000000000000000000000000000156c8a6a2c184569d69a76be144b5cdc5141d2d2ca4fe341f011e25e3969c55ad9e9b9ce2eb833c81a908e5fa4ac5f", 19 | "ExpectedError": "invalid field element top bytes", 20 | "Name": "bls_mapg1_top_bytes" 21 | }, 22 | { 23 | "Input": "000000000000000000000000000000002f6d9c5465982c0421b61e74579709b3b5b91e57bdd4f6015742b4ff301abb7ef895b9cce00c33c7d48f8e5fa4ac09ae", 24 | "ExpectedError": "invalid fp.Element encoding", 25 | "Name": "bls_invalid_fq_element" 26 | } 27 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-mul_G1_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_g1mul_empty_input" 6 | }, 7 | { 8 | "Input": "00000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e10000000000000000000000000000000000000000000000000000000000000002", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_g1mul_short_input" 11 | }, 12 | { 13 | "Input": "000000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e10000000000000000000000000000000000000000000000000000000000000002", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_g1mul_large_input" 16 | }, 17 | { 18 | "Input": "0000000000000000000000000000000031f2e5916b17be2e71b10b4292f558e727dfd7d48af9cbc5087f0ce00dcca27c8b01e83eaace1aefb539f00adb2271660000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e10000000000000000000000000000000000000000000000000000000000000002", 19 | "ExpectedError": "invalid fp.Element encoding", 20 | "Name": "bls_g1mul_invalid_field_element" 21 | }, 22 | { 23 | "Input": "0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb00000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 24 | "ExpectedError": "invalid point: not on curve", 25 | "Name": "bls_g1mul_point_not_on_curve" 26 | }, 27 | { 28 | "Input": "1000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e10000000000000000000000000000000000000000000000000000000000000002", 29 | "ExpectedError": "invalid field element top bytes", 30 | "Name": "bls_g1mul_violate_top_bytes" 31 | }, 32 | { 33 | "Input": "000000000000000000000000000000000123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef00000000000000000000000000000000193fb7cedb32b2c3adc06ec11a96bc0d661869316f5e4a577a9f7c179593987beb4fb2ee424dbb2f5dd891e228b46c4a0000000000000000000000000000000000000000000000000000000000000002", 34 | "ExpectedError": "g1 point is not on correct subgroup", 35 | "Name": "bls_g1mul_g1_not_in_correct_subgroup" 36 | } 37 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-mul_G2_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_g2mul_empty_input" 6 | }, 7 | { 8 | "Input": "000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000000000000000000000000000000000002", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_g2mul_short_input" 11 | }, 12 | { 13 | "Input": "0000000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000000000000000000000000000000000002", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_g2mul_large_input" 16 | }, 17 | { 18 | "Input": "000000000000000000000000000000001c4bb49d2a0ef12b7123acdd7110bd292b5bc659edc54dc21b81de057194c79b2a5803255959bbef8e7f56c8c12168630000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000000000000000000000000000000000002", 19 | "ExpectedError": "invalid fp.Element encoding", 20 | "Name": "bls_g2mul_invalid_field_element" 21 | }, 22 | { 23 | "Input": "00000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb800000000000000000000000000000000086b990f3da2aeac0a36143b7d7c824428215140db1bb859338764cb58458f081d92664f9053b50b3fbd2e4723121b68000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000000000000000000000000000000000002", 24 | "ExpectedError": "invalid point: not on curve", 25 | "Name": "bls_g2mul_point_not_on_curve" 26 | }, 27 | { 28 | "Input": "10000000000000000000000000000000024aa2b2f08f0a91260805272dc51051c6e47ad4fa403b02b4510b647ae3d1770bac0326a805bbefd48056c8c121bdb80000000000000000000000000000000013e02b6052719f607dacd3a088274f65596bd0d09920b61ab5da61bbdc7f5049334cf11213945d57e5ac7d055d042b7e000000000000000000000000000000000ce5d527727d6e118cc9cdc6da2e351aadfd9baa8cbdd3a76d429a695160d12c923ac9cc3baca289e193548608b82801000000000000000000000000000000000606c4a02ea734cc32acd2b02bc28b99cb3e287e85a763af267492ab572e99ab3f370d275cec1da1aaa9075ff05f79be0000000000000000000000000000000000000000000000000000000000000002", 29 | "ExpectedError": "invalid field element top bytes", 30 | "Name": "bls_g2mul_violate_top_bytes" 31 | }, 32 | { 33 | "Input": "00000000000000000000000000000000197bfd0342bbc8bee2beced2f173e1a87be576379b343e93232d6cef98d84b1d696e5612ff283ce2cfdccb2cfb65fa0c00000000000000000000000000000000184e811f55e6f9d84d77d2f79102fd7ea7422f4759df5bf7f6331d550245e3f1bcf6a30e3b29110d85e0ca16f9f6ae7a000000000000000000000000000000000f10e1eb3c1e53d2ad9cf2d398b2dc22c5842fab0a74b174f691a7e914975da3564d835cd7d2982815b8ac57f507348f000000000000000000000000000000000767d1c453890f1b9110fda82f5815c27281aba3f026ee868e4176a0654feea41a96575e0c4d58a14dbfbcc05b5010b10000000000000000000000000000000000000000000000000000000000000002", 34 | "ExpectedError": "g2 point is not on correct subgroup", 35 | "Name": "bls_g2mul_g2_not_in_correct_subgroup" 36 | } 37 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fail-multiexp_G1_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "", 4 | "ExpectedError": "invalid input length", 5 | "Name": "bls_g1multiexp_empty_input" 6 | }, 7 | { 8 | "Input": "00000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 9 | "ExpectedError": "invalid input length", 10 | "Name": "bls_g1multiexp_short_input" 11 | }, 12 | { 13 | "Input": "000000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 14 | "ExpectedError": "invalid input length", 15 | "Name": "bls_g1multiexp_long_input" 16 | }, 17 | { 18 | "Input": "0000000000000000000000000000000031f2e5916b17be2e71b10b4292f558e727dfd7d48af9cbc5087f0ce00dcca27c8b01e83eaace1aefb539f00adb2271660000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 19 | "ExpectedError": "invalid fp.Element encoding", 20 | "Name": "bls_g1multiexp_invalid_field_element" 21 | }, 22 | { 23 | "Input": "1000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb0000000000000000000000000000000008b3f481e3aaa0f1a09e30ed741d8ae4fcf5e095d5d00af600db18cb2c04b3edd03cc744a2888ae40caa232946c5e7e1000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 24 | "ExpectedError": "invalid field element top bytes", 25 | "Name": "bls_g1multiexp_violate_top_bytes" 26 | }, 27 | { 28 | "Input": "0000000000000000000000000000000017f1d3a73197d7942695638c4fa9ac0fc3688c4f9774b905a14e3a3f171bac586c55e83ff97a1aeffb3af00adb22c6bb00000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a21000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 29 | "ExpectedError": "invalid point: not on curve", 30 | "Name": "bls_g1multiexp_point_not_on_curve" 31 | }, 32 | { 33 | "Input": "000000000000000000000000000000000123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef00000000000000000000000000000000193fb7cedb32b2c3adc06ec11a96bc0d661869316f5e4a577a9f7c179593987beb4fb2ee424dbb2f5dd891e228b46c4a000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000112b98340eee2777cc3c14163dea3ec97977ac3dc5c70da32e6e87578f44912e902ccef9efe28d4a78b8999dfbca942600000000000000000000000000000000186b28d92356c4dfec4b5201ad099dbdede3781f8998ddf929b4cd7756192185ca7b8f4ef7088f813270ac3d48868a210000000000000000000000000000000000000000000000000000000000000002", 34 | "ExpectedError": "g1 point is not on correct subgroup", 35 | "Name": "bls_g1multiexp_g1_not_in_correct_subgroup" 36 | } 37 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/fast_subgroup_checks.md: -------------------------------------------------------------------------------- 1 | # Fast subgroup checks used by BEP-439 2 | 3 | ### Fields and Groups 4 | 5 | Field Fp is defined as the finite field of size `p` with elements represented as integers between 0 and p-1 (both inclusive). 6 | 7 | Field Fp2 is defined as `Fp[X]/(X^2-nr2)` with elements `el = c0 + c1 * v`, where `v` is the formal square root of `nr2` represented as integer pairs `(c0,c1)`. 8 | 9 | Group G1 is defined as a set of Fp pairs (points) `(x,y)` such that either `(x,y)` is `(0,0)` or `x,y` satisfy the curve Fp equation. 10 | 11 | Group G2 is defined as a set of Fp2 pairs (points) `(x',y')` such that either `(x,y)` is `(0,0)` or `(x',y')` satisfy the curve Fp2 equation. 12 | 13 | ## Curve parameters 14 | 15 | The set of parameters used by fast subgroup checks: 16 | 17 | ``` 18 | |x| (seed) = 15132376222941642752 19 | x is negative = true 20 | Cube root of unity modulo p - Beta = 793479390729215512621379701633421447060886740281060493010456487427281649075476305620758731620350 21 | r = 4002409555221667392624310435006688643935503118305586438271171395842971157480381377015405980053539358417135540939437 * v 22 | s = 2973677408986561043442465346520108879172042883009249989176415018091420807192182638567116318576472649347015917690530 + 1028732146235106349975324479215795277384839936929757896155643118032610843298655225875571310552543014690878354869257 * v 23 | ``` 24 | 25 | ## Helper function to compute the conjugate over Fp2 - `conjugate` 26 | 27 | `conjugate(c0 + c1 * v) := c0 - c1 * v` 28 | 29 | ## G1 endomorphism - `phi` 30 | 31 | The endomorphism `phi` transform the point from `(x,y)` to `(Beta*x,y)` where `Beta` is a precomputed cube root of unity modulo `p` given above in parameters sections: 32 | 33 | `phi((x,y)) := (Beta*x,y)` 34 | 35 | ## G2 endomorphism - `psi` 36 | 37 | `psi((x,y)) := (conjugate(x)*r,conjugate(y)*s)` 38 | 39 | # The G1 case 40 | 41 | Before accepting a point `P` as input that purports to be a member of G1 subject the input to the following endomorphism test: `phi(P) + x^2*P = 0` 42 | 43 | 44 | # The G2 case 45 | 46 | Before accepting a point `P` as input that purports to be a member of G2 subject the input to the following endomorphism test: `psi(P) + x*P = 0` 47 | 48 | # Resources 49 | 50 | * https://eprint.iacr.org/2021/1130.pdf, sec.4 51 | * https://eprint.iacr.org/2022/352.pdf, sec. 4.2 52 | -------------------------------------------------------------------------------- /BEPs/assets/bep-439/map_fp2_to_G2_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "0000000000000000000000000000000007355d25caf6e7f2f0cb2812ca0e513bd026ed09dda65b177500fa31714e09ea0ded3a078b526bed3307f804d4b93b040000000000000000000000000000000002829ce3c021339ccb5caf3e187f6370e1e2a311dec9b75363117063ab2015603ff52c3d3b98f19c2f65575e99e8b78c", 4 | "Name": "bls_g2map_", 5 | "Expected": "0000000000000000000000000000000000e7f4568a82b4b7dc1f14c6aaa055edf51502319c723c4dc2688c7fe5944c213f510328082396515734b6612c4e7bb700000000000000000000000000000000126b855e9e69b1f691f816e48ac6977664d24d99f8724868a184186469ddfd4617367e94527d4b74fc86413483afb35b000000000000000000000000000000000caead0fd7b6176c01436833c79d305c78be307da5f6af6c133c47311def6ff1e0babf57a0fb5539fce7ee12407b0a42000000000000000000000000000000001498aadcf7ae2b345243e281ae076df6de84455d766ab6fcdaad71fab60abb2e8b980a440043cd305db09d283c895e3d", 6 | "Gas": 75000, 7 | "NoBenchmark": false 8 | }, 9 | { 10 | "Input": "00000000000000000000000000000000138879a9559e24cecee8697b8b4ad32cced053138ab913b99872772dc753a2967ed50aabc907937aefb2439ba06cc50c000000000000000000000000000000000a1ae7999ea9bab1dcc9ef8887a6cb6e8f1e22566015428d220b7eec90ffa70ad1f624018a9ad11e78d588bd3617f9f2", 11 | "Name": "bls_g2map_616263", 12 | "Expected": "00000000000000000000000000000000108ed59fd9fae381abfd1d6bce2fd2fa220990f0f837fa30e0f27914ed6e1454db0d1ee957b219f61da6ff8be0d6441f000000000000000000000000000000000296238ea82c6d4adb3c838ee3cb2346049c90b96d602d7bb1b469b905c9228be25c627bffee872def773d5b2a2eb57d00000000000000000000000000000000033f90f6057aadacae7963b0a0b379dd46750c1c94a6357c99b65f63b79e321ff50fe3053330911c56b6ceea08fee65600000000000000000000000000000000153606c417e59fb331b7ae6bce4fbf7c5190c33ce9402b5ebe2b70e44fca614f3f1382a3625ed5493843d0b0a652fc3f", 13 | "Gas": 75000, 14 | "NoBenchmark": false 15 | }, 16 | { 17 | "Input": "0000000000000000000000000000000018c16fe362b7dbdfa102e42bdfd3e2f4e6191d479437a59db4eb716986bf08ee1f42634db66bde97d6c16bbfd342b3b8000000000000000000000000000000000e37812ce1b146d998d5f92bdd5ada2a31bfd63dfe18311aa91637b5f279dd045763166aa1615e46a50d8d8f475f184e", 18 | "Name": "bls_g2map_6162636465663031", 19 | "Expected": "00000000000000000000000000000000038af300ef34c7759a6caaa4e69363cafeed218a1f207e93b2c70d91a1263d375d6730bd6b6509dcac3ba5b567e85bf3000000000000000000000000000000000da75be60fb6aa0e9e3143e40c42796edf15685cafe0279afd2a67c3dff1c82341f17effd402e4f1af240ea90f4b659b0000000000000000000000000000000019b148cbdf163cf0894f29660d2e7bfb2b68e37d54cc83fd4e6e62c020eaa48709302ef8e746736c0e19342cc1ce3df4000000000000000000000000000000000492f4fed741b073e5a82580f7c663f9b79e036b70ab3e51162359cec4e77c78086fe879b65ca7a47d34374c8315ac5e", 20 | "Gas": 75000, 21 | "NoBenchmark": false 22 | }, 23 | { 24 | "Input": "0000000000000000000000000000000008d4a0997b9d52fecf99427abb721f0fa779479963315fe21c6445250de7183e3f63bfdf86570da8929489e421d4ee950000000000000000000000000000000016cb4ccad91ec95aab070f22043916cd6a59c4ca94097f7f510043d48515526dc8eaaea27e586f09151ae613688d5a89", 25 | "Name": "bls_g2map_713132385f717171", 26 | "Expected": "000000000000000000000000000000000c5ae723be00e6c3f0efe184fdc0702b64588fe77dda152ab13099a3bacd3876767fa7bbad6d6fd90b3642e902b208f90000000000000000000000000000000012c8c05c1d5fc7bfa847f4d7d81e294e66b9a78bc9953990c358945e1f042eedafce608b67fdd3ab0cb2e6e263b9b1ad0000000000000000000000000000000004e77ddb3ede41b5ec4396b7421dd916efc68a358a0d7425bddd253547f2fb4830522358491827265dfc5bcc1928a5690000000000000000000000000000000011c624c56dbe154d759d021eec60fab3d8b852395a89de497e48504366feedd4662d023af447d66926a28076813dd646", 27 | "Gas": 75000, 28 | "NoBenchmark": false 29 | }, 30 | { 31 | "Input": "0000000000000000000000000000000003f80ce4ff0ca2f576d797a3660e3f65b274285c054feccc3215c879e2c0589d376e83ede13f93c32f05da0f68fd6a1000000000000000000000000000000000006488a837c5413746d868d1efb7232724da10eca410b07d8b505b9363bdccf0a1fc0029bad07d65b15ccfe6dd25e20d", 32 | "Name": "bls_g2map_613531325f616161", 33 | "Expected": "000000000000000000000000000000000ea4e7c33d43e17cc516a72f76437c4bf81d8f4eac69ac355d3bf9b71b8138d55dc10fd458be115afa798b55dac34be1000000000000000000000000000000001565c2f625032d232f13121d3cfb476f45275c303a037faa255f9da62000c2c864ea881e2bcddd111edc4a3c0da3e88d00000000000000000000000000000000043b6f5fe4e52c839148dc66f2b3751e69a0f6ebb3d056d6465d50d4108543ecd956e10fa1640dfd9bc0030cc2558d28000000000000000000000000000000000f8991d2a1ad662e7b6f58ab787947f1fa607fce12dde171bc17903b012091b657e15333e11701edcf5b63ba2a561247", 34 | "Gas": 75000, 35 | "NoBenchmark": false 36 | } 37 | ] 38 | -------------------------------------------------------------------------------- /BEPs/assets/bep-439/map_fp_to_G1_bls.json: -------------------------------------------------------------------------------- 1 | [ 2 | { 3 | "Input": "00000000000000000000000000000000156c8a6a2c184569d69a76be144b5cdc5141d2d2ca4fe341f011e25e3969c55ad9e9b9ce2eb833c81a908e5fa4ac5f03", 4 | "Name": "bls_g1map_", 5 | "Expected": "00000000000000000000000000000000184bb665c37ff561a89ec2122dd343f20e0f4cbcaec84e3c3052ea81d1834e192c426074b02ed3dca4e7676ce4ce48ba0000000000000000000000000000000004407b8d35af4dacc809927071fc0405218f1401a6d15af775810e4e460064bcc9468beeba82fdc751be70476c888bf3", 6 | "Gas": 5500, 7 | "NoBenchmark": false 8 | }, 9 | { 10 | "Input": "00000000000000000000000000000000147e1ed29f06e4c5079b9d14fc89d2820d32419b990c1c7bb7dbea2a36a045124b31ffbde7c99329c05c559af1c6cc82", 11 | "Name": "bls_g1map_616263", 12 | "Expected": "00000000000000000000000000000000009769f3ab59bfd551d53a5f846b9984c59b97d6842b20a2c565baa167945e3d026a3755b6345df8ec7e6acb6868ae6d000000000000000000000000000000001532c00cf61aa3d0ce3e5aa20c3b531a2abd2c770a790a2613818303c6b830ffc0ecf6c357af3317b9575c567f11cd2c", 13 | "Gas": 5500, 14 | "NoBenchmark": false 15 | }, 16 | { 17 | "Input": "0000000000000000000000000000000004090815ad598a06897dd89bcda860f25837d54e897298ce31e6947378134d3761dc59a572154963e8c954919ecfa82d", 18 | "Name": "bls_g1map_6162636465663031", 19 | "Expected": "000000000000000000000000000000001974dbb8e6b5d20b84df7e625e2fbfecb2cdb5f77d5eae5fb2955e5ce7313cae8364bc2fff520a6c25619739c6bdcb6a0000000000000000000000000000000015f9897e11c6441eaa676de141c8d83c37aab8667173cbe1dfd6de74d11861b961dccebcd9d289ac633455dfcc7013a3", 20 | "Gas": 5500, 21 | "NoBenchmark": false 22 | }, 23 | { 24 | "Input": "0000000000000000000000000000000008dccd088ca55b8bfbc96fb50bb25c592faa867a8bb78d4e94a8cc2c92306190244532e91feba2b7fed977e3c3bb5a1f", 25 | "Name": "bls_g1map_713132385f717171", 26 | "Expected": "000000000000000000000000000000000a7a047c4a8397b3446450642c2ac64d7239b61872c9ae7a59707a8f4f950f101e766afe58223b3bff3a19a7f754027c000000000000000000000000000000001383aebba1e4327ccff7cf9912bda0dbc77de048b71ef8c8a81111d71dc33c5e3aa6edee9cf6f5fe525d50cc50b77cc9", 27 | "Gas": 5500, 28 | "NoBenchmark": false 29 | }, 30 | { 31 | "Input": "000000000000000000000000000000000dd824886d2123a96447f6c56e3a3fa992fbfefdba17b6673f9f630ff19e4d326529db37e1c1be43f905bf9202e0278d", 32 | "Name": "bls_g1map_613531325f616161", 33 | "Expected": "000000000000000000000000000000000e7a16a975904f131682edbb03d9560d3e48214c9986bd50417a77108d13dc957500edf96462a3d01e62dc6cd468ef11000000000000000000000000000000000ae89e677711d05c30a48d6d75e76ca9fb70fe06c6dd6ff988683d89ccde29ac7d46c53bb97a59b1901abf1db66052db", 34 | "Gas": 5500, 35 | "NoBenchmark": false 36 | } 37 | ] -------------------------------------------------------------------------------- /BEPs/assets/bep-439/test-vectors.md: -------------------------------------------------------------------------------- 1 | # Test Vectors for BEP-439 - Precompile for BLS12-381 curve operations 2 | 3 | These test vectors are derived from [BLS 12-381 tests](https://github.com/ethereum/bls12-381-tests/tree/eip-2537) 4 | 5 | - [`BLS12_G1ADD` Machine-readable data](add_G1_bls.json) 6 | - [`BLS12_G2ADD` Machine-readable data](add_G2_bls.json) 7 | - [`BLS12_G1MUL` Machine-readable data](mul_G1_bls.json) 8 | - [`BLS12_G2MUL` Machine-readable data](mul_G2_bls.json) 9 | - [`BLS12_MAP_FP_TO_G1` Machine-readable data](map_fp_to_G1_bls.json) 10 | - [`BLS12_MAP_FP2_TO_G2` Machine-readable data](map_fp2_to_G2_bls.json) 11 | - [`BLS12_G1MULTIEXP` Machine-readable data](multiexp_G1_bls.json) 12 | - [`BLS12_G2MULTIEXP` Machine-readable data](multiexp_G2_bls.json) 13 | - [`BLS12_PAIRING_CHECK` Machine-readable data](pairing_check_bls.json) 14 | - [Fail `BLS12_G1ADD` Machine-readable data](fail-add_G1_bls.json) 15 | - [Fail `BLS12_G2ADD` Machine-readable data](fail-add_G2_bls.json) 16 | - [Fail `BLS12_G1MUL` Machine-readable data](fail-mul_G1_bls.json) 17 | - [Fail `BLS12_G2MUL` Machine-readable data](fail-mul_G2_bls.json) 18 | - [Fail `BLS12_MAP_FP_TO_G1` Machine-readable data](fail-map_fp_to_G1_bls.json) 19 | - [Fail `BLS12_MAP_FP2_TO_G2` Machine-readable data](fail-map_fp2_to_G2_bls.json) 20 | - [Fail `BLS12_G1MULTIEXP` Machine-readable data](fail-multiexp_G1_bls.json) 21 | - [Fail `BLS12_G2MULTIEXP` Machine-readable data](fail-multiexp_G2_bls.json) 22 | - [Fail `BLS12_PAIRING_CHECK` Machine-readable data](fail-pairing_check_bls.json) 23 | -------------------------------------------------------------------------------- /BEPs/assets/bep-520/5-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/bnb-chain/BEPs/ba7accfedf5a5b54b5fd8e137b00fa70b5e30420/BEPs/assets/bep-520/5-3.png --------------------------------------------------------------------------------