From 903437d16168087dc8ac39e410355e0c5c8d6d25 Mon Sep 17 00:00:00 2001 From: 0xYYY <0xYYY@protonmail.com> Date: Wed, 23 Nov 2022 22:50:34 +0800 Subject: [PATCH 1/3] doc: fix spec typos --- specs/introduction.md | 8 ++++---- specs/overview.md | 4 ++-- specs/rollup-node.md | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/specs/introduction.md b/specs/introduction.md index 0a0399def66f4..1b835299a85c5 100644 --- a/specs/introduction.md +++ b/specs/introduction.md @@ -60,13 +60,13 @@ In order to scale Ethereum without sacrificing security, we must preserve 3 crit liveness, availability, and validity. 1. **Liveness** - Anyone must be able to extend the rollup chain by sending transactions at any time. - - There are two ways transactions can be sent to the rollup chain: 1) via the sequencer, and 2) directly on layer -2. The sequencer provides low latency & low cost transactions, while sending transactions directly to layer 1 provides + - There are two ways transactions can be sent to the rollup chain: 1) via the sequencer, and 2) directly on layer 1. +The sequencer provides low latency & low cost transactions, while sending transactions directly to layer 1 provides censorship resistance. -3. **Availability** - Anyone must be able to download the rollup chain. +2. **Availability** - Anyone must be able to download the rollup chain. - All information required to derive the chain is embedded into layer 1 blocks. That way as long as the layer 1 chain is available, so is the rollup. -4. **Validity** - All transactions must be correctly executed and all withdrawals correctly processed. +3. **Validity** - All transactions must be correctly executed and all withdrawals correctly processed. - The rollup state and withdrawals are managed on an L1 contract called the `L2 State Oracle`. This oracle is guaranteed to _only_ finalize correct (ie. valid) rollup block hashes given a **single honest verifier** assumption. If there is ever an invalid block hash asserted on layer 1, an honest verifier will prove it is invalid and win a bond. diff --git a/specs/overview.md b/specs/overview.md index 6fd506f0ce0a8..00fcfd4e5e8c5 100644 --- a/specs/overview.md +++ b/specs/overview.md @@ -26,7 +26,7 @@ This document assumes you've read the [introduction](./introduction.md). ## Architecture Design Goals -- **Execution-Level EVM Equivalence:** The developer experience should be identical to L2 except where L2 introduces a +- **Execution-Level EVM Equivalence:** The developer experience should be identical to L1 except where L2 introduces a fundamental difference. - No special compiler. - No unexpected gas costs. @@ -137,7 +137,7 @@ Optimism's block derivation function is designed such that it: The rollup chain is subdivided into epochs. There is a 1:1 correspondence between L1 block numbers and epoch numbers. For L1 block number `n`, there is a corresponding rollup epoch `n` which can only be derived after a _sequencing window_ -worth of blocks haspassed, i.e. after L1 block number `n + SEQUENCING_WINDOW_SIZE` is added to the L1 chain. +worth of blocks has passed, i.e. after L1 block number `n + SEQUENCING_WINDOW_SIZE` is added to the L1 chain. Each epoch contains at least one block. Every block in the epoch contains an L1 info transaction which contains contextual information about L1 such as the block hash and timestamp. The first block in the epoch also contains all diff --git a/specs/rollup-node.md b/specs/rollup-node.md index 9116db564f483..de9247957d32c 100644 --- a/specs/rollup-node.md +++ b/specs/rollup-node.md @@ -72,4 +72,4 @@ The input and return types here are as defined by the [engine API specs][engine- OR `String` - one of `"safe"`, `"latest"`, or `"pending"`. - returns: 1. `version`: `DATA`, 32 Bytes - the output root version number, beginning with 0. - 1. `l2OutputRoot`: `DATA`, 32 Bytes - the output root + 2. `l2OutputRoot`: `DATA`, 32 Bytes - the output root. From ed31c64099448d518e2a874d53a988323848af1d Mon Sep 17 00:00:00 2001 From: 0xYYY <0xYYY@protonmail.com> Date: Wed, 23 Nov 2022 22:55:59 +0800 Subject: [PATCH 2/3] doc: fix CONTRIBUTING.md typo --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4a54d8be92b50..8e1fe80ab5aa4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,7 +6,7 @@ There are plenty of ways to contribute, in particular we appreciate support in t - Reporting issues. For security issues see [Security policy](https://github.com/ethereum-optimism/.github/blob/master/SECURITY.md). - Fixing and responding to existing issues. You can start off with those tagged ["good first issue"](https://github.com/ethereum-optimism/optimism/contribute) which are meant as introductory issues for external contributors. -- Improving the [community site](https://community.optimism.io/)[documentation](https://github.com/ethereum-optimism/community-hub) and [tutorials](https://github.com/ethereum-optimism/optimism-tutorial). +- Improving the [community site](https://community.optimism.io/), [documentation](https://github.com/ethereum-optimism/community-hub) and [tutorials](https://github.com/ethereum-optimism/optimism-tutorial). - Become an "Optimizer" and answer questions in the [Optimism Discord](https://discord.optimism.io). - Get involved in the protocol design process by proposing changes or new features or write parts of the spec yourself in the [optimistic-specs repo](https://github.com/ethereum-optimism/optimistic-specs). From bc10b10d3d7a9db53941894d68112407a359adfe Mon Sep 17 00:00:00 2001 From: 0xYYY <0xYYY@protonmail.com> Date: Thu, 24 Nov 2022 00:02:03 +0800 Subject: [PATCH 3/3] doc: set ordered list index to 1 --- specs/deposits.md | 2 +- specs/introduction.md | 4 ++-- specs/rollup-node.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/deposits.md b/specs/deposits.md index b600566b72ebc..f781911b32c8a 100644 --- a/specs/deposits.md +++ b/specs/deposits.md @@ -58,7 +58,7 @@ byte sequence. The first version has `0x00` as the version byte and then as the [EIP-2718]: https://eips.ethereum.org/EIPS/eip-2718 -- `bytes32 sourceHash`: the source-hash, uniquely identifies the origin of the deposit +- `bytes32 sourceHash`: the source-hash, uniquely identifies the origin of the deposit. - `address from`: The address of the sender account. - `address to`: The address of the recipient account, or the null (zero-length) address if the deposited transaction is a contract creation. diff --git a/specs/introduction.md b/specs/introduction.md index 1b835299a85c5..9f00a42125fbe 100644 --- a/specs/introduction.md +++ b/specs/introduction.md @@ -63,10 +63,10 @@ liveness, availability, and validity. - There are two ways transactions can be sent to the rollup chain: 1) via the sequencer, and 2) directly on layer 1. The sequencer provides low latency & low cost transactions, while sending transactions directly to layer 1 provides censorship resistance. -2. **Availability** - Anyone must be able to download the rollup chain. +1. **Availability** - Anyone must be able to download the rollup chain. - All information required to derive the chain is embedded into layer 1 blocks. That way as long as the layer 1 chain is available, so is the rollup. -3. **Validity** - All transactions must be correctly executed and all withdrawals correctly processed. +1. **Validity** - All transactions must be correctly executed and all withdrawals correctly processed. - The rollup state and withdrawals are managed on an L1 contract called the `L2 State Oracle`. This oracle is guaranteed to _only_ finalize correct (ie. valid) rollup block hashes given a **single honest verifier** assumption. If there is ever an invalid block hash asserted on layer 1, an honest verifier will prove it is invalid and win a bond. diff --git a/specs/rollup-node.md b/specs/rollup-node.md index de9247957d32c..b35784fa565c9 100644 --- a/specs/rollup-node.md +++ b/specs/rollup-node.md @@ -72,4 +72,4 @@ The input and return types here are as defined by the [engine API specs][engine- OR `String` - one of `"safe"`, `"latest"`, or `"pending"`. - returns: 1. `version`: `DATA`, 32 Bytes - the output root version number, beginning with 0. - 2. `l2OutputRoot`: `DATA`, 32 Bytes - the output root. + 1. `l2OutputRoot`: `DATA`, 32 Bytes - the output root.