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 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 diff --git a/pages/stack/design-principles.mdx b/pages/stack/design-principles.mdx index d18a01b23..b3104d679 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. @@ -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 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 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. 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. 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: 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).