Closed karalabe closed 3 years ago
It seems beneficial to have this protocol include a Status
message that is sent upon initial handshake (and also maybe elsewhere) so that this protocol isn't dependent on the ETH
protocol to handle fork/network negotiation. It would be nice to have this be fully independent of the ETH
protocol.
Similarly, it seems like it could be beneficial to have the Status
contain information on what parts of the trie the client has available which might reduce the number of requests sent to clients that they cannot fulfill because they have not yet acquired certain sections of the account state.
@pipermerriam Sorry for not replying, was on holiday when you wrote, forgot.
Soo, we've been thinking about this a lot and making it a satellite protocol was a deliberate decision (maybe not a perfect one, but definitely deliberate). The goal of snap
is state sync. It should have everything needed for syncing the state (like fast, beam, etc), but it should not add in the mix chain sync. Otherwise we really just end up with eth/6x. If we remove support for syncing the chain, then we lose the ability to detect when the chain moves, so we must rely on eth for that. From that point onward there's no reason to duplicate anything from eth, because we'll always have that.
A second reason is a bit more "greedy". Serving snap is not free. It requires maintaining an extra acceleration structure that's 15-20GB in size. I am fine with any client talking snap and leeching data, as long as they also start serving it back for other afterwards. By making snap
fully standalone, you can build a light client protocol on top which only leeches, never serves. That's super nasty on the nodes that take the extra hit. So I want snap
to only support running for full nodes that play nice and support each other.
EQAxAe0EqvANW9ExDuxgA8HqAD3BWE_bP-DdVlIQwlK_SifB
This is a work in progress to permit discussion, don't merge!