LCD Purpose

[jackzampolin]

Picking up discussion from: #2352

A decision was made on that issue to continue with the current format of the LCD (disconnected process, w/ proofs on balance endpoint), and finalize the interface. That work has been roughly completed, and leads to questions about the purpose of the lite client daemon (stargate?)

Currently the lcd contains the following pieces of functionality:

• Lite client proofs
• Queries for the gaia state machine
• Automate-able key generation, storage, and utilization

I propose splitting up those pieces.

Proofs

Move work on lite client proofs to developing a specification for emitting those proofs from tendermint and then verifying them from a client language (javascript). The goal of this work would be to make the lite client functions of our chains no longer dependent on a go binary, and usable by client developers. I think we should work heavily with the Voyager team and other client applications (wallets) in specifying this functionality.

Queries

Move the queries in the interface exposed by gaiacli rest-server to gaiad and allow enablement/disablement of that new interface via config file/flags on gaiad.

Open question: should the transaction generation endpoints be exposed on this interface? Maybe in generate-only configuration?

Keys

Move the /keys routes and any signing functionality into a process. The user we are trying to serve here is a high volume user who needs to manage a number of keys in an automated fashion while rapidly generating and sending transactions.

[alexanderbez]

Automate-able key generation, storage, and utilization

How does gaia lite facilitate this? Isn't this the CLI binary?

---

I like the note on queries -- I think that makes sense.

[alexanderbez]

/cc @jaekwon @cwgoes @ValarDragon @sunnya97

[jackzampolin]

@alexanderbez

How does gaia lite facilitate this? Isn't this the CLI binary?

It puts a rest interface over the keybase which is easier and more elegant to program against than using the CLI for the same operations.

[cwgoes]

Move the queries in the interface exposed by gaiacli rest-server to gaiad and allow enablement/disablement of that new interface via config file/flags on gaiad.

This doesn't easily allow lite client proofs; that's the primary issue.

We could move the "querier" logic into a client-side library and possibly add logic in Tendermint for easy batch queries and range queries (to make large scans faster).

[alexanderbez]

@cwgoes can you elaborate please?

[cwgoes]

@cwgoes can you elaborate please?

Sure, sorry if that wasn't clear.

This doesn't easily allow lite client proofs; that's the primary issue.

If we reformat the data (e.g. in JSON) before returning it to the client, we can't prove it, since the JSON-encoded data isn't actually in the blockchain state. Furthermore, if we do complex things like scanning and filtering, we can't prove to the client that we (the node) filtered correctly - we could return results not matching the filter or fail to return results matching the filter (e.g. proposals in status "voting period").

We could move the "querier" logic into a client-side library and possibly add logic in Tendermint for easy batch queries and range queries (to make large scans faster).

If the "querier" logic (which is just an API wrapper / data reformatting layer) is client-side, then the nodes can send along full lite-client proofs which the client-side library can verify, before reformatting the data as JSON (so this requires client-side Amino) or applying any other transformations.

Does that help @alexanderbez?

[alexanderbez]

Perfect! Makes complete sense.

[jackzampolin]

Closing this issue. Please holler at me if you want to discuss.