[ETCM-316] Fast-sync branch resolver

[biandratti]

Description

This task has as dependence the task [ETCM-313]. When a invalid block is detected from the master peer. We need to search for a new peer potencial and validate the our chain saved with this new peer.
In this way, with this new peer we need to follow the next points.

1. First ask this peer for the last several blocks, starting from current mantis best + 1, in reverse. i.e let's say our current best block is 100, then we ask potential peer for blocks with numbers from 101 to 101 - X, where x is some hyperparameter. Then we check the block one by one if they make a chain connection with our local chain. i.e first check if remote 101 is child of local 100, if not then check if remote 100 is child of local 99. If we find a match, rewind to a matched block and that starts syncing from there, and if not go to point 2.
2. If we do find not matched blocks in most fresh local blocks, it means that chains diverged earlier. To find the first common block between local and remote blockchain we can use binary search as both blockchain are sorted lists. First we ask remote peer for a block in the middle of our local blockchain, if block from response is the same as local, then it means chains diverged later otherwise they diverged earlier.

Proposed Solution

We have an actor called FastSyncBranchResolver responsible for this behavior. When FastSync actor need to resolve it branch; FastSyncBranchResolver is called with the message “StartBranchResolver”. In this way, we have the following strategy:

1. Get a new master peer.
2. If we don't detect a master peer, we wait a second and retry again.
3. Get a set of the last BlockHeaders from this master peer.
4. Validate the set of blocks received from master peer andwe validate it with our chain. If deptect the last valid block, we discard the last invalid blocks in our chain and send a message “BranchResolvedSuccessful” to the fast sync to continue with the syncing. In case if we cant detect the last valid block it diverged earlier (5).
5. We continue with a binary search validation, block per block with the peer master until we detect the last valid block in our chain. When detecting this block, we discard the last invalid blocks in our chain and send a message “BranchResolvedSuccessful to the fast sync to continue with the syncing.

Pending work

• We need to remove binary search logic from the actor, and put it into another normal class. Making it possible to test it completely in all the cases. ✔️
• [task: ETCM-531] We need to change the behavior of traits BlacklistSupport and PeerListSupport. Both should be actors. Today when we switched between FastSync and FastSyncBranchResolver, we lost the list of peers in memory from blackList and handshake. So we need to uncouple this behavior and don't lose the changes. This new behavior should also work in the future to regular sync. ✔️

Testing

It needs a battery of integration test to cover these case.

[KonradStaniec]

In general idea looks good.

One thing i would change is to remove as much logic from actor, and move it to normal class to make it possible to test whole binary search logic without akka (and timeouts). So actor would be only to communicate with other actors

[pullrequest]

These changes look good. The tests appear to cover all of the new functionality. I don't find anything blocking, and no additional comments from what other reviewers have already covered. There are a couple of instances of the val blocksSentFromPee which I suspect should be named blocksSentFromPeer. Good work!

Steven

---

Reviewed with ❤️ by PullRequest

[pullrequest]

	1 Message
✅	Due to its size, this pull request will likely have a little longer turnaround time and will probably require multiple passes from our reviewers.