On Cross Chain State Consumption

[tynes]

As specified, the interop protocol is able to reliably observe the logs of remote chains. This is done using a single invariant, every ExecutingMessage event tuple from a specific predeploy must contain an Identifier that correctly references its log. This reference is made up of a chain id, block number and log index - all of the information required to point to a specific log on a specific chain.

// no need to emit the entire log, just need its hash
event ExecutingMessage(bytes32 indexed logHash, Identifier identifier);

struct Identifier {
    address origin;
    uint256 blocknumber;
    uint256 logIndex;
    uint256 timestamp;
    uint256 chainid;
}

Notice the ExecutingMessage event contains the log hash - this means the log itself is observable from within the EVM. This can be thought of as being similar to multicast UDP for logs.

If a block is included that contains an ExecutingMessage where its tuple doesn't match, the block is reorg'd out as part of the L2 fork choice rule. This gives users the integrity to trust all cross chain messages at the application layer.

It is also possible to do interop using storage slots rather than just logs. The Identifier would just look a little bit different.

event ExecutingMessage(bytes32 indexed storageValue, Identifier identifier);

struct Identifier {
    address origin;
    uint256 blocknumber;
    bytes32 storageKey;
    uint256 timestamp;
    uint256 chainid;
}

This design was discarded due to the archival state requirement for verifying that a storage slot key value pair match on a particular chain at a given block number. If we add a history accumulator to the L2 block header, then we can solve the problem of infrastructure cost by running a single instance of a data pipeline that indexes a set of composable witnesses that are able to prove any storage slot at any height and use this to feed into the fork choice rule and proof system.