dependency-set: update spec (#493)

Updates the spec to match the latest definition of the dependency set.
It is no longer an onchain construct but instead is an offchain
construct in the client software.

specs/interop/dependency-set.md

@@ -6,32 +6,29 @@
 
 - [Chain ID](#chain-id)
 - [Updating the Dependency Set](#updating-the-dependency-set)
-- [Security Considerations](#security-considerations)
+- [Future Considerations](#future-considerations)
   - [Layer 1 as Part of the Dependency Set](#layer-1-as-part-of-the-dependency-set)
+- [Security Considerations](#security-considerations)
+  - [Dependency Set Size](#dependency-set-size)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
 The dependency set defines the set of chains that destination chains allow as source chains. Another way of
-saying it is that the dependency set defines the set of initiating messages that are valid for an executing
-message to be included. An executing message MUST have an initiating message that is included in a chain
+saying it is that the dependency set defines the set of initiating messages that are valid to be used
+as part of an executing message. An executing message MUST have an initiating message that is created by a chain
 in the dependency set.
 
 The dependency set is defined by a set of chain ids. Since it is impossible to enforce uniqueness of chain ids,
 social consensus MUST be used to determine the chain that represents the canonical chain id. This
 particularly impacts the block builder as they SHOULD use the chain id to assist in validation
 of executing messages.
 
-The dependency set is configured on a per chain basis and is a unidirectional relationship. This means
-that it is possible to depend on a chain without it depending back. This means that it is possible
-to send assets to a chain where they cannot be sent back.
+The dependency set is configured on a per cluster basis. All chains that are in the dependency set
+can accept initiating messages from any other chain in the dependency set, resulting in a mesh.
 
 The chain id of the local chain MUST be considered as part of its own dependency set. This allows a chain
 to consume logs that it has produced much more cheaply than providing a block hash proof.
 
-While the dependency set explicitly defines the set of chains that are depended on for incoming messages,
-the full set of transitive dependencies must be known to allow for the progression of safety.
-This means that the `op-node` needs to be aware of all transitive dependencies.
-
 ## Chain ID
 
 The concept of a chain id was introduced in [EIP-155](https://eips.ethereum.org/EIPS/eip-155) to prevent
@@ -43,29 +40,24 @@ In the future, OP Stack chains reserve the right to use up to 32 bytes to repres
 configuration of the chain should deterministically map to a chain id and with careful architecture
 changes, all possible OP Stack chains in the superchain will be able to exist counterfactually.
 
-It is a known issue that not all software in the Ethereum can handle 32 byte chain ids.
+It is a known issue that not all software in the Ethereum ecosystem can handle 32 byte chain ids.
 
 ## Updating the Dependency Set
 
-The `SystemConfig` is updated to manage a new role, `dependencyManager`.
-It can only updated by the `ProxyAdmin` during an contract upgrade.
-The sole holder of this role is the only address
-permissioned to update (remove/add to) the dependency set of that chain.
+The dependency set is managed in the client software. Adding a chain to the dependency set is
+considered an upgrade to the network. It is not possible to remove chains from the dependency set.
 
-The `SystemConfig` is also updated to manage the dependency set.
-The address with the `dependency manager` role can add or remove
-chains from the dependency set through the `SystemConfig`.
+## Future Considerations
 
-The `SystemConfig` MUST enforce that the maximum size of the dependency set is `type(uint8).max` or 255.
+### Layer 1 as Part of the Dependency Set
 
-## Security Considerations
+The layer one MAY be part of the dependency set in the future. This means that any event
+created on layer one is consumable on layer two.
 
-### Layer 1 as Part of the Dependency Set
+## Security Considerations
 
-The layer one MAY be part of the dependency set if the fault proof implementation is set up
-to support it. It is known that it is possible but it is not known if this is going to be
-a feature of the first release. This section should be clarified when the decision is made.
+### Dependency Set Size
 
-If layer one is part of the dependency set, then it means that any event on L1 can be pulled
-into any L2. This is a very powerful abstraction as a minimal amount of execution can happen
-on L1 which triggers additional execution across all L2s in the OP Stack.
+It becomes increasingly expensive to fully validate the full cluster as the size of the dependency
+set grows. The proof system requires validating all of the chains so the size of the dependency
+set is limited by the performance of the proof.