[DBFT] Optimize dBFT Consensus Timing Mechanism

nep-dbft.mediawiki

@@ -0,0 +1,138 @@
+<NEP: xxx>
+  Title: Optimize dBFT Consensus Timing Mechanism
+  Author: Jimmy Liao <[email protected]>
+  Status: Draft
+  Created: 2025-02-08
+  Requires: N/A
+  Replaces: N/A
+  Hardfork: HF_Echidna
+
+==Abstract==
+
+This NEP proposes an optimization to the dBFT consensus timing mechanism in Neo N3, to be implemented as part of the HF_Echidna hardfork. The change modifies how consensus rounds are scheduled by integrating the consensus time within the block time, transforming from a sequential approach to an overlapping timeline approach.
+
+==Terminology==
+
+===Time Parameters===
+* Block Time (Tb): The fixed time interval between two consecutive blocks
+* Consensus Time (Tc): The actual time required to complete one round of consensus
+* Previous Implementation: Tb + Tc was the effective time between blocks
+* New Implementation: Tc occurs within Tb, making the effective time between blocks equal to Tb
+
+==Motivation==
+
+As we plan to reduce the block time in future updates, network anomalies and latency issues will have a more pronounced impact on block generation speed. This could potentially slow down the block production rate and, consequently, affect the <code>GAS</code> generation rate. Therefore, we need to implement a mechanism to minimize these latency effects and maintain a stable gas generation rate across the network.
+
+The proposed optimization aims to:
+1. Mitigate the impact of network latency on block generation
+2. Ensure consistent gas generation rates despite reduced block times
+3. Enhance network resilience against timing anomalies
+
+==Specification==
+
+===Current Implementation===
+* Block time: Tb
+* Consensus time: Tc
+* Current effective cycle: Tb + Tc
+* Current behavior: 
+  * Round N consensus completes (takes Tc)
+  * System waits for full block time (Tb)
+  * Total time between blocks = Tb + Tc
+
+===Proposed Implementation===
+* Block time: Tb (unchanged)
+* Consensus time: Tc (occurs within Tb)
+* New effective cycle: Tb
+* New behavior:
+  * Let T(n) be the start time of Round N
+  * Round N consensus completes at time T(n) + Tc(n), where Tc(n) is the actual consensus time for Round N
+  * Round N+1 starts at time max(T(n) + Tb, T(n) + Tc(n))
+    * If T(n) + Tc(n) ≤ T(n) + Tb: Round N+1 starts at T(n) + Tb
+    * If T(n) + Tc(n) > T(n) + Tb: Round N+1 starts immediately after Round N completes
+  * This ensures:
+    * Under normal conditions (Tc(n) < Tb), rounds start at fixed Tb intervals
+    * If consensus takes longer than expected, the next round starts without additional delay
+    * No artificial waiting period is introduced when consensus exceeds the target block time
+
+===Hardfork Activation===
+* Hardfork Name: HF_Echidna
+* The new consensus timing mechanism will be activated at the HF_Echidna hardfork height
+* All nodes must upgrade before the hardfork activation height
+* Pre-hardfork behavior will continue until the activation height is reached
+
+===Technical Details===
+* Modify the consensus timing mechanism to track T(n) (start time of each round)
+* Calculate next round start time using max(T(n) + Tb, T(n) + Tc(n))
+* Implement proper synchronization to handle cases where Tc(n) approaches or exceeds Tb
+* Monitor and log cases where Tc(n) > Tb to identify potential network issues
+
+===Edge Cases and Handling===
+* When Tc(n) > Tb:
+  * System immediately starts Round N+1 without waiting
+  * T(n+1) = T(n) + Tc(n)
+  * This may indicate network performance issues that should be monitored
+* When Tc(n) << Tb:
+  * System waits until T(n) + Tb to start Round N+1
+  * T(n+1) = T(n) + Tb
+  * This represents optimal network conditions
+
+==Rationale==
+
+The proposed change optimizes network efficiency by:
+* Utilizing the previously idle waiting period for consensus operations
+* Maintaining a consistent block time for network stability
+* Reducing actual system idle time without compromising security or reliability
+* Improving the overall efficiency of the consensus process
+
+This optimization doesn't change the fundamental security properties of dBFT but makes better use of the time window between blocks.
+
+==System Impact==
+
+===Block Production Rate===
+* Current System:
+  * Effective block time = Tb + Tc
+  * Example: With Tb = 15s and Tc = 3s, effective block time is 18s
+* New System:
+  * Effective block time = Tb
+  * Example: With Tb = 15s, effective block time is 15s
+* Impact:
+  * Approximately (Tb + Tc)/Tb times more blocks will be produced
+  * Using the example above: 18/15 = 1.2x more blocks per time unit
+
+===GAS Generation Impact===
+* Increased Block Production:
+  * More blocks produced per time unit
+  * Each block generates fixed amount of GAS
+  * Total GAS generation rate will increase proportionally with block production
+* Economic Considerations:
+  * Higher GAS generation rate may affect token economics
+
+==Backwards Compatibility==
+
+This change requires activation through the HF_Echidna hardfork as it modifies the consensus timing mechanism. The change:
+* Will be activated at the HF_Echidna hardfork height
+* Requires all consensus nodes to upgrade before the hardfork activation
+* Is not backwards compatible with pre-hardfork nodes
+* Nodes running pre-hardfork versions will fork off the network at the activation height
+
+==Implementation==
+
+The implementation requires modifications to:
+1. The consensus timing mechanism in the consensus module
+2. The block generation scheduling system
+3. The synchronization mechanism between consensus rounds
+
+===Testing Requirements===
+* Extensive testing of consensus timing under various network conditions
+* Verification of proper handling of delayed consensus rounds
+* Confirmation of maintained block time
+* Stress testing with different network latencies and loads
+* Hardfork activation testing:
+  * Verify correct behavior before hardfork height
+  * Test activation at hardfork height
+  * Verify proper handling of mixed version nodes
+  * Test network partition detection for non-upgraded nodes
+
+==Reference Implementation==
+
+[Link to reference implementation when available]