diff --git a/pages/stack/fault-proofs/cannon.mdx b/pages/stack/fault-proofs/cannon.mdx index 4ad45ea78..fc933496b 100644 --- a/pages/stack/fault-proofs/cannon.mdx +++ b/pages/stack/fault-proofs/cannon.mdx @@ -16,7 +16,7 @@ However, Cannon is Optimism's default Fault Proof Virtual Machine (FPVM). Cannon * Onchain `MIPS.sol`: EVM implementation to verify execution of a single MIPS instruction. * Offchain `mipsevm`: Go implementation to produce a proof for any MIPS instruction to verify onchain. -Note that Cannon is just one example of a FPVM that can be used to resolve disputes. +Note that Cannon is just one example of an FPVM that can be used to resolve disputes. This documentation will go into detail about the subcomponents that make up the offchain Cannon implementation as a whole. Additionally, we will explore the differences between Cannon and the onchain `MIPS.sol`. For more information about the onchain @@ -52,7 +52,7 @@ where the code that has been compiled into MIPS instructions is OP-Program. OP-Program is golang code that will be compiled into MIPS instructions and run within the Cannon FPVM. OP-Program, whether run as standalone golang code or in Cannon, fetches all necessary data used for deriving the state of the L2. It is built such that the same inputs will produce not only the same outputs, but the same execution trace. This allows all participants in a fault dispute game to run -OP-Program such that, given the same L2 output root state transition, can generate the same execution traces. This in turn generates the same +OP-Program such that, given the same L2 output root state transition, they can generate the same execution traces. This in turn generates the same witness proof for the exact same MIPS instruction that will be run onchain. ## Overview of offchain Cannon components @@ -155,7 +155,7 @@ is used to parse all the symbols stored in the ELF file. Understanding which ELF they are located is important for other functionality, such as understanding if the current `PC` is running within a specific function. Another step that occurs while loading the ELF file is patching the binary of any incompatible functions. This step is crucial, as a key design decision -important**, as a key design decision in both the onchain and offchain `mipsevm` implementations is that neither implementation +in both the onchain and offchain `mipsevm` implementations is that neither implementation has access to a kernel. This is primarily due to the limitations within the EVM itself, and since the offchain Cannon implementation must match functionality exactly with its onchain counterpart, kernel access is also not available within Cannon. This means that the VMs cannot replicate behavior that would otherwise be performed by a kernel 1:1, which primarily impacts system calls (syscalls). @@ -169,9 +169,9 @@ within the ELF file, and effectively stubbing out the function by returning imme Once the MIPS binary is loaded into Cannon, we can then begin to run MIPS instructions one at a time. [`run.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/run.go) contains the top-level code responsible for stepping through MIPS instructions. Additionally, before each MIPS instruction, `run.go` will determine whether -separate action(s) needs to be performed. The actions to be performed are configured by the user, and can include logging information, +separate action(s) need(s) to be performed. The action(s) to be performed are configured by the user, and can include logging information, stopping at a certain instruction, taking a snapshot at a certain instruction, or signaling to the VM to generate the witness proof. -Actions to be performed are instantiated and checked by [`matcher.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/matcher.go), +The action(s) to be performed are instantiated and checked by [`matcher.go`](https://github.com/ethereum-optimism/optimism/blob/develop/cannon/cmd/matcher.go), which generates a match function that triggers when the configured regular expression is true. Within `run.go`, the `StepFn` is the wrapper that initiates the MIPS instruction to be run. diff --git a/pages/stack/fault-proofs/challenger.mdx b/pages/stack/fault-proofs/challenger.mdx index 17be766d5..d6e12aa17 100644 --- a/pages/stack/fault-proofs/challenger.mdx +++ b/pages/stack/fault-proofs/challenger.mdx @@ -43,7 +43,7 @@ graph TD; `op-challenger` assesses each claim's validity, countering only those deemed invalid, following this logic: 1. If the trusted node agrees with the output, `op-challenger` takes no action. An honest challenger does nothing because there are no claims it disagrees with. It continues to monitor the game in case someone posts a counter-claim to the valid root claim, in which case the challenger will participate in the game to defend the proposal. -2. If the trusted node disagrees, `op-challenger` posts a counter-claim to challenge the proposed output. In contrast to the above, an honest challenger aims to delete any output roots that its trusted node disagrees with in order to claim the bond attached to it. The honest challenger assumes that their rollup node is synced to the canonical state and that the fault proof program is correct, so it is willing to put its money on the line to counter any faults. +2. If the trusted node disagrees, `op-challenger` posts a counter-claim to challenge the proposed output. In contrast to the above scenario, an honest challenger aims to delete any output roots that its trusted node disagrees with in order to claim the bond attached to it. The honest challenger assumes that their rollup node is synced to the canonical state and that the fault proof program is correct, so it is willing to put its money on the line to counter any faults. ## Fault dispute game responses diff --git a/pages/stack/fault-proofs/fp-security.mdx b/pages/stack/fault-proofs/fp-security.mdx index 6f070fb06..4efaaeb1d 100644 --- a/pages/stack/fault-proofs/fp-security.mdx +++ b/pages/stack/fault-proofs/fp-security.mdx @@ -55,7 +55,7 @@ The `FaultDisputeGame` contracts store bonds within a `DelayedWETH` contract tha ### Cumulative security impact As with the original system, the cumulative effect of these security capabilities is that the `Guardian` role provides fast response capabilities while the `SystemOwner` can always step in to resolve all classes of bugs that could result in a loss of funds. -The most significant change in security model with the introduction of Fault Proof Mainnet is that `SystemOwner` can take a more passive role as invalid proposals will generally be rejected by the Fault Proof System while the `Guardian` can act as a backstop only in case of a failure in the fault proof game. +With the introduction of Fault Proof Mainnet, The most significant change in the security model is that `SystemOwner` can take a more passive role. Invalid proposals will generally be rejected by the Fault Proof System, while the `Guardian` can act as a backstop only in case of a failure in the fault proof game. ## Next steps diff --git a/pages/stack/fault-proofs/mips.mdx b/pages/stack/fault-proofs/mips.mdx index 3623ae991..987027520 100644 --- a/pages/stack/fault-proofs/mips.mdx +++ b/pages/stack/fault-proofs/mips.mdx @@ -22,7 +22,7 @@ The `FaultDisputeGame.sol` interacts with `MIPS.sol` and then `MIPS.sol` calls i * Pre-images contain data from both L1 and L2, which includes information such as block headers, transactions, receipts, world state nodes, and more. Pre-images are used as the inputs to the derivation process used to calculate the true L2 state, and subsequently the true L2 state is used to resolve a dispute game. * A Fault Dispute Game, at a high-level, will effectively determine what L2 state is currently agreed-upon, and move through L2 state until the first disagreed-upon state is found. How the Pre-images are determined and populated into the `PreimageOracle.sol` contract is out-of-scope for this reference document on the `MIPS.sol` contract, as that contract only consumes Pre-images that have already been populated by the off-chain Cannon implementation. -The `MIPS.sol` contract is called by a running instance of a dispute game i.e. by a `FaultDisputeGame.sol` contract, and is only called once a dispute game reaches a leaf node in the state transition tree that is currently being disputed. +The `MIPS.sol` contract is called by a running instance of a dispute game (i.e. by a `FaultDisputeGame.sol` contract), and is only called once a dispute game reaches a leaf node in the state transition tree that is currently being disputed. A leaf node represents a single MIPS instruction (in the case that we're using Cannon as the FPVM) that can then be run onchain. Given a Pre-image, which is the previously agreed-upon L2 state up until this instruction, and the instruction state to run in the `MIPS.sol` contract, the fault dispute game can determine the true post state (or Post-image). This true post state will then be used to determine the outcome of the fault dispute game by comparing the disputed post-state at the leaf node with the post-state proposed by the disputer. @@ -69,7 +69,7 @@ The following information is stored in the `State` struct. See [doc reference](h ### State hash The state hash is the `bytes32` value returned to the active Fault Dispute Game upon the completion of a single MIPS instruction in the `MIPS.sol` contract. -The hash is derived by taking the `keccak256` of the above packed VM execution `State` struct, and then replacing the first byte of the hash with a value that represents the status of the VM. +The hash is derived by taking the `keccak256` of the above packed VM execution `State` struct, then replacing the first byte of the hash with a value that represents the status of the VM. This value is derived from the `exitCode` and `exited` values, and can be: * Valid (0) @@ -78,19 +78,19 @@ This value is derived from the `exitCode` and `exited` values, and can be: * Unfinished (3) The reason for adding the VM status to the state hash is to communicate to the dispute game whether the VM determined the proposed output root was valid or not. -This in turn prevents a user from disputing an output root during a dispute game, but provides the state hash from a cannon trace that actually proves the output root is valid. +This in turn prevents a user from disputing an output root during a dispute game, while providng the state hash from a cannon trace that actually proves the output root is valid. ### Memory proofs Using a 32-bit ISA means that the total size of the address space (assuming no virtual address space) is `2^32 = 4GiB`. Additionally, the `MIPS.sol` contract is stateless, so it does not store the MIPS memory in contract storage. The primary reason for this is because having to load the entire memory into the `MIPS.sol` contract in order to execute a single instruction onchain is prohibitively expensive. Additionally, the entire memory would need to be loaded per fault proof game, requiring multiple instances of the `MIPS.sol` contract. Therefore, in order to optimize the amount of data that needs to be provided per onchain instruction execution while still maintaining integrity over the entire 32-bit address space, Optimism has converted the memory into a binary merkle tree. -The binary merkle tree (or hash tree) used to store the memory of the MIPS VM has leaf values that are 32 bytes and has a fixed depth of 27 levels. This in turn allows the binary merkle tree to span the full 32-bit address space: `2^27 * 32 = 2^32` (See [memory proofs](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md#memory-proofs) for more details). In order to ensure the integrity of the entire address space each time memory is read or written to, one or more memory proofs are provided by the FaultDisputeGame.sol contract each time a MIPS instruction is executed onchain in MIPS.sol. A memory proof consists of the current leaf value and 27 sibling nodes (28, 32-byte values in total), where the sibling nodes are the `keccak256` hash of its own child nodes. Using the leaf value, its 27 sibling nodes, and the memory address converted to its binary representation as a guide (0 or 1 tells the order to concatenate left and right values), we can calculate a merkle root. This merkle root should be exactly the same as the merkle root stored in the VM execution State struct. +The binary merkle tree (i.e. hash tree) used to store the memory of the MIPS VM has leaf values that are 32 bytes and has a fixed depth of 27 levels. This in turn allows the binary merkle tree to span the full 32-bit address space: `2^27 * 32 = 2^32` (See [memory proofs](https://github.com/ethereum-optimism/optimism/blob/546fb2c7a5796b7fe50b0b7edc7666d3bd281d6f/cannon/docs/README.md#memory-proofs) for more details). In order to ensure the integrity of the entire address space each time memory is read or written to, one or more memory proofs are provided by the FaultDisputeGame.sol contract each time a MIPS instruction is executed onchain in MIPS.sol. A memory proof consists of the current leaf value and 27 sibling nodes (28, 32-byte values in total), where the sibling nodes are the `keccak256` hash of its own child nodes. Using the leaf value, its 27 sibling nodes, and the memory address converted to its binary representation as a guide (0 or 1 tells the order to concatenate left and right values), we can calculate a merkle root. This merkle root should be exactly the same as the merkle root stored in the VM execution State struct. -Reading to memory and writing to memory work similarly, both involve calculating the merkle root. In the case of a memory write, `MIPS.sol` must take care to verify the provided proof for the memory location to write to is correct. Additionally, writing to memory will change the merkle root stored in the VM execution `State` struct. +Reading to memory and writing to memory work similarly, both involve calculating the merkle root. In the case of a memory write, `MIPS.sol` must take care to verify that the provided proof for the memory location to write to is correct. Additionally, writing to memory will change the merkle root stored in the VM execution `State` struct. ### State calculation -While the `MIPS.sol` contract may only execute a single instruction onchain, the off-chain Cannon implementation executes all prerequisite MIPS instructions for all state transitions in the disputed L2 state required to reach the disputed instruction that will be executed onchain. This ensures that the MIPS instruction executed onchain has the correct VM state and necessary Pre-images stored in the `PreimageOracle.sol` contract to generate the true post-state that can be used to resolve the dispute game. +While the MIPS.sol contract may only execute a single instruction onchain, the off-chain Cannon implementation executes all prerequisite MIPS instructions for all state transitions in the disputed L2 state. These transitions are required to reach the disputed instruction that will be executed onchain. This ensures that the MIPS instruction executed onchain has the correct VM state and necessary Pre-images stored in the `PreimageOracle.sol` contract to generate the true post-state that can be used to resolve the dispute game. ## Functions diff --git a/pages/stack/features/send-raw-transaction-conditional.mdx b/pages/stack/features/send-raw-transaction-conditional.mdx index 75cb7e8c5..71bca0a59 100644 --- a/pages/stack/features/send-raw-transaction-conditional.mdx +++ b/pages/stack/features/send-raw-transaction-conditional.mdx @@ -8,7 +8,7 @@ import { Callout } from 'nextra/components' # SendRawTransactionConditional explainer -A sequencer rpc, `eth_sendRawTransactionConditional`, allowing callers to conditionally include a transaction based on a set of provided options. +A sequencer RPC method, `eth_sendRawTransactionConditional`, allows callers to conditionally include a transaction based on a set of provided options. This feature is meant to unblock use cases that require atomic inclusion, otherwise possible on Ethereum through specialized block builders like Flashbots. Some examples: diff --git a/pages/stack/rollup.mdx b/pages/stack/rollup.mdx index ca95c2564..09d75273b 100644 --- a/pages/stack/rollup.mdx +++ b/pages/stack/rollup.mdx @@ -11,9 +11,9 @@ import { Card, Cards } from 'nextra/components' The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high l... + + - - diff --git a/pages/stack/rollup/derivation-pipeline.mdx b/pages/stack/rollup/derivation-pipeline.mdx index 2c2aad540..2f0995104 100644 --- a/pages/stack/rollup/derivation-pipeline.mdx +++ b/pages/stack/rollup/derivation-pipeline.mdx @@ -13,7 +13,7 @@ The derivation pipeline is a fundamental component of the OP Stack protocol, res The following are key functions of the derivation pipeline: * **Batch Submission and Sequencing**: Transactions are collected and sequenced into batches by the sequencer. These batches are then submitted to Layer 1 (L1) for finality and inclusion in the blockchain. -* **Safe Head and Unsafe Blocks**: The derivation pipeline maintains two types of heads: the Safe Head and the Unsafe Head. The Safe Head represents the most recent confirmed state on L1, while Unsafe Blocks are those that have been sequenced but not yet confirmed on L1. +* **Safe Head and Unsafe Blocks**: The derivation pipeline maintains two types of heads: the Safe Head and the Unsafe Head. The Safe Head represents the most recent confirmed state on L1, while the Unsafe Head represents the highest unsafe L2 block that the rollup node knows about. Unsafe Blocks are those that have been sequenced but not yet confirmed on L1 (i.e. those from above the Safe Head up to and including the Unsafe Head). * **Reorg and Recovery**: If the sequencing window (typically 12 hours) is exceeded without a valid batch being discovered on L1, the pipeline will revert all Unsafe Blocks from that period. The pipeline then progresses using a default block that is empty except for deposits, allowing the network to recover and continue processing new transactions. ## Sequencer window diff --git a/pages/stack/rollup/outages.mdx b/pages/stack/rollup/outages.mdx index 70faa381c..52677d7e9 100644 --- a/pages/stack/rollup/outages.mdx +++ b/pages/stack/rollup/outages.mdx @@ -23,7 +23,7 @@ Keep reading to learn more about these potential outages and how to handle them. ### Description Sequencer downtime outages occur when the Sequencer is unable to receive and/or process L2 transactions from users. -Outages of this type may be caused by any number of different issues including bugs in client software, cloud outages, or other similar errors. +Outages of this type may be caused by any number of different issues, including bugs in client software, cloud outages, or other similar errors. Exact causes of Sequencer downtime outages can be dependent on the specific infrastructure used to run the Sequencer for any given OP Stack chain. ### Impact diff --git a/pages/stack/rollup/overview.mdx b/pages/stack/rollup/overview.mdx index d9a6f23e7..b29615ea6 100644 --- a/pages/stack/rollup/overview.mdx +++ b/pages/stack/rollup/overview.mdx @@ -9,7 +9,7 @@ description: Learn how Optimistic Rollups work at a high level. The big idea that makes Optimism possible is the Optimistic Rollup. We'll go through a brief explainer of *how* Optimistic Rollups work at a high level. Then we'll explain *why* Optimism is built as an Optimistic Rollup and why we believe it's the best option for a system that addresses all of our design goals. -Check out the [protocol specs](https://specs.optimism.io/), if you want to more detail about the rollup protocol. +Check out the [protocol specs](https://specs.optimism.io/), if you want more details about the rollup protocol. ## Optimistic rollups TL;DR @@ -54,10 +54,10 @@ For the moment, [The Optimism Foundation](https://www.optimism.io/) runs the onl ## Block execution -The execution engine (implemented as the `op-geth` component) receive blocks using two mechanisms: +The execution engine (implemented as the `op-geth` component) receives blocks using two mechanisms: -1. The execution engine can update itself using peer to peer network with other execution engines. - This operates the same way that the L1 execution clients synchronize the state across the network. +1. The execution engine can update itself using a peer-to-peer network with other execution engines. + This operates in the same way that the L1 execution clients synchronize the state across the network. You can read more about it [in the specs](https://specs.optimism.io/protocol/exec-engine.html#happy-path-sync). 2. The rollup node (implemented as the `op-node` component) derives the L2 blocks from L1. @@ -70,7 +70,7 @@ Optimism is designed so that users can send arbitrary messages between smart con This makes it possible to transfer ETH or tokens, including ERC20 tokens, between the two networks. The exact mechanism by which this communication occurs differs depending on the direction in which messages are being sent. -OP Mainnet uses this functionality in the Standard bridge to allow users to deposit tokens from Ethereum to OP Mainnet and also allow withdrawals of the same tokens from OP Mainnet back to Ethereum. +OP Mainnet uses this functionality in the Standard bridge to allow users to deposit tokens from Ethereum to OP Mainnet and also to allow withdrawals of the same tokens from OP Mainnet back to Ethereum. See the [developer documentation and examples](/builders/app-developers/bridging/standard-bridge) for details on the inner workings of the Standard bridge. ### Moving from Ethereum to OP Mainnet diff --git a/pages/stack/transactions.mdx b/pages/stack/transactions.mdx index 4f82dfc0f..c5749c781 100644 --- a/pages/stack/transactions.mdx +++ b/pages/stack/transactions.mdx @@ -8,10 +8,9 @@ import { Card, Cards } from 'nextra/components' # Transactions -Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Transactions, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. +Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. - @@ -23,7 +22,6 @@ Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Tra - diff --git a/pages/stack/transactions/deposit-flow.mdx b/pages/stack/transactions/deposit-flow.mdx index 54e80753b..b8b4d0f15 100644 --- a/pages/stack/transactions/deposit-flow.mdx +++ b/pages/stack/transactions/deposit-flow.mdx @@ -14,7 +14,7 @@ This guide explains the deposit flow process for L2 deposit transactions, trigge The process is somewhat similar to the way [most networking stacks work](https://en.wikipedia.org/wiki/Encapsulation_\(networking\)). Information is encapsulated in lower layer packets on the sending side and then retrieved and used by those layers on the receiving side while going up the stack to the receiving application. -![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow.svg) +![Deposit Flow Diagram.](/img/op-stack/protocol/deposit-flow-dark-mode.svg) ## L1 processing diff --git a/pages/stack/transactions/fees.mdx b/pages/stack/transactions/fees.mdx index cba93d183..4934845e4 100644 --- a/pages/stack/transactions/fees.mdx +++ b/pages/stack/transactions/fees.mdx @@ -43,7 +43,7 @@ The [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee) is the min Transactions must specify a maximum base fee higher than the block base fee to be included. The actual fee charged is the block base fee, even if the transaction specifies a higher maximum base fee. -The OP Mainnet base fee behaves exactly like the Ethereum base fee with a few small parameter changes to account for the much shorter block times on OP Mainnet. +The OP Mainnet base fee behaves exactly like the Ethereum base fee, with a few small parameter changes to account for the much shorter block times on OP Mainnet. None of these parameters should significantly impact your application, but you can read more about each of these parameters on the [OP Mainnet differences](/stack/differences#eip-1559-parameters) page. Read more about the base fee in the [Ethereum.org documentation](https://ethereum.org/en/developers/docs/gas/#base-fee). @@ -52,7 +52,7 @@ Read more about the base fee in the [Ethereum.org documentation](https://ethereu Just like on Ethereum, OP Mainnet transactions can specify a **priority fee**. This priority fee is a price per unit of gas that is paid on top of the base fee. For example, if the block base fee is 1 gwei and the transaction specifies a priority fee of 1 gwei, the total price per unit of gas is 2 gwei. -The priority fee(tip) is an optional component of the execution gas fee and can technically be set to 0. +The priority fee(i.e. tip) is an optional component of the execution gas fee and can technically be set to 0. However, while EIP-1559 does not define a minimum priority fee, certain wallets and mempool implementations (like Geth) may enforce a minimum value. For instance, Geth typically defaults to a minimum priority fee of 1 gwei, but this can be configured to other values. **The OP Mainnet sequencer will prioritize transactions with a higher priority fee** and execute them before any transactions with a lower priority fee. @@ -101,7 +101,7 @@ the L1 Data Fee are generally quite small and should not impact the average tran Prior to the Ecotone upgrade, the L1 Data Fee is calculated based on the following parameters: -* The **signed** transaction serialized according to [the standard Ethereum transaction RLP encoding](https://github.com/ethereum-optimism/op-geth/blob/11a890f1ee0348a17687149abc72f394f9faa5ce/core/types/transaction.go#L131-L141). +* The **signed** transaction, serialized according to [the standard Ethereum transaction RLP encoding](https://github.com/ethereum-optimism/op-geth/blob/11a890f1ee0348a17687149abc72f394f9faa5ce/core/types/transaction.go#L131-L141). * The current Ethereum base fee (trustlessly relayed from Ethereum). * A fixed overhead cost for publishing a transaction (currently set to 188 gas). * A dynamic overhead cost which scales with the size of the transaction (currently set to 0.684). @@ -161,7 +161,7 @@ gas price multiplier. weighted_gas_price = 16*base_fee_scalar*base_fee + blob_base_fee_scalar*blob_base_fee ``` -The l1 data fee is then: +The L1 data fee is then: ```python l1_data_fee = tx_compressed_size * weighted_gas_price @@ -180,7 +180,7 @@ Chain operators can use the [Ecotone fee parameter calculator](https://docs.goog The L1 Data Fee formula changed with the Fjord upgrade. Refer to the [Network Upgrade Overview](/builders/node-operators/network-upgrades) for network upgrade activation timestamps for OP Sepolia and OP Mainnet. -The pricing function changes with Fjord upgrade because of the FastLZ compression estimator, which more accurately charges for L1 data usage on a per-transaction basis. +The pricing function changes with the Fjord upgrade because of the FastLZ compression estimator, which more accurately charges for L1 data usage on a per-transaction basis. The updated function uses the following parameters: * The FastLZ-compressed size of the signed transaction. @@ -206,7 +206,7 @@ Both scalars are scaled by 1e6. The final L1 Data Fee is then l1Cost = estimatedSizeScaled * l1FeeScaled / 1e12 ``` -The new cost function takes into account the compression ratio, so chain operators will need to adjust their `baseFeeScalar` and `blobFeeScalar` to account for any previous compression ratios that they encountered on their chains. Chain operators can use the [Fjord fee parameter calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit#gid=186414307) to get a better estimate of scalar values to use for your chain. +The new cost function takes into account the compression ratio, so chain operators will need to adjust their `baseFeeScalar` and `blobFeeScalar` to account for any previous compression ratios that they encountered on their chains. Chain operators can use the [Fjord fee parameter calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit#gid=186414307) to get a better estimate of scalar values to use for their chain. ## Sequencer Fee Vault diff --git a/pages/stack/transactions/transaction-finality.mdx b/pages/stack/transactions/transaction-finality.mdx index 5dd7d7528..8bb4db697 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). diff --git a/pages/stack/transactions/transaction-flow.mdx b/pages/stack/transactions/transaction-flow.mdx index b076e5c4e..fb0af08f5 100644 --- a/pages/stack/transactions/transaction-flow.mdx +++ b/pages/stack/transactions/transaction-flow.mdx @@ -15,9 +15,9 @@ This guide explains the transaction flow process for rollup transactions. The pr * The transaction needs to be executed to modify the state (by `op-geth`). Afterwards, `op-proposer` writes a [commitment](https://en.wikipedia.org/wiki/Commitment_scheme) to the post-transaction state to L1. - Note that `op-proposer` does not need to write a commitment after each transaction to L1, it is OK to commit to the state after a block of transactions. + Note that `op-proposer` does not need to write a commitment after each transaction to L1; it is OK to commit to the state after a block of transactions. -![Overall process.](/img/op-stack/protocol/transaction-flow.svg) +![Overall process.](/img/op-stack/protocol/transaction-flow-dark-mode.svg) ## Writing the transaction to L1 @@ -35,8 +35,8 @@ You can read more about this process [in the specs](https://specs.optimism.io/pr When a channel is full or times out it is compressed and written. The maximum time that a channel can be open, from the first transaction to the last, is specified in units of L1 block time (so a value of 5 means 5\*12=60 seconds). -You can specify it either as an environment variable (`OP_BATCHER_MAX_CHANNEL_DURATION`) or a command line parameters (`--max-channel-duration`). -Alternatively, you can set it to zero (the default) to avoid posting smaller, less cost efficient, transactions. +You can specify it either as an environment variable (`OP_BATCHER_MAX_CHANNEL_DURATION`) or a command line parameter (`--max-channel-duration`). +Alternatively, you can set it to zero (the default) to avoid posting smaller, less cost efficient transactions. A channel is full when the anticipated compressed size is the target L1 transaction size. This is controlled by two parameters: @@ -84,14 +84,14 @@ The directions here are for [Foundry](https://book.getfoundry.sh/), but the conc ``` 2. Get the number of the latest finalized block. - If the result is greater than the block number of the transaction, or equal, the transaction is finalized. + If the result is greater than or equal to the block number of the transaction, the transaction is finalized. ```sh cast block finalized --field number ``` 3. Get the number of the latest safe block. - If the result is greater than the block number of the transaction, or equal, the transaction is safe. + If the result is greater than or equal to the block number of the transaction, the transaction is safe. ```sh cast block safe --field number diff --git a/pages/stack/transactions/transactions.mdx b/pages/stack/transactions/transactions.mdx deleted file mode 100644 index 02d703c69..000000000 --- a/pages/stack/transactions/transactions.mdx +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Transactions -description: Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. -lang: en-US ---- - -import { Card, Cards } from 'nextra/components' - -# Transactions - -Documentation covering Cross Domain, Deposit Flow, Fees, Forced Transaction, Transaction Flow, Withdrawal Flow in the Transactions section of the OP Stack ecosystem. - - - - - - - - - - - - - - diff --git a/public/img/op-stack/protocol/deposit-flow-dark-mode.svg b/public/img/op-stack/protocol/deposit-flow-dark-mode.svg new file mode 100644 index 000000000..0b020e9f2 --- /dev/null +++ b/public/img/op-stack/protocol/deposit-flow-dark-mode.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/public/img/op-stack/protocol/transaction-flow-dark-mode.svg b/public/img/op-stack/protocol/transaction-flow-dark-mode.svg new file mode 100644 index 000000000..931eb7d5d --- /dev/null +++ b/public/img/op-stack/protocol/transaction-flow-dark-mode.svg @@ -0,0 +1 @@ + \ No newline at end of file