feat: the CLOAK privacy solution #1737
Conversation
WalkthroughAdded Validium/version support across coordinator, rollup, and libzkp: task payloads gain version/encryption fields, config adds Sequencer and ValidiumMode, verifier and libzkp switch to version-based validation, and an optional decryption key is threaded through FFI and prover task generation. L1-message fetching and relayer/watcher flows updated for validium. Changes
Sequence Diagram(s)sequenceDiagram
participant Coordinator
participant ProverTask
participant LibZKP
participant Verifier
rect rgb(230,245,250)
Note over Coordinator,ProverTask: Prover task creation (validium-aware)
Coordinator->>ProverTask: formatProverTask(hardForkName)
ProverTask->>ProverTask: ver := version(hardForkName, validiumMode)
ProverTask->>ProverTask: decode Sequencer.DecryptionKey (if validium)
ProverTask->>LibZKP: GenerateUniversalTask(type, taskJSON, fork, expectedVk, decryptionKey)
LibZKP-->>ProverTask: generated task payload
end
rect rgb(240,250,240)
Note over Coordinator,Verifier: Verifier init & validation
Coordinator->>Verifier: NewVerifier(cfg, useValidiumMode)
Verifier->>Verifier: resolve version (cfg or utils)
Coordinator->>Verifier: Validate(proof, version)
Verifier->>Verifier: pi_hash_check(version)
Verifier-->>Coordinator: validation result
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Areas needing extra attention:
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings, 1 inconclusive)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (2)
⏰ 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). (7)
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 |
| WithdrawRoot common.Hash `json:"withdraw_root"` | ||
| DataHash common.Hash `json:"data_hash"` | ||
| IsPadding bool `json:"is_padding"` | ||
| // TxBytes []byte `json:"tx_bytes"` |
There was a problem hiding this comment.
Has confirmed that this field has been deprecated for quite a long time and there is no reference to it. The corresponding defination in rust side also has no such a field
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #1737 +/- ##
===========================================
- Coverage 36.90% 36.77% -0.13%
===========================================
Files 245 247 +2
Lines 20957 21049 +92
===========================================
+ Hits 7734 7741 +7
- Misses 12401 12481 +80
- Partials 822 827 +5
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:
|
| stateRoot := b.StateRoot() | ||
|
|
||
| // Temporary workaround for the wrong genesis state root configuration issue. | ||
| if lastBlock.Header.Number.Uint64() == 0 { |
There was a problem hiding this comment.
Plan to keep this code for a while since there are some utilities would generate test data beginning from the first block.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (9)
tests/prover-e2e/README.md (4)
3-3: Clarify what "some blocks" refers to.The phrase "contains data from some blocks in a specified testnet" is vague. Consider being more explicit about which blocks or how they're selected, or reference the staff-set options mentioned in the Prepare section.
-It contains data from some blocks in a specified testnet, and helps to generate a series of chunks/batches/bundles from these blocks, filling the DB for the coordinator, so an e2e test (from chunk to bundle) can be run completely local +It contains block data from a specified testnet (see Prepare section for available networks), and helps generate chunks/batches/bundles from those blocks. This fills the coordinator DB, enabling end-to-end testing locally (from chunk to bundle).
5-8: Improve formatting consistency in the Prepare section.The use of
+for list items is unconventional in markdown. Use standard bullet points or numbered lists for better readability and consistency with the Steps section below.Prepare: -link the staff dir as "conf" from one of the dir with staff set, currently we have following staff sets: -+ sepolia: with blocks from scroll sepolia -+ cloak-xen: with blocks from xen sepolia, which is a cloak network +link the staff dir as "conf" from one of the available staff sets: +- sepolia: blocks from Scroll Sepolia testnet +- cloak-xen: blocks from Xen Sepolia testnet (CLOAK network)
11-11: Fix PostgreSQL capitalization.The correct spelling is "PostgreSQL", not "postgreSql".
-1. run `make all` under `tests/prover-e2e`, it would launch a postgreSql db in local docker container, which is ready to be used by coordinator (include some chunks/batches/bundles waiting to be proven) +1. run `make all` under `tests/prover-e2e`, it would launch a PostgreSQL db in local docker container, which is ready to be used by coordinator (includes chunks/batches/bundles waiting to be proven)
10-17: Add context about what each step accomplishes.The steps are comprehensive, but consider adding brief context about the purpose of each group of steps. For example, steps 1–3 prepare assets and infrastructure, steps 4–6 configure services, and step 7 runs the test. This helps users understand the overall flow.
Steps: +**Setup local infrastructure and assets:** 1. run `make all` under `tests/prover-e2e`, it would launch a postgreSql db in local docker container, which is ready to be used by coordinator (include some chunks/batches/bundles waiting to be proven) 2. download circuit assets with `download-release.sh` script in `zkvm-prover` 3. generate the verifier stuff corresponding to the downloaded assets by `make gen_verifier_stuff` in `zkvm-prover` + +**Configure and launch services:** 4. setup `config.json` and `genesis.json` for coordinator, copy the generated verifier stuff in step 3 to the directory which coordinator would load them 5. build and launch `coordinator_api` service locally 6. setup the `config.json` for zkvm prover to connect with the locally launched coordinator api + +**Run end-to-end test:** 7. in `zkvm-prover`, launch `make test_e2e_run`, which would specific prover run locally, connect to the local coordinator api service according to the `config.json`, and prove all tasks being injected to db in step 1.tests/prover-e2e/prepare/dump_chunk_records.sql (1)
19-41: Use unquoted literals for numeric fields.The script applies
quote_literal()to all fields, including numeric ones (index, block numbers, gas values, timestamps). This is inefficient and non-idiomatic SQL. Numeric and temporal fields should be unquoted to let PostgreSQL infer the correct type.Consider refactoring to conditionally quote only non-numeric fields. Alternatively, use a more direct approach such as
COPYwith a CSV format, which is more efficient for large migrations. If you prefer to keep the current approach, you can improve readability by grouping numeric and text fields:SELECT 'INSERT INTO chunk (' || 'index, hash, start_block_number, start_block_hash, end_block_number, end_block_hash, ' || 'start_block_time, total_l1_messages_popped_before, total_l1_messages_popped_in_chunk, ' || 'prev_l1_message_queue_hash, post_l1_message_queue_hash, parent_chunk_hash, state_root, ' || 'parent_chunk_state_root, withdraw_root, codec_version, enable_compress, ' || 'total_l2_tx_gas, total_l2_tx_num, total_l1_commit_calldata_size, total_l1_commit_gas, ' || 'created_at, updated_at' || ') VALUES (' || - quote_literal(index) || ', ' || + index || ', ' || quote_literal(hash) || ', ' || - quote_literal(start_block_number) || ', ' || + start_block_number || ', ' || - quote_literal(start_block_hash) || ', ' || + quote_literal(start_block_hash) || ', ' || - quote_literal(end_block_number) || ', ' || + end_block_number || ', ' || quote_literal(end_block_hash) || ', ' || - quote_literal(start_block_time) || ', ' || + EXTRACT(EPOCH FROM start_block_time)::text || ', ' || ... quote_literal(updated_at) || ');'Alternatively, consider whether a
COPYor directINSERT ... SELECTapproach would be simpler and more performant.crates/l2geth/src/rpc_client.rs (2)
256-266: Consider adding assertions to strengthen the test.The test structure is appropriate for an integration test requiring external configuration. However, it currently only prints results without verifying correctness.
Optional enhancement: Add basic assertions to validate the response structure, such as checking that each message has expected fields or that the Vec is properly deserialized.
172-204: Add a brief clarifying comment for the "synced" parameter.The hardcoded
"synced"parameter is correct per Scroll's L2geth RPC specification—it indicates the node should return fully synchronized L1 messages. However, adding a comment on line 191 would help maintainers understand its purpose:(block_number_hex, "synced"), // Request finalized/synchronized L1 messages from Scroll nodeThis makes it explicit that "synced" is a required state selector, not an arbitrary value, and clarifies the method's behavior.
tests/prover-e2e/cloak-xen/.make.env (1)
1-2: LGTM!Test configuration is clear and straightforward.
Consider adding a newline at the end of the file to follow POSIX conventions:
BEGIN_BLOCK?=35 END_BLOCK?=49 +coordinator/internal/utils/version.go (1)
8-11: Consider documenting the bit layout for DomainOffset.The constants define a version encoding scheme where
DomainOffset=6places the domain in bits 6-7 and the STF version in bits 0-5. Consider adding a comment explaining this bit layout for maintainability.Apply this diff to add documentation:
const ( + // DomainOffset defines the bit position for the domain field in the version byte. + // Version encoding: bits 6-7 = domain (0-3), bits 0-5 = stfVersion (0-63) DomainOffset = 6 STFVersionMask = (1 << DomainOffset) - 1 )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
Cargo.lockis excluded by!**/*.lockgo.workis excluded by!**/*.workgo.work.sumis excluded by!**/*.sumrollup/go.sumis excluded by!**/*.sum
📒 Files selected for processing (49)
Cargo.toml(1 hunks)common/types/message/message.go(4 hunks)common/version/version.go(1 hunks)coordinator/cmd/tool/verify.go(1 hunks)coordinator/conf/config.json(1 hunks)coordinator/internal/config/config.go(2 hunks)coordinator/internal/config/config_test.go(1 hunks)coordinator/internal/controller/api/controller.go(1 hunks)coordinator/internal/logic/libzkp/lib.go(1 hunks)coordinator/internal/logic/libzkp/libzkp.h(1 hunks)coordinator/internal/logic/libzkp/mock_universal_task.go(1 hunks)coordinator/internal/logic/libzkp/universal_task.go(2 hunks)coordinator/internal/logic/provertask/batch_prover_task.go(3 hunks)coordinator/internal/logic/provertask/bundle_prover_task.go(1 hunks)coordinator/internal/logic/provertask/chunk_prover_task.go(1 hunks)coordinator/internal/logic/provertask/prover_task.go(4 hunks)coordinator/internal/logic/submitproof/proof_receiver.go(1 hunks)coordinator/internal/logic/verifier/verifier.go(2 hunks)coordinator/internal/utils/codec_validium.go(1 hunks)coordinator/internal/utils/version.go(1 hunks)crates/l2geth/src/rpc_client.rs(3 hunks)crates/libzkp/Cargo.toml(1 hunks)crates/libzkp/src/lib.rs(2 hunks)crates/libzkp/src/proofs.rs(3 hunks)crates/libzkp/src/tasks.rs(3 hunks)crates/libzkp/src/tasks/batch.rs(5 hunks)crates/libzkp/src/tasks/bundle.rs(3 hunks)crates/libzkp/src/tasks/chunk.rs(4 hunks)crates/libzkp/src/tasks/chunk_interpreter.rs(2 hunks)crates/libzkp/src/verifier.rs(2 hunks)crates/libzkp/src/verifier/universal.rs(2 hunks)crates/libzkp_c/src/lib.rs(1 hunks)crates/prover-bin/assets_url_preset.json(1 hunks)rollup/cmd/rollup_relayer/app/app.go(1 hunks)rollup/go.mod(2 hunks)rollup/internal/controller/relayer/l2_relayer.go(1 hunks)rollup/internal/controller/sender/estimategas.go(1 hunks)rollup/internal/controller/watcher/l2_watcher.go(4 hunks)rollup/internal/utils/utils.go(3 hunks)rollup/tests/integration_tool/imports.go(5 hunks)rollup/tests/integration_tool/main.go(1 hunks)tests/prover-e2e/.gitignore(1 hunks)tests/prover-e2e/Makefile(2 hunks)tests/prover-e2e/README.md(1 hunks)tests/prover-e2e/cloak-xen/.make.env(1 hunks)tests/prover-e2e/cloak-xen/config.json(1 hunks)tests/prover-e2e/prepare/dump_block_records.sql(1 hunks)tests/prover-e2e/prepare/dump_chunk_records.sql(1 hunks)tests/prover-e2e/seoplia/config.json(1 hunks)
🧰 Additional context used
🧠 Learnings (5)
📚 Learning: 2025-10-18T06:49:24.796Z
Learnt from: Thegaram
Repo: scroll-tech/scroll PR: 1746
File: rollup/internal/controller/sender/sender.go:637-640
Timestamp: 2025-10-18T06:49:24.796Z
Learning: In the file `rollup/internal/controller/sender/sender.go`, the resubmission logic in `createReplacingTransaction` does not convert V0 blob sidecars to V1 when resubmitting transactions after the Fusaka upgrade. This is an accepted edge case because it's unlikely to occur, geth is expected to handle it gracefully, and manual recovery is available if needed.
Applied to files:
rollup/internal/utils/utils.gorollup/internal/controller/relayer/l2_relayer.go
📚 Learning: 2024-10-20T16:13:20.397Z
Learnt from: colinlyguo
Repo: scroll-tech/scroll PR: 1530
File: rollup/internal/controller/watcher/batch_proposer.go:291-294
Timestamp: 2024-10-20T16:13:20.397Z
Learning: In `batch_proposer.go`, it's acceptable to call `utils.CalculateBatchMetrics` multiple times within the loop because the batch's chunks are increasing in the loop, and each calculation reflects the updated batch state.
Applied to files:
rollup/internal/utils/utils.go
📚 Learning: 2025-07-29T16:38:24.647Z
Learnt from: colinlyguo
Repo: scroll-tech/scroll PR: 1714
File: rollup/internal/controller/relayer/l2_relayer.go:1548-1555
Timestamp: 2025-07-29T16:38:24.647Z
Learning: In rollup/internal/controller/relayer/l2_relayer.go, the validateBatchFields function should error out when GetBatchByHash fails to find a parent batch. This is intentional behavior - missing parent batches represent genuine error conditions that should halt batch submission processing. Genesis batch handling occurs separately from normal batch validation flow.
Applied to files:
rollup/internal/utils/utils.gorollup/internal/controller/relayer/l2_relayer.gorollup/cmd/rollup_relayer/app/app.gorollup/tests/integration_tool/imports.go
📚 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/verifier/universal.rscrates/libzkp/src/tasks.rscoordinator/internal/logic/submitproof/proof_receiver.go
📚 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/seoplia/config.json
🧬 Code graph analysis (24)
coordinator/internal/logic/provertask/bundle_prover_task.go (2)
common/types/message/message.go (1)
BundleTaskDetail(109-115)common/version/version.go (1)
Version(31-31)
crates/libzkp/src/verifier.rs (1)
crates/libzkp/src/verifier/universal.rs (1)
new(19-26)
coordinator/internal/controller/api/controller.go (4)
coordinator/internal/config/config.go (2)
L2(37-42)ProverManager(13-29)coordinator/internal/logic/verifier/verifier.go (1)
NewVerifier(77-105)coordinator/internal/logic/verifier/mock.go (1)
NewVerifier(12-20)coordinator/internal/logic/verifier/types.go (1)
Verifier(11-17)
rollup/tests/integration_tool/main.go (1)
database/config.go (1)
DBConfig(12-19)
crates/libzkp/src/lib.rs (2)
crates/libzkp/src/tasks/chunk.rs (1)
try_from_with_interpret(29-90)crates/libzkp/src/tasks/chunk_interpreter.rs (1)
try_from_with_interpret(27-31)
crates/l2geth/src/rpc_client.rs (1)
crates/libzkp/src/tasks/chunk_interpreter.rs (1)
try_fetch_l1_msgs(21-23)
rollup/internal/controller/relayer/l2_relayer.go (2)
coordinator/internal/utils/codec_validium.go (1)
CodecVersion(10-10)rollup/internal/orm/batch.go (2)
Batch(25-75)Batch(83-85)
coordinator/cmd/tool/verify.go (4)
coordinator/internal/logic/verifier/verifier.go (1)
NewVerifier(77-105)coordinator/internal/logic/verifier/mock.go (1)
NewVerifier(12-20)coordinator/internal/config/config.go (2)
ProverManager(13-29)L2(37-42)coordinator/internal/logic/verifier/types.go (1)
Verifier(11-17)
coordinator/internal/logic/verifier/verifier.go (4)
coordinator/internal/utils/version.go (1)
Version(16-38)coordinator/internal/config/config.go (2)
AssetConfig(66-72)VerifierConfig(75-79)coordinator/internal/logic/verifier/mock.go (1)
NewVerifier(12-20)coordinator/internal/logic/verifier/types.go (1)
Verifier(11-17)
crates/libzkp_c/src/lib.rs (3)
crates/libzkp_c/src/utils.rs (1)
c_char_to_str(3-6)crates/l2geth/src/lib.rs (1)
get_client(14-19)crates/libzkp/src/lib.rs (1)
checkout_chunk_task(40-49)
crates/libzkp/src/verifier/universal.rs (2)
coordinator/internal/utils/version.go (1)
Version(16-38)crates/libzkp/src/proofs.rs (1)
pi_hash_check(185-203)
coordinator/internal/logic/provertask/chunk_prover_task.go (1)
common/types/message/message.go (1)
ChunkTaskDetail(41-48)
coordinator/internal/logic/provertask/prover_task.go (3)
coordinator/internal/utils/version.go (1)
Version(16-38)coordinator/internal/config/config.go (2)
L2(37-42)Sequencer(52-54)coordinator/internal/logic/libzkp/lib.go (1)
GenerateUniversalTask(96-98)
coordinator/internal/utils/codec_validium.go (1)
coordinator/internal/utils/version.go (2)
Version(16-38)STFVersionMask(10-10)
coordinator/internal/logic/submitproof/proof_receiver.go (1)
common/types/message/message.go (1)
ChunkInfo(132-149)
rollup/cmd/rollup_relayer/app/app.go (3)
rollup/internal/controller/watcher/l2_watcher.go (1)
NewL2WatcherClient(45-63)rollup/internal/config/l2.go (1)
L2Config(10-29)rollup/internal/config/relayer.go (1)
RelayerConfig(63-88)
crates/libzkp/src/tasks/chunk_interpreter.rs (2)
crates/l2geth/src/rpc_client.rs (2)
try_fetch_storage_node(152-170)try_fetch_l1_msgs(172-204)crates/libzkp/src/tasks/chunk.rs (1)
try_from_with_interpret(29-90)
crates/libzkp/src/tasks/batch.rs (3)
coordinator/internal/utils/version.go (1)
Version(16-38)crates/libzkp/src/tasks/batch/utils.rs (4)
to_blob(27-41)blob_to_kzg_commitment(44-48)get_versioned_hash(54-58)get_kzg_proof(66-74)crates/libzkp/src/tasks.rs (1)
check_aggregation_proofs(24-41)
coordinator/internal/config/config.go (1)
coordinator/internal/utils/version.go (1)
Version(16-38)
crates/libzkp/src/tasks/bundle.rs (4)
crates/libzkp/src/tasks/chunk.rs (1)
precheck_and_build_metadata(211-216)crates/libzkp/src/tasks/batch.rs (1)
precheck_and_build_metadata(252-261)crates/libzkp/src/proofs.rs (2)
from(173-178)metadata(188-196)crates/libzkp/src/tasks.rs (1)
check_aggregation_proofs(24-41)
coordinator/internal/logic/provertask/batch_prover_task.go (4)
common/types/message/message.go (3)
ChunkInfo(132-149)BatchTaskDetail(94-106)Byte48(51-53)coordinator/internal/types/get_task.go (1)
GetTaskSchema(12-19)coordinator/internal/utils/version.go (1)
Version(16-38)coordinator/internal/utils/codec_validium.go (2)
CodecVersion(10-10)FromVersion(39-41)
crates/libzkp/src/tasks/chunk.rs (3)
common/types/message/message.go (1)
ChunkInfo(132-149)crates/libzkp/src/tasks/chunk_interpreter.rs (1)
try_from_with_interpret(27-31)crates/libzkp/src/verifier/universal.rs (1)
new(19-26)
crates/libzkp/src/proofs.rs (1)
coordinator/internal/utils/version.go (1)
Version(16-38)
rollup/tests/integration_tool/imports.go (2)
common/types/db.go (1)
ProvingTaskProvedDEPRECATED(150-150)rollup/internal/utils/utils.go (1)
BatchMetrics(59-70)
🪛 Checkov (3.2.334)
coordinator/conf/config.json
[medium] 21-22: Basic Auth Credentials
(CKV_SECRET_4)
tests/prover-e2e/seoplia/config.json
[medium] 4-5: Basic Auth Credentials
(CKV_SECRET_4)
🪛 GitHub Actions: Docker
rollup/internal/controller/watcher/l2_watcher.go
[error] 120-120: Method 'GetL1MessagesInBlock' is undefined for type '*L2WatcherClient'. This indicates missing implementation or dependency issue in the code.
[error] 120-120: Undefined symbol 'eth.QueryModeSynced'. Missing import, dependency, or definition in the codebase.
⏰ 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). (7)
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: check
🔇 Additional comments (33)
common/version/version.go (1)
8-8: Version tag updated correctly.The version bump from v4.6.1 to v4.6.3 aligns with the deployment tag versioning requirement in the PR objectives. The change is self-contained and does not affect the commit extraction or version string construction logic.
crates/prover-bin/assets_url_preset.json (1)
6-8: Verify this addition aligns with prior guidance on preset management.A previous reviewer (noel2004) noted that the "preset" section should not be set if circuit assets are uploaded via CI. This PR now adds three new preset entries for the 0.6.0-rc.1 release. Please confirm:
- Whether the 0.6.0-rc.1 assets are being uploaded via CI (and if so, why they need preset entries)
- Whether there was a deliberate strategy change from the prior guidance
- Whether this is essential for the CLOAK privacy solution feature, or if it should be deferred to a later CI/asset-upload refactor
rollup/internal/controller/sender/estimategas.go (1)
53-55: LGTM! Log refinement improves consistency.Removing the "fallback gas limit" field clarifies the error log, as no fallback logic exists in this function. The remaining fields (from, nonce, to address, error) provide sufficient debugging context, and this change aligns the logging pattern with
estimateBlobGas(lines 86-87).Cargo.toml (1)
20-22: Commit 546172b is valid and the dependency update is appropriate.Verification confirms:
- Commit 546172b exists and is tagged as v0.6.0-rc.6 in the zkvm-prover repository
- All three packages (prover, verifier, types) are workspace members with synchronized versioning (all at v0.6.0)
- Updating them together to the same commit is correct and expected behavior for workspace crates
- Changes between versions include intentional feature additions (L3 Validium support) with proper legacy compatibility fixes
No breaking changes or compatibility issues detected. The update is ready.
crates/libzkp/Cargo.toml (1)
8-8: Manually verify the "scroll" feature is available in scroll-zkvm-types.The specified commit 546172b could not be located in the repository, preventing automated verification. While the feature addition aligns with the pattern in adjacent dependencies (
sbv-primitivesandsbv-coreboth use "scroll"), you should:
- Confirm the "scroll" feature exists in
scroll-zkvm-typesat your target commit- Verify no feature conflicts or incompatibilities are introduced
- Ensure the feature is actually utilized by libzkp code or required for future changes
tests/prover-e2e/prepare/dump_chunk_records.sql (1)
10-44: No changes needed—review comment premise appears incorrect.The search results show that
EncryptionKeyexists on message and proof metadata types in Go code, but thechunktable schema contains noencryption_keycolumn across all 28 migrations. The filedump_chunk_records.sqlcorrectly exports all 24 persisted columns from thechunktable. IfEncryptionKeyis part of the Go type system but not persisted to the database, this SQL script requires no changes.Verify: Is
EncryptionKeyintended to be persisted in the database schema, or is it transient/derived at runtime?crates/l2geth/src/rpc_client.rs (1)
8-8: LGTM!The import addition is necessary for the new L1 message fetching functionality and is correctly placed.
tests/prover-e2e/cloak-xen/config.json (1)
7-8: LGTM!The addition of
validium_modeconfiguration aligns with the validium feature rollout across the codebase.coordinator/internal/config/config_test.go (1)
38-48: LGTM!Test configuration properly reflects the new config structure with
validium_modeandsequencerfields, ensuring test coverage for the extended schema.coordinator/internal/logic/libzkp/mock_universal_task.go (1)
17-17: LGTM!The updated function signature correctly adds the
decryptionKeyparameter to match the real implementation. It's expected that mock implementations may not use all parameters.rollup/tests/integration_tool/main.go (1)
89-90: LGTM!The addition of the
ValidiumModefield properly extends the config structure to support validium mode testing.coordinator/internal/logic/provertask/bundle_prover_task.go (1)
276-286: LGTM!The version retrieval and propagation to
BundleTaskDetailis properly implemented with appropriate error handling, consistent with the broader versioning feature across task types.tests/prover-e2e/seoplia/config.json (1)
1-9: LGTM!Test configuration is properly structured with database config and validium mode flag. The hardcoded credentials flagged by static analysis are acceptable for local development test configurations.
crates/libzkp/src/verifier.rs (1)
44-76: Version plumbing looks correct.Passing
cfg.versionintoVerifier::newkeeps initialization deterministic and the updated log line will make future fork/version bumps much easier to audit. Nicely done.coordinator/internal/logic/libzkp/libzkp.h (1)
39-46: Header signature update aligns with the new key flow.Extending the ABI with
decryption_keyand its length keeps the C side in lockstep with the Go bridge and prevents silent struct corruption. Looks good.rollup/cmd/rollup_relayer/app/app.go (1)
117-117: Validium flag is wired through correctly.Threading
cfg.L2Config.RelayerConfig.ValidiumModeinto the watcher keeps the relayer and watcher behavior consistent after the constructor change.coordinator/internal/config/config.go (1)
39-69: Configuration schema captures the new knobs cleanly.Adding
validium_mode, the sequencer key holder, and per-assetversionkeeps the config self-descriptive for both rollup and validium deployments. Thanks for keeping the JSON tags aligned.coordinator/internal/logic/provertask/chunk_prover_task.go (1)
240-253: Chunk task payload now carries the right metadata.Deriving the version once and populating both
VersionandPostMsgQueueHashkeeps the task detail consistent with the updated message schema. Thanks for handling the error path explicitly.rollup/internal/utils/utils.go (1)
142-205: The genesis guardrail and version gate make sense.Deriving
stateRootlocally lets you patch the mis-configured genesis cases without mutating the batch, and restricting the version byte to the known codec upgrades ensures we fail fast if a new codec sneaks in unnoticed. The warning log will also help spot surprises during bring-up.crates/libzkp/src/lib.rs (2)
21-21: LGTM! The VALIDIUM_VERSION constant aligns with the version encoding scheme.The constant value
0b01000001(65) correctly encodes domain=1 and stfVersion=1, matching the validium mode logic incoordinator/internal/utils/version.gowhere(domain << 6) + stfVersion = (1 << 6) + 1 = 65.
40-49: LGTM! The decryption_key parameter is correctly propagated.The function signature change to include
decryption_key: Option<&[u8]>is properly wired through to the universal task generation path viaChunkProvingTask::try_from_with_interpret.crates/libzkp/src/verifier/universal.rs (2)
19-26: LGTM! Version-based initialization is correctly implemented.The constructor properly accepts a
u8version number and converts it to theVersiontype usingVersion::from(ver_n). This aligns with the broader version-based refactoring across the codebase.
30-56: LGTM! Version-based verification is correctly implemented.All
pi_hash_checkcalls have been consistently updated fromself.forktoself.version, maintaining the verification logic while supporting the version-based flow. The verify method correctly handles theResult<(), Error>return type fromverify_stark_proof.Based on learnings
coordinator/internal/logic/libzkp/lib.go (1)
96-98: LGTM! The decryptionKey parameter is correctly added and propagated.The function signature update adds the
decryptionKey []byteparameter and correctly forwards it to the underlyinggenerateUniversalTaskimplementation, maintaining consistency with the decryption key flow across the codebase.crates/libzkp/src/proofs.rs (2)
185-203: LGTM! Version-based pi_hash_check is correctly implemented.The method signature has been properly updated from
ForkNametoversion::Version, and the internal logic correctly usespi_hash_by_version(ver)instead ofpi_hash_by_fork. This maintains the public input hash verification while supporting the new version-based architecture.
256-256: LGTM! Test data updated for new BundleInfo structure.The addition of
encryption_key: Nonecorrectly aligns with the updatedBundleInfostructure that now includes encryption key handling for validium mode support.coordinator/internal/utils/version.go (2)
13-38: I need to gather more context to verify the remaining concerns. Let me search for additional information:Now let me search the codebase to understand how the
ValidiumModeis used and whether the hardcoding is intentional:Remove the incorrect claim about unused STFVersionMask and clarify the design questions requiring team input.
The original concern contains a factual error:
STFVersionMaskis NOT unused. It's actively exported and used incodec_validium.go:40in theFromVersion()function to extract the STF version from a packed version byte. That function already provides the extraction logic suggested by your comment, making a separateExtractSTFVersion()helper redundant.Regarding the hardcoded validium mode implementation (line 22 setting
stfVersion = 1and the TODO on line 15), these are design decisions that require clarification from the team rather than clear bugs:
- Clarify whether the
stfVersion = 1for validium mode is intentional and whether it should derive fromhardForkName- Document what specific scenarios the TODO comment refers to
Likely an incorrect or invalid review comment.
25-34: Verify hardForkName handling is sufficient.The function only supports three hardForkNames: "euclidv1" (6), "euclidv2" (7), and "feynman" (8). Ensure that:
- These are the only fork names currently returned by
encoding.GetHardforkName()- The stfVersion values align with the corresponding fork implementations
- Future forks will be added to this switch statement
Note: The code includes a TODO comment ("This is not foolproof and does not cover all scenarios"), indicating known incompleteness. The
encodingpackage definition is not accessible in the repository, so manual verification of the contract betweenVersion()andencoding.GetHardforkName()is required to confirm no additional fork names can be returned.coordinator/internal/logic/provertask/batch_prover_task.go (1)
268-299: Encryption key propagation looks correct.Thanks for carrying the per-chunk encryption key through the task payload; this keeps
ChunkInfoaligned with the updated message schema and removes the need for downstream hacks.crates/libzkp/src/tasks.rs (1)
24-36: Version-based aggregation guard looks good.Switching the aggregation proof check to use
Versionkeeps the validation logic consistent with the new public-input plumbing. 👍rollup/tests/integration_tool/imports.go (1)
127-192: Nice pre-seeding of the L1 queue state.Inserting a leading chunk when L1 messages appear mid-range should keep the message-queue hashes continuous for the generated fixtures—thanks for tackling that edge case.
crates/libzkp/src/tasks/chunk.rs (1)
67-90: Validium inputs plumbing looks solid.Fetching the per-block validium payloads and packaging them with the decryption key keeps the witness builder self-contained—nice work.
crates/libzkp/src/tasks/batch.rs (1)
198-206: Validium invariants enforcedThe explicit asserts for “no blob DA in validium” keep the witness path honest and will flush any misconfigured coordinator quickly—nice guardrails.
| if count > 0 { | ||
| log.Info("Fetching encrypted messages in validium mode") | ||
| txs, err = w.GetL1MessagesInBlock(context.Background(), block.Hash(), eth.QueryModeSynced) | ||
| if err != nil { | ||
| return fmt.Errorf("failed to get L1 messages: %v, block hash: %v", err, block.Hash().Hex()) | ||
| } | ||
| } |
There was a problem hiding this comment.
Fix missing validium RPC helpers before merging.
L2WatcherClient (and the embedded ethclient.Client) expose no GetL1MessagesInBlock, and eth.QueryModeSynced is also undefined. The Docker job already fails on these compile errors. Please wire up an existing RPC helper (or implement one) and drop/replace the missing constant before we can merge.
🧰 Tools
🪛 GitHub Actions: Docker
[error] 120-120: Method 'GetL1MessagesInBlock' is undefined for type '*L2WatcherClient'. This indicates missing implementation or dependency issue in the code.
[error] 120-120: Undefined symbol 'eth.QueryModeSynced'. Missing import, dependency, or definition in the codebase.
|
e2e tasks for compatibility testing:
All tests should be proven by a v4.6.1 prover |
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (2)
coordinator/internal/logic/provertask/prover_task.go (1)
212-216: Validate sequencer decryption key length before FFI
hex.DecodeStringwill happily return any length. When Validium mode is on and the configured key is not exactly 32 bytes, we still forward it tolibzkp.GenerateUniversalTask; the Rust side assertslen == 32, so we’ll panic inside FFI and abort the coordinator. Please hard-fail here if the decoded key is present but not 32 bytes long.decryptionKey, err := hex.DecodeString(b.cfg.Sequencer.DecryptionKey) if err != nil { return nil, nil, fmt.Errorf("sequencer decryption key hex-decoding failed") } + if l := len(decryptionKey); l > 0 && l != 32 { + return nil, nil, fmt.Errorf("sequencer decryption key must be 32 bytes, got %d", l) + }common/types/message/message.go (1)
117-129: Restore RawBytes JSON round-tripEmitting numeric arrays without a matching
UnmarshalJSONleaves every Go consumer still expecting the legacy base64 string, so decodingRawBytesnow fails immediately. Please add anUnmarshalJSONthat accepts both the new numeric representation and the old base64 form so coordinator ↔ prover payloads keep working.@@ -import ( - "encoding/json" - "errors" - "fmt" - "math/big" +import ( + "encoding/base64" + "encoding/json" + "errors" + "fmt" + "math/big" @@ type RawBytes []byte func (r RawBytes) MarshalJSON() ([]byte, error) { @@ } return json.Marshal(rn) } + +func (r *RawBytes) UnmarshalJSON(data []byte) error { + if string(data) == "null" { + *r = nil + return nil + } + + var ints []uint16 + if err := json.Unmarshal(data, &ints); err == nil { + buf := make([]byte, len(ints)) + for i, v := range ints { + if v > 0xFF { + return fmt.Errorf("byte value %d out of range", v) + } + buf[i] = byte(v) + } + *r = RawBytes(buf) + return nil + } + + var encoded string + if err := json.Unmarshal(data, &encoded); err != nil { + return err + } + + raw, err := base64.StdEncoding.DecodeString(encoded) + if err != nil { + return err + } + + *r = RawBytes(raw) + return nil +}
🧹 Nitpick comments (1)
tests/prover-e2e/sepolia/.make.env (1)
1-2: LGTM! Consider adding documentation.The syntax and block range configuration are correct. The 10-block range (10973711–10973721) is appropriate for e2e testing.
Optionally, consider adding a comment explaining the significance of these specific Sepolia blocks (e.g., whether they contain specific CLOAK/Validium test data or represent a particular test scenario).
Example:
+# Sepolia blocks containing test data for CLOAK privacy solution e2e tests +# Range selected for [brief reason, e.g., "validium mode transactions" or "encryption key handling"] BEGIN_BLOCK?=10973711 END_BLOCK?=10973721
📜 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 (12)
Cargo.toml(1 hunks)common/types/message/message.go(4 hunks)coordinator/conf/config_cloak_template.json(1 hunks)coordinator/conf/config_sepolia_template.json(1 hunks)coordinator/internal/logic/provertask/batch_prover_task.go(2 hunks)coordinator/internal/logic/provertask/prover_task.go(4 hunks)crates/libzkp/src/tasks.rs(1 hunks)crates/libzkp/src/tasks/batch.rs(4 hunks)crates/libzkp/src/tasks/bundle.rs(3 hunks)crates/libzkp/src/tasks/chunk.rs(4 hunks)tests/prover-e2e/sepolia/.make.env(1 hunks)tests/prover-e2e/sepolia/config.json(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- Cargo.toml
🧰 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.rs
🧬 Code graph analysis (6)
crates/libzkp/src/tasks/chunk.rs (2)
crates/libzkp/src/tasks/chunk_interpreter.rs (1)
try_from_with_interpret(27-31)crates/libzkp/src/verifier/universal.rs (1)
new(19-26)
crates/libzkp/src/tasks.rs (2)
crates/libzkp/src/utils.rs (1)
panic_catch(43-53)crates/libzkp/src/proofs.rs (1)
metadata(188-196)
crates/libzkp/src/tasks/bundle.rs (2)
crates/libzkp/src/tasks/batch.rs (1)
precheck_and_build_metadata(266-275)crates/libzkp/src/tasks.rs (1)
check_aggregation_proofs(24-37)
crates/libzkp/src/tasks/batch.rs (5)
coordinator/internal/utils/version.go (1)
Version(16-38)crates/libzkp/src/tasks/chunk.rs (1)
precheck_and_build_metadata(184-189)crates/libzkp/src/tasks/bundle.rs (1)
precheck_and_build_metadata(60-69)crates/libzkp/src/tasks/batch/utils.rs (4)
to_blob(27-41)blob_to_kzg_commitment(44-48)get_versioned_hash(54-58)get_kzg_proof(66-74)crates/libzkp/src/tasks.rs (1)
check_aggregation_proofs(24-37)
coordinator/internal/logic/provertask/batch_prover_task.go (5)
common/types/message/message.go (3)
OpenVMChunkProof(181-190)BatchTaskDetail(94-106)Byte48(51-53)coordinator/internal/types/get_task.go (1)
GetTaskSchema(12-19)coordinator/internal/orm/batch.go (2)
Batch(18-72)Batch(80-82)coordinator/internal/utils/version.go (1)
Version(16-38)coordinator/internal/utils/codec_validium.go (2)
CodecVersion(10-10)FromVersion(39-41)
coordinator/internal/logic/provertask/prover_task.go (3)
coordinator/internal/utils/version.go (1)
Version(16-38)coordinator/internal/config/config.go (2)
L2(37-42)Sequencer(52-54)coordinator/internal/logic/libzkp/lib.go (1)
GenerateUniversalTask(96-98)
🪛 Checkov (3.2.334)
coordinator/conf/config_sepolia_template.json
[medium] 22-23: Basic Auth Credentials
(CKV_SECRET_4)
coordinator/conf/config_cloak_template.json
[medium] 21-22: Basic Auth Credentials
(CKV_SECRET_4)
tests/prover-e2e/sepolia/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). (7)
- GitHub Check: check
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
🔇 Additional comments (2)
coordinator/conf/config_sepolia_template.json (2)
11-11: Clarify thefeatures: "legacy_witness"field for consistency.This field appears in the Sepolia template but not in the CLOAK template. Verify whether this is:
- Required only for Sepolia (due to prover version compatibility)
- Should be added to both templates for consistency
- Optional and can be removed if not actively used
Ensure the template documentation clarifies when this field is required.
30-30: Document the expected process for configuring the Alchemy endpoint in template files.The
config_sepolia_template.jsonincludes an Alchemy endpoint with what appears to be an API key. While this is a Sepolia testnet endpoint (lower risk than mainnet), the template lacks documentation explaining:
- Whether users should substitute their own Alchemy key or alternative endpoint
- How template files relate to production
config.jsonconfiguration- Best practices for endpoint configuration in deployment
Add documentation (in
coordinator/README.mdor inline comments) clarifying the template configuration process and whether the included endpoint is intended for development-only testing or if users must provide their own credentials.
| }, | ||
| { | ||
| "assets_path": "assets", | ||
| "assets_path": "asset", |
There was a problem hiding this comment.
🧩 Analysis chain
Clarify the intent of assets_path: "asset" for CLOAK configuration.
The assets path is set to the singular "asset" here, whereas the Sepolia template uses the plural "assets". Verify whether this is intentional for CLOAK mode or a typo. If intentional, consider documenting the distinction.
Run the following to check if both paths exist and are used correctly:
🏁 Script executed:
#!/bin/bash
# Find references to "asset" and "assets" directories
fd -t d "^asset(s)?$" --max-depth 2
# Check if the verifier in verifier.go or related files handles both paths
rg -n "assets_path" coordinator/internal/config/ -A 2 -B 2Length of output: 828
I need to verify the actual content of the CLOAK config template and check how the assets_path is used throughout the codebase.
I need to examine the actual config files and how the assets_path is used in the code.
🏁 Script executed:
#!/bin/bash
# Check the actual config template files
echo "=== CLOAK Config Template ==="
cat coordinator/conf/config_cloak_template.json 2>/dev/null | head -30
echo -e "\n=== Sepolia Config Template ==="
cat coordinator/conf/config_sepolia_template.json 2>/dev/null | head -30
echo -e "\n=== Check for all template files ==="
fd "template.json$" coordinator/conf/
echo -e "\n=== How AssetsPath is used in code ==="
rg -n "AssetsPath" coordinator/ -A 3 -B 3Length of output: 5965
Correct assets_path in CLOAK config from "asset" to "assets" for consistency.
The CLOAK template uses the singular "asset" while the Sepolia template uses the plural "assets". Test configurations also consistently use "assets". The code treats this as a simple directory path with no special handling for singular vs. plural forms. This inconsistency appears unintentional—correct line 13 to "assets_path": "assets" to align with other templates and tests.
🤖 Prompt for AI Agents
In coordinator/conf/config_cloak_template.json around line 13, the CLOAK
template uses "assets_path": "asset" which is inconsistent with other
templates/tests that use the plural "assets"; change the value to "assets" so
the line reads "assets_path": "assets" to align with Sepolia and test
configurations.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
crates/libzkp/src/tasks/batch.rs (3)
83-84: Clarify documentation for the version field.The comment describes this as "the version of the chunks in the batch," but the field actually represents the version for the entire batch task (encoding both domain and STF version). Consider updating the comment to reflect this more accurately.
- /// The version of the chunks in the batch, as per [`Version`]. + /// The version byte encoding domain and STF version for this batch, as per [`Version`]. pub version: u8,
220-236: Consider error propagation instead of unreachable! for unsupported version combinations.The
unreachable!at line 234 will panic if an unexpected (domain, stf_version) combination is encountered. For library code used in production, consider returning aResultwith a descriptive error instead, allowing the caller to handle the error gracefully.-impl BatchProvingTask { - fn build_guest_input(&self) -> BatchWitness { +impl BatchProvingTask { + fn build_guest_input(&self) -> Result<BatchWitness> { let version = Version::from(self.version); // ... existing code ... let reference_header = match (version.domain, version.stf_version) { (Domain::Scroll, STFVersion::V6) => { ReferenceHeader::V6(*self.batch_header.must_v6_header()) } (Domain::Scroll, STFVersion::V7) => { ReferenceHeader::V7(*self.batch_header.must_v7_header()) } (Domain::Scroll, STFVersion::V8) => { ReferenceHeader::V8(*self.batch_header.must_v8_header()) } (Domain::Validium, STFVersion::V1) => { ReferenceHeader::Validium(*self.batch_header.must_validium_header()) } - (domain, stf_version) => { - unreachable!("unsupported domain={domain:?},stf-version={stf_version:?}") - } + (domain, stf_version) => { + return Err(eyre::eyre!( + "unsupported domain={domain:?},stf-version={stf_version:?}" + )) + } }; - // ... rest of function returns BatchWitness + Ok(BatchWitness { + // ... fields ... + }) }Note: This change would require updating callers to handle the Result.
256-258: Validate consistency between version.fork and self.fork_name.Line 257 uses
version.fork(derived fromself.version) while the struct also hasself.fork_name(line 100). These should represent the same fork but come from different sources. Consider adding a validation check to ensure they're consistent.Add validation after line 131:
let version = Version::from(self.version); // Validate consistency between version-derived fork and explicit fork_name let expected_fork_name = format!("{:?}", version.fork).to_lowercase(); let actual_fork_name = self.fork_name.to_lowercase(); assert_eq!( expected_fork_name, actual_fork_name, "fork name mismatch: version.fork={:?}, task.fork_name={}", version.fork, self.fork_name );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
crates/libzkp/src/tasks.rs(1 hunks)crates/libzkp/src/tasks/batch.rs(4 hunks)crates/libzkp/src/tasks/bundle.rs(3 hunks)crates/libzkp/src/tasks/chunk.rs(5 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/libzkp/src/tasks/bundle.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.rs
🧬 Code graph analysis (3)
crates/libzkp/src/tasks.rs (2)
crates/libzkp/src/utils.rs (1)
panic_catch(43-53)crates/libzkp/src/proofs.rs (1)
metadata(188-196)
crates/libzkp/src/tasks/batch.rs (5)
common/types/message/message.go (1)
ChunkInfo(132-149)coordinator/internal/utils/version.go (1)
Version(16-38)crates/libzkp/src/tasks/bundle.rs (1)
precheck_and_build_metadata(60-72)crates/libzkp/src/tasks/batch/utils.rs (4)
to_blob(27-41)blob_to_kzg_commitment(44-48)get_versioned_hash(54-58)get_kzg_proof(66-74)crates/libzkp/src/tasks.rs (1)
check_aggregation_proofs(24-36)
crates/libzkp/src/tasks/chunk.rs (3)
common/types/message/message.go (1)
ChunkInfo(132-149)crates/libzkp/src/tasks/chunk_interpreter.rs (1)
try_from_with_interpret(27-31)crates/libzkp/src/verifier/universal.rs (1)
new(19-26)
⏰ 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). (7)
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
🔇 Additional comments (7)
crates/libzkp/src/tasks.rs (2)
17-17: LGTM: Import additions support version-based validation.The addition of
VersionandMultiVersionPublicInputsto the imports is appropriate and necessary for the refactoredcheck_aggregation_proofsfunction.
24-36: No issues found - call sites and trait integration verified.All concerns have been successfully addressed:
- Call sites updated correctly: Both
batch.rs(line 272) andbundle.rs(line 66) correctly pass the new signature—metadata slice andVersionparameter.- Trait method signature confirmed: The
validate()method is called withw[1].validate(&w[0], version), confirming the expected signature from the externalscroll_zkvm_typescrate.- Function is actively used: The function is not dead code; it's called in two locations within the tasks module.
crates/libzkp/src/tasks/batch.rs (5)
22-27: LGTM: Clean wrapper struct for Validium headers.The flattened serialization approach provides good compatibility with the existing header format while adding the batch_hash field.
35-77: LGTM: Validium variant properly integrated.The new Validium variant follows the existing pattern. The placement at the top of the enum is appropriate given the untagged deserialization behavior.
Note: The accessor methods use
panic!()for type mismatches, which is consistent with the existing codebase style but aggressive for library code. This is an existing pattern, not introduced by this change.
266-278: LGTM: Properly updated for version-based validation.The changes correctly pass the version to
check_aggregation_proofs, aligning with the version-based validation approach introduced across the codebase.
239-253: Block hash zeroing is intentional design, but the "patch" label warrants clarification.The code correctly shows intentional, domain-specific handling:
- Scroll domain (versions V6/V7/V8): explicitly zeros
prev_blockhashandpost_blockhash- Validium domain (version V1): preserves original block hashes
The conditional logic is properly implemented with matching domain-specific structures (different ReferenceHeader types, BatchHeader formats, and KZG handling). However, the inline comment labels this as a "patch," which suggests it may be a temporary workaround rather than permanent design.
Clarify:
- Is the "patch" label still accurate, or is this now permanent design?
- Document why Scroll domain specifically requires zeroed block hashes (e.g., circuit requirements, proof protocol constraints)
- Confirm this zeroing does not compromise verification or security properties for Scroll
The code itself is correct; this is about documenting the business logic rationale.
133-218: Fork/header pairing validation is correct; consider error handling for unreachable cases.The refactored logic correctly validates fork-to-header-type correspondence: V6 headers require EuclidV1 (asserted), V7_8 headers require EuclidV2 or Feynman (matched), and Validium domains properly bypass blob DA. The assertions validate internal invariants.
However, the
unreachable!macros at lines 167-171 and 174 assume these mismatches cannot occur. If there's any possibility of untrusted input or logic errors producing unexpected fork/header combinations, consider returning aResultinstead of panicking. This would allow graceful failure rather than process termination in production.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
coordinator/internal/logic/verifier/mock.go (1)
11-12: Consider naming the ignored parameter for clarity.The second parameter is intentionally ignored in this mock implementation, but naming it (e.g.,
useValidiumMode) would improve readability and make the relationship to the real verifier implementation more explicit. Additionally, update the function comment to document the new parameter.Apply this diff to improve clarity:
-// NewVerifier Sets up a mock verifier. -func NewVerifier(cfg *config.VerifierConfig, _ bool) (*Verifier, error) { +// NewVerifier Sets up a mock verifier. +// The useValidiumMode parameter is ignored in this mock implementation. +func NewVerifier(cfg *config.VerifierConfig, useValidiumMode bool) (*Verifier, error) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
coordinator/internal/logic/verifier/mock.go(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
coordinator/internal/logic/verifier/mock.go (3)
coordinator/internal/logic/verifier/verifier.go (1)
NewVerifier(77-105)coordinator/internal/config/config.go (1)
VerifierConfig(75-79)coordinator/internal/logic/verifier/types.go (1)
Verifier(11-17)
⏰ 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). (7)
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: check
- GitHub Check: tests
- GitHub Check: check
🔇 Additional comments (1)
coordinator/internal/logic/verifier/mock.go (1)
22-40: LGTM!The mock verification methods remain unchanged and continue to provide appropriate test doubles for the real verifier. The simple logic (returning success except for explicitly invalid proofs) is suitable for mock testing purposes.
Purpose or design rationale of this PR
Describe your change. Make sure to answer these three questions: What does this PR do? Why does it do it? How does it do it?
PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
Deployment tag versioning
Has
tagincommon/version.gobeen updated or have you addedbump-versionlabel to this PR?Breaking change label
Does this PR have the
breaking-changelabel?Summary by CodeRabbit
New Features
Configuration
Chores