This PR consists of three commits: one reverts proof-of-stake-time, one completely removes the concept of weight from the codebase, and the final one contains the implementation of Doomslug. It might be easier to review the last commit without the first two, since the first two are very mechanical, but create enormous number of changes.
Since Github doesn't by default pick up the description of the multi-commit PR, pasting here the description of Doomslug commit:
Implementation and integration of Doomslug (see https://near.ai/doomslug).
Doomslug itself is in
Doomslug is stored on the client, not chain, because both block
Doomslug needs to know about the latest Tip. Instead of intercepting the
This change also solves a problem that approvals before were in a cache
The text was updated successfully, but these errors were encountered:
@@ Coverage Diff @@ ## staging #1991 +/- ## =========================================== + Coverage 87.13% 87.38% +0.25% =========================================== Files 170 170 Lines 33544 33845 +301 =========================================== + Hits 29227 29575 +348 + Misses 4317 4270 -47
In preparation for implementing Doomslug, removing the concept of `weight` and replacing the fork choice rule to choose the chain with the highest score, and then height. Replacing score with the height of the last pre-voted block rather than the weight.
Implementation and integration of Doomslug (see https://near.ai/doomslug). Doomslug itself is in `chain/doomslug.rs`, and doesn't depend on chain or any other code. It also always takes the current time as an argument. It significantly simplifies testing. Doomslug is stored on the client, not chain, because both block production and approvals processing happens on client. Instantiating on chain would require a slightly more complex interface (e.g. it would be impossible to pass `me`). Doomslug needs to know about the latest Tip. Instead of intercepting the lowest level tip-updating routine (which is in storage), I update the Tip in the client when we accept the new head. It could miss head changes related to syncing and challenges. To be safe I always update the head whenever I interact with Doomslug, so the head is guaranteed to be accurate whenever we do anything related to Doomslug, but it might get sent to Doomslug with a slight delay. This change also solves a problem that approvals before were in a cache hash map, therefore an adversary could have spammed a node with lots of invalid approvals and remove all valid approvals from the cache, resulting in a node not having enough approvals when producing the block. New logic is more complex, see `DoomslugApprovalsTrackersAtHeight` class. Test plan --------- 1. Sanity tests (basic invariants for `set_tip` and approval processing) 2. A fuzzy test that tests safety and liveness under different times to GST and deltas. 3. `test_catchup_sanity_blocks_produced_doomslug` verifies that heights are properly skipped. 4. Also added checking doomslug invariant into `cross_shard_tx`, which is known to evoke all kinds of weird structures (but `cross_shard_tx` operates without the requirement to have 50% approvals on the block, thus still causing lots of forkfullness). 5. A new version of `cross_shard_tx` that enables doomslug, but disables tampering with the finality gadget. Thus the vanilla version tests heavy forkfulness and tampers with FG, while the new doomslug version has practically no forfulness due to doomslug, and doesn't stress the FG as much, but does test block production with doomslug.