feat: Use bytes API for underlying precompile library APIs#2705
feat: Use bytes API for underlying precompile library APIs#2705rakita merged 24 commits intobluealloy:mainfrom
Conversation
CodSpeed Performance ReportMerging #2705 will not alter performanceComparing Summary
|
|
Pulled out of #2675 |
| let mut scalars = Vec::with_capacity(k); | ||
| let mut point_scalar_pairs: Vec<(G1Point, [u8; SCALAR_LENGTH])> = Vec::with_capacity(k); | ||
|
|
||
| for i in 0..k { |
There was a problem hiding this comment.
Would remove this for loop, the only thing that we do here is removal of the padding and adding creating new vec. And inside crypto provider you would again create an additional vec to transform the fields.
We can transmute it and send it padded and leave crypto provider to do it in the loop:
let points = unsafe {
mem::transmute::<&[u8], &[([u8; PADDED_G1_LENGTH], [u8; SCALAR_LENGTH])]>(&input)
};There was a problem hiding this comment.
I had initially done this to have a create a clean abstraction since the padding is an EVM specific operation and the cryptography modules don't have any context about the EVM -- If we can't avoid the extra allocation, I can use a transmute and remove padding in the cryptography module. Perhaps we could use an iterator?
There was a problem hiding this comment.
Removed the initial allocation here 7d3e169 -- what do you think?
There was a problem hiding this comment.
Have also rebased this ontop of #2706 to show what it looks like with CryptoProvider
There was a problem hiding this comment.
Iterators are lazy so it makes sense that allocation is skipped here, it looks great. Would need to check just to be sure, but can do that later.
Co-authored-by: rakita <rakita@users.noreply.github.com>
Co-authored-by: rakita <rakita@users.noreply.github.com>
Co-authored-by: rakita <rakita@users.noreply.github.com>
| /// Verify KZG proof. | ||
| #[inline] | ||
| pub fn verify_kzg_proof(commitment: &Bytes48, z: &Bytes32, y: &Bytes32, proof: &Bytes48) -> bool { | ||
| pub fn verify_kzg_proof( |
There was a problem hiding this comment.
Removes the library specific types from the public API
kevaundray
changed the title
2 participants
Motivation
Using revm inside of a zkVM involves patching certain cryptographic libraries using patch-crates.io -- this is quite brittle because one needs to ensure that the versions match up and long term we would like these to be patched using extern C.
One could implement extern C methods under a feature flag, however the more general strategy would be to have a pluggable architecture like alloy-rs/alloy#2634 -- This PR is a precursor to adding the pluggable architecture since the functions that are being plugged in shouldn't rely on the types of a particular library.