Timeouts two ways

[hxrts]

There are two remote timeout constructions we discussed. The first of which needs to be avoided, the second we need to be careful with.

1) Program starts on Chain A, advances to Chain B, and you want to reason on Chain A whether remote execution timed out in order to initiate a continuation.
What you DO NOT want to do here is use the Chain A clock time as a proxy for the Chain B clock and presume that the absence of a timeout delivery packet implies a remote time out occurred. This could lead to a situation where the packet is delivered and accepted on Chain B, but due to clock drift or network latency the logic on Chain A draws the wrong conclusion. Ex post inference about remote evaluation results must be avoided.

2) Program starts on Chain A, the relayer goes down for some indefinite amount of time, after which it restarts message delivery. When the packet is delivered on Chain B you want to reason about timeout expiry.
This is the scenario relevant to Keyne's PR, and the construction we're using is acceptable for now, however it's incomplete in its current form, which is why I'm writing this up. In this case we are using the Chain A clock to construct a timeout threshold that will eventually be validated on Chain B with the Chain B clock. Here the clock drift between Chain A and Chain B could cause the timeout threshold to be set incorrectly, however the result is less catastrophic. Worst case, we're creating uncertainty as to whether or not the execution will occur on Chain B (not a runtime exception of the program). Ex ante inference about remote evaluation conditions is ok, so long as we set the evaluation conditions correctly. IBC provides a similar timeout facility, however IBC also has the notion of light client updates, which act as a heartbeat, committing to monotonically increasing timestamps from the remote chain. Client expiry then bounds the clock drift between chains, thereby preventing long-range attacks.

Takeaway is we're going to want something analogous to client updates and client expiration when we get to state proofs.