[GH-ISSUE #3743] [Feature] OP Stack reverse engineering: L1 batches, deposits, withdrawals, derivation and fault-proof artifacts #1450

New issue

Open

opened 2026-10-16 21:05:33 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:05:33 +00:00

Owner

Originally created by @matbrgz on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3743

Problem Statement & Context

The OP Stack (powering OP Mainnet, Base, Zora, Mode, and the Superchain ecosystem) represents the most widely deployed Optimistic Rollup framework on Ethereum.

An OP Stack rollup is not an isolated blockchain; its canonical state is derived directly from Layer 1 Ethereum:

L1 Batch Ingestion & Channel Derivation: Sequencer transaction batches posted to L1 batch inbox addresses (e.g., as EIP-4844 blobs or calldata). Batches are framed into channels, compressed using Zlib, and decompressed into sequential L2 execution blocks.
Deposit Transactions & System Config: L1-to-L2 deposits initiated via OptimismPortal contracts, creating special L1Attributes transactions in each L2 block without cryptographic signatures (derived from L1 event logs).
Withdrawal Provenance & Two-Step Finalization: L2-to-L1 withdrawals initiated via L2ToL1MessagePasser, requiring an on-chain Merkle proof against the L2OutputOracle / DisputeGameFactory, followed by a 7-day challenge window and finalization call.
Fault Proof Artifacts (Cannon / op-challenger): Interactive dispute games executing MIPS32 / 64-bit state transition programs inside a single-step fault-proof virtual machine to resolve disputed L2 state claims.

Reverse engineering an incident or transaction on an OP Stack rollup requires tracing derivation pipelines from L1 down to L2. REA needs a dedicated OP Stack analyzer capable of parsing L1 batch blobs, reconstructing channel frames, modeling deposit/withdrawal lifecycles, and inspecting fault-proof dispute artifacts.

Proposed Architecture

flowchart TD
    A["L1 Batch Data (Blobs / Calldata) / L2 Block Data / Dispute Game State"] --> B["OP Stack Semantic Engine"]
    B --> C["L1 Batch Derivation & Channel Decompressor"]
    B --> D["Deposit & SystemConfig Parser"]
    B --> E["Withdrawal Lifecycle & State Prover"]
    B --> F["Fault-Proof Dispute Game Inspector (Cannon MIPS)"]
    
    C --> C1["EIP-4844 Blob / Calldata Slicing"]
    C --> C2["Channel Frame Assembly & Zlib Decompression"]
    C --> C3["Sequential L2 Transaction Batches"]
    
    D --> D1["OptimismPortal Deposit Log Reconstruction"]
    D --> D2["L1Block / L1Attributes Predeployed Contract Mapping"]
    
    E --> E1["L2ToL1MessagePasser Storage Withdrawal Hash"]
    E --> E2["ProveWithdrawal & FinalizeWithdrawal Transaction Tracking"]
    
    F --> F1["DisputeGameFactory State Claims"]
    F --> F2["Cannon MIPS Single-Step State Witness Parsing"]
    
    C & D & E & F --> G["Synthesized L1 ↔ L2 Cross-Layer Derivation Blueprint & Transaction Graph"]

Technical Capabilities & Modules

L1 Derivation Pipeline Slicing:
- Ingest raw L1 transactions targeting the batch inbox address (including EIP-4844 blob sidecars).
- Parse channel framing: Channel ID, Frame Number, Is Last flag, Frame Data.
- Assemble and decompress complete channel streams to recover canonical L2 block transactions.
Deposit Transaction Reconstruction:
- Detect TransactionDeposited event logs emitted by OptimismPortal on L1.
- Map how L1 deposits are translated into unsigned deposit transactions (Type 0x7E) on L2.
- Track SystemConfig updates: gas limits, basefee overhead, scalar parameters, and batcher address updates.
Withdrawal Lifecycle & Proof Tracking:
- Trace L2-to-L1 withdrawals:
  - Step 1: L2 transaction calling L2ToL1MessagePasser.initiateWithdrawal.
  - Step 2: L1 transaction calling OptimismPortal.proveWithdrawalTransaction with storage proof.
  - Step 3: L1 transaction calling OptimismPortal.finalizeWithdrawalTransaction after challenge delay.
- Model the complete multi-day state progression into a unified status graph.
Fault-Proof & Dispute Game Analysis:
- Dissect dispute game contracts (FaultDisputeGame, PermissionedDisputeGame).
- Parse claims, bisection tree positions, and claim clocks.
- Inspect single-step fault proof traces executed under Cannon (MIPS32 machine state, memory reads/writes, preimage oracle lookups).

Acceptance Criteria

Automated decoding of OP Stack batch frames from L1 calldata and EIP-4844 blobs.
Decompression and extraction of L2 blocks and transactions from channel byte streams.
End-to-end correlation linking L1 deposit events to L2 deposit transactions.
Verification of three-step withdrawal lifecycles between L2 and L1.
Inspection of fault proof dispute game bisection trees and claims.

Complements #972 (Solidity/EVM reverse engineering)
Complements #2391 (EVM calldata and execution trace analysis)
Complements #3621 (Unknown binary file-format inference)

Originally created by @matbrgz on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3743 [![Type: Feature](https://img.shields.io/badge/type-feature-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Domain: Reverse Engineering](https://img.shields.io/badge/domain-reverse_engineering-blueviolet.svg?style=flat-square)](https://github.com/morluto/rea) [![Status: Proposed](https://img.shields.io/badge/status-proposed-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Ecosystem: REA](https://img.shields.io/badge/ecosystem-morluto%2Frea-8A2BE2.svg?style=flat-square)](https://github.com/morluto/rea) ### Problem Statement & Context The OP Stack (powering OP Mainnet, Base, Zora, Mode, and the Superchain ecosystem) represents the most widely deployed Optimistic Rollup framework on Ethereum. An OP Stack rollup is not an isolated blockchain; its canonical state is derived directly from Layer 1 Ethereum: 1. **L1 Batch Ingestion & Channel Derivation**: Sequencer transaction batches posted to L1 batch inbox addresses (e.g., as EIP-4844 blobs or calldata). Batches are framed into channels, compressed using Zlib, and decompressed into sequential L2 execution blocks. 2. **Deposit Transactions & System Config**: L1-to-L2 deposits initiated via `OptimismPortal` contracts, creating special `L1Attributes` transactions in each L2 block without cryptographic signatures (derived from L1 event logs). 3. **Withdrawal Provenance & Two-Step Finalization**: L2-to-L1 withdrawals initiated via `L2ToL1MessagePasser`, requiring an on-chain Merkle proof against the `L2OutputOracle` / `DisputeGameFactory`, followed by a 7-day challenge window and finalization call. 4. **Fault Proof Artifacts (Cannon / op-challenger)**: Interactive dispute games executing MIPS32 / 64-bit state transition programs inside a single-step fault-proof virtual machine to resolve disputed L2 state claims. Reverse engineering an incident or transaction on an OP Stack rollup requires tracing derivation pipelines from L1 down to L2. REA needs a dedicated OP Stack analyzer capable of parsing L1 batch blobs, reconstructing channel frames, modeling deposit/withdrawal lifecycles, and inspecting fault-proof dispute artifacts. ### Proposed Architecture ```mermaid flowchart TD A["L1 Batch Data (Blobs / Calldata) / L2 Block Data / Dispute Game State"] --> B["OP Stack Semantic Engine"] B --> C["L1 Batch Derivation & Channel Decompressor"] B --> D["Deposit & SystemConfig Parser"] B --> E["Withdrawal Lifecycle & State Prover"] B --> F["Fault-Proof Dispute Game Inspector (Cannon MIPS)"] C --> C1["EIP-4844 Blob / Calldata Slicing"] C --> C2["Channel Frame Assembly & Zlib Decompression"] C --> C3["Sequential L2 Transaction Batches"] D --> D1["OptimismPortal Deposit Log Reconstruction"] D --> D2["L1Block / L1Attributes Predeployed Contract Mapping"] E --> E1["L2ToL1MessagePasser Storage Withdrawal Hash"] E --> E2["ProveWithdrawal & FinalizeWithdrawal Transaction Tracking"] F --> F1["DisputeGameFactory State Claims"] F --> F2["Cannon MIPS Single-Step State Witness Parsing"] C & D & E & F --> G["Synthesized L1 ↔ L2 Cross-Layer Derivation Blueprint & Transaction Graph"] ``` ### Technical Capabilities & Modules 1. **L1 Derivation Pipeline Slicing:** - Ingest raw L1 transactions targeting the batch inbox address (including EIP-4844 blob sidecars). - Parse channel framing: Channel ID, Frame Number, Is Last flag, Frame Data. - Assemble and decompress complete channel streams to recover canonical L2 block transactions. 2. **Deposit Transaction Reconstruction:** - Detect `TransactionDeposited` event logs emitted by `OptimismPortal` on L1. - Map how L1 deposits are translated into unsigned deposit transactions (Type `0x7E`) on L2. - Track `SystemConfig` updates: gas limits, basefee overhead, scalar parameters, and batcher address updates. 3. **Withdrawal Lifecycle & Proof Tracking:** - Trace L2-to-L1 withdrawals: - Step 1: L2 transaction calling `L2ToL1MessagePasser.initiateWithdrawal`. - Step 2: L1 transaction calling `OptimismPortal.proveWithdrawalTransaction` with storage proof. - Step 3: L1 transaction calling `OptimismPortal.finalizeWithdrawalTransaction` after challenge delay. - Model the complete multi-day state progression into a unified status graph. 4. **Fault-Proof & Dispute Game Analysis:** - Dissect dispute game contracts (`FaultDisputeGame`, `PermissionedDisputeGame`). - Parse claims, bisection tree positions, and claim clocks. - Inspect single-step fault proof traces executed under Cannon (MIPS32 machine state, memory reads/writes, preimage oracle lookups). ### Acceptance Criteria - [ ] Automated decoding of OP Stack batch frames from L1 calldata and EIP-4844 blobs. - [ ] Decompression and extraction of L2 blocks and transactions from channel byte streams. - [ ] End-to-end correlation linking L1 deposit events to L2 deposit transactions. - [ ] Verification of three-step withdrawal lifecycles between L2 and L1. - [ ] Inspection of fault proof dispute game bisection trees and claims. ### Related Issues & Dependencies - Complements #972 (Solidity/EVM reverse engineering) - Complements #2391 (EVM calldata and execution trace analysis) - Complements #3621 (Unknown binary file-format inference)

bsakaguchi referenced this issue

2026-10-17 21:11:32 +00:00

[PR #1450] [MERGED] perf(process): stop padding rendered terminal lines to full width #2895

bsakaguchi referenced this issue

2026-10-17 21:11:37 +00:00

[PR #1465] [MERGED] docs(process): clarify normalized terminal line representation #2904

bsakaguchi referenced this issue

2026-10-17 21:11:40 +00:00

[PR #1466] [CLOSED] docs(process): clarify normalized terminal row geometry #2905