KIP 7 - Finality Rules Improvement

kip-0007.md

@@ -0,0 +1,27 @@
+```
+    KIP: 7
+    Title: Finality Rules Improvement  
+    Layer: Consensus (Finality)
+    Type: Standards Track
+    Author: Ori Newman <[email protected]>
+    Status: Draft
+```
+
+# Motivation
+Currently, finality rules can be too decisive. For example, an attacker can sync a new node with a side chain of `finality_depth` blocks where the split point is genesis. This will be very cheap, since genesis' difficulty is very low. After that, any attempt to update the node with a better state will be rejected due to finality rules. So in order to solve that we need to treat differently blocks that were added when the node is synced or unsynced.
+
+# Proposal
+We propose to add a new `u64` field for each block called `block_added_time` that will record the time where it was added to the database. After this change, the finality point will be the first block that is both in `finality_depth` from virtual, and that also satisfies `now() - block_added_time >= target_time_per_block * finality_depth`.
+
+Specifically, whenever we replace a consensus instance with headers proof, the new consensus should save the finality point of the old consensus, so if we don't find any block in the new consensus that satisfies those terms, we'll use the old finality point.
+
+Note that if this new set of rules is applied, the pruning rules cannot guarantee anymore that when a reorg is triggered all merged blocks will be available. So if it happens, we should reject the reorg.
+
+# Rationale
+To avoid a situation where an IBD can quickly lock the node state to one POV, we want to give open a challenge period where other peers will be able to  challenge the POV of the said IBD.
+
+# Resource Cost
+Current pruning depth is 185798, and `block_added_time` is 8 bytes, so the new field will add about 4.9 MB of storage. When we apply higher BPS, it's also possible to save this field to only a portion of the blocks to avoid making it grow linearly as a function of the BPS.
+
+# Backward compatibility
+This KIP makes finality rules more relaxed, so it shouldn't affect backward compatibility: it cannot affect live nodes, and any node that was already locked away from the network consensus will also reject the state of upgraded nodes.