Merge pull request #6 from ethereum-optimism/feat/interop

feat: interop specs

specs/SUMMARY.md

@@ -32,4 +32,14 @@
       - [Honest Challenger](./experimental/fault-proof/honest-challenger-fdg.md)
       - [Bond Incentives](./experimental/fault-proof/bond-incentives.md)
   - [Plasma](./experimental/plasma.md)
+  - [Interoperability](./interop/README.md)
+    - [Dependency Set](./interop/dependency_set.md)
+    - [Messaging](./interop/messaging.md)
+    - [Predeploys](./interop/predeploys.md)
+    - [Execution](./interop/execution.md)
+    - [Sequencer](./interop/sequencer.md)
+    - [Verifier](./interop/verifier.md)
+    - [Rollup Node P2P](./interop/rollup_node_p2p.md)
+    - [Fault Proof](./interop/fault_proof.md)
+    - [Upgrade](./interop/upgrade.md)
 - [Glossary](./glossary.md)

specs/interop/README.md

@@ -0,0 +1,39 @@
+<!-- DOCTOC SKIP -->
+
+# Interop
+
+The ability for a blockchain to easily read the state of another blockchain is called interoperability.
+Low latency interoperability allows for horizontally scalable blockchains, a key feature of the superchain.
+
+Note: this document references an "interop network upgrade" as a temporary name. The actual name of the
+network upgrade will be included in this document in the future.
+
+| Term                | Definition                                                                                          |
+|---------------------|-----------------------------------------------------------------------------------------------------|
+| Source Chain        | A blockchain that includes an initiating message                                                    |
+| Destination Chain   | A blockchain that includes an executing message                                                     |
+| Initiating Message  | An event emitted from a source chain                                                                |
+| Executing Message   | A transaction submitted to a destination chain that corresponds to an initiating message            |
+| Cross Chain Message | The cumulative execution and side effects of the initiating message and executing message           |
+| Dependency Set      | The set of chains that originate initiating transactions where the executing transactions are valid |
+
+A total of two transactions are required to complete a cross chain message.
+The first transaction is submitted to the source chain and emits an event that can be consumed on a destination chain.
+The second transaction is submitted to a destination chain, where the block builder SHOULD only include it if they are
+certain that the first transaction was included in the source chain.
+There is no strict requirement that the execution message is ever submitted.
+
+The term "block builder" is used interchangeably with the term "sequencer" for the purposes of this document but
+they need not be the same entity in practice.
+
+## Specifications
+
+- [Dependency Set](./dependency_set.md): definition of chains and chain-dependencies in the Superchain.
+- [Messaging](./messaging.md): messaging functionality, core of protocol-level interoperability.
+- [Predeploys](./predeploys.md): system contracts to interface with other chains.
+- [Execution](./execution.md): enhancements to the execution-layer.
+- [Sequencer](./sequencer.md): Sequencer Policy and block-building information.
+- [Verifier](./verifier.md): Verification of cross-L2 messaging.
+- [Rollup Node P2P](./rollup_node_p2p.md): modifications to the rollup-node P2P layer to support fast interop.
+- [Fault Proof](./fault_proof.md): modifications to prove interop functionality in the fault-proof.
+- [Upgrade](./upgrade.md): Superchain upgrade process to activate Interop.

specs/interop/dependency_set.md

