Add uncompressed public key recover #2003
Conversation
|
Docker tags |
| .map_err(WasmRuntimeError::InvalidSecp256k1Signature)?; | ||
|
|
||
| self.api | ||
| .consume_cost_units(ClientCostingEntry::Secp256k1EcdsaKeyRecover)?; |
There was a problem hiding this comment.
Is this Secp256k1EcdsaKeyRecover variant used here deliberately?
I guess the costs for uncompressed variant are similar, so this probably makes sense.
There was a problem hiding this comment.
I noticed this too. The uncompressed version should be cheaper, but didn't bother changing it for now.
| pub fn verify_and_recover_secp256k1_uncompressed( | ||
| signed_hash: &Hash, | ||
| signature: &Secp256k1Signature, | ||
| ) -> Option<[u8; secp256k1::constants::UNCOMPRESSED_PUBLIC_KEY_SIZE]> { |
There was a problem hiding this comment.
Is it worth us adding an explicit new type for this, e.g. ExpandedSecp256k1PublicKey - which we can use here and in scrypto? (And can be a semantic transparent wrapper around a pub [u8; 65])
There was a problem hiding this comment.
And maybe adding to the Rust doc for Secp256k1PublicKey that it's the compressed public key, which is the default format used in the Radix stack?
There was a problem hiding this comment.
I will add the wrapper.
|
|
||
| runtime | ||
| .crypto_utils_secp256k1_ecdsa_verify_and_key_recover_uncompressed(message, signature) | ||
| .map(|buffer| buffer.0) |
There was a problem hiding this comment.
what does this method do? returns u64 and not a public key? why do we call buffer.0? should we not return the full buffer and update the return type to be Result<[u8: 64], _>? (or 65, depending on representation)
There was a problem hiding this comment.
We can not pass the array raw to wasm as a function return, and have to wrap it into a buffer (which will be read by wasm later).
The wasmi linker requires a u32/u64 return type, so we had to unwrap the Buffer.
There was a problem hiding this comment.
This is the Engine side of the Engine <=> WASM boundary. It effectively returns a pointer to the buffer in WASM's memory space
There was a problem hiding this comment.
so the caller of this function reads out the 65 bytes how? via mut caller? I lack the WASM knowledge to understand this :D but just looked wrong. I assume it is some WASM vodoo magic making this work...
There was a problem hiding this comment.
wrote simultaneously... thx makes sense
iamyulong
force-pushed
the
feature/uncompressed-public-key
branch
from
7570a13 to
fdb2ad3
Compare
Benchmark for e438eecClick to view benchmark
|
No description provided.