Ankr-network · ghost · Jul 10, 2020 · Aug 25, 2020 · Aug 27, 2020 · Aug 28, 2020
diff --git a/BAPs/BAP-578.md b/BAPs/BAP-578.md
diff --git a/BAPs/README.md b/BAPs/README.md
@@ -0,0 +1,29 @@
+# BNB Chain Application Proposals (BAPs)
+
+- [BNB Chain Application Proposals (BAPs)](#bnb-chain-application-proposals-baps)
+  - [What is a BAP?](#what-is-a-bap)
+  - [BAP Workflow](#bap-workflow)
+  - [BAP Format](#bap-format)
+    - [Numbering and File Naming](#numbering-and-file-naming)
+
+## What is a BAP?
+
+BNB Chain Application Proposals (BAPs) are community-driven design documents that specify application-level standards, conventions, and best practices for the BNB Chain ecosystem. BAPs aim to improve interoperability and user experience across dApps, wallets, services, and tooling.
+
+- Scope includes: token and NFT standards, wallet interaction flows, RPC/ABI conventions, indexer/query schemas, cross-dApp messaging, off-chain service interfaces, and other app-layer norms.
+- BAPs are distinct from BEPs (BNB Chain Evolution Proposals), which target protocol/consensus or node-level changes.
+
+## BAP Workflow
+
+BAP workflow follows the process described in [BEP-1](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP1.md#4--bep-workflow).
+![overall workflow](../BEPs/assets/bep-1/workflow.png)
+
+The **Review** stage is central to BAPs and requires feedback from the community, especially from relevant ecosystem partners. Feedback can be provided in this repository or on the [BNB Chain Forum](https://forum.bnbchain.org/). PR status is maintained by the BAP editors, primarily the maintainers of this GitHub repository.
+
+## BAP Format
+The BAP format follows the [BEP format](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP1.md#5--bep-format). Providing reference implementations is strongly recommended to clarify interface definitions.
+
+### Numbering and File Naming
+
+- Provisional PRs may use `BAP-xxxx.md`; a concrete number is assigned upon Acceptance.
+- Place the file at `BAPs/BAP-<number>.md` with a clear, descriptive title.
diff --git a/BEP1.md b/BEP1.md
diff --git a/BEPs/BEP-225.md b/BEPs/BEP-225.md
@@ -0,0 +1,133 @@
+<pre>
+  BEP: 225
+  Title: Implement EIP2565 ModExp Gas Cost 
+  Status: Enabled
+  Type: Standards
+  Created: 2023-4-27
+</pre>
+
+# BEP-225: Implement EIP-2565 ModExp Gas Cost
+- [BEP-225: Implement EIP2565 ModExp Gas Cost](#bep-225-implement-eip-2565-modexp-gas-cost)
+  - [1. Summary](#1-summary)
+  - [2. Abstract](#2-abstract)
+  - [3. Motivation](#3-motivation)
+  - [4. Specification](#4-specification)
+  - [5. Rationale](#5-rationale)
+  - [6. Test Cases](#6-test-cases)
+  - [7. Security Considerations](#7-security-considerations)
+  - [8. License](#8-license)
+  - [9. Reference](#9-reference)
+
+## 1. Summary
+
+As part of Berlin upgrade, EIP-2565: ModExp Gas Cost is required to be implemented to BSC.
+
+This EIP Defines the gas cost of the `ModExp (0x00..05)` precompile.
+
+## 2. Abstract
+
+To accurately reflect the real world operational cost of the `ModExp` precompile, this EIP specifies an algorithm for
+calculating the gas cost. 
+
+This algorithm approximates the multiplication complexity cost and multiplies that by an approximation of the
+iterations required to execute the exponentiation.
+
+## 3. Motivation
+
+Refer to EIP-2565 description:
+
+Modular exponentiation is a foundational arithmetic operation for many cryptographic functions including signatures,
+VDFs, SNARKs, accumulators, and more. Unfortunately, the ModExp precompile is currently over-priced, making these 
+operations inefficient and expensive. 
+
+By reducing the cost of this precompile, these cryptographic functions become more practical, enabling improved
+security, stronger randomness (VDFs), and more.
+
+## 4. Specification
+
+As of `FORK_BLOCK_NUMBER`, the gas cost of calling the precompile at address `0x0000000000000000000000000000000000000005` 
+will be calculated as follows:
+
+```
+def calculate_multiplication_complexity(base_length, modulus_length):
+max_length = max(base_length, modulus_length)
+words = math.ceil(max_length / 8)
+return words**2
+
+def calculate_iteration_count(exponent_length, exponent):
+iteration_count = 0
+if exponent_length <= 32 and exponent == 0: iteration_count = 0
+elif exponent_length <= 32: iteration_count = exponent.bit_length() - 1
+elif exponent_length > 32: iteration_count = (8 * (exponent_length - 32)) + ((exponent & (2**256 - 1)).bit_length() - 1)
+return max(iteration_count, 1)
+
+def calculate_gas_cost(base_length, modulus_length, exponent_length, exponent):
+multiplication_complexity = calculate_multiplication_complexity(base_length, modulus_length)
+iteration_count = calculate_iteration_count(exponent_length, exponent)
+return max(200, math.floor(multiplication_complexity * iteration_count / 3))
+```
+
+## 5. Rationale
+
+After benchmarking the ModExp precompile, we discovered that it is ‘overpriced’ relative to other precompiles. We also discovered that the current gas pricing formula could be improved to better estimate the computational complexity of various ModExp input variables. The following changes improve the accuracy of the ModExp pricing:
+
+### Modify `computational complexity` formula to better reflect the computational complexity
+The complexity function defined in EIP-198 is as follow:
+
+```
+def mult_complexity(x):
+if x <= 64: return x ** 2
+elif x <= 1024: return x ** 2 // 4 + 96 * x - 3072
+else: return x ** 2 // 16 + 480 * x - 199680
+```
+
+where is x is max(length_of_MODULUS, length_of_BASE)
+
+The complexity formula in EIP-198 was meant to approximate the difficulty of Karatsuba multiplication. However, we found a better approximation for modelling modular exponentiation. In the complexity formula defined in this EIP, x is divided by 8 to account for the number of limbs in multiprecision arithmetic. A comparison of the current ‘complexity’ function and the proposed function against the execution time can be seen below:
+
+![Complexity Function](./assets/BEP-225/Complexity_Regression.png)
+
+The complexity function defined here has a better fit vs. the execution time when compared to the EIP-198 complexity function. This better fit is because this complexity formula accounts for the use of binary exponentiation algorithms that are used by ‘bigint’ libraries for large exponents. You may also notice the regression line of the proposed complexity function bisects the test vector data points. This is because the run time varies depending on if the modulus is even or odd.
+
+### Change the value of GQUADDIVISOR
+   After changing the ‘computational complexity’ formula in EIP-198 to the one defined here it is necessary to change QGUADDIVSOR to bring the gas costs inline with their runtime. By setting the QGUADDIVISOR to 3 the cost of the ModExp precompile will have a higher cost (gas/second) than other precompiles such as ECRecover.
+
+![GQuad_Change](./assets/BEP-225/GQuad_Change.png)
+
+### Set a minimum gas cost to prevent abuse
+   This prevents the precompile from underpricing small input values.
+
+## 6. Test Cases
+There are no changes to the underlying interface or arithmetic algorithms, so the existing test vectors can be reused. Below is a table with the updated test vectors:
+
+| Test Case | EIP-198 Pricing	| EIP-2565 Pricing |
+| --------- | -----------------|------------------|
+| modexp_nagydani_1_square |	204	| 200              |
+| modexp_nagydani_1_qube |	204	| 200              |
+| modexp_nagydani_1_pow0x10001 | 3276 | 	341             |
+| modexp_nagydani_2_square	|665| 	200             |
+| modexp_nagydani_2_qube	|665| 	200             |
+| modexp_nagydani_2_pow0x10001	|10649| 	1365            |
+| modexp_nagydani_3_square	|1894| 	341             |
+| modexp_nagydani_3_qube	|1894| 	341             |
+| modexp_nagydani_3_pow0x10001	|30310	| 5461             |
+| modexp_nagydani_4_square	|5580	| 1365             |
+| modexp_nagydani_4_qube	|5580	| 1365             |
+| modexp_nagydani_4_pow0x10001	|89292	| 21845            |
+| modexp_nagydani_5_square	|17868	| 5461             |
+| modexp_nagydani_5_qube	|17868	| 5461             |
+| modexp_nagydani_5_pow0x10001	|285900	| 87381            |
+
+## 7. Security Considerations
+
+The biggest security consideration for this EIP is creating a potential DoS vector by making ModExp operations too inexpensive relative to their computation time.
+
+## 8. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## 9. Reference
+
+Most description of this BEP refer to [EIP-2565](https://eips.ethereum.org/EIPS/eip-2565):
+
+Kelly Olson (@ineffectualproperty), Sean Gulley (@sean-sn), Simon Peffers (@simonatsn), Justin Drake (@justindrake), Dankrad Feist (@dankrad), "EIP-2565: ModExp Gas Cost," Ethereum Improvement Proposals, no. 2565, March 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2565.
diff --git a/BEPs/BEP-229.md b/BEPs/BEP-229.md
@@ -0,0 +1,95 @@
+<pre>
+  BEP: 229
+  Title: Implement EIP-2718 Typed Transaction Envelope
+  Status: Enabled
+  Type: Standards
+  Created: 2023-4-19
+</pre>
+
+# BEP-229: Implement EIP-2718 Typed Transaction Envelope
+- [BEP-229: Implement EIP-2718 Typed Transaction Envelope](#bep-229-implement-eip-2718-typed-transaction-envelope)
+    - [1. Summary](#1-summary)
+    - [2. Abstract](#2-abstract)
+    - [3. Motivation](#3-motivation)
+    - [4. Specification](#4-specification)
+    - [5. Rationale](#5-rationale)
+    - [6. Backwards Compatibility](#6-backwards-compatibility)
+    - [7. Security Considerations](#7-security-considerations)
+    - [8. License](#8-license)
+    - [9. Reference](#9-reference)
+
+## 1. Summary 
+As part of Berlin upgrade, EIP-2718 Typed Transaction Envelope is required to be implemented to BSC.
+
+## 2. Abstract
+`TransactionType || TransactionPayload` is a valid transaction and `TransactionType || ReceiptPayload` is a valid transaction receipt where `TransactionType` identifies the format of the transaction and `*Payload` is the transaction/receipt contents, which are defined in future EIPs.
+
+## 3. Motivation
+In the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types.
+This was seen in [EIP-155](./eip-155.md) where the new value was bit-packed into one of the encoded fields.
+There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides `msg.sender` to pay for gas, and proposals related to layer 1 multi-sig transactions.
+These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.
+
+By introducing an envelope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between `TransactionType`s.
+
+## 4. Specification
+### Definitions
+* `||` is the byte/byte-array concatenation operator.
+
+### Transactions
+As of `FORK_BLOCK_NUMBER`, the transaction root in the block header **MUST** be the root hash of `patriciaTrie(rlp(Index) => Transaction)` where:
+* `Index` is the index in the block of this transaction
+* `Transaction` is either `TransactionType || TransactionPayload` or `LegacyTransaction`
+* `TransactionType` is a positive unsigned 8-bit number between `0` and `0x7f` that represents the type of the transaction
+* `TransactionPayload` is an opaque byte array whose interpretation is dependent on the `TransactionType` and defined in future EIPs
+* `LegacyTransaction` is `rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])`
+
+All signatures for future transaction types **SHOULD** include the `TransactionType` as the first byte of the signed data.
+This makes it so we do not have to worry about signatures for one transaction type being used as signatures for a different transaction type.
+
+### Receipts
+As of `FORK_BLOCK_NUMBER`, the receipt root in the block header **MUST** be the root hash of `patriciaTrie(rlp(Index) => Receipt)` where:
+* `Index` is the index in the block of the transaction this receipt is for
+* `Receipt` is either `TransactionType || ReceiptPayload` or `LegacyReceipt`
+* `TransactionType` is a positive unsigned 8-bit number between `0` and `0x7f` that represents the type of the transaction
+* `ReceiptPayload` is an opaque byte array whose interpretation is dependent on the `TransactionType` and defined in future EIPs
+* `LegacyReceipt` is `rlp([status, cumulativeGasUsed, logsBloom, logs])`
+
+The `TransactionType` of the receipt **MUST** match the `TransactionType` of the transaction with a matching `Index`.
+
+## 5. Rationale
+### TransactionType only goes up to 0x7f
+For the forseable future, 0x7f is plenty and it leaves open a number of options for extending the range such as using the high bit as a continuation bit.
+This also prevents us from colliding with legacy transaction types, which always start with a byte `>= 0xc0`.
+### **SHOULD** instead of **MUST** for the TransactionType being first byte of signed data
+While it is strongly recommended that all future transactions sign the first byte to ensure that there is no problem with signature reuse, the authors acknowledge that this may not always make sense or be possible.
+One example where this isn't possible is wrapped legacy transactions that are signature compatible with the legacy signing scheme.
+Another potential situation is one where transactions don't have a signature in the traditional sense and instead have some other mechanism for determining validity.
+### TransactionType selection algorithm
+There was discussion about defining the `TransactionType` identifier assignment/selection algorithm in this standard.
+While it would be nice to have a standardized mechanism for assignment, at the time of writing of this standard there is not a strong need for it so it was deemed out of scope.
+A future EIP may introduce a standard for TransactionType identifier assignment if it is deemed necessary.
+### Opaque byte array rather than an RLP array
+By having the second byte on be opaque bytes, rather than an RLP (or other encoding) list, we can support different encoding formats for the transaction payload in the future such as SSZ, LEB128, or a fixed width format.
+### ORIGIN and CALLER
+There was discussion about having ORIGIN and CALLER opcodes become dependent on the transaction type, so that each transaction type could define what those opcodes returned.
+However, there is a desire to make transaction type opaque to the contracts to discourage contracts treating different types of transactions differently.
+There also were concerns over backward compatibility with existing contracts which make assumptions about ORIGIN and CALLER opcodes.
+Going forward, we will assume that all transaction types will have an address that reasonably represents a `CALLER` of the first EVM frame and `ORIGIN` will be the same address in all cases.
+If a transaction type needs to supply additional information to contracts, they will need a new opcode.
+
+## 6. Backwards Compatibility
+Clients can differentiate between the legacy transactions and typed transactions by looking at the first byte.
+If it starts with a value in the range `[0, 0x7f]` then it is a new transaction type, if it starts with a value in the range `[0xc0, 0xfe]` then it is a legacy transaction type.
+`0xff` is not realistic for an RLP encoded transaction, so it is reserved for future use as an extension sentinel value.
+
+## 7. Security Considerations
+When designing a new 2718 transaction type, it is **STRONGLY** recommended to include the transaction type as the first byte of the signed payload.  If you fail to do this, it is possible that your transaction may be signature compatible with transactions of another type which can introduce security vulnerabilities for users.
+
+## 8. License
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+## 9. Reference
+Most description of this BEP refer to [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)
+
+Micah Zoltu (@MicahZoltu), "EIP-2718: Typed Transaction Envelope," Ethereum Improvement Proposals, no. 2718, June 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2718.