@@ -0,0 +1,85 @@
+# The Dependency Set
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+**Table of Contents**
+
+- [Chain ID](#chain-id)
+- [Updating the Dependency Set](#updating-the-dependency-set)
+  - [`DEPENDENCY_SET` UpdateType](#dependency_set-updatetype)
+- [Security Considerations](#security-considerations)
+  - [Dynamic Size of L1 Attributes Transaction](#dynamic-size-of-l1-attributes-transaction)
+  - [Maximum Size of the Dependency Set](#maximum-size-of-the-dependency-set)
+  - [Layer 1 as Part of the Dependency Set](#layer-1-as-part-of-the-dependency-set)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+The dependency set defines the set of chains that a destination chains allows 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
+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.
+
+The chainid of the local chain MUST be considered as part of its own dependency set.
+
+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](#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
+replay attacks between chains. This EIP does not specify the max size of a chain id, although
+[EIP-2294](https://eips.ethereum.org/EIPS/eip-2294) attempts to add a maximum size. Since this EIP is
+stagnant, all representations of chain ids MUST be the `uint256` type.
+
+In the future, OP Stack chains reserve the right to use up to 32 bytes to represent a chain id. The
+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.
+
+## Updating the Dependency Set
+
+The `SystemConfig` is updated to manage the dependency set. The chain operator can add or remove
+chains from the dependency set through the `SystemConfig`. A new `ConfigUpdate` event `UpdateType`
+enum is added that corresponds to a change in the dependency set.
+
+The `SystemConfig` MUST enforce that the maximum size of the dependency set is `type(uint8).max` or 255.
+
+### `DEPENDENCY_SET` UpdateType
+
+When a `ConfigUpdate` event is emitted where the `UpdateType` is `DEPENDENCY_SET`, the L2 network will
+update its dependency set. The chain operator SHOULD be able to add or remove chains from the dependency set.
+
+## Security Considerations
+
+### Dynamic Size of L1 Attributes Transaction
+
+The L1 Attributes transaction includes the dependency set which is dynamically sized. This means that
+the worst case (largest size) transaction must be accounted for when ensuring that it is not possible
+to create a block that has force inclusion transactions that go over the L2 block gas limit.
+It MUST be impossible to produce an L2 block that consumes more than the L2 block gas limit.
+Limiting the dependency set size is an easy way to ensure this.
+
+### Maximum Size of the Dependency Set
+
+The maximum size of the dependency set is constrained by the L2 block gas limit. The larger the dependency set,
+the more costly it is to fully verify the network. It also makes the block building role more centralized
+as it requires more hardware to verify executing transactions before inclusion.
+
+### Layer 1 as Part of the Dependency Set
+
+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.
+
+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 exeuction across all L2s in the OP Stack.

specs/interop/execution.md

@@ -0,0 +1,52 @@
+# Execution
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+**Table of Contents**
+
+- [Overview](#overview)
+- [Security Considerations](#security-considerations)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+## Overview
+
+This is an experimental section and may be changed in the future. It is not required
+for the initial release.
+
+After the full execution of a block, the set of [logs][log] that are emitted MUST be merklized and
+included in the block header. This commitment MUST be included as the block header's
+[extra data field][block-extra-data]. The events are serialized with using [Simple Serialize][ssz] aka SSZ.
+
+The goal of committing to data in the extra data field is to make commitments to data required to
+verify executing messages easier. The commitment could also commit to the set of executing messages
+instead of just the logs which represent all possible initiating messages that originate in the block.
+This would reduce rounds of communication for nodes that use proofs to verify executing messages.
+
+[log]: https://github.com/ethereum/go-ethereum/blob/5c67066a050e3924e1c663317fd8051bc8d34f43/core/types/log.go#L29
+[block-extra-data]: https://github.com/ethereum/execution-specs/blob/1fed0c0074f9d6aab3861057e1924411948dc50b/src/ethereum/frontier/fork_types.py#L115
+[ssz]: https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md
+
+| Name                     | Value                         |
+|--------------------------|-------------------------------|
+| `MAX_LOG_DATA_SIZE`      | `uint64(2**24)` or 16,777,216 |
+| `MAX_MESSAGES_PER_BLOCK` | `uint64(2**20)` or 1,048,576  |
+
+```python
+class Log(Container):
+    address: ExecutionAddress
+    topics: List[bytes32, 4]
+    data: ByteList[MAX_LOG_DATA_SIZE]
+    transaction_hash: bytes32
+    transaction_index: uint64
+    log_index: uint64
+
+logs = List[Log, MAX_MESSAGES_PER_BLOCK](
+  log_0, log_1, log_2, ...)
+
+block.extra_data = logs.hash_tree_root()
+```
+
+## Security Considerations
+
+TODO

specs/interop/fault_proof.md

@@ -0,0 +1,24 @@
+# Fault Proof
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+**Table of Contents**
+
+- [Security Considerations](#security-considerations)
+  - [Cascading dependencies](#cascading-dependencies)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+TODO
+
+No changes to the dispute game bisection are required. The only changes required are to the fault proof program itself.
+The insight is that the fault proof program can be a superset of the state transition function.
+
+## Security Considerations
+
+TODO
+
+### Cascading dependencies
+
+Deposits are a special case, synchronous with derivation, at enforced cross-L2 delay.
+Thus deposits cannot reference each others events intra-block.