Transaction Finality Explainer

pages/stack/transactions/_meta.json

@@ -3,5 +3,6 @@
     "transaction-flow": "Transaction Flow",
     "deposit-flow": "Deposit Flow",
     "withdrawal-flow": "Withdrawal Flow",
+    "transaction-finality":"Transaction finality",
     "forced-transaction": "Forced Transaction"
 }

pages/stack/transactions/transaction-finality.mdx

@@ -0,0 +1,140 @@
+---
+title: Transaction Finality
+lang: en-US
+description: Learn about finality in OP Stack and the steps to achieve transaction settlement.
+---
+
+import Image from 'next/image'
+import { Callout } from 'nextra/components'
+
+# Overview
+
+This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges.
+
+OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. 
+This enables it to take advantage of Ethereum's transaction ordering mechanism and finalize its own blocks without requiring a new consensus layer.
+
+## State Machines and Transaction Processing
+
+State machines, such as the Ethereum Virtual Machine (EVM), rely on input lists (transactions) to evolve from one state to another. The order of the transactions is critical because incorrect ordering can lead to an invalid state.
+
+For example, if a user attempts to send 1 ETH to two different parties at the same time, only one transaction can be valid. The order determines which transaction succeeds, making transaction ordering an essential aspect of consensus.
+
+## Commutative vs. Non-Commutative Operations
+
+Commutative operations allow the order of inputs to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Therefore, both the availability and the order of the transaction list are fundamental to ensuring the system's integrity.
+
+## Consensus and Ordering
+
+Consensus determines the valid chain or list of transactions. In the OP Stack, Ethereum's Proof of Stake (PoS) consensus mechanism is used to achieve transaction ordering and finality.
+
+## Why Use Ethereum's Consensus?
+
+By publishing blocks on Ethereum, the OP Stack effectively outsources its consensus mechanism. Instead of creating a separate consensus protocol, the OP Stack relies on Ethereum's ordering and finality guarantees.
+
+### Key benefits of this approach:
+
+*   OP Stack inherits Ethereum's security and transaction ordering properties.
+*   It simplifies the design and development process by eliminating the need for a separate consensus protocol.
+*   Attack vectors, such as double-spends, are mitigated by Ethereum's security mechanisms.
+
+## Sequencer Operations
+
+The sequencer (block producer) processes transactions in the following steps:
+
+1.  Pre-publishing Distribution:
+    *   The sequencer receives transactions from users.
+    *   It creates blocks containing these transactions.
+    *   It distributes these blocks to network nodes before L1 publication.
+    *   Nodes mark these blocks as "unsafe."
+
+2.  L1 Publication:
+    *   The sequencer publishes the blocks to Ethereum (L1).
+    *   Once included in L1, the blocks are marked as "safe."
+    *   Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes).
+
+### Sequencer Trust Assumptions
+
+The sequencer operates with the following trust assumptions:
+
+*   It can temporarily withhold transactions.
+*   It may attempt to reorder transactions before L1 publication.
+*   Once transactions are published on L1, the sequencer cannot modify or censor them.
+*   The sequencer cannot affect finalized transactions.
+
+## Transaction Finality States
+
+In the OP Stack, transaction finality progresses through three key stages:
+
+1.  **Unsafe:** The L2 sequencer creates a block containing the transaction, but the transaction data has not yet been posted to Ethereum (L1). The block is circulated within the L2 network for speed.
+
+2.  **Safe:** The sequencer's batcher posts the transaction data to L1. At this point, any L2 node can derive the transaction.
+
+3.  **Finalized:** Transactions are finalized once more than 65 Ethereum blocks (approximately 20 minutes) have passed, ensuring that the L1 data is secure and cannot be reorganized.
+
+<Image src="/img/op-stack/protocol/tx-finality.png" alt="Transaction Finality Diagram." width={0} height={0} sizes="100vw" style={{ width: '100%', height: 'auto' }} quality={100} />
+
+## Block and Transaction Validity in the OP Stack
+
+When a block is submitted to Ethereum, it is either valid or invalid. If the block is valid, the state is updated accordingly. If it is invalid, the block is discarded. Nodes execute valid blocks and update the state as required.
+
+### Reorgs and Finality
+
+Once a block is included in a finalized Ethereum block, it cannot be reorganized. Therefore, blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is managed by the OP Stack architecture.
+
+### Handling Reorgs
+
+If an Ethereum reorganization (reorg) occurs:
+
+1.  L2 nodes detect the L1 reorg.
+2.  Affected L2 blocks revert to an "unsafe" status.
+3.  The sequencer typically republishes the same transactions.
+4.  The system returns to a consistent state after reprocessing.
+
+## The Role of the Proof System
+
+The proof system is entirely separate from the core OP Stack protocol. It is an application-level validation system designed to ensure the accuracy of certain claims about the transaction state.
+
+### What Is a Claim?
+
+A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it.
+
+### Fault Proofs and Challenges
+
+Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol.
+
+### Bridge Independence
+
+Key aspects of bridge systems include:
+
+*   Bridges are application-level constructs.
+*   They operate independently from the core OP Stack protocol.
+*   Bridge security does not affect the validity of L2 transactions.
+*   Bridge failures do not cause L2 reorgs or state changes.
+
+### Example: Custom Bridges in OP Stack
+
+A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets.
+
+## 7-Day Challenge Period in OP Stack
+
+The 7-day challenge period provides time for challenges to be raised and resolved. 
+Although OP Stack finalizes transactions quickly (within 20 minutes), withdrawals from L2 are delayed to allow for fault-proof validation. 
+This delay ensures that any malicious activity can be detected and addressed before it impacts the system.
+
+### Why Seven Days?
+
+The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol.
+
+### Withdrawal Delays vs. Finality
+
+One common misconception is confusing withdrawal delays with transaction finality:
+
+*   Transaction finality occurs in approximately 20 minutes.
+*   Withdrawal delays (often 7 days) are separate from transaction finality.
+*   Withdrawal delays are application-level security features.
+*   These delays affect only L1 withdrawals, not L2 transaction finality.
+
+## Conclusion
+
+Transaction finality in the OP Stack relies on Ethereum's consensus mechanism. The OP Stack inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While blocks finalize quickly, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms.

words.txt

@@ -16,6 +16,7 @@ Arweave
 authrpc
 Badgeholder's
 Badgeholders
+badgeholders
 basefee
 BGEZ
 BGTZ
@@ -169,7 +170,6 @@ leveldb
 lightkdf
 logfile
 logfmt
-marketshare
 MAXAGE
 maxage
 MAXBACKUPS
@@ -204,7 +204,6 @@ MTHI
 MTLO
 MULT
 multiaddr
-Multichain
 multichain
 multiclient
 multisigs
@@ -303,7 +302,7 @@ replayability
 reproven
 REQUIREDBLOCKS
 requiredblocks
-Rollouts
+rollouts
 Rollups
 rollups
 Routescan