Red Queen's: New Sync Proposal

Execution Layer Research
1

As part of Ethereum 1x efforts, we want to tackle the issue of the growing blockchain state. Large state size leads to long sync times. On top of that, geth’s fast sync is not that fast and takes a few hours. Parity’s warp sync is faster, but is not supported in geth. We propose a new sync protocol and an algorithm, which we believe can perform snapshot sync in less than an hour. The idea is somewhat similar to Warp Sync and especially to Leaf Sync (under development in geth). Moreover, the new protocol caters for clients with a different storage structure than the canonical Patricia trie (e.g. turbo-geth).

The new protocol and algorithm are described in a paper. See also my presentation at Ethereum Core Devs Eth1x/Istanbul Planning Meeting in Berlin.

This is the first version; comments, suggestions, critique are most welcome.

5 Likes
2

@yperbasis thanks for sharing! I assume this is not compatible with the Beam Sync proposal that Trinity has been working on?

3

They’re compatible :slight_smile:

“Beam Sync” is a slight misnomer, it’s not a sync protocol, and instead it’s more of a sync strategy. Currently, Beam Sync works by using the GetNodeData requests that eth already supports, but Beam Sync could just as easily use Red Queen’s GetStateNodes request. In fact, it would run much faster if it could use GetStateNodes, because a single call of GetStateNodes is enough to fetch an account, something which takes around 7 round-trips using GetNodeData.

Though, this is just my impression of the situation, @carver might not agree with all of it.

1 Like