[Feat] Galileo forking #1753
[Feat] Galileo forking #1753
Conversation
WalkthroughProject version bumped to v4.7.1; workspace Cargo deps pinned to tags; per-asset Changes
Sequence Diagram(s)sequenceDiagram
actor Coordinator
participant VerifierInit as Verifier Init
participant LibZKP as libzkp
participant ProverBin as Prover Bin
participant TaskExt as ProvingTaskExt
rect rgb(243,247,255)
note left of Coordinator: Old flow (pre-change)
Coordinator->>VerifierInit: load VerifierConfig (features)
VerifierInit->>LibZKP: SetDynamicFeature(features)
LibZKP->>LibZKP: set global dynamic feature
end
rect rgb(247,255,243)
note left of Coordinator: New flow (per-asset / per-task)
Coordinator->>VerifierInit: load AssetConfig (features)
VerifierInit->>LibZKP: verifier_init(circuits) — parse features map
LibZKP->>LibZKP: populate per-fork FeatureOptions registry
ProverBin->>TaskExt: deserialize input -> ProvingTaskExt (use_openvm_13)
TaskExt->>ProverBin: return ProvingTaskExt
ProverBin->>LibZKP: request gen_universal_* (no fork param)
LibZKP->>LibZKP: precheck/into_proving_task_with_precheck -> (pi_hash, metadata, ProvingTask)
LibZKP->>ProverBin: return (pi_hash, metadata, ProvingTask)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. 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 |
|
e2e test (for galileo blocks with guest |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
common/version/version.go (1)
8-8: Verify the version jump from 4.6.3 to 4.7.1.Skipping version 4.7.0 is unusual. Was this intentional, or should it be 4.7.0 instead?
Cargo.toml (1)
17-17: Version bump aligns with project-wide update.The version bump to 4.7.1 is consistent with the version update in
common/version/version.go. However, as noted in another comment, skipping 4.7.0 is unusual and should be verified as intentional.
🧹 Nitpick comments (9)
tests/prover-e2e/sepolia-galileo/config.json (1)
4-4: Test environment credentials are acceptable; refactoring to env vars is optional.The hardcoded credentials in this test config are intentional. The docker-compose.yml explicitly marks this setup as "for local debugging only" and binds PostgreSQL exclusively to localhost (127.0.0.1:5432). The credentials match the docker-compose environment variables, confirming this is part of the designed local test infrastructure. Since this is a self-contained local-only setup with no production exposure, the hardcoded "dev:dev" credentials are acceptable and consistent across all prover-e2e test configs.
Migrating to environment variables would be a nice refactoring improvement, but is not required for this context.
crates/prover-bin/src/prover.rs (1)
275-303: Handler cache ignores TaskConfig; fine today, but fragile if config ever varies by taskWith the new
(prover_task, task_cfg)tuple, you correctly threadtask_cfgintoUniversalHandler::new. However, the handler cache is still keyed only byvk, so any subsequent task with the samevkwill reuse the existing handler regardless of itsTaskConfig.Given the current design (per-fork features → constant
use_openvm_13per circuit/vk), that’s effectively safe. But if you ever introduce task-level variability foris_openvm_v13(or more TaskConfig fields), the cache will silently give you a handler initialized with stale config.To make this more robust, consider keying the cache by
(vk, is_openvm_v13)or asserting thattask_cfg.is_openvm_v13matches when reusing a handler:- let handler = if let Some(handler) = self.handlers.get(&vk) { + let handler = if let Some(handler) = self.handlers.get(&vk) { handler.clone() } else { … let circuits_handler = Arc::new(Mutex::new(UniversalHandler::new(&asset_path, &task_cfg)?)); self.handlers.insert(vk, circuits_handler.clone()); circuits_handler };(If you keep single-key cache, a runtime assert comparing the stored config vs new
task_cfgwould at least fail loudly if the invariant is ever broken.)crates/libzkp/src/lib.rs (3)
37-56: FeatureOptions parsing is fine; consider skipping empty segments to avoid noisy logs
FeatureOptions::newwalks a colon-separated list and logs a warning for any unrecognized token. If the config ever provides an empty string or trailing colon (e.g."legacy_witness:"), you’ll end up with an “unrecognized dynamic feature” warning for the empty segment.Not a correctness issue, but you can cheaply avoid noise:
- for feat_s in feats.split(':') { - match feat_s.trim().to_lowercase().as_str() { + for feat_s in feats.split(':') { + let feat_s = feat_s.trim(); + if feat_s.is_empty() { + continue; + } + match feat_s.to_lowercase().as_str() { "legacy_witness" => { … } "openvm_13" => { … } s => tracing::warn!("unrecognized dynamic feature: {s}"), } }Overall, the feature registry wiring in
verifier_init(buildingADDITIONAL_FEATURESfromcfg.circuits) looks solid.Also applies to: 247-265
136-193: Version/fork consistency checks and ProvintTaskExt wrapping look good; minor error-message polishThe enhancements in
gen_universal_taskdo a few important things correctly:
- Normalize
task.fork_nameto lowercase and enforce that it matches thefork_name_strargument.- Independently decode
Version::from(task.version)and enforce thatversion.forkagrees with the fork argument as well.- Wrap the resulting
u_taskintoProvintTaskExtand apply per-forkfor_openvm_13_proverfromADDITIONAL_FEATURES, giving a single source of truth for OpenVM 13 flags.This substantially hardens task sanity checking and feature propagation.
The only nit: the panic-catch error message is
"caught panic in chunk task{e}"for all three task types (chunk/batch/bundle); if you care about log clarity, you might want to either use task-specific labels or a generic"caught panic in universal task {e}".Also applies to: 199-218
58-60: set_dynamic_feature is now deprecated; confirm all callers are truly obsoleteTurning
set_dynamic_featureinto a no-op that just logs an error is consistent with moving to config-time features viaverifier_init. However, any existing FFI or external callers relying on runtime feature toggling will now silently stop working apart from the log message.If that’s intentional, consider documenting this deprecation clearly (e.g., in release notes or header comments) and, where feasible, removing or gating the C FFI export in a future breaking release so that consumers don’t assume it still has effect.
crates/libzkp/src/tasks/chunk.rs (1)
212-244: Avoid hard-codingVersion::euclid_v2()in deprecated interpreter pathIn
prepare_task_via_interpret, using a fixedVersion::euclid_v2()when callingbuild_guest_inputmay diverge fromself.versionif this helper is ever used for non-EuclidV2 chunks (e.g., Feynman/Galileo or validium), which could subtly change witness construction during the retry loop.Unless this method is only ever invoked for EuclidV2 tasks, it would be safer and simpler to derive the version from the task itself:
- loop { - let witness = self.build_guest_input(Version::euclid_v2()); + loop { + let witness = self.build_guest_input(Version::from(self.version));This keeps the deprecated path behavior consistent with other call sites.
crates/libzkp/src/tasks/bundle.rs (1)
49-76: Bundle guest input + precheck now correctly version-aware with per-version pi-hash
build_guest_input(&self, version: Version)constructingBundleWitnessandprecheck_and_build_metadataderiving(BundleInfo, pi_hash_by_version(version)), pluscheck_aggregation_proofs(witness.batch_infos, Version::from(self.version)), aligns bundle behavior with batch/chunk. This ensures the pi-hash and adjacency validation are both driven by the same version.If you want a micro-cleanup, you could reuse the local
versionincheck_aggregation_proofsto avoid a secondVersion::from(self.version)call, but it’s not significant.crates/libzkp/src/tasks.rs (2)
38-59:ProvintTaskExtwrapper cleanly adds theuse_openvm_13flag while preserving task shapeFlattening
ProvingTaskintoProvintTaskExtand adding ause_openvm_13bool with a default offalseis a neat way to extend the serialized format without breaking existing consumers. TheFrom<ProvintTaskExt> for ProvingTaskplusProvintTaskExt::new(task)helpers are minimal and sufficient.If you expect frequent construction from plain
ProvingTask, you might also consider animpl From<ProvingTask> for ProvintTaskExtas a minor ergonomics improvement, but it’s optional.
91-105: Bundle universal task: duplicatedbundle_pi_hashreturn vs metadata seems intentional but worth double-checking
gen_universal_bundle_tasknow returnsbundle_pi_hashboth as the first tuple element and embedded inBundleProofMetadata { bundle_info, bundle_pi_hash }. This looks deliberate (e.g., convenience for callers that only care about the hash while keeping it in metadata for downstream uses), but it does mean the same value is carried twice.If there’s no compatibility constraint forcing both, you could consider dropping one of them; otherwise, please confirm callers rely on this shape as-is.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (27)
Cargo.toml(1 hunks)common/version/version.go(1 hunks)coordinator/conf/config.json(1 hunks)coordinator/internal/config/config.go(1 hunks)coordinator/internal/logic/libzkp/lib.go(0 hunks)coordinator/internal/logic/provertask/batch_prover_task.go(3 hunks)coordinator/internal/logic/verifier/verifier.go(2 hunks)crates/libzkp/Cargo.toml(1 hunks)crates/libzkp/src/lib.rs(3 hunks)crates/libzkp/src/proofs.rs(0 hunks)crates/libzkp/src/tasks.rs(3 hunks)crates/libzkp/src/tasks/batch.rs(8 hunks)crates/libzkp/src/tasks/bundle.rs(3 hunks)crates/libzkp/src/tasks/chunk.rs(5 hunks)crates/libzkp/src/verifier.rs(1 hunks)crates/prover-bin/Cargo.toml(1 hunks)crates/prover-bin/src/prover.rs(2 hunks)crates/prover-bin/src/zk_circuits_handler/universal.rs(2 hunks)tests/prover-e2e/Makefile(3 hunks)tests/prover-e2e/cloak-xen/.make.env(1 hunks)tests/prover-e2e/prepare/dump_block_records.sql(1 hunks)tests/prover-e2e/sepolia-feynman/.make.env(1 hunks)tests/prover-e2e/sepolia-feynman/genesis.json(1 hunks)tests/prover-e2e/sepolia-galileo/.make.env(1 hunks)tests/prover-e2e/sepolia-galileo/config.json(1 hunks)tests/prover-e2e/sepolia-galileo/genesis.json(1 hunks)zkvm-prover/config.json.template(1 hunks)
💤 Files with no reviewable changes (2)
- coordinator/internal/logic/libzkp/lib.go
- crates/libzkp/src/proofs.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-16T02:09:51.657Z
Learnt from: noel2004
Repo: scroll-tech/scroll PR: 1736
File: crates/libzkp/src/verifier/universal.rs:35-45
Timestamp: 2025-09-16T02:09:51.657Z
Learning: The verify_stark_proof method in scroll-zkvm-verifier returns Result<(), Error> indicating success/failure, not Result<bool, Error>. When it succeeds, verification passed; when it fails, it returns an error.
Applied to files:
crates/libzkp/src/tasks/bundle.rscrates/libzkp/src/tasks/batch.rs
🧬 Code graph analysis (9)
coordinator/internal/logic/provertask/batch_prover_task.go (1)
coordinator/internal/utils/version.go (1)
Version(16-40)
crates/prover-bin/src/zk_circuits_handler/universal.rs (2)
crates/libzkp/src/lib.rs (1)
new(38-55)crates/libzkp/src/tasks.rs (1)
new(53-58)
crates/prover-bin/src/prover.rs (1)
crates/prover-bin/src/zk_circuits_handler/universal.rs (2)
get_task_from_input(46-53)new(25-38)
crates/libzkp/src/lib.rs (5)
coordinator/internal/types/auth.go (1)
HardForkName(24-24)crates/libzkp/src/tasks.rs (2)
new(53-58)from(47-49)crates/libzkp_c/src/lib.rs (1)
set_dynamic_feature(281-284)crates/libzkp/src/utils.rs (1)
panic_catch(43-53)crates/libzkp/src/verifier.rs (1)
init(61-83)
crates/libzkp/src/verifier.rs (2)
coordinator/internal/config/config.go (1)
VerifierConfig(76-79)coordinator/internal/types/auth.go (1)
HardForkName(24-24)
crates/libzkp/src/tasks/chunk.rs (3)
crates/libzkp/src/lib.rs (1)
witness_use_legacy_mode(16-27)crates/libzkp/src/tasks/batch.rs (3)
build_guest_input(142-282)precheck_and_build_metadata(284-298)try_from(118-138)crates/libzkp/src/tasks/bundle.rs (3)
build_guest_input(49-60)precheck_and_build_metadata(62-76)try_from(82-102)
crates/libzkp/src/tasks/bundle.rs (4)
crates/libzkp/src/tasks/batch.rs (3)
build_guest_input(142-282)precheck_and_build_metadata(284-298)try_from(118-138)crates/libzkp/src/tasks/chunk.rs (3)
build_guest_input(159-177)precheck_and_build_metadata(183-190)try_from(100-116)crates/libzkp/src/tasks.rs (2)
from(47-49)check_aggregation_proofs(24-36)crates/libzkp/src/lib.rs (1)
witness_use_legacy_mode(16-27)
crates/libzkp/src/tasks.rs (3)
crates/libzkp/src/lib.rs (1)
new(38-55)crates/prover-bin/src/zk_circuits_handler/universal.rs (1)
new(25-38)crates/libzkp/src/verifier/universal.rs (1)
new(19-26)
crates/libzkp/src/tasks/batch.rs (5)
coordinator/internal/utils/version.go (1)
Version(16-40)crates/libzkp/src/tasks/bundle.rs (2)
build_guest_input(49-60)precheck_and_build_metadata(62-76)crates/libzkp/src/tasks/chunk.rs (2)
build_guest_input(159-177)precheck_and_build_metadata(183-190)crates/libzkp/src/lib.rs (1)
witness_use_legacy_mode(16-27)crates/libzkp/src/tasks.rs (2)
from(47-49)check_aggregation_proofs(24-36)
🪛 Checkov (3.2.334)
tests/prover-e2e/sepolia-galileo/config.json
[medium] 4-5: Basic Auth Credentials
(CKV_SECRET_4)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: check
🔇 Additional comments (37)
zkvm-prover/config.json.template (1)
28-32: Configuration addition looks good.The new
galileocircuit entry follows the established pattern from thefeynmanconfiguration and uses appropriate S3 paths and workspace directories for the new hard fork. JSON syntax is valid and properly structured.tests/prover-e2e/prepare/dump_block_records.sql (1)
28-28: Verify the block range aligns with Galileo fork timing on Scroll testnet.The change shifts the block range from early blocks (1-49) to a specific Galileo-era range (20278000-20278050). While this appears intentional for Galileo fork testing, confirm that:
- Block 20278000 is the correct Galileo fork block number on the Scroll testnet environment used by e2e tests
- This block range contains representative blocks needed for comprehensive Galileo fork testing
Additionally, note that the PR checklist indicates regression e2e tests for Feynman blocks (v0.5.2) are still pending. Clarify whether this change replaces Feynman block testing entirely or if a separate configuration should handle both Feynman and Galileo block ranges.
tests/prover-e2e/sepolia-feynman/.make.env (1)
3-3: LGTM. Straightforward environment variable addition for codec version selection.tests/prover-e2e/sepolia-galileo/.make.env (1)
1-3: LGTM. New test environment configuration follows established patterns and aligns codec version (9) with Galileo fork designation.tests/prover-e2e/cloak-xen/.make.env (1)
2-3: LGTM. Codec version 8 correctly assigned for cloak-xen (consistent with pre-Galileo fork tests).tests/prover-e2e/sepolia-galileo/genesis.json (1)
1-110: LGTM. Valid genesis configuration file with proper fork activation sequencing (feynman at 1751271989, galileo at 1751271990) enabling boundary-condition testing.tests/prover-e2e/sepolia-feynman/genesis.json (1)
1-109: LGTM. Genesis configuration correctly omits galileoTime (fork not relevant for feynman-only regression tests). Structure is consistent with paired galileo configuration.tests/prover-e2e/Makefile (4)
12-12: Verify backward compatibility:prepare_dbnow part ofalltarget.Adding
prepare_dbto thealltarget introduces a database migration reset on every run. If developers or CI pipelines rely on incremental builds without full database resets, this is a breaking change. Consider documenting the new workflow or creating a separate target (e.g.,all_fresh) for full resets.
46-48: LGTM. Newprepare_dbtarget cleanly encapsulates migration reset logic; good separation of concerns.
55-65: Verify CODEC_VERSION availability in genericimport_datatarget.The generic
import_datatarget (lines 64–65) depends on${CODEC_VERSION}being set from.make.env. Ensure:
- CODEC_VERSION is always defined in the linked conf/.make.env.
- A sensible default or error message is provided if CODEC_VERSION is missing.
- Documentation or help text clarifies that users should use explicit targets (
import_data_feynman,import_data_galileo) or ensure CODEC_VERSION is set.The explicit codec targets (
import_data_euclid,import_data_feynman,import_data_galileo) are a good safeguard, but the genericimport_datashould be resilient.
67-68: LGTM.reimport_datatarget provides convenient full-reset workflow by chainingprepare_dbandimport_data.coordinator/internal/config/config.go (1)
65-73: LGTM! Feature configuration moved to asset level.The addition of the
Featuresfield toAssetConfigaligns with the PR's objective of supporting per-fork feature configuration, enabling more granular control over features at the asset level rather than the verifier level.crates/libzkp/src/verifier.rs (2)
42-49: LGTM! Features field added with proper defaults.The addition of the
featuresfield toCircuitConfigwithserde(default)ensures backward compatibility when the field is absent in older configurations. This aligns with the per-fork feature handling introduced across the PR.
56-56: LGTM! Visibility adjustment for internal usage.Changing
HardForkNametopub(crate)appropriately limits its visibility to within the crate, supporting the centralized per-fork handling while preventing unnecessary public exposure.Cargo.toml (3)
50-62: LGTM! Consistent patch updates to tagged releases.All revm-related crate patches have been updated from rev-based references to the
scroll-v91tag, ensuring consistent versioning across the dependency tree. This improves build reproducibility.
20-26: Dependency tags verified and accessible.Both tags exist in their upstream repositories:
v0.7.0-rc.4in scroll-tech/zkvm-prover ✓scroll-v91in scroll-tech/stateless-block-verifier ✓The update to tagged releases improves reproducibility as intended.
41-41: I'll use web search to verify the serde_with version constraint and available versions in the 3.x series.I need to inspect the codebase to see how serde_with is actually being used.
Based on my research, serde_with's latest version is 3.16.0, released just days ago. The version constraint change from
3.11.0to3is compatible because:
- Recent releases between 3.15.1 to 3.16.0 show only additions of new features with no breaking changes.
- Semantic versioning dictates that within major version 3, all minor and patch releases are backward compatible. The constraint
3allows any version from 3.0.0 through 3.16.0+.- Projects in the Rust ecosystem (like iceberg-rust) routinely update to the latest 3.x version without issues.
The change from specifying
3.11.0to3is a standard practice that follows semantic versioning and is safe. All features available in 3.11.0 are preserved in newer 3.x versions.
crates/libzkp/src/tasks/batch.rs (6)
29-48: LGTM! BatchHeaderV enum updated to support Galileo fork.The restructured
BatchHeaderVenum now properly handles STF versions V7, V8, and V9 using the sameBatchHeaderV7variant, as the codec for these versions is identical. The documentation clearly explains this design decision.
76-81: LGTM! Accessor method renamed for clarity.The method name
must_v7_v8_v9_headeraccurately reflects that it now handles V7, V8, and V9 STF versions uniformly. The error message also clearly indicates the expected range.
142-165: Comprehensive version validation added.The runtime assertions ensure that the parsed header type matches the version byte, catching configuration errors early. The checks cover:
- Validium domain validation
- V6 fork matching for EuclidV1
- V7/V8/V9 header matching for EuclidV2/Feynman/Galileo
174-187: Verify codec-based blob padding logic.The code now uses padded blob bytes for Codec::V7 but not for Codec::V6. This is a critical difference that affects the challenge digest computation. Please verify that:
- V6 codec intentionally uses unpadded blob bytes
- V7 codec (covering STF V7/V8/V9) requires padding to N_BLOB_BYTES
Based on learnings and the code logic, this appears intentional, but it's worth confirming with the team or documentation that this codec-based branching correctly implements the da-codec specification differences between V6 and V7.
284-298: All callers properly handle the new return type.The verification confirms that all call sites of
precheck_and_build_metadatahave been correctly updated to destructure and handle the new(BatchInfo, B256)tuple return type. The changes ingen_universal_batch_task,gen_universal_chunk_task, andgen_universal_bundle_taskall properly destructure the tuple and use both values appropriately.
231-254: No changes required; ReferenceHeader::V7_V8_V9 variant is correctly used.The verification confirms that the
ReferenceHeader::V7_V8_V9variant exists in the scroll-zkvm-types dependency at tag v0.7.0-rc.4. The code is using the correct variant name, which is properly defined and consistently used throughout the zkvm-prover codebase.coordinator/conf/config.json (1)
11-21: LGTM! Per-fork feature configuration added.The
featuresfield has been added to the Feynman fork configuration with value"legacy_witness:openvm_13", while the Galileo fork has no features specified. This aligns with the per-fork feature system introduced in this PR and allows Feynman blocks to use legacy witness encoding with OpenVM 13 support.crates/prover-bin/Cargo.toml (1)
11-11: LGTM! Prover-bin now depends on libzkp.The addition of the local libzkp dependency enables prover-bin to utilize the extended task handling and feature system introduced in this PR. The use of a path dependency is appropriate for workspace members.
crates/libzkp/Cargo.toml (1)
12-12: Feature verification confirmed.The
scroll-compress-infofeature exists in sbv-primitives at the scroll-v91 tag and is properly defined with all required dependencies. The change is valid.coordinator/internal/logic/verifier/verifier.go (1)
28-33: Per-asset features wiring into rustCircuitConfig looks consistentThe new
Featuresfield onrustCircuitConfigand its population fromcfg.Featurescleanly align the Go-side verifier config with the RustCircuitConfig.featuressemantics. Usingjson:"features,omitempty"ensures we omit the field when no features are configured, which is what the RustOption<String>expects. No issues from this change alone.Also applies to: 47-52
coordinator/internal/logic/provertask/batch_prover_task.go (1)
297-347: Stricter codec version gating is reasonable; consider future-proofingRejecting unsupported
CodecVersionvalues up front and logging the successful decode makes the control flow clearer and avoids undefined behavior on unknown encodings. The behavior (bubble up as internal failure) is consistent with the rest of this method.One thing to keep in mind is that each time a new codec version is introduced in
da-codec, this switch must be updated; otherwise batches using the new codec will start failing with “Unsupported codec version”. That’s fine as long as adding a codec is always accompanied by updating this list, but it’s worth treating that as part of the rollout checklist.crates/prover-bin/src/zk_circuits_handler/universal.rs (1)
14-18: TaskConfig + per-task parsing cleanly propagateuse_openvm_13into the proverThe new
TaskConfigandget_task_from_inputflow look coherent:
ProvintTaskExtis deserialized once from input, converted intoProvingTask, and itsuse_openvm_13bit is captured inTaskConfig.UniversalHandler::newnow consumes&TaskConfigand wiresis_openvm_v13intoProverConfig, which is exactly where this flag belongs.The design keeps the prover’s runtime configuration separate from the task payload while staying minimal (single bool). I don’t see correctness issues here.
Also applies to: 25-34, 46-53
crates/libzkp/src/tasks/chunk.rs (3)
1-9: Version/public-inputs imports match new usageBringing
Version(and related public-inputs types) into this module is consistent with the new version-aware guest-input and metadata APIs; nothing to change here.
97-107: ChunkProvingTask → ProvingTask conversion correctly switched to version-aware witness + legacy toggleUsing
value.build_guest_input(value.version.into())and guarding serialization withwitness_use_legacy_mode(&value.fork_name)?cleanly aligns chunk behavior with batch/bundle: one source of truth for versioned witnesses, plus per-fork legacy encoding. No issues from a correctness standpoint.
159-190: Version-aware chunk witness + metadata/pi-hash handling looks soundThe new
build_guest_input(&self, version: Version)cleanly separates validium vs scroll paths and reuses the sameversionboth for constructing the witness and forChunkInfo::pi_hash_by_version(version)inprecheck_and_build_metadata. This keeps the pi-hash selection in lockstep with the actual witness encoding and matches the pattern used in batch and bundle.crates/libzkp/src/tasks/bundle.rs (2)
2-44: Bundle identifier viametadata.batch_info.batch_hashis consistent with new metadata layoutSwitching
identifier()to readbatch_hashthroughmetadata.batch_infofor the first/last proofs matches the updatedBatchProofMetadata/BundleInfostructure and still enforces non-empty bundles viaBUNDLE_SANITY_MSG. Looks correct.
79-103: BundleProvingTask → ProvingTask conversion matches the new version/legacy patternUsing
value.build_guest_input(value.version.into())andwitness_use_legacy_mode(&value.fork_name)?mirrors the updated chunk and batch conversions and keeps legacy vs modern encoding decisions centralized. No functional issues spotted.crates/libzkp/src/tasks.rs (3)
17-36: Sharedcheck_aggregation_proofsabstraction withMultiVersionPublicInputsis a good centralizationImporting
MultiVersionPublicInputs/Versionhere and routing all aggregation checks throughcheck_aggregation_proofs(usingw[1].validate(&w[0], version)insidepanic_catch) centralizes the “adjacent metadata validation per version” logic and keeps batch/bundle code slimmer. Implementation looks straightforward and correct.
61-76: Chunk universal task generation now correctly uses precomputed pi-hash
gen_universal_chunk_task’s switch tolet (chunk_info, pi_hash) = task.precheck_and_build_metadata()?;and returningpi_hashas the first tuple element keeps the universal interface the same while ensuring the hash comes fromChunkInfo::pi_hash_by_versionrather than any fork-name heuristics. The rest of the metadata (includingchunk_total_gas) is unchanged.
78-89: Batch universal task generation aligned with new(BatchInfo, pi_hash)metadata APIUsing
task.precheck_and_build_metadata()?to obtain(batch_info, batch_pi_hash)and returning(batch_pi_hash, BatchProofMetadata { batch_info }, proving_task)makes batch handling consistent with chunk and bundle: callers always get the per-version pi-hash alongside slimmed-down metadata.Just ensure all call sites that previously treated the leading
B256as “batch pi-hash” (or a differently named value) still interpret it correctly after this refactor.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
crates/libzkp/src/proofs.rs (1)
256-260: Usingpi_hash_euclidv1aligns test metadata with new PI-hash APIInitializing
bundle_pi_hashwithbundle_info.pi_hash_euclidv1()matches the new per-fork PI-hash helper and keeps the dummy metadata consistent with Euclid‑v1 semantics. The rest of the test still only validates proof/vk serialization, so behavior is unchanged.If you want slightly stronger coverage, you could also assert at the end of the test that
bundle_proof.metadata.bundle_pi_hash == bundle_proof.metadata.bundle_info.pi_hash_euclidv1()to catch accidental mismatches in future refactors.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
crates/libzkp/src/proofs.rs(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-16T02:09:51.657Z
Learnt from: noel2004
Repo: scroll-tech/scroll PR: 1736
File: crates/libzkp/src/verifier/universal.rs:35-45
Timestamp: 2025-09-16T02:09:51.657Z
Learning: The verify_stark_proof method in scroll-zkvm-verifier returns Result<(), Error> indicating success/failure, not Result<bool, Error>. When it succeeds, verification passed; when it fails, it returns an error.
Applied to files:
crates/libzkp/src/proofs.rs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
🔇 Additional comments (1)
crates/libzkp/src/proofs.rs (1)
218-218: Import narrowing in tests looks correctThe test module now only imports
BundleInfoandEvmProoffromscroll_zkvm_types, which matches what is actually used in this file and keeps the dependency surface minimal. No issues here.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
Cargo.toml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: tests
🔇 Additional comments (5)
Cargo.toml (5)
17-17: Version bump 4.6.3 → 4.7.1 appears intentional for Galileo feature release.The skip from 4.7.0 to 4.7.1 aligns with the PR objective. Confirm this does not conflict with any prior 4.7.0 tag or release.
20-22: Tag v0.7.0-rc.5 verified in zkvm-prover repository.The release tag exists and is accessible. Migration from revision to tag-based dependencies is sound and improves reproducibility.
24-26: Tag scroll-v91 verified in stateless-block-verifier repository.The HTTP 200 response confirms the tag exists and is accessible. The migration from
masterbranch to tag-based pinning improves reproducibility. Feature flags are correctly preserved:sbv-primitivesandsbv-coreretain theirscrollfeatures, withsbv-primitivesalso includingrkyv.
34-34: alloy-primitives 1.4.1 update is backwards compatible.There are no breaking changes listed for alloy-primitives v1.4.1. The micro bump from 1.3 to 1.4.1 is a safe, backwards-compatible update, and the
tiny-keccakfeature flag remains properly configured.
50-62: Verify if op-revm should also be patched with scroll-v91 tag.The
scroll-v91tag exists and is accessible. However, the patch section contains only 12 revm crates (not 13 as stated). The workspace at scroll-v91 includes 13 published crates, butop-revmis not patched. Confirm whether this omission is intentional—ifop-revmrequires Scroll-specific changes or depends on patched revm crates, it should likely also referencescroll-v91.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
coordinator/Makefile (1)
40-45: Use consistent path variables in Makefile conditionals.The conditional block mixes
$(PWD)(line 41) and$(CURDIR)(line 43), which is unreliable. In Makefiles,$(CURDIR)is the standard and safer choice across all contexts, whereas$(PWD)is shell-dependent and may be unset in nested invocations.Apply this diff to use
$(CURDIR)consistently:-@if [ -f "$(PWD)/conf/config.template.json" ]; then \ - SRC="$(PWD)/conf/config.template.json"; \ +@if [ -f "$(CURDIR)/conf/config.template.json" ]; then \ + SRC="$(CURDIR)/conf/config.template.json"; \tests/prover-e2e/cloak-xen/config.template.json (1)
20-22: Credentials in test template—acceptable context but document intent.Checkov flags the PostgreSQL DSN credentials (
dev:dev) as a security concern. This is a test template with placeholder values, so the flag is a false positive for local/test environments. However, to prevent future confusion and align with secure-by-default principles, consider adding a brief comment clarifying that these are placeholder credentials intended for local development setup.Add an inline comment above the db section (e.g.,
// Template with placeholder credentials for local development only.) to document the intent.coordinator/internal/logic/provertask/batch_prover_task.go (2)
331-331: Consider Debug level for operational detail logs.This Info log will fire on every batch task decode. In high-throughput production environments, this may generate excessive log volume. Unless this information is needed for operational monitoring, Debug level would be more appropriate for implementation details.
Apply this diff if you prefer Debug level:
- log.Info("Decode batchheader bytes to canonical header", "version", batchHeader.Version()) + log.Debug("Decode batchheader bytes to canonical header", "version", batchHeader.Version())
342-342: Consider Debug level for configuration detail logs.Changing this log from Debug to Info means it will appear for every validium batch task. Since this represents a configuration/mode detail rather than an actionable event, Debug level may be more appropriate to reduce log verbosity in production.
Apply this diff if you prefer Debug level:
- log.Info("Apply validium mode for batch proving task") + log.Debug("Apply validium mode for batch proving task")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
coordinator/Makefile(1 hunks)coordinator/build/setup_releases.sh(2 hunks)coordinator/conf/config.json(1 hunks)coordinator/internal/logic/provertask/batch_prover_task.go(3 hunks)tests/prover-e2e/Makefile(2 hunks)tests/prover-e2e/cloak-xen/.make.env(1 hunks)tests/prover-e2e/cloak-xen/config.template.json(1 hunks)tests/prover-e2e/sepolia-feynman/.make.env(1 hunks)tests/prover-e2e/sepolia-feynman/config.template.json(1 hunks)tests/prover-e2e/sepolia-galileo/.make.env(1 hunks)tests/prover-e2e/sepolia-galileo/config.template.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- tests/prover-e2e/sepolia-galileo/.make.env
- coordinator/conf/config.json
- tests/prover-e2e/sepolia-feynman/.make.env
- tests/prover-e2e/Makefile
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-04-15T08:52:44.176Z
Learnt from: colinlyguo
Repo: scroll-tech/scroll PR: 1645
File: rollup/proposer-tool-config.json:34-40
Timestamp: 2025-04-15T08:52:44.176Z
Learning: In configuration files like `rollup/proposer-tool-config.json`, placeholders such as `<mainnet read db config>` are intentionally left as-is to be replaced by users with their own configuration values when deploying the tool.
Applied to files:
tests/prover-e2e/sepolia-galileo/config.template.json
🧬 Code graph analysis (1)
coordinator/internal/logic/provertask/batch_prover_task.go (1)
coordinator/internal/utils/version.go (1)
Version(16-40)
🪛 Checkov (3.2.334)
tests/prover-e2e/sepolia-galileo/config.template.json
[medium] 21-22: Basic Auth Credentials
(CKV_SECRET_4)
tests/prover-e2e/sepolia-feynman/config.template.json
[medium] 22-23: Basic Auth Credentials
(CKV_SECRET_4)
tests/prover-e2e/cloak-xen/config.template.json
[medium] 21-22: Basic Auth Credentials
(CKV_SECRET_4)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
🔇 Additional comments (8)
coordinator/build/setup_releases.sh (1)
46-46: Fork filtering logic and logging are well-aligned.The extraction of
fork_namefrom config and the fork-aware logging provide good visibility into which verifier is being processed. This aligns well with the broader per-fork feature handling introduced in the PR.Also applies to: 63-63, 68-68
tests/prover-e2e/cloak-xen/.make.env (1)
2-4: LGTM! Configuration aligns with Feynman regression testing.The additions of
CODEC_VERSION?=8andSCROLL_FORK_NAME=feynmanproperly configure this test fixture for Feynman fork regression testing, which aligns with the PR's checklist item "regression e2e tests: for feynman blocks."Note:
SCROLL_FORK_NAMEintentionally uses=instead of?=, ensuring this test always runs against the Feynman fork regardless of environment overrides, which is appropriate for a dedicated test fixture.tests/prover-e2e/sepolia-feynman/config.template.json (2)
13-15: Configuration correctly reflects per-asset features schema.The template includes the
featuresfield (line 13), which aligns with the PR objective to move per-asset features into configuration and populate them into libzkp at init. The combination offeatures,assets_path, andfork_nameproperly models the new configuration structure.
20-22: Credentials in test template—acceptable context.Checkov flags the PostgreSQL DSN credentials, which is a false positive for this test template. The placeholder credentials (dev:dev) are appropriate for local/test environments.
tests/prover-e2e/sepolia-galileo/config.template.json (3)
12-16: Verify whether thefeaturesfield should be included for Galileo fork.This template omits the
featuresfield that is present in thesepolia-feynmantemplate (lines 13 in that file). Given the PR's focus on per-asset feature handling and the aligned schema in the feynman template, confirm whether Galileo requires different feature flags or if this is an unintended omission.
13-14: Verifyassets_pathnaming convention across forks.The
assets_pathis set to generic"assets"here, whereas thesepolia-feynmantemplate uses"assets_feynman". Confirm whether this difference is intentional based on Galileo fork requirements, or if it should be"assets_galileo"for consistency and clarity.
19-23: Credentials in test template—acceptable context.Checkov flags the PostgreSQL DSN credentials, which is a false positive for this test template. The placeholder credentials (dev:dev) are appropriate for local/test environments.
coordinator/internal/logic/provertask/batch_prover_task.go (1)
317-320: LGTM: Explicit error handling for unsupported codec versions.The explicit error return for unsupported codec versions (instead of falling through) improves error visibility and prevents silent failures.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1753 +/- ##
===========================================
- Coverage 36.56% 36.55% -0.02%
===========================================
Files 247 247
Lines 21191 21190 -1
===========================================
- Hits 7748 7745 -3
- Misses 12615 12616 +1
- Partials 828 829 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
crates/libzkp/src/lib.rs (1)
16-27: Normalize fork_name before lookup to prevent case-sensitivity issues.This is a duplicate of a previous review comment. The function looks up ADDITIONAL_FEATURES without normalizing fork_name, but keys are stored lowercased at line 256. While current callers may pass normalized values, the function should be defensive against future callers.
Apply this diff:
pub(crate) fn witness_use_legacy_mode(fork_name: &str) -> eyre::Result<bool> { + let canonical = fork_name.to_lowercase(); ADDITIONAL_FEATURES .get() - .and_then(|features| features.get(fork_name)) + .and_then(|features| features.get(&canonical)) .map(|cfg| cfg.legacy_witness_encoding) .ok_or_else(|| { eyre::eyre!( "can not find features setting for unrecognized fork {}", fork_name ) }) }
🧹 Nitpick comments (1)
coordinator/internal/logic/provertask/batch_prover_task.go (1)
314-316: Consider adding an inline comment documenting the integration test workaround.Based on the past review discussion, this version 0 handling is a known workaround for integration tests. To prevent future confusion, consider adding a code comment explaining why version 0 returns early with incomplete fields.
case 0: + // Integration tests use dummy tasks with unfilled fields and empty blob bytes. + // Return early to avoid parsing failures. This should never occur in production. log.Warn("the codec version is 0, if it is not under integration test we have encountered an error here") return taskDetail, nil
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
coordinator/internal/logic/libzkp/libzkp.h(0 hunks)coordinator/internal/logic/provertask/batch_prover_task.go(2 hunks)crates/libzkp/src/lib.rs(3 hunks)crates/libzkp/src/tasks.rs(3 hunks)crates/libzkp/src/tasks/batch.rs(7 hunks)crates/libzkp_c/src/lib.rs(0 hunks)crates/prover-bin/src/prover.rs(3 hunks)crates/prover-bin/src/zk_circuits_handler/universal.rs(3 hunks)tests/prover-e2e/cloak-xen/config.template.json(1 hunks)
💤 Files with no reviewable changes (2)
- coordinator/internal/logic/libzkp/libzkp.h
- crates/libzkp_c/src/lib.rs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-09-16T02:09:51.657Z
Learnt from: noel2004
Repo: scroll-tech/scroll PR: 1736
File: crates/libzkp/src/verifier/universal.rs:35-45
Timestamp: 2025-09-16T02:09:51.657Z
Learning: The verify_stark_proof method in scroll-zkvm-verifier returns Result<(), Error> indicating success/failure, not Result<bool, Error>. When it succeeds, verification passed; when it fails, it returns an error.
Applied to files:
crates/prover-bin/src/zk_circuits_handler/universal.rscrates/libzkp/src/tasks/batch.rscrates/prover-bin/src/prover.rs
🧬 Code graph analysis (1)
crates/libzkp/src/tasks/batch.rs (4)
common/version/version.go (1)
Version(31-31)coordinator/internal/utils/version.go (1)
Version(16-40)crates/libzkp/src/lib.rs (2)
witness_use_legacy_mode(16-27)new(38-55)crates/libzkp/src/tasks/batch/utils.rs (3)
to_blob(27-41)blob_to_kzg_commitment(44-48)get_versioned_hash(54-58)
🪛 Checkov (3.2.334)
tests/prover-e2e/cloak-xen/config.template.json
[medium] 21-22: Basic Auth Credentials
(CKV_SECRET_4)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: tests
🔇 Additional comments (21)
tests/prover-e2e/cloak-xen/config.template.json (1)
19-24: Remove this review comment; the hardcoded credentials are intentional local test fixtures, not security concerns.All three template files (
cloak-xen,sepolia-feynman,sepolia-galileo) use identical hardcodedpostgres://dev:dev@localhost/scroll?sslmode=disablecredentials by design. The README confirms these are LOCAL test environment templates—the PostgreSQL instance runs in a local Docker container permake all. The credentials are generic dev fixtures pointing to localhost, not production secrets. The pattern is consistent across all templates, confirming this is intentional design: static database credentials for local testing, while other service secrets use placeholders for environment-specific configuration. No security risk is present.Likely an incorrect or invalid review comment.
coordinator/internal/logic/provertask/batch_prover_task.go (2)
319-319: Good improvement: explicit error for unsupported codec versions.Returning an explicit error for unsupported codec versions is better than the previous silent fall-through behavior, making debugging easier.
341-341: Appropriate logging level for operational mode selection.Elevating validium mode activation to Info level improves observability, as this mode selection significantly affects proving behavior.
crates/libzkp/src/lib.rs (5)
29-56: LGTM! Feature parsing is straightforward and tolerant.The implementation correctly parses colon-separated feature flags, normalizes them for matching, and provides clear logging. The use of
Default::default()ensures sensible behavior when no features are specified.
137-148: LGTM! Version-fork validation prevents malformed tasks.The added validation at lines 143-148 ensures that the version's fork matches the expected fork_name, providing early detection of inconsistent task data. The error messages clearly indicate the mismatch.
157-166: LGTM! Consistent validation for batch tasks.
175-208: LGTM! Bundle validation and feature propagation are correct.The version validation follows the same defensive pattern, and the feature lookup at line 200 correctly uses the normalized fork_name. The warning at lines 204-207 provides useful diagnostics when features are missing.
244-265: LGTM! verifier_init correctly populates the feature map.The initialization properly normalizes fork names (line 252) and handles missing features gracefully with
unwrap_or_default()(line 257). The OnceLock ensures thread-safe initialization.crates/prover-bin/src/prover.rs (1)
276-310: LGTM! Correct extraction and propagation of the openvm_13 feature flag.The code properly extracts the
use_openvm_13flag from the extended task (line 277), converts the task toProvingTask(line 278), and passes the flag to the handler initialization (line 306). The refactoring cleanly separates feature configuration from proof type.crates/prover-bin/src/zk_circuits_handler/universal.rs (2)
22-22: Verify the segment_len reduction from ~4M to ~2M.The segment length has been halved from
(1 << 22) - 100(~4.2M) to(1 << 21) - 100(~2.1M). This change could significantly impact proving performance, memory usage, and the number of segments generated per proof.Please confirm:
- Is this change intentional for Galileo forking?
- Have performance benchmarks been run to assess the impact?
- Does this align with zkvm-prover requirements for the new fork?
6-6: LGTM! API changes correctly reflect the new task structure.The signature updates properly replace
ProofTypewith the booleanis_openvm_v13flag, and the return type correctly reflectsProvingTaskExt. The feature flag is passed through toProverConfig.Also applies to: 19-28, 40-42
crates/libzkp/src/tasks/batch.rs (7)
29-58: LGTM! BatchHeaderV consolidation is well-structured.The enum correctly consolidates STF versions v7, v8, and v9 under a single variant
V7_V8_V9, which aligns with the fact that the da-codec is identical for these versions. The Display implementation and batch_hash method properly handle all variants.
76-81: LGTM! Unified accessor reflects the consolidated header variants.The rename from separate
must_v7_header/must_v8_headertomust_v7_v8_v9_headercorrectly reflects the consolidated header structure. The error message clearly indicates the expected range.
115-138: LGTM! New into_proving_task_with_precheck method provides cleaner API.The method correctly delegates to
precheck(), handles legacy witness encoding when needed (line 118), and returns a well-structured tuple. The serialization logic properly branches based on thelegacy_witness_encodingfeature flag.
140-163: LGTM! Comprehensive version-header validation.The assertions at lines 147-163 provide thorough validation:
- Validium domain check (lines 148-151)
- V6 fork alignment (lines 152-156)
- V7/V8/V9 fork alignment (lines 157-162)
The error messages clearly indicate expected vs. actual values, aiding debugging.
165-227: LGTM! Codec-aware point evaluation handling.The code correctly distinguishes between Codec::V6 (line 180) and Codec::V7 (line 183) for envelope processing:
- V6 uses raw blob_bytes without padding
- V7 uses padded blob_bytes (lines 172-176)
The assertions at lines 191-201 verify that coordinator-provided values match computed values, ensuring consistency.
229-252: LGTM! STFVersion routing is well-documented and correct.The extensive comments (lines 233-242) clearly explain why V7, V8, and V9 share the same codec and reference header variant. The pattern match correctly maps:
- V6 → ReferenceHeader::V6
- V7|V8|V9 → ReferenceHeader::V7_V8_V9
- Validium → ReferenceHeader::Validium
282-296: LGTM! precheck method provides clean separation of concerns.The method properly separates validation from witness construction, calling
build_guest_inputwith the parsed version, generating metadata, validating proof adjacency, and computing the pi_hash. The explicitVersion::from(self.version)usage ensures version awareness throughout.crates/libzkp/src/tasks.rs (3)
38-59: LGTM! ProvingTaskExt provides clean feature flag extension.The struct design is sound:
#[serde(flatten)]at line 40 maintains backward compatibility with existing JSON serialization#[serde(default)]at line 42 ensuresuse_openvm_13defaults tofalsewhen not present- The
Fromimplementation (lines 46-50) provides clean unwrapping- The constructor (lines 52-59) ensures a safe default state
62-75: LGTM! gen_universal_chunk_task correctly uses the new precheck API.The function properly calls
into_proving_task_with_precheck()(line 66), destructures the tuple, and returns the pi_hash first followed by metadata and proving_task. The ordering and structure are consistent.
77-102: LGTM! Batch and bundle task generation follow the same correct pattern.Both
gen_universal_batch_task(lines 77-87) andgen_universal_bundle_task(lines 89-102) consistently use the newinto_proving_task_with_precheck()API and return tuples in the same format (pi_hash, metadata, proving_task).
This PR induced works required by galileo forking
v0.7.0-rcguestsregression e2e tests:
v0.5.2guests4.6.1andv0.5.2guestsSummary by CodeRabbit
New Features
Bug Fixes
Improvements
Chores
✏️ Tip: You can customize this high-level summary in your review settings.