bnb-chain · zzzckck · Feb 20, 2025 · Feb 19, 2025 · Feb 19, 2025 · Feb 19, 2025
diff --git a/BEPs/BEP-520.md b/BEPs/BEP-520.md
@@ -1,22 +1,22 @@
 <pre>
   BEP: 520
-  Title: Short Block Interval
+  Title: Short Block Interval Phase One: 1.5 seconds
   Status: Draft
   Type: Standards
   Created: 2025-02-10
-  Description: To shorten the block interval from 3 seconds to 0.75 seconds.
+  Description: To shorten the block interval from 3 seconds to 1.5 seconds.
 </pre>
 
-# BEP-520: Short Block Interval
-- [BEP-520: Short Block Interval](#bep-520-short-block-interval)
+# BEP-520: Short Block Interval Phase One: 1.5 seconds
+- [BEP-520: Short Block Interval Phase One: 1.5 seconds](#bep-520-short-block-interval-phase-one-15-seconds)
   - [1. Summary](#1-summary)
   - [2. Abstract](#2-abstract)
   - [3. Motivation](#3-motivation)
   - [4. Specification](#4-specification)
     - [4.1 Parlia Changes](#41-parlia-changes)
       - [4.1.1 Millisecond Representation in Block Header](#411-millisecond-representation-in-block-header)
-      - [4.1.2 Penalizing Intentional Block Production Delays](#412-penalizing-intentional-block-production-delays)
-    - [4.2 Parameters Changes](#42-parameters-changes)
+      - [4.1.2 Penalize Intentional Delay Block Production](#412-penalize-intentional-delay-block-production)
+    - [4.2 Parameter Changes](#42-parameter-changes)
       - [4.2.1 Change table](#421-change-table)
   - [5. Rational](#5-rational)
     - [5.1 Epoch and TurnLength](#51-epoch-and-turnlength)
@@ -27,19 +27,25 @@
     - [6.1 MEV](#61-mev)
     - [6.2 Layer 2 Solutions](#62-layer-2-solutions)
     - [6.3 Quarterly Auto-Burn](#63-quarterly-auto-burn)
+    - [6.4 Block Finality](#64-block-finality)
   - [7. License](#7-license)
 
 ## 1. Summary
-Shorten the block interval from 3 seconds to 0.75 seconds to enable faster transaction confirmations and improve user experience.
+Shorten the block interval from 3 seconds to 1.5 seconds to enable faster transaction confirmation and improve user experience.
 
 ## 2. Abstract
 Since its inception, BSC has maintained a 3-second block interval. Shortening this interval can provide quicker transaction confirmations, enhancing user experience. However, this modification presents challenges that require adjustments to the consensus mechanism and network parameters.
+There would be two phases to shorten block interval from 3 seconds to 0.75 seconds.
+- Phase One: shorten block interval from 3 seconds to 1.5 seconds.
+- Phase Two: shorten block interval from 1.5 seconds to 0.75 seconds.
+
+This BEP is mainly for phase one, but it will also include some description of phase two, as they are highly relevant.
 
 ## 3. Motivation
 In a competitive blockchain landscape, users demand faster transaction confirmations. Reducing the block interval will make BSC more competitive and meet user expectations for high-performance blockchains.
+And the two phases strategy is to avoid one big step to reduce it to 0.75s directly, which could be too risky, as the overall infrastructure may not be fully ready to this change. Phase two(0.75s) would be carried out after phase one(1.5s) has been verified.
 
 ## 4. Specification
-The block interval will be gradually reduced through two hard forks. The first reduction will decrease it from 3 seconds to 1.5 seconds, and the second reduction will decrease it from 1.5 seconds to 0.75 seconds.
 ### 4.1 Parlia Changes
 #### 4.1.1 Millisecond Representation in Block Header
 Before the implementation of this BEP, both block intervals and block times were represented with a minimum unit of `second`. Post - BEP, the minimum unit is changed to `millisecond`.
@@ -63,7 +69,7 @@ func (h *Header) TimeInMilliseconds() uint64 {
 }
 ```
 
-#### 4.1.2 Penalizing Intentional Block Production Delays
+#### 4.1.2 Penalize Intentional Delay Block Production
 In the Parlia engine, each block height has a designated in-turn validator responsible for producing the block. If the in-turn validator fails to produce the block in time, a second-priority validator will take over after a delay equal to `initialBackOffTime`.
 Current settings:
 ```Go
@@ -82,25 +88,26 @@ func (p *Parlia) isBlockDelayMinedOnPurpose(header, parent *types.Header) {
 }
 ```
 
-### 4.2 Parameters Changes
+### 4.2 Parameter Changes
+As mentioned above, phase one and phase two are highly relevant, their parameter changes will be put in one table for easy comparison. But the parameters of phase two here is only for reference, as it could be changed in the future when phase two is finally delivered.
+
 #### 4.2.1 Change table
 A multitude of system parameters are configured based on the assumption that the default block interval is 3 seconds. Consequently, when the block interval is altered, these parameters must be adjusted accordingly:
-|parameter |type |current value  |first hardfork |second hardfork|
+|parameter |type |origin(3s)  | phase one(1.5s) | phase two(0.75s)|
 |--------|--------|--------|--------|--------|
-|Epoch  |client parameter |200  |2000 |2000|
-|GasLimit |client parameter |140M |65M |30M|
+|Epoch  |client parameter |200  |1000 |2000|
+|GasLimit |client parameter |140M |60M |30M|
 |GasLimitBoundDivisor |client parameter |256 |1024 |1024|
 |Blob Target  |client parameter |3  |2  |1|
 |Blob Maximum |client parameter |6  |3  |2|
-|Blob Update Fraction |client parameter |3338477  |5007716  |3338477|
 |Blob MinBlocksForBlobRequests  |client parameter |524288 |1048576 (524288 × 2) |2097152 (524288 × 4)|
 |BSCGovernor.votingDelay  |contract parameter |$votingDelay |$votingDelay × 2  |$votingDelay × 4|
 |BSCGovernor.votingPeriod |contract parameter |$votingPeriod  |$votingPeriod × 2 |$votingPeriod × 4|
 |BSCGovernor.minPeriodAfterQuorum |contract parameter |$minPeriodAfterQuorum  |$minPeriodAfterQuorum × 2 |$minPeriodAfterQuorum × 4 |
 |BSCValidatorSet.misdemeanorThreshold |contract parameter |$misdemeanorThreshold  |$misdemeanorThreshold × 2 |$misdemeanorThreshold × 4|
 |BSCValidatorSet.felonyThreshold  |contract parameter |$felonyThreshold  |$felonyThreshold × 2  |$felonyThreshold × 4|
 |BSCValidatorSet.felonySlashScope |contract parameter |$felonySlashScope  |$felonySlashScope × 2 |$felonySlashScope × 4|
-|BSCValidatorSet.TurnLength  |contract parameter |4  |32  |32|
+|BSCValidatorSet.TurnLength  |contract parameter |4  |16  |32|
 ## 5. Rational
 ### 5.1 Epoch and TurnLength
 Within an epoch, some validators may fail to produce blocks as scheduled due to maintenance, system failures, or other issues. This can lead to an increased number of low-difficulty blocks, reducing network stability. When a new epoch begins, the validator set is adjusted, replacing validators that have repeatedly failed to produce blocks as scheduled to maintain network stability. Therefore, the epoch duration must not be too long, or the network’s stability will degrade.
@@ -112,23 +119,24 @@ At validator set transition points, a validator can deliberately delay broadcast
 Considering these factors, the epoch length is set to 2000, and `TurnLength` to 32. When the block interval is ultimately reduced to 0.75 seconds, the epoch duration will increase from 600 to 1500 seconds. A 2000-block epoch roughly allows 21 validators to produce three full rounds of 32 blocks each.
 
 ### 5.2 GasLimit and GasLimitBoundDivisor
-As the block interval shortens, the gas limit per block must decrease accordingly. However, since not all time within a block interval is used for transaction processing, the gas limit is reduced slightly more than the proportional decrease in block interval. The gas limit is initially set to decrease to 65M in the first hard fork and to 30M in the second.
+As the block interval shortens, the gas limit per block must decrease accordingly. However, since not all time within a block interval is used for transaction processing, the gas limit is reduced slightly more than the proportional decrease in block interval. The gas limit is initially set to decrease to 60M in the phase one hard fork and to 30M in phase two hard fork.
 
-GasLimitBoundDivisor represents the rate of change in GasLimit. Since the block interval is reduced by a factor of four, GasLimitBoundDivisor is increased by the same factor to maintain a consistent rate of GasLimit adjustment.
-### 5.3 Blob Related
-This BEP implementation aims to maintain or enhance the network’s capacity to handle blobs. According to the table, before the first hard fork, the network handles a target of 1 blob per second (3/3). After the second hard fork, this increases to 4/3 blobs per second (1/0.75), representing a 33% improvement in blob processing capacity.
+GasLimitBoundDivisor represents the rate of change in GasLimit. Since the block interval will be reduced by a factor of four after phase two, GasLimitBoundDivisor is increased by the same factor to maintain a consistent rate of GasLimit adjustment to avoid sharp gas limit fluctuation if some validators use a too small or too large gas limit value.
 
-The target-to-max ratio from EIP-4844 was originally 1:2. After the first hard fork, it changed to 2:3, and after the second hard fork, it reverted to 1:2. Referencing [EIP-7691](https://github.com/ethereum/EIPs/blob/d96625a4dcbbe2572fa006f062bd02b4582eefd5/EIPS/eip-7691.md#update-fraction), the Blob Update Fraction was set to 5,007,716 and 3,338,477 for the first and second hard forks, respectively.
+As GasLimit is not part of consensus, it is calculated based on validators' configuration. So need validators's support to downgrade their gas limit configuration before each hard fork.
+
+### 5.3 Blob Related
+This BEP implementation aims to maintain or enhance the network’s capacity to handle blobs. According to the table, before phase one hard fork, the network handles a target of 1 blob per second (3 blobs/3 seconds). After phase one hard fork, it will be 4/3 blobs per second(2 blobs/1.5seconds). So there will be ~33% improvement in blob processing capacity.
 
 ### 5.4 Contract Parameters
 The seven parameters—`BSCGovernor.votingDelay`, `BSCGovernor.votingPeriod`, `BSCGovernor.minPeriodAfterQuorum`, `BSCValidatorSet.misdemeanorThreshold`, `BSCValidatorSet.felonyThreshold`, `BSCValidatorSet.felonySlashScope`, and `Blob MinBlocksForBlobRequests`—are all measured in block numbers and used to calculate time. Therefore, when the block interval is reduced, the block numbers must be increased proportionally to maintain the same time representation.
 
 ## 6. Backward Compatibility
 ### 6.1 MEV
-When the block interval is reduced to 0.75 seconds, a single validator will produce 32 consecutive blocks per turn, keeping the total block production time at 24 seconds (0.75 × 32). However, the shorter block time significantly reduces the collaboration window for searchers, builders, and validators, impacting the current process and requiring adjustments.
+After phase one, the block interval will be reduced to 1.5 seconds, a single validator will produce 16 consecutive blocks per turn, keeping the total block production time at 24 seconds (1.5 × 16). However, the shorter block time significantly reduces the collaboration window for searchers, builders, and validators, impacting the current process and requiring adjustments.
 
 ### 6.2 Layer 2 Solutions
-With BSC’s blob-handling capacity increased by 1/3, the required blob support for L2 solutions has also been enhanced.
+The usage of blob transaction will be changed, as blob target will be decreased from 3 to 2 and blob maximum will be decreased from 6 to 3. Layer 2 can only attach 3 blobs at most for each transaction and the blob gas price calculation mechanism will also be slightly different.
 
 ### 6.3 Quarterly Auto-Burn
 The [Quarterly Auto-Burn](https://www.bnbburn.info/) mechanism also requires adjustment,The block count in the formula is replaced with time, resulting in the new formula:
@@ -137,5 +145,11 @@ The [Quarterly Auto-Burn](https://www.bnbburn.info/) mechanism also requires adj
 </div>
 where T represents the number of seconds in the corresponding quarter.
 
+### 6.4 Block Finality
+This BEP will not change the fast finality mechanism, but short block interval could bring some challenges to fast finality, as votes need to be propagated in a shorter time. When fast finality works properly, with this BEP, the average transaction finality time would be reduced from 7.5 seconds to 3.75 seconds.
+But if fast finality failed, with TurnLength 16 and ValidatorSize 21, for natural block finality, it will be:
+- (with >1/2 validator confirmations):  176(11*16) blocks, that is 264 seconds
+- (with >2/3 validator confirmations):  240(15*16) blocks, that is 360 seconds
+
 ## 7. License
 The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/BEPs/BEP-524.md b/BEPs/BEP-524.md
@@ -0,0 +1,76 @@
+<pre>
+  BEP: 524
+  Title: Short Block Interval Phase Two: 0.75 seconds
+  Status: Draft
+  Type: Standards
+  Created: 2025-02-18
+  Description: To shorten the block interval from 1.5 seconds to 0.75 seconds.
+</pre>
+
+# BEP-524: Short Block Interval Phase Two: 0.75 seconds
+- [BEP-524: Short Block Interval Phase Two: 0.75 seconds](#bep-524-short-block-interval-phase-two-075-seconds)
+  - [1. Summary](#1-summary)
+  - [2. Abstract](#2-abstract)
+  - [3. Motivation](#3-motivation)
+  - [4. Specification](#4-specification)
+    - [4.1 Parameter Changes](#41-parameter-changes)
+      - [4.2.1 Change table](#421-change-table)
+  - [5. Rational](#5-rational)
+  - [6. Backward Compatibility](#6-backward-compatibility)
+    - [6.1 MEV](#61-mev)
+    - [6.2 Layer 2 Solutions](#62-layer-2-solutions)
+    - [6.3 Quarterly Auto-Burn](#63-quarterly-auto-burn)
+    - [6.4 Block Finality](#64-block-finality)
+  - [7. License](#7-license)
+
+## 1. Summary
+Shorten the block interval from 1.5 seconds to 0.75 seconds to enable faster transaction confirmation and improve user experience.
+
+## 2. Abstract
+BEP-520 is the phase one to reduce the block interval from 3 seconds to 1.5 seconds. And this BEP is the phase two, which would reduce it further to 0.75 seconds.
+
+## 3. Motivation
+Faster transaction confirmation is a critical and long term goal, with 0.75 seconds block interval, it could meet the requirement of some time sensitive applications.
+
+## 4. Specification
+The overall design specification is similar to BEP-520, so only the parameter changes will be covered in this section.
+
+### 4.1 Parameter Changes
+As mentioned above, phase one and phase two are highly relevant, their parameter changes will be put in one table for easy comparison.
+
+#### 4.2.1 Change table
+A multitude of system parameters are configured based on the assumption of the default block interval. Consequently, when the block interval is altered, these parameters must be adjusted accordingly:
+|parameter |type | origin(3s)  | phase one(1.5s) | phase two(0.75s)|
+|--------|--------|--------|--------|--------|
+|Epoch  |client parameter |200  |1000 |2000|
+|GasLimit |client parameter |140M |60M |30M|
+|GasLimitBoundDivisor |client parameter |256 |1024 |1024|
+|Blob Target  |client parameter |3  |2  |1|
+|Blob Maximum |client parameter |6  |3  |2|
+|Blob MinBlocksForBlobRequests  |client parameter |524288 |1048576 (524288 × 2) |2097152 (524288 × 4)|
+|BSCGovernor.votingDelay  |contract parameter |$votingDelay |$votingDelay × 2  |$votingDelay × 4|
+|BSCGovernor.votingPeriod |contract parameter |$votingPeriod  |$votingPeriod × 2 |$votingPeriod × 4|
+|BSCGovernor.minPeriodAfterQuorum |contract parameter |$minPeriodAfterQuorum  |$minPeriodAfterQuorum × 2 |$minPeriodAfterQuorum × 4 |
+|BSCValidatorSet.misdemeanorThreshold |contract parameter |$misdemeanorThreshold  |$misdemeanorThreshold × 2 |$misdemeanorThreshold × 4|
+|BSCValidatorSet.felonyThreshold  |contract parameter |$felonyThreshold  |$felonyThreshold × 2  |$felonyThreshold × 4|
+|BSCValidatorSet.felonySlashScope |contract parameter |$felonySlashScope  |$felonySlashScope × 2 |$felonySlashScope × 4|
+|BSCValidatorSet.TurnLength  |contract parameter |4  |16  |32|
+
+## 5. Rational
+Refer BEP-520
+
+## 6. Backward Compatibility
+### 6.1 MEV
+After phase two, the block interval will be reduced to 0.75 seconds, a single validator will produce 32 consecutive blocks per turn, keeping the total block production time at 24 seconds (0.75 × 32). However, the shorter block time significantly reduces the collaboration window for searchers, builders, and validators, impacting the current process and requiring adjustments.
+
+### 6.2 Layer 2 Solutions
+TBD
+
+### 6.3 Quarterly Auto-Burn
+TBD
+
+### 6.4 Block Finality
+TBD
+
+## 7. License
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/README.md b/README.md
@@ -84,7 +84,8 @@ Here is the list of subjects of BEPs:
 | [BEP-441](./BEPs/BEP-441.md) | Implement EIP-7702: Set EOA account code | Standards | Review |
 | [BEP-466](./BEPs/BEP-466.md) | Make the block header format compatible with EIP-7685 | Standards | Review |
 | [BEP-496](./BEPs/BEP-496.md) | Implement EIP-7623: Increase calldata cost | Standards | Review |
-| [BEP-520](./BEPs/BEP-520.md) | Short Block Interval | Standards | Draft |
+| [BEP-520](./BEPs/BEP-520.md) | Short Block Interval Phase One: 1.5 seconds | Standards | Draft |
+| [BEP-524](./BEPs/BEP-524.md) | Short Block Interval Phase Two: 0.75 seconds | Standards | Draft |
 
 
 # BNB Chain Upgrades