Closed frolosofsky closed 5 years ago
Rebased with master, updated test to epoch=1 feature. Picked updated #856.
@kostyantyn
We should also extend feature_snapshot.py if we see it's not enough. The added feature_snapshot_finalization.py seems to duplicate the same functionality.
It does not duplicate. It tests snapshot and commits integration, i.e., checks that finalization state transfer complete and node can operate after fast sync, e.g., accept votes and process finalization state further.
@frolosofsky we don't have 2 ways to sync snapshot. We used headers first, now we switched to commits first, so the initial test needs to be adjusted. From the description of that test we cover:
This test covers the following scenarios:
1. node can discover the peer that has snapshot
2. sync using snapshot
3. after the sync, the node can accept/propose new blocks
4. the node can switch to the fork which is created right after the snapshot
At the time of writing that test, we didn't have commits so we didn't assert finalizationstate but now we do have so let's add assert_finalizationstate
there. This is the only thing I see is not covered in feature_snapshot.py.
@kostyantyn It's not enough to add assert_finalizationstate
, we also need to connect validator and setup some deposit. That test already runs 6 nodes that makes logs messy.
I'm not a big fan of having all-in-one tests. Let's split that test on three files and then merge test_fast_sync
scenario with feature_snapshot_finalization
.
Extended feature_snapshot_finalization with a checks that test double votes conditions during fast-sync.
This PR adds integration code for snapshot and finalizer commits that effectively enables fast-sync with minor restrictions (https://github.com/dtr-org/unit-e/pull/852#pullrequestreview-222746353). On the first step of fast-sync, node restores finalization state by downloading finalizer commits from peers. On the second step, node downloads UTXO snapshot from peers and then downloads last missing blocks.
TODO:
Chapter in the #836 story.