Light Client RPC Service

[brapse]

Updated to reflect the conclusion of the discussion in comments and slack

The light client fetches headers/validator sets from other nodes to perform verification. The light client should also make those headers/validator sets available to the network through an RPC service.

The goal here is to create an RPC service operating in a separate runtime with access to it's own light client handler similar to:

tendermint-rs/light-client/examples/light_client.rs

Line 155 in 1df3ac3

let mut handle = supervisor.handle();

This issue should exclusively include endpoints for:

• /status: returns local status information, like the latest height, latest block and valset hashes, list of of connected full nodes (primary and secondaries), etc.
• /state: returns the latest header, commit, and validator set

Follow up issues can address potential further improvements.

[ebuchman]

The goal here is essentially a light-node: a process that syncs the blockchain using light-client verification and exposes an http API for interacting with the blockchain (ie. queries, transactions). Such an API could be used to build local applications that read/write to the blockchain securely without needing a local full node.

In Go, we have tendermint lite, which runs a light node that exposes the same RPC API as the full node, essentially an http proxy that does light client verification. There's also the gaiacli rest-server, a similar idea but with an application specific REST API (eg. for accounts, staking, governance etc.) rather than the RPC exposed by Tendermint full nodes (which can do raw abci queries, but doesn't know anything about accounts, staking, governance, etc.).

To start, we should expose two http endpoints in the light-node process:

• /status: returns local status information, like the latest height, latest block and valset hashes, list of of connected full nodes (primary and secondaries), etc.
• /state: returns the latest header, commit, and validator set

Once we have the basics, we can draft a longer term plan for this API, and consider something like the complete tendermint lite proxy in Rust, which would effectively wrap our tendermint-rs RPC client with light client verification. Note for full compatibility we'd have to support queries for historical heights, which could require running the light client backwards.

[liamsi]

Cross posting this here for @xla:

You guys asked me last week what methods the rpc would need from the light client. As far as I can see it’s only one method:

• given a target height h , either return the stored result, (if still valid) or, run the light client to that height ( h might potentially be in the past)

It’s needed by the endpoints: /blockchain, /block, /block_by_hash, /block_results, /commit, /tx, /validators, /consensus_params, /abci_query, (some of them take a height param and that should trigger the light client to catch up or request a past height if necessary)

These are the routes that need to be implemented:
https://github.com/tendermint/tendermint/blob/74cae49c3b1eadb1355a0a23ae6bb81545fb08ea/light/proxy/routes.go#L12-L50

[ebuchman]

Just a note that we probably shouldn't start with a full proxy yet as a lot is likely to change this year in the Go RPC, and we might want to wait for that.

I was thinking to start we would just expose the two endpoints I outlined above, one to get some status info and one for the latest state.

We could extend the latest state one to also return previous state or to fetch state it doesn't have. But I think we should hold off on the full proxy for now.

[xla]

@brapse Two clarifications inline.

The light client should also make those headers/validator sets available to the network through an RPC service

Probably unnecessary nit-picking, but isn't that the we want the light node to make these available through an RPC API?

The goal here is to create an RPC service operating in a separate runtime with access to it's own light client handler similar to:

Which requirements dictate the constraint for RPC to run on a separate runtime.

[brapse]

Right, the light node naming here makes sense.

The light client runs in its own thread as to not necessarily block the RPC or Relayer when doing long verification runs.

[xla]

/status: returns local status information, like the latest height, latest block and valset hashes, list of of connected full nodes (primary and secondaries), etc.

To proceed more information is needed for the following points:

• latest height: which height are we referring to? ideally we can point to a specific point in the system where this height would come form
• latest block: is this not covered with /state? Or are we interested in surfacing even non-trusted or unverified blocks here?
• valset hashes: Again does that no overlap with /state which would expose that?
• connected nodes: This seems straightforward and might be just surfacing the contents of the Supervisor peerlist.

Any other thoughts appreciated as well.

[ebuchman]

So /state should return the latest trusted full LightBlock data structure. But /status should return only a couple of elements from that as a quick reference. Those elements are (where light_block is what you would return in /state):

• height (ie. light_block.signed_header.header.height)
• block hash (light_block.signed_header.header.hash())
• valset hash (light_block.signed_header.header.next_validator_set_hash) - note it's the next_valset because that's the latest valset we trust, even though it may not have signed a block we trust yet ...

And then the connected nodes aren't in a light block but would come from the supervisor.

[xla]

@ebuchman Thanks for the clarification, I'm not quite sure what the benefit is of the mostly duplicated data, except the next_val_set_hash I guess. Thought the /status endpoint is more operational and shows some of the internal state.

On the upside the /state endpoint is on its way and implemented to your understanding.

[ebuchman]

what the benefit is of the mostly duplicated data

It's a snapshot of the latest state. Similar to the way the /status endpoint on tendermint nodes returns hashes from the latest block. It's so you don't have to consume and traverse a much larger data structure but can just see directly a reference/summary of the latest state from the /status endpoint

[brapse]

The /state endpoint landed with #366 and we are just waiting for an implementation of /status ☺️

[liamsi]

@ebuchman for the /status endpoint:

/status: returns local status information, like the latest height, latest block and valset hashes, list of of connected full nodes (primary and secondaries), etc.

It's probably sufficient to return a list of PeerIDs for the list of connected full nodes? Is there any benefit in highlighting the primary? My currentl thinking is that the rust struct returned by a yet to be created handler will look like this:

pub struct LatestStatus {
    pub height: Height,
    pub block_hash: Hash,
    pub valset_hash: Hash,
    pub connected_nodes: Vec<PeerId>,
}

Am I missing anything?