From 0cc4bc44a9b2125bfb0bf0d9d84bbc4b3a81c5b9 Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:09:40 +0200 Subject: [PATCH 1/9] Update design-principles.mdx --- pages/stack/design-principles.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/design-principles.mdx b/pages/stack/design-principles.mdx index d18a01b23..8c0b36f92 100644 --- a/pages/stack/design-principles.mdx +++ b/pages/stack/design-principles.mdx @@ -17,7 +17,7 @@ It's important to understand these pillars as they heavily influence the design ### Simplicity -Optimism is designed to be as simple as possible for the featureset it provides. +Optimism is designed to be as simple as possible for the feature set it provides. Ideally, Optimism should be composed of the minimum number of moving parts required for a secure, scalable, and flexible L2 system. This simplicity gives Optimism's design a number of significant advantages over other more complex L2 constructions. From 654fab31655c14a94cbc9a678711e86d165ccaaa Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:14:54 +0200 Subject: [PATCH 2/9] Update explainer.mdx --- pages/stack/interop/explainer.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/stack/interop/explainer.mdx b/pages/stack/interop/explainer.mdx index bb8e6b3bc..759694683 100644 --- a/pages/stack/interop/explainer.mdx +++ b/pages/stack/interop/explainer.mdx @@ -159,8 +159,8 @@ If a sequencer chooses to accept unsafe messages, the sequencer must trust the s F[Chain F] <--> G[Chain G] ``` - For example, there could be a block in chain D that depends on an initiating message in chain E> - If the block with that initiating message is still unsafe (not written to L1), then the block in chain D is also usafe, even if it has been written to L1. + For example, there could be a block in chain D that depends on an initiating message in chain E. + If the block with that initiating message is still unsafe (not written to L1), then the block in chain D is also unsafe, even if it has been written to L1. As a result, a block in chain B that depends on the chain D block can also be unsafe, as can a block in chain A that depends on the block in chain B. From 14dd21fbd5dd25c9bf3d960347aeadec94addf9e Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:15:22 +0200 Subject: [PATCH 3/9] Update send-raw-transaction-conditional.mdx --- pages/stack/features/send-raw-transaction-conditional.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/features/send-raw-transaction-conditional.mdx b/pages/stack/features/send-raw-transaction-conditional.mdx index 71bca0a59..f087ed935 100644 --- a/pages/stack/features/send-raw-transaction-conditional.mdx +++ b/pages/stack/features/send-raw-transaction-conditional.mdx @@ -35,7 +35,7 @@ The "cost" of a given conditional is *approximately* determined by the number of Since the sequencer is not compensated for the additional state checks, otherwise through the GAS of the transaction, a configured rate limit is applied to this cost. - To also disincentive the use of this endpoint for MEV in comparison to `eth_sendRawTransaction`, the conditional is checked against the parent of the latest block. + To also disincentivize the use of this endpoint for MEV in comparison to `eth_sendRawTransaction`, the conditional is checked against the parent of the latest block. This conditional is checked once at the RPC layer prior to mempool submission. If rejected against chain state, the RPC will return an error with the following spec From e64e955c550e7ad0183ee9f831b3fb51ccd58958 Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:38:14 +0200 Subject: [PATCH 4/9] Update security.mdx --- pages/stack/interop/security.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/interop/security.mdx b/pages/stack/interop/security.mdx index 938eb3e29..67f20f561 100644 --- a/pages/stack/interop/security.mdx +++ b/pages/stack/interop/security.mdx @@ -15,7 +15,7 @@ import { InteropCallout } from '@/components/WipCallout' ## The trust model -This interop vulnerability arises when an initiating message seems to exist, prompting the processing of the executing message. However, the initiating message ends up not actually appear in the canonical chain. +This interop vulnerability arises when an initiating message seems to exist, prompting the processing of the executing message. However, the initiating message ends up not actually appearing in the canonical chain. Excluding L1 reorgs, this can happen in two ways: * *Equivocation*. A sequencer publishes a block using the gossip protocol that is different from the one that eventually gets written to L1. From 4fd7c08c9de36383d0ee48efcad9d283948e8be3 Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:38:26 +0200 Subject: [PATCH 5/9] Update outages.mdx --- pages/stack/rollup/outages.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/rollup/outages.mdx b/pages/stack/rollup/outages.mdx index 52677d7e9..4523bfc69 100644 --- a/pages/stack/rollup/outages.mdx +++ b/pages/stack/rollup/outages.mdx @@ -7,7 +7,7 @@ description: Learn what happens if the Sequencer goes down and how you can be pr # Sequencer outages All OP Stack chains have a Sequencer that can receive, order, and publish L2 transactions to L1. -Like any software systems, a Sequencer could potentially become unavailable for any number of different reasons. +Like any software system, a Sequencer could potentially become unavailable for any number of different reasons. It's important to be aware of the implications of a Sequencer outage and how you can be prepared for it. Sequencer outages can broadly be categorized into two different types: From 76335fe0064ccebfee9f9a3805f409524dbb161a Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:45:13 +0200 Subject: [PATCH 6/9] Update transaction-finality.mdx --- pages/stack/transactions/transaction-finality.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 8bb4db697..60b61d9b7 100644 --- a/pages/stack/transactions/transaction-finality.mdx +++ b/pages/stack/transactions/transaction-finality.mdx @@ -24,7 +24,7 @@ OP Stack chains in the standard configuration are Rollups that use Ethereum's co Transactions on OP Stack chains go through the following process to reach finality: 1. A user submits a transaction to the network, which forwards it to the Sequencer. -2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"**- a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes a few seconds from transaction submission. +2. The Sequencer includes the transaction in a block and distributes it over a public peer-to-peer network. At this point, the transaction is considered **"unsafe"** - a technical term indicating that the transaction is in a block but its data has not yet been posted to Ethereum. This process typically takes a few seconds from transaction submission. 3. The Sequencer publishes this block's data to Ethereum, either as [blob data](https://www.eip4844.com/) or as calldata attached to a standard Ethereum transaction. Once included in an Ethereum block, the transaction is considered **"safe"**. This step usually takes 5–10 minutes from transaction submission. 4. The Ethereum block containing the Sequencer's transaction is finalized. At this point, the transaction reaches a **"finalized"** state. Ethereum finalization typically takes about 2 epochs (approximately 12.8 minutes from transaction submission) under normal network conditions, but may take longer during adverse conditions. Finality depends entirely on [Ethereum's consensus mechanism](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). From 21d1aeb8a785625ba7982cb6601f91c47ba32473 Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:47:59 +0200 Subject: [PATCH 7/9] Update beta-features.mdx --- pages/stack/beta-features.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/beta-features.mdx b/pages/stack/beta-features.mdx index 8ac25ed02..b44b3182a 100644 --- a/pages/stack/beta-features.mdx +++ b/pages/stack/beta-features.mdx @@ -42,7 +42,7 @@ When using beta features, please keep the following in mind: Feedback from beta users helps improve and refine these features. Here's how to contribute: 1. **Document Your Experience**: Take note of any issues, suggestions, or enhancements you'd like to see. -2. **Report Through Official Channels**: Submit feedback and bug report through the optimism [monorepo](https://github.com/ethereum-optimism/optimism/issues). +2. **Report Through Official Channels**: Submit feedback and bug reports through the optimism [monorepo](https://github.com/ethereum-optimism/optimism/issues). 3. **Participate in Surveys**: Occasionally, we'll send surveys to beta users. Participating in these helps us prioritize improvements. ## Available beta features From 809a4133188ebbaf6c2781a1656a588b46d424d0 Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:52:05 +0200 Subject: [PATCH 8/9] Update components.mdx --- pages/stack/components.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/components.mdx b/pages/stack/components.mdx index b89bd4a2e..bb658e97f 100644 --- a/pages/stack/components.mdx +++ b/pages/stack/components.mdx @@ -88,7 +88,7 @@ An Attestation-based Fault Proof mechanism uses an optimistic protocol to establ #### Fault Proof Optimistic Settlement -A Fault Proof Optimistic Settlement mechanism is mostly identical to the Attestation-based Fault Proof mechanism used today but it replaces the MultiSig challenger with a permissionless fault proving process. A correctly constructed fault proof should be able to invalidate any incorrect proposals during the allocated challenge period. This places a trust assumption on the correctness of the fault proof construction. At this time, work on the development of a Fault Proof mechanism is well underway. +A Fault Proof Optimistic Settlement mechanism is mostly identical to the Attestation-based Fault Proof mechanism used today but it replaces the MultiSig challenger with a permissionless fault proving process. A correctly constructed fault proof should be able to invalidate any incorrect proposals during the allocated challenge period. This places a trust assumption on the correctness of the fault proof construction. At this time, work on the development of a Fault Proof mechanism is well underway. #### Validity Proof Settlement From 6584c8436517df810a0ccaa876ccc675a3bf0942 Mon Sep 17 00:00:00 2001 From: futreall <86553580+futreall@users.noreply.github.com> Date: Sun, 26 Jan 2025 19:53:43 +0200 Subject: [PATCH 9/9] Update design-principles.mdx --- pages/stack/design-principles.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/design-principles.mdx b/pages/stack/design-principles.mdx index 8c0b36f92..b3104d679 100644 --- a/pages/stack/design-principles.mdx +++ b/pages/stack/design-principles.mdx @@ -45,7 +45,7 @@ Sometimes the best solution isn't the prettiest one. Optimism is also developed with the understanding that any core team will have limited areas of expertise. Optimism is developed iteratively and strives to continuously pull feedback from users. -Many core Optimism features today (like [EVM Equivalence](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306)) were only made possible by this iterative approach to protocol development. +Many core Optimism features today (like [EVM Equivalence](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) were only made possible by this iterative approach to protocol development. ### Sustainability