New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstract away Tendermint height / IAVL version offset #6567
Comments
Suggestion by @alexanderbez - include both heights as metadata. |
Including both heights directly in the query response would require a change to ABCI, since the store query returns I could change the abci struct to include both heights if that's the preferred solution. Though I think it makes more sense to make the ABCI query response return the tendermint height as opposed to IAVL height |
Hmm, that's annoying. Are we planning any changes to ABCI we could bundle this with? I still think both heights are preferable. |
Can you please clarify what do you mean by Tendermint commit height and by IAVL height in this context? Returning two heights is a potential source of confusion (and bugs) as we have trouble to figure out clear semantics even with one height :) |
For purposes of verifying proofs, the light client (e.g. in IBC, but also just running locally) needs to reason about the block height at which state updates (e.g. packets sent) executed during height |
I am also not clear. From the relayer pov, in one possible implementation, currently:
With the new proposal I believe things would need to change:
Not sure I got this right but the new 1) is a bit of a pain. And still needs to be adjusted for other types of chains. |
actually it's ok, I think it's just a small change in our design. |
Yeah, I suppose due to the events we can't really avoid height offsets. Maybe this isn't worth doing. It would be nice to at least abstract this somehow though... |
I don't think any of the proposed solutions involving changing the actual handling of the Query function. The only difference is upstreaming the I do think this is a problem worth dealing with (even if it involves breaking some api and waiting for it to be included in a later release). This is because relayers are not going to want to add handlers in for specific ABCI applications. Doing I think returning the Query height as Adding another field to abci might make sense (block height and proof height) if it was common for ABCI apps to have block heights different from their proof height in storage. If this is not the case, it would seem a little strange to me to add a field just to satisfy tendermint characteristics. However, given the options, I think this would be the best approach and would give ABCI applications slightly more flexibility in how their protocol functions |
To clarify |
From my understanding, So a proof generated for block |
I need to test this, but I believe the events are associated with the ABCI height (ie, the height in which the state gets committed), not the IAVL height. This would make things even easier for relayers, not the options mentioned above. Not fully certain, I have to test this is the case tomorrow. |
The path forward here isn't yet clear; let's come to consensus on this in a meeting & then tackle it again once we've updated the relayer. At minimum, we should abstract the height differential somewhere so that |
One idea would be hiding +1 from the user, i.e., pushing this responsibility to the server side (Tendermint). So the flow would be: 1) ABCIQuery(p, h) which returns the result and the proof p that is related to AppHash after block at height h is executed, and 2) GetHeaderToProve(h) that would return header at height h+1. In this case a user (for example relayer) does not need to understand Tendermint blockchain internals (+1 offset). The potential issue would be the fact that GetHeaderToProve would potentially block until the block at height h+1 is committed. |
For now, let's abstract this |
We should do this as soon as we start updating the relayer. |
Return the Tendermint commit height instead of the IAVL height on proof queries.
This will greatly simplify off-by-one issues on proofs in the relayer & other light clients.
cc @AdityaSripal @colin-axner @fedekunze
The text was updated successfully, but these errors were encountered: