-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: test all available curves #186
Conversation
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Warning Rate limit exceeded@smuu has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 0 minutes and 6 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThis pull request introduces a comprehensive enhancement to the cryptographic key management across the Prism project. The changes primarily focus on introducing a more flexible and algorithm-agnostic approach to handling cryptographic keys. The modifications span multiple crates, replacing hardcoded Ed25519 implementations with a new Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 6
🧹 Nitpick comments (20)
crates/da/src/lib.rs (2)
3-3
: Use consistent dependency management across crates.Replacing "ed25519_consensus" with "prism_keys" appears correct. Make sure the old dependency is fully removed from Cargo.toml to avoid confusion or duplication.
56-56
: Clear error messaging.Relying on a single error variant (“Invalid signature length”) might mask more descriptive errors. Consider returning the underlying error message from “from_algorithm_and_bytes” for easier troubleshooting.
crates/cli/src/main.rs (6)
40-48
: DRY up repeated checks.The verifying_key_algorithm validation is repeated in multiple places. Extracting this into a helper function could improve readability and prevent duplication.
- if verifying_key_algorithm.is_empty() { - ... - } - if !["ed25519", "secp256k1", "secp256r1"].contains(&verifying_key_algorithm) { - ... - } + fn validate_algorithm(algorithm: &str) -> std::io::Result<()> { + if algorithm.is_empty() { + return Err(...); + } + if !["ed25519", "secp256k1", "secp256r1"].contains(&algorithm) { + return Err(...); + } + Ok(()) + }
52-52
: LightClient instantiation.Passing Some(prover_vk) is fine, though consider clarifying whether a None case is possible or how fallback logic is handled.
92-92
: Passing cloned verifying key into config.Storing both signing_key and verifying_key in the config is valid, but ensure they remain in sync, especially if any rotation logic is introduced later.
98-98
: Logging clarity.“prover verifying key: {}” is helpful. Consider adding algorithm info for completeness.
127-127
: Key retrieval flow repeated.Same note about repeating the KeyChain retrieval logic. Consolidate if possible.
151-157
: Careful error mapping.If invalid data is encountered, returning “invalid prover verifying key” is good but consider whether more context is needed, e.g. exact reason.
crates/keys/src/verifying_keys.rs (2)
77-77
: Enumerate allowed algorithms.Rather than returning “Unexpected algorithm,” consider enumerating possible algorithms in the error message or providing a typed error.
216-222
: Graceful fallback for unknown curves.Returning “Invalid curve type” is good. If you foresee additional curves in the future, plan for extension or clearer messages.
crates/node_types/prover/src/prover/tests.rs (3)
23-30
: TransactionBuilder calls.register_service_with_random_keys, create_account_with_random_key_signed, etc. confirm that these random keys are properly seeded for deterministic test results if needed.
Line range hint
64-84
: Process transaction logic.This block thoroughly tests insert and update flows. The random key approach is beneficial, though ensure any negative test cases are covered (e.g., invalid signatures).
112-116
: Redundant block?Again, the same pattern. Possibly factor out a macro or parameterized test approach for DRY.
crates/tests/Cargo.toml (1)
22-24
: Consider documenting supported curves in workspace README.The consistent addition of
prism-keys
across crates establishes a solid foundation for multi-curve support. Consider:
- Documenting supported curves in the workspace README
- Adding a compatibility matrix for different node types (prover, full node) and their supported curve combinations
- Including migration guides for users updating from ed25519-consensus
crates/keys/src/signatures.rs (1)
41-41
: Improve error message for algorithm validationThe error message now includes the actual algorithm value, which is helpful for debugging. However, consider adding valid algorithm options to the message.
- _ => bail!("Unexpected algorithm for Signature: {}", algorithm), + _ => bail!("Unexpected algorithm for Signature: '{}'. Expected one of: ed25519, secp256k1, secp256r1", algorithm),crates/keys/src/signing_keys.rs (1)
66-66
: Improve error message consistencyUpdate the error message to match the format suggested for
new_with_algorithm
.- _ => bail!("Unexpected algorithm for SigningKey: {}", algorithm), + _ => bail!("Unexpected algorithm for SigningKey: '{}'. Expected one of: ed25519, secp256k1, secp256r1", algorithm),crates/tests/src/lib.rs (1)
Line range hint
89-104
: Consider separating test scenariosThe test combines account creation and updates in a single loop. Consider separating these into distinct test cases for better clarity and easier debugging.
#[tokio::test] async fn test_account_creation() -> Result<()> { // Test only account creation } #[tokio::test] async fn test_account_updates() -> Result<()> { // Test only account updates }crates/cli/src/cfg.rs (1)
210-210
: Consider documenting the configuration precedence.The configuration application logic correctly prioritizes command-line arguments over config file values, but this behavior should be documented.
Add a comment explaining the precedence:
+ // Command-line arguments take precedence over config file values verifying_key_algorithm: args.verifying_key_algorithm.unwrap_or(config.verifying_key_algorithm),
crates/common/src/tree/mod.rs (2)
63-75
: Consider using test parameterization to reduce duplication.While the current implementation provides good test coverage for all algorithms, there's significant duplication in the test functions. Consider using a test framework feature for parameterized tests to reduce code duplication.
Example approach using a test macro:
macro_rules! parameterized_test { ($test_name:ident, $test_fn:ident) => { #[test] fn $test_name() { for algorithm in ["ed25519", "secp256k1", "secp256r1"] { $test_fn(algorithm); } } }; } parameterized_test!(test_insert_and_get_all_algorithms, test_insert_and_get);Also applies to: 97-109, 142-154, 181-193, 220-232, 251-264, 318-330, 373-385, 405-417, 459-472
Line range hint
1-472
: Well-structured implementation of multi-algorithm support.The changes effectively implement support for multiple cryptographic algorithms while maintaining backward compatibility and providing comprehensive test coverage. The architecture cleanly separates the algorithm-specific implementation details through the prism_keys abstraction.
Consider documenting the supported algorithms and their use cases in the project's documentation to help users make informed decisions about algorithm selection.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (17)
crates/cli/src/cfg.rs
(4 hunks)crates/cli/src/main.rs
(4 hunks)crates/common/src/transaction_builder.rs
(5 hunks)crates/common/src/tree/mod.rs
(11 hunks)crates/da/Cargo.toml
(1 hunks)crates/da/src/lib.rs
(2 hunks)crates/keys/src/lib.rs
(2 hunks)crates/keys/src/signatures.rs
(1 hunks)crates/keys/src/signing_keys.rs
(2 hunks)crates/keys/src/verifying_keys.rs
(4 hunks)crates/node_types/lightclient/Cargo.toml
(1 hunks)crates/node_types/lightclient/src/lightclient.rs
(2 hunks)crates/node_types/prover/Cargo.toml
(0 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/node_types/prover/src/prover/tests.rs
(7 hunks)crates/tests/Cargo.toml
(1 hunks)crates/tests/src/lib.rs
(5 hunks)
💤 Files with no reviewable changes (1)
- crates/node_types/prover/Cargo.toml
🔇 Additional comments (42)
crates/da/src/lib.rs (1)
53-53
: Validate that the inserted algorithm matches the key.
Using vk.algorithm() to construct the signature is good, but ensure that the provided bytes truly align with that chosen algorithm to avoid subtle verification issues.
crates/cli/src/main.rs (6)
7-7
: Import looks good.
Importing SigningKey and VerifyingKey from prism_keys centralizes cryptographic key usage. Ensure consistency with the rest of the codebase.
71-71
: Key retrieval.
KeyStoreType::KeyChain(KeyChain).get_signing_key() is returning a raw key. Confirm if concurrency or thread-safety is a concern.
86-86
: Verifying key derivation.
verifying_key = signing_key.verifying_key() is clean. Make sure no mismatch occurs between config-provided verifying key and the derived verifying key if both are used.
131-134
: Bubble up error with clarity.
An empty verifying_key_algorithm leads to an InvalidInput error. The message is helpful, but ensure the CLI usage instructions mention this requirement.
136-141
: Repeated algorithm checks.
Again, these checks appear multiple times in the file. Might be beneficial to unify them as a helper.
142-143
: From bytes usage.
Consider verifying any special constraints (e.g., compressed vs. uncompressed for secp256k1/r1) if that might break usage.
crates/keys/src/verifying_keys.rs (2)
89-89
: Matching signature type with key type.
This approach is robust. The pattern matching clarifies that a signature’s actual type must match the verifying key’s type.
199-200
: Documentation clarity.
Stating that 32 bytes is for Ed25519, 33/65 for secp256 curves is a helpful reference.
crates/node_types/prover/src/prover/tests.rs (17)
11-11
: Parameterizing tests by algorithm.
This is a good approach to test all supported algorithms thoroughly. Ensure test coverage for each.
15-15
: Config with key algorithm.
Config::default_with_key_algorithm typically indicates test usage. Consider where production config usage might differ.
19-19
: Mock transactions helper.
Parameterizing by algorithm ensures consistent coverage. Good usage of “service_id” to isolate test scenarios.
34-39
: Multiple calls to validate_and_queue_update.
Testing the same transaction multiple times is helpful. We confirm duplicate submission logic.
50-52
: Separate test for ed25519.
This pattern is repeated for each curve, ensuring thorough coverage.
54-62
: Separate tests for secp256k1 and secp256r1.
Similarly, good coverage. No issues noted.
80-80
: SigningKey::new_with_algorithm.
This is consistent with the rest of the code that parameterizes by algorithm.
103-108
: Repeated test pattern.
Same concept as before for process_transactions. This repetition is acceptable for varied cryptographic coverage.
117-134
: execute_block with conflicting transactions.
This is a well-structured test scenario for block-level validations.
142-154
: Test multiple curves with invalid block transactions.
As with the prior logic, coverage is thorough.
156-179
: execute_block.
Collective creation of mock transactions, verifying resulting proofs is robust. No immediate issues found.
Line range hint 180-188
: Epoch finalization.
Testing epoch finalization across different algorithms further ensures correctness.
192-204
: Separate curve tests for finalize_new_epoch.
Matches prior pattern. Good coverage.
Line range hint 206-249
: test_restart_sync_from_scratch.
Combining DA-layer usage with spawning a Prover in the background is an effective concurrency test.
250-262
: Additional coverage for different curves.
Again, consistent approach.
Line range hint 264-299
: test_load_persisted_state.
This ensures persisted state can be reloaded properly. Good for ensuring data consistency.
300-313
: Long form multi-curve testing.
Completes coverage for all supported algorithms on state loading.
crates/da/Cargo.toml (1)
24-24
: LGTM! Verify DA proof compatibility.
The addition of prism-keys
is consistent with the project-wide migration. Since this is the DA (Data Availability) module, ensure that the proof verification logic remains compatible with all supported curves.
✅ Verification successful
Let me gather more information about the cryptographic verification implementation to ensure compatibility.
Let me check one more thing to understand the algorithm and signature types being used.
Signature verification implementation is correctly migrated
The verification logic in the DA module is properly implemented using the new prism-keys
dependency. The code correctly:
- Uses algorithm-agnostic types (
SigningKey
,VerifyingKey
,Signature
) - Handles signature verification with proper error handling
- Maintains compatibility by using the verifying key's algorithm for signature creation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for proof verification implementations
rg -A 5 "verify.*proof|verify.*signature" crates/da/src/
Length of output: 775
Script:
#!/bin/bash
# Check the type definitions and imports related to VerifyingKey
ast-grep --pattern 'use $_::VerifyingKey;'
# Check the full implementation context
rg -B 5 -A 10 'verify_signature' crates/da/src/
Length of output: 2133
Script:
#!/bin/bash
# Check for signature and algorithm type usage
rg -B 2 -A 2 "Signature::from_algorithm_and_bytes|algorithm()" crates/da/src/
# Check imports to understand the cryptographic types
rg -B 2 "use prism_keys::" crates/da/src/
Length of output: 666
crates/tests/Cargo.toml (1)
24-24
: LGTM! Ensure comprehensive curve testing.
The addition of prism-keys
to the test crate is crucial. With the mock_prover feature available, this provides a good foundation for testing different cryptographic curves.
crates/keys/src/lib.rs (2)
16-16
: LGTM! Good addition of secp256r1 support.
The import follows the established pattern of aliasing curve-specific signing keys.
126-137
: LGTM! Comprehensive test coverage for secp256r1.
The test follows the same pattern as ed25519 and secp256k1 tests, ensuring consistent verification of key serialization and deserialization.
crates/node_types/lightclient/src/lightclient.rs (2)
2-2
: LGTM! Good migration to generic VerifyingKey.
The change from ed25519-specific to generic VerifyingKey type enables multi-curve support.
75-75
: LGTM! Correct ownership handling in signature verification.
Using clone() is appropriate here as verify_signature takes ownership of the key.
crates/cli/src/cfg.rs (2)
104-104
: LGTM! Good default configuration.
The default to "ed25519" maintains backward compatibility while enabling opt-in support for other curves.
Also applies to: 115-115
39-41
: 🛠️ Refactor suggestion
Consider adding validation for verifying_key_algorithm.
While the documentation clearly states the supported algorithms, there's no validation at the configuration level. This could lead to runtime errors if an invalid algorithm is provided.
Consider adding validation in the apply_command_line_args function:
verifying_key_algorithm: Option<String>,
+#[arg(long, value_parser = ["ed25519", "secp256k1", "secp256r1"])]
verifying_key_algorithm: Option<String>,
crates/common/src/transaction_builder.rs (5)
87-93
: LGTM! Method correctly updated to support multiple algorithms.
The change properly introduces algorithm flexibility while maintaining the existing functionality.
123-127
: LGTM! Method signature and implementation correctly updated.
The changes maintain consistency with the new algorithm-flexible approach.
146-151
: LGTM! Method properly updated for algorithm flexibility.
The implementation correctly handles the algorithm parameter and maintains consistency.
185-190
: LGTM! Methods correctly updated to support algorithm parameter.
Both methods properly implement the algorithm flexibility changes.
Also applies to: 195-200
272-278
: LGTM! Methods properly updated for algorithm support.
The changes maintain consistency with the algorithm-flexible approach.
Also applies to: 284-288
crates/node_types/prover/src/prover/mod.rs (3)
2-2
: LGTM! Imports and type declarations properly updated.
The changes correctly switch from ed25519-specific types to algorithm-agnostic types.
Also applies to: 49-49
57-67
: LGTM! Default implementation maintains backward compatibility.
The changes properly maintain ed25519 as the default while using the new API.
72-82
: LGTM! Test helper method properly implemented.
The new method correctly enables testing with different algorithms while being appropriately scoped to test code.
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Nitpick comments (5)
crates/node_types/prover/src/prover/tests.rs (1)
11-17
: Consider using test parameterization for better maintainability.The test suite has been properly updated to support multiple algorithms, but the current approach of creating separate test functions for each algorithm leads to code duplication. Consider using test parameterization for better maintainability.
Example using
rstest
:use rstest::rstest; #[rstest] #[case("ed25519")] #[case("secp256k1")] #[case("secp256r1")] #[tokio::test] async fn test_create_test_prover(#[case] algorithm: &str) { let prover = create_test_prover(algorithm).await; // ... rest of the test }crates/tree/src/tests.rs (3)
Line range hint
44-459
: Consider using test parameterization macros for better organization.The current approach of creating separate test functions for each algorithm creates maintenance overhead. Consider using test frameworks that support parameterized tests, such as
rstest
or similar, to reduce code duplication and improve maintainability.Example approach:
use rstest::rstest; #[rstest] #[case("ed25519")] #[case("secp256k1")] #[case("secp256r1")] fn test_insert_and_get(#[case] algorithm: &str) { // ... test implementation ... }
Line range hint
58-90
: Enhance error assertions in failure test cases.The error assertions in failure test cases (e.g.,
test_insert_for_nonexistent_service_fails
) only check if an error occurred but don't verify the specific error type or message. This could allow incorrect errors to pass the test.Consider using more specific error assertions:
- assert!(insertion_result.is_err()); + match insertion_result { + Err(e) => assert!(e.to_string().contains("service not found")), + Ok(_) => panic!("Expected error for nonexistent service"), + }
Line range hint
406-459
: Replace println! statements with test-appropriate logging.The batch writing tests contain multiple
println!
statements which can make test output noisy. Consider using thetracing
crate's test features or conditional compilation for debug output.- println!("Inserting acc_1"); + trace!("Inserting acc_1");crates/node_types/prover/src/prover/mod.rs (1)
53-65
: Consider making the default key algorithm configurable.The
Default
implementation hardcodesed25519
as the key algorithm. Consider:
- Making the algorithm configurable via environment variables
- Adding a constant for the default algorithm
+const DEFAULT_KEY_ALGORITHM: &str = "ed25519"; impl Default for Config { fn default() -> Self { - let signing_key = SigningKey::new_ed25519(); + let algorithm = std::env::var("PRISM_KEY_ALGORITHM") + .unwrap_or_else(|_| DEFAULT_KEY_ALGORITHM.to_string()); + let signing_key = SigningKey::new_with_algorithm(&algorithm);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (4)
crates/node_types/prover/Cargo.toml
(0 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/node_types/prover/src/prover/tests.rs
(7 hunks)crates/tree/src/tests.rs
(11 hunks)
💤 Files with no reviewable changes (1)
- crates/node_types/prover/Cargo.toml
🔇 Additional comments (1)
crates/node_types/prover/src/prover/tests.rs (1)
80-80
: Verify key generation across different algorithms.
The test suite creates signing keys for different algorithms. Let's verify that the key generation is working correctly for all supported algorithms.
Also applies to: 122-122, 223-223
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
crates/tree/src/tests.rs (1)
Line range hint
12-42
: Add test cases for invalid algorithm strings.The current tests only verify valid algorithm strings. Consider adding negative test cases to verify proper error handling for invalid algorithms.
#[test] fn test_insert_and_get_invalid_algorithm() { let mut tree = KeyDirectoryTree::new(Arc::new(MockTreeStore::default())); let mut tx_builder = TransactionBuilder::new(); let result = tx_builder.register_service_with_random_keys("invalid_algo", "service_1"); assert!(result.is_err()); assert!(result.unwrap_err().to_string().contains("Invalid algorithm")); }
🧹 Nitpick comments (5)
crates/keys/src/signing_keys.rs (1)
66-66
: Enhance error message clarity.Consider making the error message more descriptive by including the list of supported algorithms, similar to the message in
new_with_algorithm
.- _ => bail!("Unexpected algorithm for SigningKey: {}", algorithm), + _ => bail!("Unexpected algorithm for SigningKey: '{}'. Expected one of: ed25519, secp256k1, secp256r1", algorithm),crates/cli/src/main.rs (1)
163-173
: Consider moving validate_algorithm to the keys crate.This validation logic would be more appropriate in the
prism_keys
crate where it can be reused by other crates.crates/tree/src/tests.rs (3)
Line range hint
12-42
: Consider improving test maintainability with shared test constants.To enhance test maintainability and readability, consider extracting commonly used test values into constants:
+ const TEST_ALGORITHMS: [&str; 3] = ["ed25519", "secp256k1", "secp256r1"]; + const TEST_SERVICE_ID: &str = "service_1"; + const TEST_ACCOUNT_ID: &str = "acc_1"; fn test_insert_and_get(algorithm: &str) { let mut tree = KeyDirectoryTree::new(Arc::new(MockTreeStore::default())); let mut tx_builder = TransactionBuilder::new(); - let service_tx = tx_builder.register_service_with_random_keys(algorithm, "service_1").commit(); + let service_tx = tx_builder.register_service_with_random_keys(algorithm, TEST_SERVICE_ID).commit(); // ... rest of the function }
Line range hint
406-444
: Remove debug println statements from test code.The test contains multiple debug println statements that should be removed from the test code as they add noise to the test output.
fn test_batch_writing(algorithm: &str) { // ... setup code ... - println!("Inserting acc_1"); tree.process_transaction(account1_tx).unwrap(); - println!("Tree state after first insert: {:?}", tree.get_commitment()); // Try to get the first value immediately let get_result1 = tree.get(KeyHash::with::<TreeHasher>("acc_1")); - println!("Get result for key1 after first write: {:?}", get_result1); // ... rest of the function }
Line range hint
58-74
: Verify error messages in failure cases.The test verifies that the operation fails but doesn't check the specific error message. Consider adding error message verification to ensure the correct error is being returned.
fn test_insert_for_nonexistent_service_fails(algorithm: &str) { // ... setup code ... let insertion_result = tree.process_transaction(invalid_account_tx); - assert!(insertion_result.is_err()); + let err = insertion_result.unwrap_err(); + assert!(err.to_string().contains("service not found"), + "Expected 'service not found' error, got: {}", err); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
crates/cli/src/main.rs
(5 hunks)crates/keys/src/signing_keys.rs
(2 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/tests/src/lib.rs
(5 hunks)crates/tree/src/tests.rs
(11 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/node_types/prover/src/prover/mod.rs
🔇 Additional comments (4)
crates/keys/src/signing_keys.rs (1)
34-41
: LGTM! Well-implemented error handling.
The implementation correctly returns a Result type instead of panicking and provides clear error messages for unsupported algorithms.
crates/tests/src/lib.rs (2)
45-46
: Parameterize test to cover all supported algorithms.
The test currently only verifies secp256r1. Consider parameterizing the test to cover all supported algorithms.
- let algorithm = "secp256r1";
+ for algorithm in ["ed25519", "secp256k1", "secp256r1"] {
+ test_light_client_prover_talking_with_algorithm(algorithm).await?;
+ }
50-51
: LGTM! Proper error handling implementation.
The code correctly handles potential errors from new_with_algorithm
and transaction builder methods using the ?
operator for error propagation.
Also applies to: 83-83, 96-96, 115-115
crates/cli/src/main.rs (1)
42-47
: LGTM! Robust error handling implementation.
The error handling for verifying keys is well-implemented with proper error messages and type conversions.
Also applies to: 133-138
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 6
🧹 Nitpick comments (12)
Cargo.toml (1)
111-111
: Consider using workspace version for paste crateFor consistency with other dependencies, consider moving the paste crate version to the workspace.package section.
-paste = "1.0.15" +paste = { version = "1.0.15", workspace = true }crates/keys/src/lib.rs (1)
13-19
: Consider making 'Placeholder' a hidden or deprecated variant.
If "Placeholder" is never intended for real usage, it could be best to hide or remove this variant to avoid confusion and reduce complexity.crates/tree/src/tests.rs (2)
5-5
: Enhance discoverability of 'KeyAlgorithm' usage.
Importing both 'SigningKey' and 'KeyAlgorithm' from 'prism_keys' is fine, but consider a dedicated doc comment or README reference for these new enumerated algorithms, to help future contributors quickly identify the available options.
12-24
: Mind the code duplication in test logic.
Although you are using macros to generate multi-algorithm tests, there's still some repeated setup across tests (e.g., new tree, new tx_builder). Consider extracting that into a common fixture or utility function to further DRY up your test code.crates/keys/src/signatures.rs (1)
31-42
: Consolidate error messages for unexpected algorithms.
Currently, the code bails out with "Unexpected algorithm for Signature." If you're handling multiple unexpected algorithm paths in different modules, consider centralizing or reusing a single error message format for clarity and consistency.crates/keys/src/tests.rs (1)
1-140
: LGTM: Comprehensive test coverage for all curvesThe test suite thoroughly covers key operations across all supported curves (Ed25519, Secp256k1, Secp256r1) including serialization, deserialization, and error cases.
Consider organizing the tests into sub-modules by curve type for better maintainability:
mod ed25519_tests { #[test] fn test_verifying_key_operations() { // Ed25519 specific tests } } mod secp256k1_tests { #[test] fn test_verifying_key_operations() { // Secp256k1 specific tests } }🧰 Tools
🪛 GitHub Check: clippy
[failure] 2-2:
module has the same name as its containing modulecrates/cli/src/main.rs (1)
Line range hint
1-169
: Consider implementing a custom error typeThe current approach of converting all errors to
std::io::Error
makes it difficult to handle specific error cases. Consider implementing a custom error type:#[derive(Debug, thiserror::Error)] pub enum PrismError { #[error("Invalid algorithm: {0}")] InvalidAlgorithm(String), #[error("Key error: {0}")] KeyError(String), #[error("Configuration error: {0}")] ConfigError(String), #[error(transparent)] IoError(#[from] std::io::Error), } impl From<PrismError> for std::io::Error { fn from(err: PrismError) -> Self { std::io::Error::new(std::io::ErrorKind::Other, err.to_string()) } }crates/keys/src/verifying_keys.rs (2)
Line range hint
90-120
: LGTM! Consider enhancing error messages.The signature verification implementation is correct for all supported curves. Each key type is properly handled with appropriate verification methods.
Consider enhancing error messages to include the actual and expected signature types:
- bail!("Invalid signature type"); + bail!("Invalid signature type: expected Ed25519, got {:?}", signature);
220-226
: Enhance error handling for curve-specific failures.The current error message "Invalid curve type" doesn't provide enough context about which curves were attempted.
Consider enhancing the error message to include which curves failed:
- Err(anyhow!("Invalid curve type")) + Err(anyhow!("Failed to parse key as either Secp256k1 or Secp256r1"))crates/node_types/prover/src/prover/tests.rs (1)
209-236
: LGTM! Efficient test generation with clear naming.The macro effectively generates tests for each curve while maintaining clear test names.
Consider adding a brief doc comment to explain the macro's purpose:
+/// Generates test functions for each supported key algorithm (Ed25519, Secp256k1, Secp256r1). macro_rules! generate_algorithm_tests {
crates/node_types/prover/src/prover/mod.rs (2)
46-46
: Update field documentation to reflect multi-curve support.The comment should be updated to indicate that the verifying key can now use different curves.
- /// Key used to verify incoming [`FinalizedEpochs`]. - /// This is not necessarily the counterpart to signing_key, as fullnodes must use the [`verifying_key`] of the prover. + /// Key used to verify incoming [`FinalizedEpochs`]. + /// This is not necessarily the counterpart to signing_key, as fullnodes must use the [`verifying_key`] of the prover. + /// Supports multiple curves (Ed25519, Secp256k1, Secp256r1) for verification.
54-64
: Consider making the default key algorithm configurable.The default implementation hardcodes Ed25519. Consider making this configurable through a const or environment variable for better flexibility.
+ const DEFAULT_KEY_ALGORITHM: KeyAlgorithm = KeyAlgorithm::Ed25519; impl Default for Config { fn default() -> Self { - let signing_key = SigningKey::new_ed25519(); + let signing_key = SigningKey::new_with_algorithm(DEFAULT_KEY_ALGORITHM) + .expect("Failed to create signing key with default algorithm");
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (14)
Cargo.toml
(1 hunks)crates/cli/src/main.rs
(5 hunks)crates/common/src/transaction_builder.rs
(6 hunks)crates/keys/src/lib.rs
(1 hunks)crates/keys/src/signatures.rs
(3 hunks)crates/keys/src/signing_keys.rs
(4 hunks)crates/keys/src/tests.rs
(1 hunks)crates/keys/src/verifying_keys.rs
(5 hunks)crates/node_types/prover/Cargo.toml
(1 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/node_types/prover/src/prover/tests.rs
(7 hunks)crates/tests/src/lib.rs
(5 hunks)crates/tree/Cargo.toml
(1 hunks)crates/tree/src/tests.rs
(11 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/node_types/prover/Cargo.toml
🧰 Additional context used
🪛 GitHub Check: clippy
crates/keys/src/tests.rs
[failure] 2-2:
module has the same name as its containing module
crates/common/src/transaction_builder.rs
[failure] 88-88:
using clone
on type KeyAlgorithm
which implements the Copy
trait
🔇 Additional comments (18)
crates/tree/Cargo.toml (1)
14-14
: Verify the usage of the paste crate
The addition of the paste
crate suggests code generation for curve-specific implementations. Let's verify its usage in the codebase.
✅ Verification successful
The paste crate is correctly used for test generation across multiple key algorithms
The paste crate is being used appropriately in the generate_algorithm_tests!
macro to create test variants for Ed25519, Secp256k1, and Secp256r1 key algorithms. This is part of the PR's changes to support multiple curve implementations, where the macro automatically generates test function names by concatenating the base test name with the algorithm variant (e.g., test_insert_and_get_ed25519
).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of paste macros in the tree crate
rg "paste::" crates/tree/
# Search for paste macro invocations
rg "paste!\s*!\s*{" crates/tree/
Length of output: 201
Script:
#!/bin/bash
# Search for paste macro usage with a simpler pattern
rg "paste!" crates/tree/
# Look for test modules or test-related code that might use paste
ast-grep --pattern 'mod tests {
$$$
}' crates/tree/src/
Length of output: 135
Script:
#!/bin/bash
# Get the context around the paste macro usage in tests.rs
rg -B 5 -A 5 "paste::paste!" crates/tree/src/tests.rs
# Check if this is a new addition by looking at git diff
git diff origin/main -- crates/tree/src/tests.rs
Length of output: 14919
Cargo.toml (2)
Line range hint 67-76
: Verify curve implementations and features
The PR aims to test different curves (Ed25519, Secp256k1, P256). Let's verify the implementations and feature flags:
✅ Verification successful
Let me gather more information about the curve implementations and their dependencies.
Curve implementations and dependencies are properly configured
The verification confirms that:
- All three curves (Ed25519, Secp256k1, and P256/Secp256r1) are properly implemented with:
- Appropriate dependencies in Cargo.toml
- Complete implementations for signing and verification
- Proper test coverage for all curves in multiple test files
- The
KeyAlgorithm
enum correctly defines all supported curves - Dependencies have necessary feature flags enabled (e.g., "secp256k1/global-context", "p256/ecdsa")
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for curve-specific implementations
echo "Checking curve implementations..."
rg -t rust "impl.*(?:Ed25519|Secp256k1|P256)"
# Check for test coverage of different curves
echo "Checking test coverage..."
rg -t rust "(?:#\[test\]|test_).*(?:ed25519|secp256k1|p256)"
# Verify feature flags for curves
echo "Checking feature flags..."
fd -e toml | xargs rg "features.*(?:ed25519|secp256k1|p256)"
Length of output: 1775
Script:
#!/bin/bash
# Check for curve-related dependencies in Cargo.toml files
echo "Checking curve-related dependencies..."
fd -e toml | xargs rg "(?:ed25519|secp256k1|p256|k256|p384|p521|curve25519)"
# Check for key algorithm definitions and usages
echo "Checking key algorithm definitions..."
rg -t rust "(?:enum|struct) .*(?:KeyAlgorithm|Algorithm)" -A 5
# Check for curve-specific signing operations
echo "Checking signing implementations..."
rg -t rust "(?:sign|verify).*(?:Ed25519|Secp256k1|P256)" -A 2
Length of output: 1808
Line range hint 38-38
: Review ZK compatibility with curves
The addition of crates/zk/sp1
and patched crypto libraries suggests ZK proof integration. Ensure all curves are compatible with SP1 ZK-VM:
Consider documenting which curves are supported in the ZK context and any performance implications.
Also applies to: 142-144
crates/keys/src/lib.rs (1)
24-31
: Good use of anyhow errors for parsing!
This improves the readability and consistency of error messages when the user provides an unsupported algorithm string.
crates/tree/src/tests.rs (2)
283-303
: Excellent approach with generate_algorithm_tests macro!
This neatly covers each algorithm variant without duplicating test functions.
316-327
: Robust negative test checks.
Verifying nonexistence in the tree with an explicit check and corresponding proof ensures stronger guarantees about the correctness of your tree logic.
crates/keys/src/signatures.rs (1)
46-51
: Great alignment between 'algorithm()' and 'from_algorithm_and_bytes()'.
Having these complementary methods ensures consistent handling of signature algorithms.
crates/keys/src/signing_keys.rs (3)
35-42
: Return 'Result' for 'new_with_algorithm'?
Panic is avoided here with a bail, which is good. This approach is consistent with the rest of the methods relying on 'Result', ensuring better error handling.
71-75
: Accurate returns from 'algorithm' method
This helps maintain clarity when converting signing keys back into user-facing data structures.
56-67
: Consistent error handling for unknown algorithm
This is aligned with best practices, but be mindful if "Placeholder" is not truly unknown. Consider giving a more precise message if you differentiate between a recognized but unsupported variant vs. a truly unknown algorithm.
crates/tests/src/lib.rs (1)
14-14
: LGTM: Key algorithm integration looks good
The changes correctly integrate the KeyAlgorithm enum and properly initialize the signing key with the specified algorithm.
Also applies to: 45-46, 50-51
crates/keys/src/verifying_keys.rs (2)
67-80
: LGTM! Type-safe algorithm handling.
The change from string-based to enum-based algorithm selection improves type safety and eliminates potential runtime errors from invalid algorithm strings.
82-87
: LGTM! Consistent use of KeyAlgorithm enum.
The method now returns a strongly-typed KeyAlgorithm instead of a string, maintaining consistency with the new type system.
crates/node_types/prover/src/prover/tests.rs (1)
Line range hint 11-103
: LGTM! Comprehensive test coverage for all curves.
The test functions have been properly parameterized to test all supported curves while maintaining the same test logic.
crates/common/src/transaction_builder.rs (1)
Line range hint 83-275
: LGTM! Consistent algorithm parameterization.
The TransactionBuilder methods have been consistently updated to support different key algorithms, improving flexibility while maintaining the existing functionality.
crates/node_types/prover/src/prover/mod.rs (3)
2-2
: LGTM: Import changes align with multi-curve support.
The addition of prism_keys
imports supports the PR's objective of testing different curves.
285-287
: Previous review comment addressed.
The signature verification changes have been implemented as suggested in the previous review.
67-79
: Verify test coverage for all supported key algorithms.
Let's ensure that tests exist for all supported key algorithms.
✅ Verification successful
Let me gather more information about the available key algorithms to ensure comprehensive test coverage.
Test coverage for key algorithms is comprehensive
The test files show that all supported key algorithms (Ed25519, Secp256k1, and Secp256r1) are being tested through parameterized test macros. Each test case is executed for all three production algorithms, as evidenced by:
- In
crates/node_types/prover/src/prover/tests.rs
:
$test_fn(KeyAlgorithm::Ed25519).await;
$test_fn(KeyAlgorithm::Secp256k1).await;
$test_fn(KeyAlgorithm::Secp256r1).await;
The create_test_prover
and create_mock_transactions
helper functions are used across multiple test scenarios with all key algorithm variants.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check test coverage for different key algorithms
# Look for test cases using different key algorithms
rg -A 10 "default_with_key_algorithm|new_with_algorithm" "crates/node_types/prover/src/prover/tests.rs"
# Look for test helper functions that might be using different algorithms
rg -A 5 "create_test_prover|create_mock_transactions" "crates/node_types/prover/src/prover/tests.rs"
Length of output: 5311
Script:
#!/bin/bash
# Look for KeyAlgorithm enum definition and its variants
rg -A 5 "enum KeyAlgorithm"
# Look for test cases that might be using different algorithm variants
rg "KeyAlgorithm::"
Length of output: 4638
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
♻️ Duplicate comments (2)
crates/common/src/transaction_builder.rs (2)
118-122
: 🛠️ Refactor suggestionMaintain consistent error handling across account creation methods.
Similar to the service registration methods, these methods should also handle errors properly instead of using
expect
.Additionally, verify that all callers of these methods are updated to handle the new algorithm parameter.
#!/bin/bash # Search for calls to account creation methods rg -A 2 "create_account_with_random_key(_signed)?" --type rustAlso applies to: 141-146
259-264
: 🛠️ Refactor suggestionImplement consistent error handling in data signing methods.
These methods should follow the same error handling pattern as suggested for other methods.
Additionally, verify that all callers of these data signing methods are updated to handle the new algorithm parameter.
#!/bin/bash # Search for calls to data signing methods rg -A 2 "add_randomly_signed_data(_verified_with_root)?" --type rustAlso applies to: 270-274
🧹 Nitpick comments (12)
crates/tree/src/tests.rs (3)
23-23
: Ensure error handling when committing transactions.Here, "create_account_with_random_key_signed(...).commit()" might fail at runtime if, for instance, account creation encounters unexpected conditions. Consider handling or propagating errors from commit() calls for more robust test error reporting.
115-115
: Consider verifying the updated account properties.After adding a random key, it might be useful to assert other updated account fields to ensure that no regressions occur in the update logic.
207-207
: Typographical error in panic message.In the panic string "Expetced insert proof for transaction," the word "Expetced" is misspelled. Consider fixing it for clarity.
Apply this diff to correct the spelling:
- panic!("Expetced insert proof for transaction"); + panic!("Expected insert proof for transaction");crates/keys/src/lib.rs (2)
18-18
: Document the 'Placeholder' variant.The 'Placeholder' variant may be confusing without explanatory context. In production code, a lack of clarity about its intended usage could introduce security or maintenance risks. Consider adding documentation detailing how and when 'Placeholder' should be used.
23-33
: Validate 'from_str' error messages.When users pass invalid algorithm strings, the error message from “Invalid algorithm: {}” might be insufficient for debugging. Consider returning or logging the set of supported algorithms to guide users toward valid options.
crates/tests/src/lib.rs (2)
37-42
: Provide explicit fallback behavior for unsupported environment variables.If users set an unsupported string for “CURVE_ALGORITHM,” the code panics. Consider offering a clearer fallback or user message, such as “Unsupported curve. Must be one of: ed25519, secp256k1, secp256r1."
Line range hint
70-77
: Repeated Docker environment setup for each curve.Spinning up and tearing down Docker in a loop ensures isolation for each algorithm test but can be time-consuming. If performance becomes a bottleneck, consider spinning up once, running all the curves in the same environment if feasible, then tearing down.
justfile (1)
70-77
: Consider caching Docker images to speed up repeated integration tests.Repeatedly building and tearing down containers can be resource-intensive. If faster iteration is desired, caching or incremental builds could be leveraged to improve test feedback times.
ci/run-validator.sh (1)
102-103
: Consider extracting common transaction flags to a variable.The
--fees
and--broadcast-mode block
flags are duplicated in both light and bridge node transaction commands.+ TX_FLAGS="--fees 21000utia --broadcast-mode block" - --fees 21000utia \ - --broadcast-mode block + $TX_FLAGS - --fees 21000utia \ - --broadcast-mode block + $TX_FLAGSAlso applies to: 164-165
crates/node_types/prover/src/prover/tests.rs (1)
19-31
: Consider parameterizing mock data generation.The mock transaction creation could be more flexible by accepting additional parameters for email domains and service IDs.
-fn create_mock_transactions(algorithm: KeyAlgorithm, service_id: String) -> Vec<Transaction> { +fn create_mock_transactions( + algorithm: KeyAlgorithm, + service_id: String, + user_emails: Vec<String>, +) -> Vec<Transaction> { let mut transaction_builder = TransactionBuilder::new(); + let mut transactions = vec![ + transaction_builder.register_service_with_random_keys(algorithm, &service_id).commit() + ]; - vec![ - transaction_builder.register_service_with_random_keys(algorithm, &service_id).commit(), - transaction_builder - .create_account_with_random_key_signed(algorithm, "user1@example.com", &service_id) - .commit(), - transaction_builder - .create_account_with_random_key_signed(algorithm, "user2@example.com", &service_id) - .commit(), - transaction_builder.add_random_key_verified_with_root(algorithm, "user1@example.com").commit(), - ] + for email in user_emails { + transactions.push( + transaction_builder + .create_account_with_random_key_signed(algorithm, &email, &service_id) + .commit() + ); + } + + // Add random key for first user + if let Some(first_user) = user_emails.first() { + transactions.push( + transaction_builder + .add_random_key_verified_with_root(algorithm, first_user) + .commit() + ); + } + + transactions }crates/common/src/transaction_builder.rs (2)
187-193
: Consider explicit type conversion and proper error handling.Two suggestions for improvement:
- Make the type conversion explicit for better readability
- Handle errors properly instead of using
expect
pub fn add_random_key( &mut self, algorithm: KeyAlgorithm, id: &str, signing_key: &SigningKey - ) -> UncommittedTransaction { - let random_key = SigningKey::new_with_algorithm(algorithm).expect("Failed to create random key").into(); + ) -> Result<UncommittedTransaction, Box<dyn std::error::Error>> { + let random_key = SigningKey::new_with_algorithm(algorithm) + .map_err(|e| format!("Failed to create random key: {}", e)) + .map(VerifyingKey::from)?; - self.add_key(id, random_key, signing_key) + Ok(self.add_key(id, random_key, signing_key))
Line range hint
1-391
: Consider implementing a comprehensive error handling strategy.The current changes introduce multiple points where errors could occur during key generation. Consider:
- Creating a custom error type for the crate to handle key-related errors
- Implementing proper error propagation throughout the builder methods
- Documenting error scenarios in the public API
This would improve the reliability and usability of the library.
Example custom error type:
#[derive(Debug, thiserror::Error)] pub enum TransactionBuilderError { #[error("Failed to create key: {0}")] KeyCreationError(String), #[error("Invalid key algorithm: {0}")] InvalidAlgorithmError(String), // Add other error variants as needed }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
ci/run-validator.sh
(3 hunks)crates/cli/src/main.rs
(5 hunks)crates/common/src/transaction_builder.rs
(6 hunks)crates/keys/src/lib.rs
(1 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/node_types/prover/src/prover/tests.rs
(7 hunks)crates/tests/src/lib.rs
(7 hunks)crates/tree/src/tests.rs
(11 hunks)justfile
(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/node_types/prover/src/prover/mod.rs
🔇 Additional comments (6)
crates/tests/src/lib.rs (1)
58-58
: Verify signing key creation errors.
“SigningKey::new_with_algorithm(algorithm)?” may return an error. Although you’re using the “?” operator to propagate it, consider whether you want more descriptive error handling or logs for diagnostic purposes.
ci/run-validator.sh (1)
171-174
: Verify impact of sequential provisioning.
The change from parallel to sequential provisioning of bridge and light nodes could increase the total provisioning time.
Also applies to: 212-212
✅ Verification successful
Based on the search results, I can now make a determination:
Sequential provisioning is safe and intentional.
The code shows that both provision_bridge_nodes
and provision_light_nodes
functions wait for the genesis block before proceeding (genesis_hash=$(wait_for_block 1)
). This indicates that the sequential ordering is intentional to ensure proper initialization order, where bridge nodes are provisioned first followed by light nodes.
No timing-related errors or race conditions were found between bridge and light nodes. The sequential provisioning appears to be a deliberate design choice for initialization order rather than a performance optimization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if there are any timing-sensitive operations or dependencies between bridge and light nodes
# Look for timing dependencies in the codebase
rg -A 5 "provision.*node.*wait|sleep|timeout"
# Check for any documented timing requirements
fd -t f "README|CONTRIBUTING" -X grep -l "provision"
Length of output: 103304
Script:
#!/bin/bash
# Check for any timing dependencies or ordering requirements between bridge and light nodes
# Look for any timing-related code around provisioning
rg -A 5 "provision_bridge|provision_light"
# Check for any error handling or dependencies between the nodes
rg -A 5 "bridge.*node.*error|light.*node.*error"
# Look for any documentation about provisioning order
fd -t f "README|CONTRIBUTING|CHANGELOG" -X grep -i "provision.*order"
Length of output: 66632
crates/cli/src/main.rs (1)
40-51
: Verify thread safety of key validation and creation.
The key validation and creation process involves multiple steps that could be affected by concurrent access.
Also applies to: 76-86, 132-162
✅ Verification successful
Let me generate additional scripts to check for thread safety aspects more thoroughly.
Based on the results, I can now generate the final response:
Key validation and creation are thread-safe by design
The key validation and creation process is stateless and does not share any mutable state. The code uses Arc
only for thread-safe reference counting of immutable data, particularly for the node types and DA layer implementations. The key validation functions themselves don't use any shared state or synchronization primitives.
- Key validation occurs during node initialization before any concurrent operations begin
- The
VerifyingKey
creation is a pure function that operates only on its input parameters - No static/global state or synchronization primitives (Mutex/RwLock) are used in the key handling code
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential race conditions in key handling
# Look for concurrent access patterns
rg -A 5 "async|tokio::spawn|Arc::new|Mutex|RwLock"
# Check for any documented thread safety requirements
ast-grep --pattern 'struct $name {
$$$
$field: Arc<$_>
$$$
}'
Length of output: 65861
Script:
#!/bin/bash
# Check for concurrent access patterns in key validation and creation
# Look for key validation and creation functions
ast-grep --pattern 'fn validate_algorithm($$$) {
$$$
}'
# Look for key creation functions
ast-grep --pattern 'fn from_algorithm_and_bytes($$$) {
$$$
}'
# Check for any shared state or static variables
rg -A 5 "static|lazy_static|thread_local|Mutex|RwLock|Arc" crates/cli/src/
# Check for any async functions that might interact with key validation
rg -A 5 "async fn" crates/cli/src/
Length of output: 6443
crates/node_types/prover/src/prover/tests.rs (2)
209-228
: LGTM! Well-designed test generation macro.
The macro effectively generates tests for each supported algorithm while maintaining readability and reducing code duplication.
230-236
: Verify test coverage across algorithms.
Let's ensure that all test cases provide adequate coverage for each algorithm's specific behaviors.
✅ Verification successful
Let me generate additional verification scripts to check the test coverage across algorithms.
The previous search didn't provide enough context about the test coverage. These additional scripts will help us:
- Find algorithm-specific test cases and assertions in test files
- Identify the KeyAlgorithm enum variants that need coverage
- Locate test helper functions used by the test macros
This will give us a better picture of the test coverage across different algorithms.
Let me try searching in the correct directory structure.
The previous search failed because we were looking in the wrong directory. These new scripts will:
- Search for algorithm-specific tests in the crates directory
- Find the KeyAlgorithm enum definition
- Look for the test helper functions and macro usages mentioned in the review snippet
This should give us better insight into the test coverage.
Test coverage is comprehensive across all supported key algorithms.
The codebase demonstrates thorough test coverage across all supported key algorithms (Ed25519, Secp256k1, and Secp256r1) through:
- A
generate_algorithm_tests!
macro that automatically generates test variants for each algorithm - Each test function is parameterized with
KeyAlgorithm
and tests algorithm-specific behaviors - Core functionality tests covering:
- Basic operations (insert, update, get)
- Error cases (invalid transactions, nonexistent services)
- State management (persistence, sync)
- Block execution and epoch finalization
The test suite ensures that each algorithm implementation is verified against the same test cases, maintaining consistent behavior across all supported algorithms.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check test coverage for algorithm-specific code paths
# Look for algorithm-specific code paths
ast-grep --pattern 'match $var {
KeyAlgorithm::$_ => $$$
}'
# Check for any algorithm-specific test assertions
rg -A 5 "assert.*algorithm|match.*algorithm"
Length of output: 131013
Script:
#!/bin/bash
# Look for algorithm-specific test cases and assertions in test files
rg -g "*.rs" -A 5 "test.*algorithm|assert.*algorithm|KeyAlgorithm::" tests/
# Find algorithm enum definition and variants
ast-grep --pattern 'enum KeyAlgorithm {
$$$
}'
# Find test helper functions that may be used by the test macros
ast-grep --pattern 'fn test_$_($_, $_) {
$$$
}'
Length of output: 227
Script:
#!/bin/bash
# Look for algorithm-specific test cases and assertions
rg -g "*.rs" -A 5 "test.*algorithm|assert.*algorithm|KeyAlgorithm::" crates/
# Find algorithm enum definition and variants
ast-grep --pattern 'enum KeyAlgorithm {
$$$
}'
# Find test helper functions that may be used by the test macros
rg -g "*.rs" -A 5 "generate_algorithm_tests|test_validate_and_queue_update|test_process_transactions|test_execute_block|test_finalize_new_epoch|test_restart_sync_from_scratch|test_load_persisted_state" crates/
Length of output: 29933
crates/common/src/transaction_builder.rs (1)
9-9
: LGTM: Import changes are correct.
The addition of KeyAlgorithm
import is appropriate for the new functionality.
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (2)
crates/keys/src/tests.rs (2)
10-35
: Consider parameterizing the tests to reduce code duplication.While the test logic is correct, the code is repetitive for each curve type. Consider using a test macro or parameterized tests to make the code more maintainable.
Example refactor using a macro:
macro_rules! test_verifying_key_reparsing { ($name:ident, $constructor:expr) => { #[test] fn $name() { let verifying_key = $constructor.verifying_key(); let re_parsed_verifying_key = VerifyingKey::from_algorithm_and_bytes( verifying_key.algorithm(), &verifying_key.to_bytes(), ) .unwrap(); assert_eq!(re_parsed_verifying_key, verifying_key); } }; } test_verifying_key_reparsing!(test_ed25519_verifying_key, SigningKey::new_ed25519()); test_verifying_key_reparsing!(test_secp256k1_verifying_key, SigningKey::new_secp256k1()); test_verifying_key_reparsing!(test_secp256r1_verifying_key, SigningKey::new_secp256r1());
1-140
: Test coverage aligns with PR objectives but could be more comprehensive.The tests successfully verify that different curves (Ed25519, Secp256k1, Secp256r1) can be used interchangeably, which aligns with the PR objective of verifying if prover and full node can use different curves. However, consider:
- Adding integration tests that specifically simulate prover and full node interaction with different curve combinations
- Adding property-based tests to verify key compatibility across a wider range of scenarios
- Adding performance benchmarks to compare different curve combinations
Would you like help implementing any of these suggestions?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (2)
crates/keys/src/tests.rs
(1 hunks)crates/tests/Cargo.toml
(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/tests/Cargo.toml
🔇 Additional comments (2)
crates/keys/src/tests.rs (2)
1-8
: LGTM: Imports are appropriate and secure.
The module correctly imports all necessary cryptographic libraries and uses OsRng for secure random number generation.
93-139
: 🛠️ Refactor suggestion
Add more error cases for string parsing.
While the invalid length test is good, consider adding tests for:
- Invalid base64 strings
- Valid base64 but invalid key data
- Empty strings
- Very long strings
Also, verify that the base64 implementation is using a secure, constant-time comparison to prevent timing attacks.
✅ Verification successful
Let me check the base64 implementation details to verify the security concerns.
Let me check the actual base64 crate being used to verify its security properties.
Add more error test cases, but no security concerns with base64
The base64 implementation uses the standard Rust base64 crate (v0.22.0) which is well-maintained and secure by default. The constant-time concern is not applicable here as:
- The base64 crate uses constant-time operations internally
- Base64 encoding/decoding doesn't typically need timing attack protection as the encoded data is public
Agree with adding these test cases:
- Invalid base64 strings (e.g., non-base64 characters)
- Valid base64 but invalid key data (e.g., all zeros)
- Empty strings
- Very long strings (>44 chars which is the base64 length of 32 bytes)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the base64 implementation uses constant-time comparison
rg -A 5 "impl.*ToBase64|impl.*FromBase64"
Length of output: 1814
Script:
#!/bin/bash
# Check the base64 implementation details
cat crates/serde/src/base64.rs
Length of output: 1156
Script:
#!/bin/bash
# Check Cargo.toml for base64 dependency version
rg "base64.*=" -A 2 "Cargo.toml"
Length of output: 82
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (8)
crates/tree/src/tests.rs (2)
Line range hint
42-59
: Consider verifying error details
You assert that processing the transaction fails for a non-existent service, which is correct. However, you might also verify the specific error message or variant to confirm the failure mode is clear to end users.
Line range hint
192-226
: Mismatched panic message
In this block:let Proof::Update(update_proof) = last_proof else { panic!("Expetced insert proof for transaction"); };You're destructuring a
Proof::Update
but the panic mentions "insert proof."Please fix the panic message to reflect the expected
Proof::Update
.- panic!("Expetced insert proof for transaction"); + panic!("Expected update proof for transaction");crates/keys/src/signing_keys.rs (1)
33-39
: Consider adding error context to ResultWhile the implementation is clean and reuses existing methods, consider adding context to the error case to help with debugging.
pub fn new_with_algorithm(algorithm: CryptoAlgorithm) -> Result<Self> { match algorithm { CryptoAlgorithm::Ed25519 => Ok(SigningKey::new_ed25519()), CryptoAlgorithm::Secp256k1 => Ok(SigningKey::new_secp256k1()), CryptoAlgorithm::Secp256r1 => Ok(SigningKey::new_secp256r1()), - } + }.map_err(|e| anyhow::anyhow!("Failed to create signing key with algorithm {:?}: {}", algorithm, e)) }crates/tests/src/lib.rs (1)
58-59
: Add error logging for key generationConsider adding debug logs for key generation to aid in troubleshooting.
+ debug!("Generating signing key with algorithm: {:?}", algorithm); let signing_key = SigningKey::new_with_algorithm(algorithm)?; + debug!("Generated verifying key from signing key"); let pubkey = signing_key.verifying_key();crates/cli/src/main.rs (2)
168-196
: Add documentation for helper functionsConsider adding documentation comments to explain the purpose and behavior of these helper functions.
+/// Validates the provided algorithm string by ensuring it's not empty and can be parsed into a CryptoAlgorithm. +/// +/// # Arguments +/// * `algorithm` - The algorithm string to validate +/// +/// # Returns +/// * `Ok(&str)` - The validated algorithm string +/// * `Err(std::io::Error)` - If the algorithm is empty or invalid fn validate_algorithm(algorithm: &str) -> Result<&str, std::io::Error> { +/// Creates a key from the provided algorithm and bytes using the specified creator function. +/// +/// # Arguments +/// * `algorithm` - The algorithm string +/// * `bytes` - The key bytes +/// * `creator` - Function to create the key from algorithm and bytes +/// +/// # Returns +/// * `Ok(T)` - The created key +/// * `Err(std::io::Error)` - If key creation fails fn create_key_from_algorithm<T>(
70-78
: Add logging for key operationsConsider adding debug logs for key operations to aid in troubleshooting.
let verifying_key_algorithm = validate_algorithm(&config.verifying_key_algorithm)?; + debug!("Creating signing key with algorithm: {}", verifying_key_algorithm); let signing_key = create_key_from_algorithm( verifying_key_algorithm, signing_key_chain.as_bytes(), SigningKey::from_algorithm_and_bytes, )?; + debug!("Deriving verifying key from signing key"); let verifying_key = signing_key.verifying_key();crates/node_types/prover/src/prover/tests.rs (1)
11-16
: Consider proper error handling in test helper functions.The test helper functions use
unwrap()
which could make test failures harder to debug. Consider usingexpect()
with descriptive messages.- let cfg = Config::default_with_key_algorithm(algorithm).unwrap(); - Arc::new(Prover::new(db.clone(), da_layer, &cfg).unwrap()) + let cfg = Config::default_with_key_algorithm(algorithm) + .expect("Failed to create config with algorithm"); + Arc::new(Prover::new(db.clone(), da_layer, &cfg) + .expect("Failed to create prover instance"))crates/common/src/transaction_builder.rs (1)
83-89
: Consider documenting algorithm compatibility requirements.The methods allow any algorithm to be used for key generation, but there might be compatibility requirements or recommendations for specific use cases (e.g., which algorithms are suitable for service keys vs account keys).
Consider adding documentation comments explaining any algorithm recommendations or restrictions.
Also applies to: 187-193
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
crates/cli/src/main.rs
(5 hunks)crates/common/src/transaction_builder.rs
(6 hunks)crates/keys/src/algorithm.rs
(1 hunks)crates/keys/src/lib.rs
(1 hunks)crates/keys/src/payload.rs
(1 hunks)crates/keys/src/signatures.rs
(3 hunks)crates/keys/src/signing_keys.rs
(5 hunks)crates/keys/src/verifying_keys.rs
(5 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/node_types/prover/src/prover/tests.rs
(7 hunks)crates/serde/src/lib.rs
(0 hunks)crates/tests/src/lib.rs
(7 hunks)crates/tree/src/tests.rs
(11 hunks)
💤 Files with no reviewable changes (1)
- crates/serde/src/lib.rs
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/node_types/prover/src/prover/mod.rs
🔇 Additional comments (25)
crates/tree/src/tests.rs (11)
5-5
: Import statements look good
The new imports for CryptoAlgorithm
and SigningKey
enable more flexible cryptographic operations. No further modification needed.
Line range hint 12-39
: Test coverage looks solid
This test verifies the creation of a service and an account using the provided algorithm. The assertions ensure the insert proofs are valid and that the lookup yields the expected account details.
Line range hint 61-90
: Robust negative test
This test properly checks the case of an invalid service challenge. Everything looks consistent, and the negative scenario is validated.
Line range hint 91-114
: Handling duplicate keys is validated
This test method thoroughly confirms that trying to create an existing account ID fails. Great job covering this edge case.
Line range hint 115-137
: Positive path for updating an existing key
This test ensures that updating an account with a new key works as expected. The proof verification logic looks correct.
138-154
: Good error path for unknown keys
This test properly checks that adding a key for a non-existent account fails. Consider verifying the specific error type if you need stronger guarantees.
Line range hint 155-191
: Multiple inserts and updates
The sequence of inserts and updates for multiple accounts thoroughly checks various interactions. Assertions for final states are correct.
Line range hint 227-243
: Root hash change detection
The test confirms the root hash changes after processing a transaction. This coverage is sufficient for verifying Merkle tree integrity updates.
Line range hint 244-282
: Batch writing
This test thoroughly exercises back-to-back operations and looks up the values immediately after each write. Overall approach is correct.
283-315
: Use of macro for test generation
You've successfully implemented a macro to avoid duplicating tests for each algorithm. This satisfies the refactor suggestion from a previous review.
316-327
: Non-existing key retrieval
This negative test ensures the tree correctly returns a non-existing proof. The verification of non-existence is an excellent addition.
crates/keys/src/payload.rs (1)
1-11
: Consider minimal validation on bytes
Although this struct is straightforward, ensure there's no scenario where an empty or malformed byte vector could cause undefined behavior downstream. You could add checks or rely on upstream validation for cryptographic payload correctness.
crates/keys/src/algorithm.rs (1)
1-22
: Enum definition is clear
The CryptoAlgorithm
enum with FromStr
support cleanly implements the supported algorithms. This provides strong type-safety when parsing algorithm strings.
crates/keys/src/lib.rs (1)
1-2
: Modular structure is logical
Introducing separate modules for algorithm
and payload
makes the cryptographic handling components more organized.
Also applies to: 7-7, 13-13
crates/keys/src/signatures.rs (3)
30-43
: Clearer mapping from algorithms to signatures
The changes to from_algorithm_and_bytes
allow for explicit matching on the CryptoAlgorithm
enum, removing the need for ad-hoc string checking. This is safer and more transparent.
44-49
: Placeholder variant defaulting to Ed25519
If Signature::Placeholder
arises, returning Ed25519
may be misleading. An explicit mention of this quirk in documentation or restricting Placeholder
usage could be beneficial.
58-58
: Serialization/Deserialization alignment
Using CryptoAlgorithm
directly in the payload simplifies conversions. The try_from
and From
implementations for Signature
cleanly encapsulate the round-trip logic.
Also applies to: 65-65
crates/keys/src/signing_keys.rs (3)
Line range hint 1-11
: LGTM! Clean import organization
The imports are well-organized and the addition of CryptoAlgorithm
aligns with the PR's objective to support multiple curves.
53-64
: LGTM! Robust error handling
The implementation properly handles errors for each algorithm type and maps them to appropriate error types.
67-72
: LGTM! Complete algorithm mapping
The method correctly maps each SigningKey variant to its corresponding CryptoAlgorithm with an exhaustive match.
crates/cli/src/main.rs (2)
119-143
: LGTM! Robust error handling
The implementation properly handles potential errors and follows good practices for key management.
40-45
:
Replace unwrap with proper error handling
The unwrap on config.verifying_key could panic at runtime.
let verifying_key_algorithm = validate_algorithm(&config.verifying_key_algorithm)?;
let prover_vk = create_key_from_algorithm(
verifying_key_algorithm,
- config.verifying_key.unwrap().as_bytes(),
+ config.verifying_key
+ .ok_or_else(|| std::io::Error::new(
+ std::io::ErrorKind::NotFound,
+ "verifying key not found in config",
+ ))?
+ .as_bytes(),
VerifyingKey::from_algorithm_and_bytes,
)?;
Likely invalid or redundant comment.
crates/keys/src/verifying_keys.rs (1)
Line range hint 85-103
: LGTM! Robust signature verification implementation.
The implementation correctly handles signature verification for all supported curves (Ed25519, Secp256k1, Secp256r1) with proper error handling and informative error messages.
crates/node_types/prover/src/prover/tests.rs (1)
209-228
: Well-designed macro for comprehensive algorithm testing.
The macro elegantly generates test cases for all supported curves, reducing code duplication while ensuring complete coverage.
crates/common/src/transaction_builder.rs (1)
259-264
: Verify the security implications of random key generation.
When generating random keys for signing data, ensure that the key generation process is cryptographically secure and that the keys have sufficient entropy for all supported algorithms.
Also applies to: 270-275
✅ Verification successful
Key generation implementation uses secure random number generation
The implementation uses OsRng
from the rand
crate for all supported algorithms (Ed25519, Secp256k1, and Secp256r1), which provides a cryptographically secure random number generator sourced from the operating system. This is the recommended approach for cryptographic key generation.
- Ed25519 keys use
Ed25519SigningKey::new(OsRng)
- Secp256k1 keys use
Secp256k1SigningKey::new(&mut OsRng)
- Secp256r1 keys use
Secp256r1SigningKey::random(&mut OsRng)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for secure random number generation usage in key generation
# Look for secure RNG usage
rg -A 5 "rand|random|generate"
# Check for any crypto-related security advisories
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: RUST, package: "ed25519-consensus") {
nodes {
advisory {
summary
severity
}
}
}
}'
Length of output: 66203
Script:
#!/bin/bash
# Let's check how the SigningKey is implemented and what RNG it uses
# Check SigningKey implementation
ast-grep --pattern 'impl SigningKey {
$$$
new_with_algorithm($$$) {
$$$
}
$$$
}'
# Check for RNG usage in key generation
ast-grep --pattern 'use rand::{$$$};'
# Look for actual key generation implementation
rg -A 5 "new_with_algorithm" crates/keys/src/
Length of output: 851
Script:
#!/bin/bash
# Let's check the specific key generation implementations
# Look for the key generation methods
ast-grep --pattern 'fn new_ed25519($$$) {
$$$
}'
ast-grep --pattern 'fn new_secp256k1($$$) {
$$$
}'
ast-grep --pattern 'fn new_secp256r1($$$) {
$$$
}'
# Also check for OsRng usage which is cryptographically secure
rg -A 5 "OsRng" crates/keys/src/
Length of output: 3043
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
♻️ Duplicate comments (2)
crates/common/src/transaction_builder.rs (1)
88-91
:⚠️ Potential issueImprove error handling in key generation.
The key generation code uses
expect
which could cause panics. This was previously flagged in past reviews but remains unaddressed.Consider propagating errors instead of using
expect
. For example:- let random_service_challenge_key = - SigningKey::new_with_algorithm(algorithm).expect("Failed to create challenge key"); - let random_service_signing_key = - SigningKey::new_with_algorithm(algorithm).expect("Failed to create signing key"); + let random_service_challenge_key = SigningKey::new_with_algorithm(algorithm) + .map_err(|e| format!("Failed to create challenge key: {}", e))?; + let random_service_signing_key = SigningKey::new_with_algorithm(algorithm) + .map_err(|e| format!("Failed to create signing key: {}", e))?;Also applies to: 124-125, 149-150, 201-202, 273-274, 284-285
crates/node_types/prover/src/prover/mod.rs (1)
293-296
: 🛠️ Refactor suggestionRemove unnecessary clone of VerifyingKey.
The
VerifyingKey
is unnecessarily cloned in the signature verification call.Apply this fix:
- epoch - .verify_signature(self.cfg.verifying_key.clone()) - .with_context(|| format!("Invalid signature in epoch {}", epoch.height))?; + epoch + .verify_signature(&self.cfg.verifying_key) + .with_context(|| format!("Invalid signature in epoch {}", epoch.height))?;
🧹 Nitpick comments (10)
crates/tree/src/tests.rs (1)
325-336
: Includetest_get_non_existing_key
in algorithm testsThe
test_get_non_existing_key
function currently tests only the default algorithm. To ensure consistent testing across all supported algorithms, consider parameterizing this test withalgorithm: CryptoAlgorithm
and using thegenerate_algorithm_tests
macro.Apply this diff to parameterize the test and include it in the macro:
#[test] -fn test_get_non_existing_key() { +fn test_get_non_existing_key(algorithm: CryptoAlgorithm) { let tree = KeyDirectoryTree::new(Arc::new(MockTreeStore::default())); let result = tree.get(KeyHash::with::<TreeHasher>("non_existing_id")).unwrap(); let NotFound(non_membership_proof) = result else { panic!("Account found for key while it was expected to be missing"); }; assert!(non_membership_proof.verify_nonexistence().is_ok()); } +generate_algorithm_tests!(test_get_non_existing_key);crates/da/src/lib.rs (1)
53-55
: Provide detailed error messages for signature parsingThe current error message "Invalid signature length" may not fully capture the reasons for failure in parsing the signature. Including the underlying error information can help with debugging.
Apply this diff to enhance error handling:
let signature: Signature = Signature::from_algorithm_and_bytes(vk.algorithm(), signature_bytes.as_slice()) - .map_err(|_| anyhow::anyhow!("Invalid signature length"))?; + .map_err(|e| anyhow::anyhow!("Failed to parse signature: {}", e))?;crates/tests/src/lib.rs (1)
146-152
: Improve random algorithm selection implementation.Consider using a more idiomatic approach with
choose()
and making the array static:+static SUPPORTED_ALGORITHMS: &[CryptoAlgorithm] = &[ + CryptoAlgorithm::Ed25519, + CryptoAlgorithm::Secp256k1, + CryptoAlgorithm::Secp256r1, +]; + fn random_algorithm(rng: &mut StdRng) -> CryptoAlgorithm { - [ - CryptoAlgorithm::Ed25519, - CryptoAlgorithm::Secp256k1, - CryptoAlgorithm::Secp256r1, - ][rng.gen_range(0..3)] + *SUPPORTED_ALGORITHMS.choose(rng).unwrap() }justfile (1)
70-76
: Enhance integration test feedback and error handling.Consider improving the test loop with better feedback and error handling:
for curve in ed25519 secp256k1 secp256r1; do + echo "Running integration tests for $curve curve..." just celestia-up - cargo test -p prism-tests --lib --release --features mock_prover + if ! cargo test -p prism-tests --lib --release --features mock_prover; then + echo "Tests failed for $curve curve" + just celestia-down + exit 1 + fi just celestia-down + echo "Successfully completed tests for $curve curve" donecrates/keys/src/tests.rs (2)
10-35
: Add negative test cases for verifying key parsing.Consider adding tests for:
- Invalid key bytes
- Mismatched algorithm and key bytes
- Empty key bytes
#[test] fn test_verifying_key_from_invalid_bytes() { let invalid_bytes = vec![0u8; 32]; let result = VerifyingKey::from_algorithm_and_bytes( CryptoAlgorithm::Ed25519, &invalid_bytes, ); assert!(result.is_err()); }
37-62
: Parameterize signing key tests.Consider using a test macro or parameterized tests to reduce code duplication:
macro_rules! test_signing_key { ($name:ident, $algorithm:expr) => { #[test] fn $name() { let signing_key = SigningKey::new_with_algorithm($algorithm).unwrap(); let re_parsed_signing_key = SigningKey::from_algorithm_and_bytes( signing_key.algorithm(), &signing_key.to_bytes(), ) .unwrap(); assert_eq!(re_parsed_signing_key, signing_key); } }; } test_signing_key!(test_ed25519_signing_key, CryptoAlgorithm::Ed25519); test_signing_key!(test_secp256k1_signing_key, CryptoAlgorithm::Secp256k1); test_signing_key!(test_secp256r1_signing_key, CryptoAlgorithm::Secp256r1);crates/cli/src/main.rs (1)
186-201
: Enhance algorithm validation.Consider improving the validation function with more specific error messages and using constants:
+const VERIFYING_KEY_REQUIRED: &str = "verifying key algorithm is required"; +const INVALID_ALGORITHM: &str = "invalid verifying key algorithm format"; fn validate_algorithm(algorithm: &str) -> Result<&str, Error> { if algorithm.is_empty() { - return Err(Error::new( - ErrorKind::InvalidInput, - "verifying key algorithm is required", - )); + return Err(Error::new(ErrorKind::InvalidInput, VERIFYING_KEY_REQUIRED)); } - if CryptoAlgorithm::from_str(algorithm).is_err() { - return Err(Error::new( - ErrorKind::InvalidInput, - "invalid verifying key algorithm format", - )); - } + CryptoAlgorithm::from_str(algorithm) + .map_err(|_| Error::new(ErrorKind::InvalidInput, INVALID_ALGORITHM))?; Ok(algorithm) }crates/cli/src/cfg.rs (2)
39-41
: Enhance documentation for verifying key algorithm.Consider adding more detailed documentation about supported algorithms and their use cases:
- /// Can be one of: ed25519, secp256k1, secp256r1 + /// The cryptographic algorithm to use for verifying keys. + /// + /// Supported algorithms: + /// - ed25519: EdDSA with Curve25519 (default, recommended for general use) + /// - secp256k1: ECDSA with secp256k1 curve (compatible with Bitcoin/Ethereum) + /// - secp256r1: ECDSA with NIST P-256 curve (FIPS compliant)
104-104
: Add validation for verifying key algorithm in Config.Consider adding validation when deserializing the Config:
impl<'de> Deserialize<'de> for Config { fn deserialize<D>(deserializer: D) -> Result<Self, D::Error> where D: serde::Deserializer<'de>, { #[derive(Deserialize)] struct ConfigHelper { // ... other fields ... verifying_key_algorithm: String, } let helper = ConfigHelper::deserialize(deserializer)?; // Validate algorithm if let Err(e) = CryptoAlgorithm::from_str(&helper.verifying_key_algorithm) { return Err(serde::de::Error::custom(format!( "invalid verifying key algorithm: {}", e ))); } Ok(Config { // ... other fields ... verifying_key_algorithm: helper.verifying_key_algorithm, }) } }Also applies to: 115-115
crates/node_types/prover/src/prover/tests.rs (1)
213-240
: Consider adding negative test cases.The macro implementation elegantly generates test variants for each supported algorithm. However, consider adding negative test cases to verify proper error handling when:
- Invalid algorithms are provided
- Algorithm mismatches occur between different keys
- Mixed algorithms are used within the same transaction chain
Would you like me to help implement these additional test cases?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
crates/cli/src/cfg.rs
(4 hunks)crates/cli/src/main.rs
(3 hunks)crates/common/src/transaction_builder.rs
(6 hunks)crates/da/src/celestia.rs
(1 hunks)crates/da/src/lib.rs
(2 hunks)crates/keys/src/algorithm.rs
(1 hunks)crates/keys/src/tests.rs
(1 hunks)crates/keys/src/verifying_keys.rs
(2 hunks)crates/node_types/lightclient/src/lightclient.rs
(2 hunks)crates/node_types/prover/Cargo.toml
(1 hunks)crates/node_types/prover/src/prover/mod.rs
(3 hunks)crates/node_types/prover/src/prover/tests.rs
(7 hunks)crates/storage/src/inmemory.rs
(1 hunks)crates/tests/src/lib.rs
(6 hunks)crates/tree/Cargo.toml
(1 hunks)crates/tree/src/tests.rs
(11 hunks)justfile
(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- crates/da/src/celestia.rs
🚧 Files skipped from review as they are similar to previous changes (5)
- crates/tree/Cargo.toml
- crates/keys/src/algorithm.rs
- crates/node_types/prover/Cargo.toml
- crates/node_types/lightclient/src/lightclient.rs
- crates/keys/src/verifying_keys.rs
🧰 Additional context used
🪛 GitHub Check: clippy
crates/cli/src/main.rs
[failure] 37-37:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 44-44:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 50-50:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 77-77:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 84-84:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 90-90:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 136-136:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 143-143:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
[failure] 149-149:
using Result.or_else(|x| Err(y))
, which is more succinctly expressed as map_err(|x| y)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: unused dependencies
- GitHub Check: integration-test
- GitHub Check: unit-test
🔇 Additional comments (10)
crates/tree/src/tests.rs (1)
293-312
: Efficient use of macros to reduce code duplicationGreat job implementing the
generate_algorithm_tests
macro. This approach significantly reduces code duplication and enhances maintainability. It also makes it easier to add support for new algorithms in the future.crates/storage/src/inmemory.rs (1)
95-97
: Refactored code improves readabilityThe refactored
get_commitment
method effectively condenses the logic and enhances readability without altering functionality. Good use ofok_or_else
to handle the potential absence of a commitment.crates/da/src/lib.rs (1)
57-57
: Confirm consistent error handling in signature verificationIncluding the error details in the signature verification failure message aids in troubleshooting. This practice is correctly followed here.
crates/tests/src/lib.rs (2)
82-84
: Add error handling for transaction builder operations.The transaction builder methods should handle potential errors from key generation.
Also applies to: 97-101, 119-121
45-47
: Enhance test coverage for all supported curves.The test only uses Ed25519 for the prover. Consider parameterizing the test to cover all supported algorithms.
crates/node_types/prover/src/prover/tests.rs (2)
3-3
: LGTM! Helper functions properly updated for algorithm support.The changes to import statements and helper functions are well-structured and maintain consistency with the new crypto algorithm support. The
create_test_prover
andcreate_mock_transactions
functions now properly accept and utilize the algorithm parameter.Also applies to: 11-17, 19-33
Line range hint
36-211
: LGTM! Test functions properly parameterized.The test functions have been consistently updated to accept and utilize the
CryptoAlgorithm
parameter while maintaining their original test coverage and assertions.crates/common/src/transaction_builder.rs (1)
83-87
: LGTM! Method signatures consistently updated.The method signatures have been comprehensively updated to accept the
CryptoAlgorithm
parameter, maintaining API consistency across all related methods.Also applies to: 120-126, 144-150, 183-187, 195-202, 268-274, 280-285
crates/node_types/prover/src/prover/mod.rs (2)
5-5
: LGTM! Config struct properly updated for new key type.The Config struct has been properly updated to use the new
VerifyingKey
type from prism_keys, maintaining consistency with the new crypto algorithm support.Also applies to: 46-46
67-89
: LGTM! Well-documented method with proper error handling.The new
default_with_key_algorithm
method is well-documented and includes proper error handling using thecontext
method for error propagation.
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Nitpick comments (5)
crates/tests/src/lib.rs (3)
45-47
: Consider parameterizing the test for comprehensive curve testing.The test currently uses Ed25519 for the prover and a random algorithm for the service. Consider creating a parameterized test that systematically tests all possible combinations of prover and service algorithms.
- let prover_algorithm = CryptoAlgorithm::Ed25519; - let service_algorithm = random_algorithm(&mut rng); + for prover_algorithm in [CryptoAlgorithm::Ed25519, CryptoAlgorithm::Secp256k1, CryptoAlgorithm::Secp256r1] { + for service_algorithm in [CryptoAlgorithm::Ed25519, CryptoAlgorithm::Secp256k1, CryptoAlgorithm::Secp256r1] { + test_with_algorithms(prover_algorithm, service_algorithm).await?; + } + }
86-86
: Use consistent logging approach.Replace println! with the logging macro to maintain consistency with the rest of the codebase.
- println!("builder accounts: {:?}", transaction_builder.get_account("test_service")); + log::debug!("builder accounts: {:?}", transaction_builder.get_account("test_service"));
150-156
: Improve maintainability of algorithm selection.Consider using array's choose method for better readability and maintainability.
-fn random_algorithm(rng: &mut StdRng) -> CryptoAlgorithm { - [ - CryptoAlgorithm::Ed25519, - CryptoAlgorithm::Secp256k1, - CryptoAlgorithm::Secp256r1, - ][rng.gen_range(0..3)] -} +fn random_algorithm(rng: &mut StdRng) -> CryptoAlgorithm { + *[ + CryptoAlgorithm::Ed25519, + CryptoAlgorithm::Secp256k1, + CryptoAlgorithm::Secp256r1, + ].choose(rng).expect("non-empty array") +}crates/cli/src/main.rs (2)
186-201
: Optimize algorithm validation.The function performs redundant validation. Since
CryptoAlgorithm::from_str
already handles empty strings, the empty check is unnecessary.fn validate_algorithm(algorithm: &str) -> Result<&str, Error> { - if algorithm.is_empty() { - return Err(Error::new( - ErrorKind::InvalidInput, - "verifying key algorithm is required", - )); - } - if CryptoAlgorithm::from_str(algorithm).is_err() { return Err(Error::new( ErrorKind::InvalidInput, "invalid verifying key algorithm format", )); } Ok(algorithm) }
157-161
: Standardize error handling patterns.The code uses different patterns for error handling. Consider standardizing on
map_err
for consistency.let prover_vk = config .verifying_key - .ok_or_else(|| Error::new(ErrorKind::NotFound, "prover verifying key not found")) - .and_then(|vk| { - VerifyingKey::from_algorithm_and_bytes(verifying_key_algorithm, vk.as_bytes()) - .map_err(|e| Error::new(ErrorKind::InvalidInput, e.to_string())) - })?; + .ok_or_else(|| Error::new(ErrorKind::NotFound, "prover verifying key not found"))?; + let prover_vk = VerifyingKey::from_algorithm_and_bytes( + verifying_key_algorithm, + prover_vk.as_bytes(), + ) + .map_err(|e| Error::new(ErrorKind::InvalidInput, e.to_string()))?;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
crates/cli/src/main.rs
(3 hunks)crates/keys/src/lib.rs
(1 hunks)crates/tests/src/lib.rs
(6 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: integration-test
- GitHub Check: unused dependencies
- GitHub Check: clippy
- GitHub Check: unit-test
🔇 Additional comments (3)
crates/keys/src/lib.rs (2)
Line range hint
1-10
: LGTM! Well-organized module structure.The module organization follows good practices with clear separation of concerns and explicit public exports.
12-13
: Good practice: Moving tests to a separate module.Moving tests to a separate file improves maintainability and keeps the main module focused. The
#[cfg(any(test, doctest))]
attribute correctly ensures the tests are only compiled when needed.Let's verify the new test module exists and contains the expected tests:
✅ Verification successful
Test module implementation verified successfully
The test module is well-structured and provides comprehensive coverage for all key algorithms (ed25519, secp256k1, secp256r1), including:
- Key parsing and serialization tests
- Signature operations
- Error cases
- Proper use of test attributes and module organization
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the new test module exists and contains tests for all algorithms # Check if the test file exists and contains tests fd "tests.rs" crates/keys/src/ --exec rg -U "mod tests \{.*?^\}" --multiline {} # Verify test coverage for different algorithms rg -i "test.*(?:ed25519|secp256k1|secp256r1)" crates/keys/src/tests.rsLength of output: 308
Script:
#!/bin/bash # Get full content of the test module to verify structure and completeness cat crates/keys/src/tests.rsLength of output: 5267
crates/tests/src/lib.rs (1)
99-103
: Enhance test coverage for account creation.While using random algorithms provides variety, it might miss specific edge cases. Consider adding dedicated tests for known problematic combinations or boundary conditions.
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (4)
crates/tests/src/lib.rs (3)
45-48
: Consider testing all curve combinationsWhile using Ed25519 for the prover and a random algorithm for the service is a good start, consider testing all possible combinations of curves between prover and service to ensure complete compatibility.
- let prover_algorithm = CryptoAlgorithm::Ed25519; - let service_algorithm = random_algorithm(&mut rng); + for prover_algorithm in [ + CryptoAlgorithm::Ed25519, + CryptoAlgorithm::Secp256k1, + CryptoAlgorithm::Secp256r1, + ] { + for service_algorithm in [ + CryptoAlgorithm::Ed25519, + CryptoAlgorithm::Secp256k1, + CryptoAlgorithm::Secp256r1, + ] { + test_with_algorithms(prover_algorithm, service_algorithm).await?; + } + }
105-105
: Remove debug logThis debug log appears to be leftover from debugging and should be removed.
- log::info!("builder accounts: {:?}", transaction_builder.get_account(&random_user_id));
149-155
: Consider using choose for cleaner codeWhile the current implementation is correct, using
choose
would be more idiomatic.fn random_algorithm(rng: &mut StdRng) -> CryptoAlgorithm { - [ + *[ CryptoAlgorithm::Ed25519, CryptoAlgorithm::Secp256k1, CryptoAlgorithm::Secp256r1, - ][rng.gen_range(0..3)] + ].choose(rng).unwrap() }crates/cli/src/main.rs (1)
165-165
: Enhance error context in final error handling.The final error handling loses context about which component failed. Consider adding more context to the error message.
-node.start().await.map_err(|e| Error::new(ErrorKind::Other, e.to_string())) +node.start().await.map_err(|e| { + error!("Failed to start node: {}", e); + Error::new(ErrorKind::Other, format!("Failed to start node: {}", e)) +})
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
crates/cli/src/cfg.rs
(4 hunks)crates/cli/src/main.rs
(3 hunks)crates/keys/src/lib.rs
(1 hunks)crates/tests/src/lib.rs
(6 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- crates/cli/src/cfg.rs
🧰 Additional context used
🪛 GitHub Actions: Rust CI
crates/keys/src/lib.rs
[error] 12-12: unexpected cfg
condition name: test
🔇 Additional comments (4)
crates/tests/src/lib.rs (3)
52-54
: LGTM! Good error handling.The key generation code with proper error handling looks good.
83-85
: LGTM! Good test coverage with different algorithms.Using different algorithms for service registration, account creation, and key updates provides good coverage of cross-curve compatibility.
Also applies to: 98-102, 122-124
133-133
: LGTM! Reasonable test configuration.The sleep duration and height check adjustments look appropriate for test stability.
Also applies to: 141-141
crates/keys/src/lib.rs (1)
12-13
:⚠️ Potential issueFix the
cfg
attribute syntax.The current
cfg
attribute is causing a pipeline failure. The correct syntax should be:-#[cfg(test)] +#[cfg(any(test, doctest))] mod tests;Likely invalid or redundant comment.
🧰 Tools
🪛 GitHub Check: unused dependencies
[failure] 12-12:
unexpectedcfg
condition name:test
🪛 GitHub Actions: Rust CI
[error] 12-12: unexpected
cfg
condition name:test
Signed-off-by: Smuu <18609909+Smuu@users.noreply.github.com>
Questions:
Closes #135
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Refactoring
ed25519-consensus
library withprism-keys
.Documentation
Breaking Changes