Light Clients in JS

[pyramation]

@jackzampolin sparked a great discussion around light clients in JS https://twitter.com/jackzampolin/status/1595855446979465216

Since this likely will be a new project, I think it's good to put our minds together about the requirements and specs so us JS folks can chip in to build this! I'm a bit of a cosmos-sdk/Go newb, so would def need some guidance, but I can definitely contribute and craft TS/JS to help bring this to life.

cc @tac0turtle @webmaster128

[jonator]

Also IBC relayers

[pyramation]

Yep! @jackzampolin mentioned that https://github.com/confio/ts-relayer has some pieces of the light client. So good point, and yes, this is also a part of this discussion 👍

[jonator]

Perhaps run this client-side relayer-as-a-service (RaaS) within browser wallet extensions, whilst still working in a window and node context? In an extension, a window could be closed and the packets could still be relayed.

[pyramation]

@hxrts shared this one https://github.com/nomic-io/js-tendermint

[amaury1093]

Has anyone tried compiling https://github.com/informalsystems/tendermint-rs/tree/main/light-client to WASM?

Seems like it's well maintained, and maybe we don't need a light client in pure JS, just a JS wrapper around it with nice API.

[webmaster128]

We worked towards that and got some help from Informal but then the project stopped for a reason I don't remember. Probably priorities. Compiling to Wasm is not the problem. Bundling it as part of a library like CosmJS that has to support a variety of execution environments is hard.

As far as I can tell, ts-relayer currently does not verify block headers.

Yeah, could and probably should be done.

[pyramation]

I think this was done?
https://github.com/informalsystems/tendermint-rs/tree/main/light-client-js
@hxrts shared this with me today ^^

[pyramation]

if this is the case, I'm wondering which features we can leverage, and which tools we can make it an option for (cosmos-kit, cosmjs, etc)

A lot of folks are using public RPC endpoints, not sure if it would replace those, but wondering what this client could replace, and then we should add it as an option to as many FE tools as possible

[webmaster128]

The primary issue I see right now is that the queries you can do with light client proofs are extremely limited. You can pretty much only get a raw key-value pair from the database. This only works for data that is directly accessible by a well defined database key. For IBC this works as those keys are part of the IBC spec. We had a light client working in CosmJS to query bank balances but then the database layout changed, breaking the query. So first of all we'd need to agree if a storage layout of modules is public or private and clarify stability guarantees around it. Then the question is how much you can actually query directly. I'd assume many of today's queries are not possible to prove as they transform data from the database or collect data from different sources. Then you are back to {g,}RPC queries for most of the stuff.

[jonator]

IMO it would be plenty if we're able to verify proofs for some of the core modules, such as bank or staking. Then we could start working on making other queries provable as needed. But, I'd be amazed if we could achieve provability for all queries in the short term.

[tac0turtle]

the biggest problem with not only our light client but with almost every one out there is they still rely on RPC. saying a light client solves the problem is only part of the problem, we should get away from relying on RPCs. We know people that use light clients, which only support rpcs connections, usually grab the first few rpcs they see. These could be from a centralised place or a validator but we run into the same issue but have now added a layer of abstraction.

To get around this issue, we should add light clients into the p2p layer of tendermint so we can make tx submission and querying of the data work in a fully trustless manor. I tried to push tendermint in this direction years ago but gave up because there wasn't interest and I wasn't willing to continually fight an uphill battle.

[pyramation]

I think this is the question I'm getting at here and here, seems that @tac0turtle has the key knowledge I'm looking for.

[aaronc]

Better support for light clients has been something I've had in mind for a while and was one of the motivations for transitioning to protobuf.

Beyond having the actual light client, a huge part of this is the ability to decode the state layout which depends on the schema of modules. Currently there is no schema description layer for most modules.

The ORM in the SDK was created with this in mind: https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-055-orm.md. It describes the layout of module state in protobuf files and also provides a better API to build modules. The natural evolution of that would be JS library support for light client proofs based on these schemas. This would allow client side proofs on basically any query.

[jackzampolin]

So my thoughts on JS light clients:

• If we can have a local storage light client that pulls headers from multiple rpc providers periodically we can provide nice security guarantees to end users. Having this as a piece of the core stack would also make it easy for wallets and other frontends to integrate. This can be a key differentiator for the cosmos ecosystem.
• If we are storing the light client data in local storage maybe we could also provide per block data to provide more robust event and transaction streams than are provided over websocket. This should also increase single page performance.
• If this primative exists could be a shared resource between multiple different wallets/frontends and should provide a better UX for cosmos chains generally.
• To @tac0turtle's point on RPCs this would reduce rpc load and more broadly spread that load. Also doesn't preclude reliance on some indexed data but should be able to increase user trust in providers of that data

[jonator]

Given your mention of extensions it's likely you agree: thoughts on making it easy (via importing a package) for extensions to maintain an instance of this light client verifier? Then, we'd have access to more and longer-lived memory then localstorage. Then, proofs can be requested via some standardized API into the extension, or via forwarded access to this instance. Ideally, the light client verifier would also be usable within the browser window context. @Thunnini

As for the frontend, at least on Osmosis we'd like to inform the user the queried data has been proven to be consensus-state-accurate, to help advertise this Cosmos-differentiator.

[jackzampolin]

I think you get my idea @jonator!