Skip to content

Bind frontier v3 to execution prefixes and strict validation - #59

Closed
guzus wants to merge 1 commit into
nuntax:mainfrom
guzus:codex/frontier-v3-execution
Closed

guzus wants to merge 1 commit into
nuntax:mainfrom
guzus:codex/frontier-v3-execution

Conversation

@guzus

@guzus guzus commented Sep 8, 2026 •

Copy link
Copy Markdown

Why

A frontier handle used for execution must identify the complete provisional transaction prefix,
not only parent/block/index/last transaction. V2 could alias re-executions with different preceding
transactions. Also, validation: true previously still disabled sender-code and block-gas checks.

Change

  • Wire v3, fixed body 160 bytes: preserve the old 96-byte layout and append parentHash
    and nonzero OS-random attemptId before logs.
  • Prefix ID is Keccak over exactly 148 bytes:
    RHF3 || parentHash || blockBE64 || attemptId || previousId || indexBE64 || transactionHash.
    Index zero uses zero previous ID; subsequent indices must be contiguous. Duplicate IDs cannot
    overwrite retained state. New attempts revoke old handles even for identical parent/transactions.
  • Failed payload construction revokes its handles. Review additionally found that failure could
    happen before the per-block guard existed: now revocation happens at native build entry before
    provider acquisition, and at production entry before message parsing/pre-execution. The new
    regression exercises actual early production failure after a completed prior attempt.
  • Add arb_frontierCapabilities, identity fields and explicit validationChecks in simulation.
    Strict mode resets nonce/base-fee/EIP-3607/block-gas flags, enforces balance checks, rejects
    protocol/custom transaction types and missing/zero/over-cap gas without clamping intent.
    Both modes check canonical parent and active attempt before and after simulation.

Scope and rollout

No merge, deployment, restart, configuration change, or order activation in this PR. This is
a node integration prerequisite, not evidence that the Rust trading system is production-ready.

V3 breaks v2 Go MEV consumers. The observed rh-reth-1 unit named
robinhood-arb-shadow.service was actually armed; disable or upgrade incompatible consumers and
verify the real writer before a separately authorized deployment. Save and hash the exact old
binary/config; keep the independent post latch and active arb-reth-rssguard.service effective.
Build with bounded resources. Rollback must stop the new consumer, restore compatible node/config,
and leave the v3 Rust writer blocked; it must not automatically re-arm Go. See the updated
docs/mev-tx-log-ipc.md for protocol, error, and rollout contracts.

Canonical parent checks and prefix witnesses are not finality or inclusion promises. RPC simulation
does not verify a signature, submit a transaction, or account for poster-byte L1 fees. Consumer
age, fee/profit, nonce ownership, live parity and single-writer handoff remain required.

Verification

  • Linux optimized full library tests: 25 engine passed; 73 node passed, 1 existing manual stress
    test ignored
    , zero failures. Exact command:
    cargo test --locked --offline --release -j 2 -p arb-reth-engine -p arb-reth-node --lib.
  • Separate frontier filter: engine 6/6, node 5/5, including actual Arb EVM checks and entry failure.
  • Touched-file rustfmt and git diff --check pass. Untouched workspace rustfmt differences remain.
  • Full receipt, toolchain/lock/test-binary hashes and identical local/remote source hashes:
    docs/frontier-v3-verification-2026-09-08.md.
  • CI separately runs full-workspace check/clippy/tests on Rust 1.97.1. Local tests used the existing
    Linux host's Rust 1.98.1 in an isolated source/cache copy, no external RPC or services changed.
    Library tests compiled the node library; this is not a new deployable node CLI binary receipt.
  • Upstream CI currently reports action_required with no jobs run for this fork PR:
    https://github.com/nuntax/arbitrum-reth/actions/runs/34228024438. Maintainer action is needed;
    this is not a CI pass. GitGuardian Security Checks passed.

@guzus guzus closed this Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant