ibc
ibc copied to clipboard
cosmos
Allow Timeout UNORDERED channel without proof of absence
Some chains do not have ability to provide proof of absence due to their choice of state commitment. This feature would allow a negotiation at the connection level, to specify that a chain would like to prove a timeout using a proof of existence rather than a proof of absence.
Requirements:
- Chains must enable this feature during version negotiation in the connection handshake
- The receiving chain must have the ability to execute "per-block" logic and write to the provable "ibc" store when a timeout for a packet has been reached.
- The sending chain must use the same timeout proof path as in the normal case, but will be proving the existence of a special "absence receipt" rather than proving nonexistence.
The receiving chain must have the ability to execute "per-block" logic and write to the provable "ibc" store when a timeout for a packet has been reached.
How can it write to the store when a timeout for a packet occurs for a packet it has never received? I mean, I guess we could just submit the packet too late, force an error/timeout response to be written to the store, then use that rather than timeout.
But if it needs the remote chain to know about the existence of a packet to work, then I think there are simpler (less disruptive) solutions.
Ahh yes you're right. Sorry wrote this up with just an initial sketch of an idea. Of course, the receiver chain cannot know the timeout of a packet which it has not yet received.
So we cannot use per-block logic to do this. However, I think the rest of the scheme is salvagable like so:
If the packet is received after the timeout has been reached, rather than just aborting transaction; we write the absence receipt into the store and return.
Everything else works just the same.
Thus, for a chain that does not have absence proofs, a relayer need only attempt a RecvPacket on the receiver chain to fill in the absence receipt on the receiver and then the sender can prove the timeout.
Does that sound like a simple solution to target for relayers? cc: @jackzampolin @adizere
If the packet is received after the timeout has been reached, rather than just aborting transaction; we write the absence receipt into the store and return.
That is a good change in any case. It is minimal overhead and allows non-Tendermint chains to prove timeout.
Thus, for a chain that does not have absence proofs, a relayer need only attempt a
RecvPacketon the receiver chain to fill in the absence receipt on the receiver and then the sender can prove the timeout.
This slightly changes the timeout liveness as previously (with proofs-of-absence) timeouts still work even if the relayer cannot submit any transactions to the destination chain (e.g. due to censorship or gas markets). I think it's probably alright but it's worth noting. However, for ordered channels we can do something better - if the current sequence is less than the packet sequence, and the packet has not been received before its timeout time and/or height, it can be considered timed-out (and a proof of the current recv sequence is enough to establish this) - I think this may be worth doing differently for different channel types because we achieve a somewhat better liveness property. Thoughts?
Yes, we actually already do this. ORDERED timeouts already work without absence proofs
So the above proposal is only relevant for UNORDERED channels
@AdityaSripal your proposed solution here (i.e. relayer tries to recvPacket and then relays proof of failure due to timeout) should be fine and could also potentially be non-breaking (we have 2 codepaths for timeouts and this is just an additive protocol change)
Does that sound like a simple solution to target for relayers? cc: @jackzampolin @adizere
Yes. For Hermes the situation should be similar to what Jack sketched above.
Yes this is non-breaking from a protocol point of view since it's just an additional feature.
One thing to note, is that I believe currently a relayer will not recv a packet that has already timed out. But now, on certain channels; the relayer will need to do so first before they can timeout the packet. This shouldn't be very difficult, just pointing it out as work that will need to be done to make this feature viable.