Blockhash/stateroot-based ISMs

[nambrot]

There are a lot of projects who focus on proving origin chain block hashes or stateroots on a destination chain. Examples are:

• Optimism L2 stateroot oracle on L1 (https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/L1/L2OutputOracle.sol#L13)
• Hashi has adapters for various blockhash oracles (https://github.com/gnosis/hashi)
• Telepathy makes available block hashes and state roots (https://github.com/succinctlabs/telepathy-contracts/blob/main/src/lightclient/LightClient.sol#L56)

Hyperlane ISMs could also wrap these mechanisms with a slightly different message trigger format (via #2442) to continue to provide the best story for allowing developers to opt into security mechanisms with improved trade-offs as they become available (while implementing the same handle method).

A key question would be how messages are expressed when not enqueued on the origin chain merkle tree. Should arbitrary events be supported? Arbitrary state reads? How would replay protection work?

[nambrot]

Use cases for this would be accessing oracles as well as proving asset ownership on the remote chain

[nambrot]

Additional context here is that hyperlane validators attesting to block hashes would allow them to be secured by things like Axiom on the origin chain, so it gives the security of Axiom to any chain (bounded by a stake that can be slashed via Axiom)

[nambrot]

Adjusting the scope of this ticket to reflect the convo of https://discord.com/channels/935678348330434570/1134483378863878154

I.e. keep the scope of this ticket to allow providers of light clients, state root attestors to implement an abstract ISM AbstractBlockhashISM and AbstractStateRootISM which should exist upon the completion of this ticket:

• Should have a verifyMessageInBlockHash/ verifyMessageInStateRoot function that proves the existence of the origin chain message with a passed storage proof
• Allows implementors to only implement a verifyBlockhash/verifyStateRoot function

Changing this abstract ISM to support alternate semantics (either by coorcing it into the current message interface/API or a new one) should be considered part of #2442

[nambrot]

The scope of this ticket should also include the relayer changes to support this. There is an open question whether the relayer would need light client specific off-chain logic and how to connect that maybe with a CCIP-read based functionality to avoid the need to have light client teams to make relayer changes while still being able to have stateproof retrieval be somewhat universally supported in the relayer already