-
Notifications
You must be signed in to change notification settings - Fork 106
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
Redjubjub signature verifier service #460
Conversation
Codecov Report
@@ Coverage Diff @@
## main #460 +/- ##
==========================================
+ Coverage 57.95% 58.25% +0.30%
==========================================
Files 91 92 +1
Lines 4419 4470 +51
==========================================
+ Hits 2561 2604 +43
- Misses 1858 1866 +8 |
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.
🔥
I will be closing this PR and moving the updated batch verifier (to work with the new |
@dconnolly The batch verification implementation makes sense to have in the upstream redjubjub crate, but I think that the async tower-based interface to it is probably better here — my experience with ed25519-zebra was that it was much easier to maintain just the synchronous, IUF-style API in the library crate. Also, I don’t think we would be able to publish a version of redjubjub that depended on tower-batch, since got dependencies are not allowed in published crates. |
Good point, I'll keep this open and update it with the |
6bd45de
to
88121d4
Compare
I don't know why this worked fine when used similarly in here but removing it allowed all tests to pass. |
okay, that's a bug. Removing the init will disable our logging and error handling stuff, so we want that to work. I'll open a separate issue to add them back and fix the bug though |
Looks like there's a panic in one of the functions that's called during the Do we have any other copies of the old tracing code in the codebase? |
zebra-consensus/Cargo.toml
Outdated
futures-util = "0.3.5" | ||
tower = "0.3.1" | ||
rand = "0.7" | ||
redjubjub = { git = "https://github.com/ZcashFoundation/redjubjub.git", branch = "batch" } |
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.
I'd prefer to wait to merge this until we can depend on a published version of redjubjub
, but that can happen essentially as soon as it's ready.
zebra-consensus/src/verify.rs
Outdated
mod script; | ||
mod transaction; | ||
|
||
pub use self::redjubjub::{RedJubjubItem, RedJubjubVerifier}; |
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.
naming: if the types are called just Item
and Verifier
, this reëxport can be dropped and users can choose how much they want to qualify the name, depending on their context, either redjubjub::Item
and redjubjub::Verifier
or Item
and Verifier
. I think this is more flexible than including RedJubjub
in the struct names.
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.
(There's then a potential naming overlap between the redjubjub
crate's Verifier
type and this one, but this is only ambiguous when code needs to refer to both synchronous and asynchronous batch verification APIs, which only happens in this specific module, otherwise people just use one or the other).
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.
I think this would still be good to do. More rationale: rust-lang/rfcs#356
👍 Nice work! The only comments I have are about naming. I guess the API might change slightly when the (sync) batch code is updated to cover both signature types. |
zebra-consensus/Cargo.toml
Outdated
chrono = "0.4.11" | ||
color-eyre = "0.5" |
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.
This should probably be a dev-dependency
let sig = sk.sign(rng, &msg[..]); | ||
|
||
verifier.ready_and().await?; | ||
results.push(span.in_scope(|| verifier.call((vk.into(), sig, msg).into()))) |
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.
I don't think this in_scope
does what is intended, this would enter span
for the duration of call, which then returns a future, but then it would push an uninstrumented future into the results
. If you want the span
to be active while the future is being polled you should use instrument
results.push(span.in_scope(|| verifier.call((vk.into(), sig, msg).into()))) | |
results.push(verifier.call((vk.into(), sig, msg).into()).instrument(span)) |
Ugh I messed up with my rebases. |
b641d63
to
4346c2e
Compare
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.
I think we should change the names to remove the module prefix but otherwise this looks great!
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.
Awesome!!
Using updated redjubjub::batch::Verifier in the redjubjub#batch branch.
Now the Verifier is agnostic of redjubjub SigTypes. Updated tests to generate sigs of both types and batch verifies the whole batch. Resolves #407
Bumps [chrono](https://github.com/chronotope/chrono) from 0.4.11 to 0.4.12. - [Release notes](https://github.com/chronotope/chrono/releases) - [Changelog](https://github.com/chronotope/chrono/blob/master/CHANGELOG.md) - [Commits](chronotope/chrono@v0.4.11...v0.4.12) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Using updated redjubjub::batch::Verifier in the redjubjub#batch branch.
To follow this convention RFC: rust-lang/rfcs#356
429e89c
to
1c40af5
Compare
And stub of
redjubjub::BatchVerifier
.