Interop Dependency Set

[Inphi]

The superchain-registry should provide Go-embeddable configuration for the dependency set. Since all chains in the superchain-registry will be upgraded to interop, we will need to provide a way to configure the dependency set of multiple clusters.

Following the config scheme used by the op-supervisor.

The interop dependency configuration should be a table that maps chain IDs to a DependencySet.
The DependencySet is a mapping of chainIDs, including the mapped chain ID, to a Dependency, where each Dependency contains:

• chainIndex - the chain ID of mapped chain (for now).
• activationTime - when the dependency chain becomes active in the cluster.
• historyMinTime - when the dependency chain's initiating messages can be executable.

As such, all chains that belong to the same cluster have the same DependencySet configuration. This duplicates configuration to simplify config management and discovery. Such that a chain can quickly figure out its intra-cluster dependencies without explicitly loading the configuration of other chains.

Alternative Configuration

Rather than create duplicate depset configurations for each chain in a cluster, an alternative scheme is to define a superchainID that identifies an interop cluster. The superchainID never changes even as a cluster admits new chains. By avoiding duplicated depsets, it becomes easy to manage the configuration of interop clusters.

I don't think this is the correct approach right now as it overly complicates configuration and the end goal is to have a single superchain cluster for all chains in the registry. But if this changes in the future, we should consider this approach.

[ajsutton]

Just to add some detail here - "Such that a chain can quickly figure out its intra-cluster dependencies without explicitly loading the configuration of other chains" is a slightly subtle but really important requirement. We can't afford for the process of finding the dependency set for a chain to require parsing all the dependency set configs and searching through them (which includes if we load them all in an init() method and populate a map). That parsing would be far too slow when executing in cannon.

We could use things like code generation in the superchain-registry to avoid actually duplicating the config as long as at runtime we only wind up loading and parsing one dependency set config. Personally I like just duplicating the config at the moment, especially since we cut scope to only 2 chains in the cluster for this first release.