-
Notifications
You must be signed in to change notification settings - Fork 122
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
Add BLS signatures #1661
Add BLS signatures #1661
Conversation
1de4826
to
b0dc5e1
Compare
Benchmark for ce7c01fClick to view benchmark
|
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.
Looks good overall.
@@ -379,10 +379,15 @@ create_well_known_lookup!( | |||
MISC_TYPES_START + 7, |
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.
Chang well-known types is a protocol change. Will need to be synchronised with a specific protocol update.
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.
AFAIK, well-known types change is not necessary, so theoretically we could skip it. But since we require the protocol update anyway I would leave it as is.
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.
Ready to go. The missing part is to handle protocol updates, which should follow.
Hashes, keys, signing, verification moved to 'radix-engine-common'. In 'transaction' above primitives are wrapped with RE specifics such as: - IntentSignature, - NotarySignature - etc.
ATM it is not required in WASM in Scrypto. Partial support (BLS verification, Keccak hash) is implemented natively via Client API.
This is to make sure public key count matches message count. Take vector of tuples (public key and message) as argument.
Do not take aggregation into account. Just sum up the costs per size for all messages.
It does not work for WASM and no_std
Add BLS aggregation features to `CryptoUtils` module
b1bf2a6
to
cea6713
Compare
…-crypto-utils Feature: Add protocol update for crypto utils
HASH, | ||
MISC_TYPES_START + 8, | ||
named_transparent("Hash", bytes_fixed_length_type_data(Hash::LENGTH),) | ||
), |
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.
Can we remove this? As this is still a protocol change
Summary
This PR adds support for:
It also implements
CryptoUtils
module for Client API, which allows to do some crypto-related stuff natively from Scrypto.CryptoUtils
functions:keccak_hash()
- generate Keccak-256 hash of the given messagebls_verify()
- do the given BLS signature verification of the given message hash using given public keyDetails
BLS details:
In order to get it working I had to move cryptographic primitives (PrivateKey, Signature definitions) from
transaction
toradix-engine-common
. What is left intransaction
are the Radix Engine cryptographics, eg.IntentSignatureV1
,NotarySignatureV1
.Cryptographic dependencies in
radix-engine-common
are not built for WASM.Reasons:
blst
) or their deps (eg.secp256k1-sys
) are not implemented in Rust. Andclang
used in macOS GH runner does not support WASM target. For now we skip it (maybe eventually we would need the WASM support there anyway)TODO: Costing
Testing
CryptoUtils
module usingCryptoScrypto
test blueprint