node: lean archival mode

[tac0turtle]

Summary

In Tendermint there are various types of nodes: Validator, full node, seed node. Full nodes can mean a few things because blocks can be pruned. While these nodes are useful there is a use case for a full archival node that is minimal in reactors. This will become useful when data retrievability becomes a more apparent issue.

Problem Definition

This is not a problem that needs solving but IMO provides usability improvements.

Proposal

Define an archival node mode. This mode will only run the blockchain reactor, light client and a simplified rpc. There will be no application (ABCI) so verification of incoming data will have to be through the light client.

Node operators would still be able to query and submit transactions directly to the application via the Light Client.

This node could be its own separate repo not by us, but as we move things to internal, the implementation will begin copy pastaing internalized pkgs.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

Seems odd that we call it a full archival node, yet it relies on a light client, or are you proposing we remove the "full" nomenclature from this mode?

[tac0turtle]

are you proposing we remove the "full" nomenclature from this mode?

Yes, it would not be a full node.

case for a full archival node that is minimal in reactors

I see the confusion in this sentence now. I meant full as in full state of the chain. A different name would be needed.

[cmwaters]

I'm generally in support of this. It seems to make sense with the introduction of state sync and block pruning where we are likely to see only a few archival nodes that keep full history whilst most nodes only keep the last x amount of blocks.

The blockchain reactor currently already has it's own form of verification (and could be possibly adopting the light client form of verification), so is having a light client really necessary?

A few other questions I have:

• Would the Blockstore RPC support the same endpoints as a full node?
• Would we want archival nodes to be recognised distinctly from other nodes (so other peers know specifically which peeers to add to their address book for syncing)

As a final side question: does Tendermint want to have any checks in place to avoid the scenario where the last full node with complete history from genesis prunes all it's history essentially severing the gap between genesis and the current height resulting in no new nodes being able of join the network

[tac0turtle]

The blockchain reactor currently already has it's own form of verification (and could be possibly adopting the light client form of verification), so is having a light client really necessary?

It could use the current form of verification but if the blockchain reactor moves to light client verification it would make sense to go with that instead of having another reactor.

Would the Blockstore RPC support the same endpoints as a full node?

Yes, the ideal situation would be the same block related endpoints so integrators could switch between nodes easily.

Would we want archival nodes to be recognised distinctly from other nodes (so other peers know specifically which peeers to add to their address book for syncing)

This is the long term goal, but we currently do not support service discovery, since this node is running with lower consumption we could increase the total inbound and outbound peers. This node will only expose the blockchain reactor channel so other nodes will know what it offers.

does Tendermint want to have any checks in place to avoid the scenario where the last full node with complete history from genesis prunes all it's history essentially severing the gap between genesis and the current height resulting in no new nodes being able of join the network

This goes into data retrievability (#7897). I have put some thought into this but it is too early to design things, IMO.

[chengzhinei]

@marbar3778

There will be no application (ABCI) so verification of incoming data will have to be through the light client.

I have a question, how can we get the application state while having no ABCI? My understanding is that we get the state through DeliverTx.
Or, the BlockStore only store the block without the state？