ethereum-optimism · krofax · Jan 27, 2025 · Jan 26, 2025 · Jan 26, 2025 · Jan 26, 2025
@@ -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

@@ -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 
 

@@ -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
 

@@ -35,7 +35,7 @@ The "cost" of a given conditional is *approximately* determined by the number of
 <Callout type="info">
   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.
 </Callout>
 
 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

@@ -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.
 </details>
 

@@ -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.

@@ -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:

@@ -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).