feat(derivation): SPEC-005 narrow scope — validator removal + Path A/B startup-time verification mode select#951
Open
curryxbo wants to merge 15 commits into
Open
feat(derivation): SPEC-005 narrow scope — validator removal + Path A/B startup-time verification mode select#951curryxbo wants to merge 15 commits into
curryxbo wants to merge 15 commits into
Conversation
Replace the internal codename "bitget" with the neutral term "polyrepo" in build context references, variable names, and container paths.
Cover the rest of the file with one-line docstrings to satisfy CodeRabbit's docstring coverage threshold.
…g Dockerfile.l2-geth Move the morph-el-0 build: section from docker-compose-4nodes.yml into a dedicated docker-compose-geth-build.yml, included only when EXECUTION_CLIENT=geth. The reth overlay now sees no build: on morph-el-0, eliminating the risk of docker compose up building geth code and tagging it as the reth image when the reth image is absent.
Keep the base devnet compose file self-contained for geth while using the reth overlay to explicitly reset inherited geth build definitions. Constraint: Do not include the devnet execution-client test file in this commit Rejected: Keep a separate geth build compose file | changes direct base compose usage Confidence: high Scope-risk: narrow
[codex] support reth execution client in devnet
- Delete node/validator package (config.go, validator.go, validator_test.go) - Drop validator wiring from node/cmd/node/main.go and derivation.NewDerivationClient signature - Drop validator field from Derivation struct - Drop ChallengeEnable/ChallengeState invocation in derivation rollback path - Remove validator.challengeEnable / validator.privateKey CLI flags - Remove MORPH_NODE_VALIDATOR_PRIVATE_KEY env from docker compose files Refs: morph-l2/morph-specs SPEC-005 §4.1 Equivalent in intent to PR #948 commit 3e49457, but applied directly to main without the Phase A reorg/halted/rollback context that 3e49457 brought along.
Same as the merge previously applied to PR #948's branch — needed because PR #935 (multi_batch / Batch Header v2) hasn't landed in main yet, but SPEC-005 narrow scope's Path B implementation depends on common/batch + common/blob packages introduced by it. Resolutions: - ops/docker/docker-compose-4nodes.yml: take origin/feat/multi_batch's TX_SUBMITTER_PRIORITY_ROLLUP=true and drop TX_SUBMITTER_SEAL_BATCH; that env block is owned by tx-submitter, which feat/derivation-batch-verify should not be modifying. - go-ethereum submodule: keep at 045be0fd (v2.2.2). Multi_batch's 53aee9b internal merge accidentally regressed the pointer to 1d460577; that regression is unrelated to multi_batch's design intent and should not propagate to feat/derivation-batch-verify.
Pull the inline state-root / withdrawal-root mismatch check out of
derivationBlock into a standalone verifyBatchRoots(batchInfo, lastHeader)
function in a new node/derivation/verify.go.
Both roots are read from L1 calldata at parse time, so verifyBatchRoots
is independent of blob data — this is the SPEC-005 §3.4 invariant that
later allows Path B (local-rebuild verification) to reuse this same
check without modification.
No behavior change: the main loop still logs + returns on mismatch, sets
stateException on the metric, and continues otherwise. Only the location
and error-message format change.
Refs: morph-l2/morph-specs SPEC-005 §4.2 / §6 ("两种模式共享同一份 verifyBatchRoots")
Contributor
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (79)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
6 tasks
Introduces Path B verification mode (SPEC-005 §4) as a startup-time
mutually-exclusive alternative to Path A. Selected via
`--derivation.verify-mode` (default "pathA", preserves current
behaviour). The two modes do not interact: under no circumstance does
the node fall back from one to the other; switching requires changing
the config and restarting.
Path B mode:
- Skips beacon-side blob fetch entirely.
- Reads L1 commitBatch tx calldata + tx.BlobHashes() only.
- Reads local L2 blocks for the batch range, replays the sequencer's
encoding (parsingTxs + buildBlockContext + BatchData) to rebuild
the blob bytes.
- Compresses + builds a BlobTxSidecar; compares its versioned hashes
against the values from L1 calldata.
- Reuses the shared verifyBatchRoots for state/withdrawal root
verification (independent of blob).
Touches:
- common/batch: export ParsingTxs / BuildBlockContext (rename from
package-private). No semantic change for tx-submitter.
- node/derivation/batch_info.go: add BatchInfo.blobHashes field;
add ParseBatchMetadataOnly (calldata-only parse, no blob).
- node/derivation/config.go + flags: add VerifyMode + flag with
fail-fast validation on unknown values.
- node/derivation/derivation.go: dispatch in main loop based on
verifyMode; populate blobHashes in Path A's fetch helper too so
BatchInfo is consistent across modes.
- node/derivation/verify_path_b.go: fetchBatchInfoPathB +
verifyBatchContentPathB + fetchLocalLastHeader.
- node/derivation/metrics.go: path_b_triggered_total /
path_b_failed_total counters.
Verified clean: `go build ./node/... ./common/...`, `go vet`,
test compile.
Refs: morph-l2/morph-specs SPEC-005 §4 / §5 / §6
Resolves the WIP item flagged in PR #951.
curryxbo
changed the title
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scope
Aligns with the current narrow SPEC-005 scope (morph-l2/morph-specs#19 / spec PR #18):
Relationship to PR #948
This PR replaces PR #948. Items from PR #948 that fall outside the narrow scope (reorg detection, halted state, rollback executor, admin RPC, sequencer mutex, 4-stage state model, etc.) are split into a separate `[DEFER]` PR #950.
Commits
Design
The two modes are completely independent. There is no automatic fallback under any circumstance: if Path A's blob fetch fails, the node does not silently switch to Path B. Switching modes requires changing config and restarting.
`verifyBatchRoots` (state root + withdrawal root, read from L1 calldata) is shared by both modes; it is independent of blob data.
Prerequisite
PR #935 (`feat/multi_batch`): Path B implementation reuses `common/batch` and `common/blob` packages introduced by it. While PR #935 is unmerged, this PR's base is conceptually `feat/multi_batch`; once #935 lands in main, this PR can be rebased onto main.
Key code points
TODO (separate commits / follow-up sessions)
Test plan