Transaction Finality Explainer

pages/stack/protocol/rollup/_meta.json

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

pages/stack/protocol/rollup/finality.mdx

@@ -0,0 +1,135 @@
+---
+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'
+
+# OP Stack rollups
+
+OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum's consensus. This way, OP Stack rollup can take advantage of Ethereum's ordering mechanism and finalize its own blocks without needing to create a new consensus layer.
+
+## State Machines and Transaction Processing
+
+State machines, such as the EVM, rely on input lists (transactions) to evolve from one state to another. The list and its order are vital because incorrect ordering can lead to an invalid state.
+
+For example, if a user tries 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 ordering an essential aspect of consensus.
+
+## Commutative vs non-Commutative operations
+
+Commutative operations allow input order to change without affecting the outcome. However, non-commutative operations (like sending funds) require strict ordering. Hence, the list's availability and ordering are fundamental to ensuring the integrity of the system.
+
+## Consensus and Ordering
+
+Consensus determines the valid chain or list of transactions. In OP Stack, Ethereum's consensus (via Proof of Stake) is used to achieve transaction ordering and finality.
+
+## Why piggybacking on Ethereum?
+
+By publishing rollup blocks on Ethereum, OP Stack effectively outsource it's consensus mechanism. Instead of running a separate consensus protocol, they rely on Ethereum's ordering and finality guarantees.
+
+Key benefits of this approach include:
+
+*   OP Stack inherit Ethereum's security and ordering properties.
+*   The OP Stack simplifies the design and development process by removing the need for a separate consensus protocol.
+*   Attack vectors such as double-spends are mitigated by Ethereum's inherent mechanisms.
+
+### Transaction finality states
+
+In OP Stack, transaction finality involves three main stages:
+
+*   Unsafe: The L2 sequencer creates a block containing the transaction, but the transaction data will not been posted to L1. It is circulated within the L2 network for speed.
+
+*   Safe: The sequencer's batcher posts transaction data to L1. Any L2 node can now derive this transaction.
+
+*   Finalized: Transactions is finalized once more than (>65) L1 blocks have passed(approximately 20 minutes), ensuring the L1 data is secure and won't 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} />
+
+## Sequencer Operations
+
+The sequencer (block producer) handles transaction processing through the following steps:
+
+1.  Pre-publishing Distribution:
+    *   Sequencer receives transactions from users
+    *   Creates blocks containing these transactions
+    *   Distributes blocks to network nodes before L1 publication
+    *   Nodes mark these blocks as "unsafe"
+
+2.  L1 Publication:
+    *   Sequencer publishes blocks to Ethereum
+    *   Blocks become "safe" once included in L1
+    *   Blocks achieve "finalized" status after L1 finalization (approximately 20 minutes)
+
+### Sequencer Trust
+
+The sequencer's role involves certain trust assumptions:
+
+*   Can temporarily withhold transactions.
+*   May attempt to reorder transactions before L1 publication.
+*   Cannot modify or censor transactions once published to L1.
+*   Cannot affect finalized transactions.
+
+## 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; otherwise, it is discarded. Nodes execute valid blocks and update the rollup state accordingly.
+
+### Reorgs and finality
+
+A block's inclusion in a finalized Ethereum block ensures its finality. If a rollup block is included in a finalized Ethereum block, it cannot be reorged. Therefore, rollup blocks enjoy the same finality guarantees as Ethereum blocks, and this finality is handled by the **OP Stack** architecture.
+
+### Reorg Handling
+
+When L1 reorgs occur:
+
+1.  Nodes detect the L1 reorg
+2.  Affected L2 blocks return to "unsafe" status
+3.  Sequencer typically republishes the same transactions
+4.  System returns to 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 app-level validation system designed to ensure that certain claims about the rollup's state are correct.
+
+### What is a claim?
+
+A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `XYZ`. Other participants can challenge this claim if they believe it to be incorrect.
+
+### Fault proofs and challenges
+
+Challenges revolve around proving whether a given claim is valid. However, the outcome of a challenge does not affect the underlying chain. For example, if a claim about the state of the rollup at a certain block is proven wrong, it only affects the app-level functionality, not the OP Stack protocol.
+
+### Bridge Independence
+
+Important points about bridge systems:
+
+*   Bridges are application-level constructs
+*   They operate independently of the core rollup protocol
+*   Bridge security doesn't affect L2 transaction validity
+*   Bridge failures don't 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 app-level and not native to the OP Stack rollup. If there's an issue with the bridge, such as incorrect proof validation, it doesn't affect the rollup itself but impacts the subjective value of the bridged assets.
+
+## 7 days challenge period in OP Stack
+
+The 7 days challenge period exists to give time for challenges to be raised and resolved. While the rollup chain itself finalizes quickly (within 20 minutes), withdrawals from Layer 2 are delayed to allow for fault-proof validation. This ensures that malicious activity can be detected and challenged before it affects the system.
+
+### Why 7 days?
+
+The 7 day period is a reasonable time frame to allow participants to organize a response, potentially even organizing a hard fork on Layer 1 to address severe issues. In the context of the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom rollup 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 on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. While finality occurs quickly for rollup blocks, the proof system introduces a delay for withdrawals to ensure the security of bridging mechanisms.