Research Area: Interop Between Chains with Non Fungible Blockspace

[tynes]

As new features are added to the protocol we want to enable the ability interop between chains that support different feature sets. Some applications may be opinionated about the types of features or blockspace they accept inbound messages from in the world of interop. This means that legibility is important when there is interoperability between chains that have non fungible blockspace.

An example of non fungible blockspace is a plasma chain vs a rollup. The security properties of the chains are completely different, therefore some applications may want to be able to introspect in on the properties of the originating chain to know how to treat the messages.

One way to allow for legibility into the type of blockspace is having a bytes32 bitfield on L1 that includes all of the features for a chain. We could update executeMessage with a new argument _type. This _type would be made available and the protocol specifications would define particular bits being set that correspond to particular features.

function executeMessage(address _target, bytes calldata _msg, bytes32 _type, Identifier calldata _id) public payable;

The fork choice rule/fault proof would be able to enforce that the _type is exactly what is defined on L1, similar to how they currently enforce the Identifier to match to the _msg exactly.

An on chain data structure would be used to ensure that an archive node is not necessary, whether its an append only list of (value, timestamp) or a "last updated blocknumber" which would give a lookup for an emitted event that contains the value.

Another possible design would be to have multiple inbox predeploys, one for each type of blockspace. This adds complexity to consensus, as now there would have to be a special case for each of the special predeploys. There are only so many predeploy spots and it means adding a new type of blockspace or a new feature would require the addition of a new predeploy to allow for them to interop. With the bytes32 type bitfield design, the bitfield can be updated and there is no need to fork upgrade in a new predeploy