Question: Re-set the height of ChannelEvents::WriteAcknowledgement

[livelybug]

Hello,

I have a question about setting the height of event ChannelEvents::WriteAcknowledgement.

After getting the packets that have been acknowledged on the destination chain but still have commitments on source chain, the corresponding events are retrieved here.

The events are of type ChannelEvents::WriteAcknowledgement, which already contain property Height.
I am confused why the height is set again here? Is it possible that the height is missing under some scenarios?

Thank you

[seanchen1991]

Hello, it turns out that the reason why the height of IbcEvents is set (this is done for all variants of the IbcEvent type, not just WriteAcknowledgements) even though each event already has a height field is because it's actually pulling double duty. Essentially, at different points in time during the event lifecycle, the way the height field is used changes.

When events are created, their height field is populated with the height at which they were produced. Then, if events are retrieved via a query, such as here in the target_height_and_send_packet_events method, which looks back in the chain's history to scan for un-relayed packets that need to be sent, then those retrieved events' heights actually get updated with the height at which those packets were queried for.

As an example, if we have un-relayed events at height 5 and 9, and we query at height 10 for un-relayed packets in the previous 5 blocks, then we'll find the events at height 5 and 9 that need to be relayed. Once we retrieve those two events, their heights are then updated to 10 (the height at which we queried for them). This is because when we send these packets to the destination chain, all we care about as far as the heights are concerned is when those heights were queried for when it comes to proving to the destination chain that these events are trusted.

Proving an event involves (i) querying for proofs, which the relayer does relative to the height at which it performed the query, and (ii) building a client update message to enable verification of proofs on the destination chain. Both of these steps are done relative to the query height (10 in our above example), so ultimately, the height at which events were created isn't really relevant anymore at this stage of the event lifecycle.

Hopefully that makes sense! 🙂

[livelybug]

Thank you, @seanchen1991 , for the detailed write-up.

so ultimately, the height at which events were created isn't really relevant anymore at this stage of the event lifecycle.

I think the logic of height in "event" verification is different in Substrate. To verify the "event" of a Substrate chain, the height at which events were created is used instead of the querying height. But so far we don't encounter height discrepancy in Substrate "event" verification. To dive deeper and reply if any finding.

BTW, the "event" is quoted because based on beefy protocol, on-chain storage is verified instead of event.

[livelybug]

To verify the "event" of a Substrate chain, the height at which events were created is used instead of the querying height.

I have to correct myself: Both the height at which events were created or the height greater than the block height at which events were created can be used.
Assuming a value is written to on-chain storage written at block height M, the state root of block height N can be used to verify the on-chain storage on block M, if N >= M.
Because the "querying height" >= "height of writing on-chain storage", so corresponding the verification doesn't fail due to height discrapancy.