Skip to content

Timeouts

Blockchains may become incapable of processing transactions for a vareity of reasons. These might include liveness failures, which can occur when the state transition function becomes unable to produce new blocks, consensus faults, transaction fee spikes that make transaction execution unprofitable, or a doomsday scenario such as a nation state sanctioned attack.

Regardless of the reason, if the destination becomes incapable of processing incoming ISMP requests, the framework provides a timeout mechanism. This feature allows for the safe reversion of state changes on the source chain that were executed prior to dispatching the request, as if no issue ever occurred.

PostRequest, PostResponse, and GetRequest all have the ability to time out due to their timeout_timestamp value. This value stipulates the lifespan of a message. A PostRequest and PostResponse will time out when their destination's host.timestamp() surpasses the timeout_timestamp. This asserts that the destination has indeed not processed the relevant messages. Conversely, a GetRequest times out when its source's host.timestamp() surpasses the sending chain's timeout_timestamp.

Handlers

The ISMP framework exposes a handler that allows users/relayers submit timeouts, alongside the neccessary state proofs required for verification so that they may be executed by IsmpModuless

handle_timeouts

/// A timeout message holds a batch of messages to be timed-out
pub enum TimeoutMessage {
    /// A non membership proof for POST requests
    Post {
        /// Timed out requests
        requests: Vec<Post>,
        /// Non membership batch proof for these requests
        timeout_proof: Proof,
    },
    /// A non membership proof for POST responses
    PostResponse {
        /// Timed out responses
        responses: Vec<PostResponse>,
        /// Non membership batch proof for these responses
        timeout_proof: Proof,
    },
    /// There are no proofs for Get timeouts, we only need to
    /// ensure that the timeout timestamp has elapsed on the host
    Get {
        /// Requests that have timed out
        requests: Vec<GetRequest>,
    },
}
 
/// Handle timed out messages
pub fn handle_timeouts<H>(host: &H, msg: TimeoutMessage) -> Result<(), Error>
where
    H: IsmpHost,
{
    // .. implementation details
}

The handle_timeouts is used to notify onchain IsmpModules of outgoing requests or responses that have now timed out. A relayer will construct the TimeoutMessage which holds a batch of these messages, and their relevant proofs. The handler will perform the following operations

  • Assert that the state machine's consensus client is not frozen
  • Assert that the configured challenge_period for the StateCommitment has elapsed
  • Assert that the messages have indeed timed out
  • Assert that the claimed messages are known by the host
  • Assert that the relevant state machine's time has advanced past the timeout_timestamp of specified messages.
  • Assert that the relevant non-membership proofs for the messages are valid
  • Finally dispatch the timeouts to the relevant IsmpModule::on_timeout and delete the commitments for the outgoing messages.