gRPC proof support

[colin-axner]

Summary

gRPC calls should support returning proofs for the query.

Problem Definition

Currently gRPC just uses the module's keeper to return the desired information. No proofs are generated for the query. In IBC, we need to generate proofs for almost every interaction so the current workaround is to essentially create wrapper functions around our gRPC calls that do ABCI queries and inject the proof into the response. It is quite redundant to do the same query twice via different mechanisms and for IBC, gRPC is unnecessary without proofs.

I imagine users might want to do a gRPC via an untrusted node and verify the returned proof via their light client.

Proposal

One probably shorter term solution is to expose a function that can generate proofs based on a key and value. That way if I do a gRPC to query object V with key K, then I'd like to be able to call GenerateProof(K, V) and get back a proof and height for the proof.

I think there has been possible discussion of adding some sort of proto headers to handle proofs, but I have no idea how this would look. I just wanted to open this issue to begin discussion around this topic since I couldn't find an existing issue.

---

For Admin Use

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

[aaronc]

Great thanks @colin-axner. Yeah, I previously mentioned the idea of doing proofs via headers. It's probably a fair amount of work, but I think it can be done for at least simple key/value queries. Proofs that for index scans would be more involved but are also I think doable. The one big challenge is making sure the protobuf encoding of the response doesn't change at some intermediate serialization step because the proof depends on the serialized store bytes.

[colin-axner]

#8116 work-around to generating proofs via keepers seems relevant

[colin-axner]

Are there any labels that can be added to get this issue tracked and potentially assigned to someone? It might take some investigation to see what's possible and what the ideal solution looks like.

I think this is a very useful feature to encourage gRPC usage

[aaronc]

I have actually been trying to work on a design for this. It's related to some other work that's being tracked. Will label this appropriately anyway.

[yvesmessy]

@aaronc I'm with Cudos.org and we're working on Proof of Compute for grpc queries on chain, would love to sync up on this if you're open to it. How do we get involved?

[aaronc]

The details of how this will work are spread across a few topics (ADR 040 and the table store discussion) and aren't really written up succinctly... so I'll probably have to do that at some point soon. In the meantime maybe you can share more details about your use case @yvesmessy ?

[clevinson]

We're putting this in the icebox at the moment, as this will likely need to be coordinated with the introduction of the ORM module, likely with some updates (as discussed in #9237)

[shravanshetty1]

#8116 work-around to generating proofs via keepers seems relevant

Doesnt seem to work in 0.43 the multistore provided is not queryable. Could you suggest another workaround to get proofs for key value pairs?
@colin-axner any suggestions?

[shravanshetty1]

The work around I am using currently is, injecting an instance of baseApp into my keeper and querying it. Seems to work very efficiently.

[tac0turtle]

I think there is a simpler way of handling this. We can do it by exposing a abciQuery query on grpc but there isn't a need to route it through tendermint. The downside is the user needs to know the keys but this is worthwhile trade off. In talking with @jackzampolin in regards to the go relayer he agreed. It would be good to hear from @adizere and @andynog for Hermes. Would this fit their needs?

[aaronc]

We should expose get key value pair with proof over grpc. When modules migrate to the orm they can have a full featured client verifying proofs transparently because the key value format will be specified for clients. Meaning bank/GetBalance can work just like it does now but can optionally prove it

[tac0turtle]

In this scenario would the query be wrapped in a message with prove as a Boolean ?

[aaronc]

In this scenario would the query be wrapped in a message with prove as a Boolean ?

There are many ways this could happen. So a boolean in the message or a prove header (like we do with height) could work with grpc. The proof could also be returned with headers or in the response message. In this scenario though, grpc is still just returning proof data, not doing the proving so there's more complexity.

The ideal scenario might be that the client has an orm implementation (with golang this is trivial) and they set a prove option on Get calls. The full ORM could work client side as long as there's some remote access to the kv store for queries, iterators and proofs

[adizere]

We can do it by exposing a abciQuery query on grpc but there isn't a need to route it through tendermint. The downside is the user needs to know the keys but this is worthwhile trade off.

The current way Hermes fetches proofs is through ABCI and indeed we need to know the key (called a path in IBC). The design you proposed does fit our needs.

[tac0turtle]

The ideal scenario might be that the client has an orm implementation (with golang this is trivial) and they set a prove option on Get calls. The full ORM could work client side as long as there's some remote access to the kv store for queries, iterators and proofs

im hesitant to hearing something like this. Ideally the client can just use grpc as is without having to build a copy of orm on their own.

[aaronc]

The ideal scenario might be that the client has an orm implementation (with golang this is trivial) and they set a prove option on Get calls. The full ORM could work client side as long as there's some remote access to the kv store for queries, iterators and proofs

im hesitant to hearing something like this. Ideally the client can just use grpc as is without having to build a copy of orm on their own.

But how will gRPC clients know how to verify proofs then? Proofs depend on store encoding which is completely opaque to clients. Without orm, you need to read keys.go and keeper methods directly to know this

[tac0turtle]

closing this as abciQuery is supported on grpc for proofs and with things like orm and collections this becomes easier