chore(sdk): various sdk fixes #2328
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe pull request introduces a series of updates across multiple files, primarily focusing on enhancing the handling of BLS signatures and improving error management within the Dash Platform's codebase. Key changes include updates to dependency versions in Changes
Possibly related PRs
Poem
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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
🛑 Comments failed to post (19)
packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/mod.rs (1)
122-123:
⚠️ Potential issueFix incorrect documentation comment for V1 variant.
The documentation comment incorrectly states "Version 0" for the V1 variant.
Apply this fix:
- /// Version 0 of the signature verification quorums + /// Version 1 of the signature verification quorums V1(SignatureVerificationQuorumSetForSavingV1),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements./// Version 1 of the signature verification quorums V1(SignatureVerificationQuorumSetForSavingV1),packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/for_saving.rs (2)
165-168: 🛠️ Refactor suggestion
Consider proper error handling while maintaining compression efficiency
The use of
to_compressed()for the public key is good for efficiency. However, similar to the previous conversion, theexpectusage could be replaced with proper error handling.Consider propagating the error while maintaining the compression:
- public_key: bls_signatures::PublicKey::from_bytes( - &quorum.public_key.0.to_compressed(), - ) - .expect("expected to convert between BLS key libraries (to chia)"), + public_key: bls_signatures::PublicKey::from_bytes( + &quorum.public_key.0.to_compressed(), + ) + .map_err(|e| format!("Failed to convert BLS key to chia: {}", e))?,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.public_key: bls_signatures::PublicKey::from_bytes( &quorum.public_key.0.to_compressed(), ) .map_err(|e| format!("Failed to convert BLS key to chia: {}", e))?,
148-151: 🛠️ Refactor suggestion
Consider proper error handling for BLS key conversion
The current implementation uses
expectwhich could cause runtime panics. While the conversion between BLS libraries might be considered safe, it's generally better to handle potential errors gracefully.Consider propagating the error instead:
- public_key: dpp::bls_signatures::PublicKey::try_from( - quorum.public_key.to_bytes().as_slice(), - ) - .expect("expected to convert between BLS key libraries (from chia)"), + public_key: dpp::bls_signatures::PublicKey::try_from( + quorum.public_key.to_bytes().as_slice(), + ) + .map_err(|e| format!("Failed to convert BLS key from chia: {}", e))?,Committable suggestion skipped: line range outside the PR's diff.
packages/rs-dpp/src/identity/random.rs (1)
69-70: 💡 Codebase verification
Breaking change detected - requires updates to test files
The change from
Vec<u8>to[u8; 32]is a breaking change that affects multiple test files. Found several impacted locations that need to be updated:
packages/strategy-tests/src/lib.rspackages/strategy-tests/src/transitions.rspackages/rs-drive-abci/tests/strategy_tests/voting_tests.rspackages/rs-drive-abci/tests/strategy_tests/strategy.rspackages/rs-drive-abci/tests/strategy_tests/main.rspackages/rs-dpp/src/state_transition/serialization.rsAll these files are currently using
Vec<_>as the generic type parameter, which won't work with the new[u8; 32]constraint.🔗 Analysis chain
Approve type constraint change for improved type safety.
The change from
Vec<u8>to[u8; 32]for private keys is a good improvement as it:
- Enforces exact key length at compile-time
- Provides better memory efficiency with stack allocation
- Prevents potential buffer overflow attacks
Let's verify the impact of this breaking change:
Let's verify the actual implementation to understand if this is a breaking change.
Let's try a different approach to check the implementation:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any existing implementations or usages that might be affected rg "random_identity_with_main_keys_with_private_key|random_identities_with_private_keys_with_rng" --type rustLength of output: 3723
Script:
#!/bin/bash # Check the implementation of these methods to understand if Vec<u8> is still supported ast-grep --pattern 'fn random_identity_with_main_keys_with_private_key<I>($$$)'Length of output: 81
Script:
#!/bin/bash # Check the content of the files containing these methods rg -A 10 "fn random_identity_with_main_keys_with_private_key" --type rustLength of output: 1771
packages/rs-sdk/src/core/transaction.rs (1)
72-78: 💡 Codebase verification
Based on the search results, I can see that tracing is extensively used throughout the codebase, particularly for error handling, debugging, and monitoring. The file under review is part of the transaction handling module where tracing is used consistently with different log levels (error, debug, trace) to provide observability.
Keep the tracing spans but consider adjusting log levels
The tracing spans in this code provide valuable transaction context for debugging. Instead of removing them completely:
- Keep the transaction ID span as it's crucial for correlation
- Consider changing
debug!totrace!level if the goal is to reduce noise- Maintain consistency with the rest of the codebase which uses structured logging
Example locations showing similar patterns:
rs-sdk/src/core/transaction.rs: Uses tracing for error handlingrs-drive-abci/src/execution/: Uses spans for transaction tracingrs-dapi-client/src/dapi_client.rs: Uses trace spans for request tracking🔗 Analysis chain
Consider keeping structured logging for production debugging
While removing debug spans reduces noise during testing, completely removing transaction ID tracing might impact our ability to debug production issues. Consider:
- Keeping error-level tracing for critical paths
- Making tracing conditional using feature flags
- Using log levels appropriately (error, warn, info) instead of removing all tracing
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if other files in the codebase still use tracing rg "tracing::(debug|error|warn|info|trace)" --type rustLength of output: 37123
packages/rs-drive-abci/src/execution/platform_events/core_chain_lock/verify_chain_lock_locally/v0/mod.rs (1)
171-176: 🛠️ Refactor suggestion
Extract duplicate signature verification logic
The signature verification logic is duplicated. Consider extracting it into a helper function to improve maintainability and ensure consistent error handling.
fn verify_signature( signature: &Signature<Bls12381G2Impl>, public_key: &PublicKey<Bls12381G2Impl>, message_digest: &[u8], ) -> bool { match signature.verify(public_key, message_digest) { Ok(_) => true, Err(e) => { tracing::debug!("Signature verification failed: {}", e); false } } }packages/rs-drive-abci/tests/strategy_tests/masternodes.rs (1)
212-220: 🛠️ Refactor suggestion
Improve error handling in private key generation
The current implementation uses
unwrap()which could panic if the key generation or conversion fails. Consider propagating errors using the?operator and handling them appropriately.Here's a suggested improvement:
- let private_key_operator_bytes = bls_signatures::PrivateKey::generate_dash(rng) - .expect("expected to generate a private key") - .to_bytes() - .to_vec(); - let private_key_operator = BlsPrivateKey::<Bls12381G2Impl>::from_be_bytes( - &private_key_operator_bytes.try_into().unwrap(), - ) - .unwrap(); + let private_key_operator_bytes = bls_signatures::PrivateKey::generate_dash(rng) + .map_err(|e| format!("Failed to generate private key: {}", e))? + .to_bytes() + .to_vec(); + let private_key_operator = BlsPrivateKey::<Bls12381G2Impl>::from_be_bytes( + &private_key_operator_bytes.try_into() + .map_err(|_| "Invalid private key length")? + ) + .map_err(|e| format!("Failed to create BLS private key: {}", e))?;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.let private_key_operator_bytes = bls_signatures::PrivateKey::generate_dash(rng) .map_err(|e| format!("Failed to generate private key: {}", e))? .to_bytes() .to_vec(); let private_key_operator = BlsPrivateKey::<Bls12381G2Impl>::from_be_bytes( &private_key_operator_bytes.try_into() .map_err(|_| "Invalid private key length")? ) .map_err(|e| format!("Failed to create BLS private key: {}", e))?; let pub_key_operator = private_key_operator.public_key().0.to_compressed().to_vec();packages/rs-dpp/src/identity/identity_public_key/random.rs (1)
141-141: 💡 Codebase verification
Based on the search results, I can now make a final determination. The results show:
- Multiple test files and implementations explicitly use
Vec<_>when calling these methods- The private keys are primarily used via
as_slice()for signing operations- The change affects both the core rs-dpp package and its dependents (wasm-dpp, rs-drive-abci)
Breaking change needs to be reverted or handled with version compatibility
The change from
Vec<u8>to[u8; 32]is causing compatibility issues as evidenced by:
Multiple callers explicitly specify
Vec<_>in their type parametersSeveral packages in the ecosystem depend on the
Vec<u8>interfaceExisting code uses
as_slice()for signing operations, which works withVec<u8>
packages/rs-dpp/src/identity/identity_public_key/random.rs: Revert the return type change or implement version-based compatibility
packages/rs-drive-abci/tests/strategy_tests/*: Update test files to handle the new type or maintain backward compatibility
packages/wasm-dpp/src/**/*: Multiple files need updates to handle fixed-size arraysThe change should either:
- Keep
Vec<u8>for backward compatibility- Implement a version-based approach where new versions use
[u8; 32]- Add conversion methods to maintain compatibility with existing code
🔗 Analysis chain
Breaking change: Private key return type modified from Vec to [u8; 32]
The change from
Vec<u8>to[u8; 32]for private keys improves type safety by enforcing a fixed length of 32 bytes, which aligns with common cryptographic standards. However, this is a breaking change that requires careful consideration.Consider:
- Adding a version migration strategy
- Documenting this breaking change in CHANGELOG.md
- Updating all dependent code to handle fixed-size arrays
Also applies to: 179-179, 275-275, 321-321, 349-349, 387-387, 414-414, 445-445, 492-492, 521-521, 561-561, 590-590, 632-632, 659-659, 706-706, 723-723
Let me analyze the results and generate additional verification scripts to better understand the impact.
The first search shows multiple files using
Vec<u8>for private keys, particularly in the wasm-dpp package. I want to verify how these keys are being used and if there are any direct dependencies on the vector nature of the private keys before making a final determination.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any direct usages of these methods that might be affected by the return type change # Search for direct method calls that might need updates rg -l "random_.*_key.*_with.*private_key" --type rust # Search for any stored private keys to ensure they're compatible with 32 bytes rg "private_key: Vec<u8>" --type rustLength of output: 2115
Script:
#!/bin/bash # Check if there are any direct usages of the return value from these random key generation methods rg -A 3 "random_.*_key.*_with.*private_key" --type rust # Check if there are any type conversions or transformations of private keys rg "private_key\.(?:to_vec|into|as_slice)" --type rust # Look for any test files that might be affected rg "test.*random_.*_key" --type rustLength of output: 15493
packages/rs-drive-abci/tests/strategy_tests/main.rs (1)
6-6: 💡 Codebase verification
Inconsistent usage of SecretKey vs PrivateKey found in the codebase
The verification reveals inconsistent usage of the BLS key terminology across the codebase:
- Several files still use
BlsPrivateKeytype alias forSecretKey- Some files directly use
SecretKeywithout the alias- JavaScript files in dashmate still use
privateKeyterminologyKey files needing alignment:
packages/rs-drive-abci/tests/strategy_tests/masternodes.rspackages/rs-drive-abci/tests/strategy_tests/masternode_list_item_helpers.rspackages/rs-drive-abci/src/mimic/test_quorum.rspackages/dashmate/src/core/getBLSPublicKeyFromPrivateKeyHex.js🔗 Analysis chain
LGTM! Verify the SecretKey usage across tests.
The import change from
PrivateKeytoSecretKeyis consistent with modern cryptographic terminology and aligns with the broader updates across the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all BLS-related code consistently uses SecretKey instead of PrivateKey # Test: Search for any remaining PrivateKey usages that might need updating rg -A 3 "PrivateKey.*Bls" # Test: Confirm SecretKey is used consistently rg -A 3 "SecretKey.*Bls"Length of output: 14745
packages/rs-drive-abci/src/platform_types/platform_state/v0/old_structures/mod.rs (1)
12-18:
⚠️ Potential issueUse
TryFrominstead ofFromfor fallible conversions to properly handle errorsCurrently, the implementations of the
Fromtrait forValidatorSet,ValidatorSetV0, andValidatorV0useunwrap()on functions that can fail (PublicKey::try_from), which can cause panics if the conversion fails. Since these conversions can fail, it's appropriate to implement theTryFromtrait instead, allowing for proper error handling without panicking.Here's how you might adjust the code:
- Implement the
TryFromtrait for these types.- Adjust function signatures to return
Result<..., ...>types.- Handle errors appropriately in the conversion logic.
Example for
ValidatorSetV0:use std::convert::TryFrom; use dpp::core_types::validator_set::v0::ValidatorSetV0 as DppValidatorSetV0; use dpp::bls_signatures::PublicKey as DppPublicKey; use bls_signatures::PublicKey as BlsPublicKey; impl TryFrom<ValidatorSetV0> for DppValidatorSetV0 { type Error = SomeErrorType; // Define an appropriate error type fn try_from(value: ValidatorSetV0) -> Result<Self, Self::Error> { let ValidatorSetV0 { quorum_hash, quorum_index, core_height, members, threshold_public_key, } = value; let dpp_members = members .into_iter() .map(|(pro_tx_hash, validator)| { Ok((pro_tx_hash, validator.try_into()?)) }) .collect::<Result<_, _>>()?; let dpp_threshold_public_key = DppPublicKey::try_from(threshold_public_key.to_bytes().as_slice()) .map_err(|e| /* map or return the error appropriately */)?; Ok(Self { quorum_hash, quorum_index, core_height, members: dpp_members, threshold_public_key: dpp_threshold_public_key, }) } }Similarly, update the implementations for
ValidatorSetandValidatorV0to useTryFromand handle errors appropriately.Also applies to: 36-57, 80-103
packages/simple-signer/src/signer.rs (1)
85-93: 🛠️ Refactor suggestion
Use specific error types for BLS key operations
In the BLS signing logic, consider replacing
ProtocolError::Genericwith the more specificProtocolError::BlsError. This will improve error clarity and make it easier to handle BLS-related issues.Apply the following changes to enhance error handling:
- .ok_or(ProtocolError::Generic( - "bls private key from bytes isn't correct".to_string(), - ))?; + .ok_or(ProtocolError::BlsError( + "Invalid BLS private key bytes: failed to construct SecretKey".to_string(), + ))?; ... - .map_err(|e| ProtocolError::Generic(format!("unable to sign {}", e)))?; + .map_err(|e| ProtocolError::BlsError(format!("Unable to sign data: {}", e)))?;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.let pk = bls_signatures::SecretKey::<Bls12381G2Impl>::from_be_bytes(private_key) .into_option() .ok_or(ProtocolError::BlsError( "Invalid BLS private key bytes: failed to construct SecretKey".to_string(), ))?; let signature = pk .sign(SignatureSchemes::Basic, data) .map_err(|e| ProtocolError::BlsError(format!("Unable to sign data: {}", e)))?; Ok(signature.as_raw_value().to_compressed().to_vec().into())packages/rs-dpp/src/signing.rs (1)
66-67:
⚠️ Potential issueAvoid panics by handling errors from
from_compressedUsing
expectonfrom_compressedcan cause a panic if the signature bytes are invalid. To ensure robustness, handle the error gracefully and return an appropriate validation result.Apply this diff to handle the potential error:
-let g2 = <Bls12381G2Impl as Pairing>::Signature::from_compressed(&signature_bytes) - .expect("G2 projective"); +let g2 = match <Bls12381G2Impl as Pairing>::Signature::from_compressed(&signature_bytes) { + Ok(g2) => g2, + Err(e) => { + return SimpleConsensusValidationResult::new_with_error( + SignatureError::BasicBLSError(BasicBLSError::new(e.to_string())).into(), + ); + } +};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.let g2 = match <Bls12381G2Impl as Pairing>::Signature::from_compressed(&signature_bytes) { Ok(g2) => g2, Err(e) => { return SimpleConsensusValidationResult::new_with_error( SignatureError::BasicBLSError(BasicBLSError::new(e.to_string())).into(), ); } };packages/rs-drive-abci/src/platform_types/signature_verification_quorum_set/v0/quorums.rs (2)
159-159:
⚠️ Potential issueUse
Debugformatting ifDisplayis not implemented forpublic_keyThe method
to_string()requiresThresholdBlsPublicKey<Bls12381G2Impl>to implement theDisplaytrait. IfDisplayis not implemented, this will result in a compilation error. Consider usingDebugformatting instead:- .field("public_key", &self.public_key.to_string()) + .field("public_key", &format!("{:?}", self.public_key))Alternatively, implement the
Displaytrait forThresholdBlsPublicKey<Bls12381G2Impl>if a custom string representation is needed.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements..field("public_key", &format!("{:?}", self.public_key))
210-216: 🛠️ Refactor suggestion
Simplify error handling when deserializing the private key
The current error handling can be made more concise and idiomatic. Since
from_be_bytesreturns anOption<SecretKey<Bls12381G2Impl>>, you can useok_or_elseto provide the error:let private_key = bls_signatures::SecretKey::<Bls12381G2Impl>::from_be_bytes(&self.private_key) - .into_option() - .ok_or(Error::BLSError( - dpp::bls_signatures::BlsError::DeserializationError( - "Could not deserialize private key".to_string(), - ), - ))?; + .ok_or_else(|| Error::BLSError( + dpp::bls_signatures::BlsError::DeserializationError( + "Could not deserialize private key".to_string(), + ), + ))?;This refactoring makes the code more readable and follows Rust's error handling best practices.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.let private_key = bls_signatures::SecretKey::<Bls12381G2Impl>::from_be_bytes(&self.private_key) .ok_or_else(|| Error::BLSError( dpp::bls_signatures::BlsError::DeserializationError( "Could not deserialize private key".to_string(), ), ))?;packages/rs-drive-abci/src/platform_types/commit/v0/mod.rs (1)
127-131:
⚠️ Potential issueAvoid including raw signatures in error messages to prevent potential leakage of sensitive data.
Including the raw signature in error messages may expose sensitive information. Consider removing the signature from the error message or replacing it with a hash or an identifier.
Apply this diff to modify the error message:
Err(_) => ValidationResult::new_with_error(AbciError::BadCommitSignature(format!( - "commit signature {} is wrong", - signature + "commit signature is invalid" ))),📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.match signature.verify(&public_key, &hash) { Ok(_) => ValidationResult::default(), Err(_) => ValidationResult::new_with_error(AbciError::BadCommitSignature(format!( "commit signature is invalid"packages/rs-sdk/src/core/dash_core_client.rs (2)
47-53: 🛠️ Refactor suggestion
Optimize the Fibonacci function to prevent stack overflow and improve efficiency
The recursive implementation of the Fibonacci function can cause stack overflows and is inefficient, even with a small
MAX_RETRIES. Consider replacing it with an iterative implementation to enhance performance and reliability.Apply this diff to refactor the function:
fn fibonacci(n: u32) -> u64 { - match n { - 0 => 0, - 1 => 1, - _ => fibonacci(n - 1) + fibonacci(n - 2), - } + let mut a = 0; + let mut b = 1; + for _ in 0..n { + let temp = a; + a = b; + b = temp + b; + } + a }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.fn fibonacci(n: u32) -> u64 { let mut a = 0; let mut b = 1; for _ in 0..n { let temp = a; a = b; b = temp + b; } a }
90-90: 🛠️ Refactor suggestion
Avoid using
expectto prevent potential panicsUsing
final_result.expect("expected a final result")might cause a panic iffinal_resultremainsNone. Although the logic suggests this shouldn't happen, it's safer to handle this case explicitly.You can modify the code to return an error instead of panicking:
- final_result.expect("expected a final result") + match final_result { + Some(result) => result, + None => Err(ContextProviderError::Generic("Failed to retrieve result after retries".to_string())), + }Committable suggestion skipped: line range outside the PR's diff.
packages/rs-drive-abci/src/mimic/test_quorum.rs (2)
283-283: 🛠️ Refactor suggestion
Encapsulate
public_keyaccess when settingquorum_public_keySimilar to the previous comment, avoid accessing the internal
.0field. Use the public interface provided byBlsPublicKey.Apply this diff:
- quorum_public_key: public_key.0.to_compressed().to_vec(), + quorum_public_key: public_key.to_compressed().to_vec(),This ensures encapsulation and reduces the risk of future breakages.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.quorum_public_key: public_key.to_compressed().to_vec(),
272-272: 🛠️ Refactor suggestion
Avoid direct access to internal fields of
public_keyAccessing the internal field
.0ofpublic_keybreaks encapsulation and may lead to maintenance issues if the internal structure changes. Use a public method to obtain the compressed representation.Apply this diff to encapsulate access:
- pub_key_share: Some(public_key.0.to_compressed().to_vec()), + pub_key_share: Some(public_key.to_compressed().to_vec()),Ensure that the
to_compressed()method is publicly accessible on theBlsPublicKeytype.Committable suggestion skipped: line range outside the PR's diff.
… test/testWithoutSpan
| @@ -131,6 +131,8 @@ impl<C> Platform<C> { | |||
| &self.config.drive, | |||
| )); | |||
|
|
|||
| println!("{:?}", drive_query); | |||
| @@ -4662,6 +4662,8 @@ fn test_dpns_query_start_after_with_null_id() { | |||
| ) | |||
| .expect("query should be built"); | |||
|
|
|||
| println!("{:?}", query); | |||
Issue being fixed or feature implemented
What was done?
How Has This Been Tested?
Breaking Changes
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit
New Features
BlsErrorvariant for enhanced error handling related to BLS signatures.Improvements
Bug Fixes
Documentation