Suggestion: Play Forward Ledger

[JoelKatz]

Currently, when a server loses sync with the network, it has to simultaneously try to re-synchronize with the network and fetch all the ledgers it missed. The current design requires the server to first synchronize with the network and then work backwards to fetch what it missed but then work forwards to rebuild any missing intermediary ledgers.

We propose that the design be changed to support a fetch operation that fetches a ledger’s header and all the transactions in the ledger in order. This will allow a server to play forward from the preceding ledger to the queried ledger with minimal network traffic. When a server loses synch, it can then collect validations to determine the ledgers it needs to go forward from its last-validated ledger to the current ledger.

This has three advantages. First, it provides greater protection from hostile majority attacks because the server only obtains full ledgers by building them locally. Second, it allows the server to conserve network and CPU resources by only having to play the ledgers forward, rather than backwards and then forwards. Third, it reduces the load the server places on other servers and permits it to stop being a burden and resume helping other servers more quickly.

This post is one suggestion for an enhancement to the XRP Ledger. See this post for context:
https://www.xrpchat.com/topic/33070-suggestions-for-xrp-ledger-enhancements/

You can find all the suggestions in one place here: https://coil.com/p/xpring/Ideas-for-the-Future-of-XRP-Ledger/-OZP0FlZQ 

 

[mDuo13]

Seems like a good optimization with minimal user-facing changes. It's not flashy, but I think it would be great.

[Sukrim]

In addition a "header first sync" mode would be nice:

Download ledger headers down to 32570 and from there start populating transaction and accountstate tries instead of doing a depth-first approach to fetching history.

Also: https://github.com/ripple/rippled/issues/1343 (submitted in 2015...) (Edit: Also: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki - and I'm sure Ethereum has something similar too)

Edited October 2, 2019 by Sukrim

[JoelMcD]

Makes good sense. Reading the suggestion reminds me of the engineer's perspective when observing a glass half-filled with water... the cup is twice as big as it needs to be.

Edited October 2, 2019 by JoelMcD