search

XRPLF / rippled

Decentralized cryptocurrency blockchain daemon implementing the XRP Ledger protocol in C++
https://xrpl.org
ISC License
4.54k stars 1.47k forks source link

Why does the ledger_index start at 0 every time I restart the node? #4335

Closed COLUD4 closed 1 year ago

COLUD4 commented 2 years ago

Why does the ledger_index start at 0 every time I restart the node? 截屏2022-11-04 15 16 34

intelliot commented 2 years ago

Are you trying to sync with a known network (such as Mainnet or Testnet), or are you running in stand-alone mode?

Either way, when a server is first started, it will automatically run consensus on its own and close ledgers over time. However, these ledgers won't necessarily be validated - that depends on the validators you've chosen (and configured). Until your server syncs with the network, your server will maintain a local ledger that has no relation to the one that the trusted validators are validating. If your server meets the requirements, your node should usually sync in less than 30 minutes.

nbougalis commented 2 years ago

When the server restarts, it does not know the state of the network that it's supposed to connect to. It internally creates a new genesis ledger (which is, of course, not validated and it's just meant as an internal scratchpad) and continues updating that while it's trying to catch up to the network. Once it does, the ledger chain it internally created is discarded and it switches to the validated ledger, according to its UNL.

As to why... well, that's because how it was coded. It could have been coded differently (and it could be changed now) to re-load the ledger ledger it observed as validated and attempt to continue from there (indeed, that is what fast_load tries to do and what other changes, like forward replay, will do).

Generally, the existence of this ledger chain during startup should be thought of as an internal implementation detail.

intelliot commented 1 year ago

No changes specific to this issue are required in rippled, so we're closing this issue. But we did open an issue for xrpl.org for documenting this behavior. https://github.com/XRPLF/xrpl-dev-portal/issues/1681