-
Notifications
You must be signed in to change notification settings - Fork 8
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
WIP: New implementations and tests for Zerokit v0.1 #34
Conversation
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.
💯
Looking at the code, a random idea i had that wanted to ask you about is:
What do you think of extracting in a patch file or separate branch these changes?:
- in poseidon_tree.rs:
//pub type PoseidonTree = FullMerkleTree<PoseidonHash>;
//pub type MerkleProof = FullMerkleProof<PoseidonHash>;
- the functions defined in
rln/src/utils.rs
.
That way the source code would not contain commented code, and someone wanting to use either the FullMerkleTree, or the conversion utils could either cherry pick the commit from the branch, or apply the git patch (assuming this operation is documented somewhere)
@richard-ramos seems a bit too much effort on the user side. I think we can reach a good compromise already using rust features and enable one Merkle tree implementation or the other by just checking which feature is active for the crate. What do you think? |
Sounds good! I did not know about rust features! |
@richard-ramos I integrated poseidon hash implementation so that works directly with arkworks (and we avoid some heavy dependencies just for conversion to poseidon-rs field type) and added compilation time features to switch to FullMerkleTree implementation and to hide performance proof generation/verification logs when running in release mode. |
Allows passing the wasm, zkey and verification key data as buffers, instead of using a path to a folder
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 is not a release PR, it is doing a lot of things at once. These should be separate PRs. The release PR should be minimal and only about adding release notes etc.
See e.g. how this is done in nwaku: https://github.com/status-im/nwaku/pull/1075/files
I'm also not convinced that we should decrease the capability this library has as part of the first release.
Probably the title is unfortunate (and the description can be a bit more talkative), but the goal was to target the items of the milestone issue #31. Then we had some blockers I mentioned you with the merge, and to not stop completely development on zerokit (after the switch to the arkworks field arithmetic, it would have been impossible to continue working to a new branch based on master without solving lots of conflicts) we just continued working on this branch. However, besides the change in the field arithmetic, the main other aspect covered by this PR is minimizing usage of dependencies, which was added to the milestone issue description as well. I agree that a release PR should be structured differently (but for this we might simply adjust description). If better, commits might be cherry-picked to different PRs instead. I also agree that we should try to not decrease capacity of the library: I internally shared some possibilities on how we can possibly address this. |
@@ -1,35 +0,0 @@ | |||
[package] |
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 is a useful example for onboarding and understanding roughly how things fit together. I don't think it makes sense to remove this package.
We could move it to an example directory.
@@ -1,15 +0,0 @@ | |||
# Poseidon-Tornado wrapper |
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.
We want this soon, but I agree it is in a so-so state and better to base based on RLN from scratch at this point.
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.
Removed in 1d8a5f5
cc @staheri14 if you want to see what this code is doing
@@ -3,76 +3,39 @@ name = "rln" | |||
version = "0.1.0" | |||
edition = "2021" | |||
|
|||
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html |
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.
Do these stylistic/refactor change in a separate PR
use ark_circom::{read_zkey, CircomBuilder, CircomConfig, WitnessCalculator}; | ||
use ark_ff::BigInteger256; | ||
use ark_bn254::{ | ||
Bn254, Fq as ArkFq, Fq2 as ArkFq2, Fr as ArkFr, G1Affine as ArkG1Affine, |
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 a change in functionality or so, belongs in a separate PR targeting an issue. Not in a release PR...
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.
Addressed by #43
@@ -35,239 +32,6 @@ pub trait Hasher { | |||
fn hash(input: &[Self::Fr]) -> Self::Fr; | |||
} | |||
|
|||
//////////////////////////////////////////////////////////// |
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 shouldn't be removed, it is a regression
|
||
// The implementation is taken from https://github.com/arnaucube/poseidon-rs/blob/233027d6075a637c29ad84a8a44f5653b81f0410/src/lib.rs | ||
// and slightly adapted to work over arkworks field data type | ||
|
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 seems like another feature ??
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.
Addressed by #44
@@ -1,49 +0,0 @@ | |||
[package] |
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 is still useful, we aren't unlikely to want to use this in the feature. There are no problems to keep it in the code base as WIP, and when it gets prioritized to update it.
Yeah I think better to close this PR and start from scratch with feature PRs and refactor PRs and then a minimal release note PR. This is just a monster right now with many separate intentions. |
@@ -3,76 +3,39 @@ name = "rln" | |||
version = "0.1.0" |
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.
@richard-ramos @staheri14 of the changes in the rln
crate, which of these are must haves from your POV? Both for normal integration (e.g. bugs found in nwaku and go-waku) as well as for the experimental wasm support?
Trying to figure out which things should be part of initial v0.1 release and which are OK to deal with later.
Changes in this PR were/will be merged by smaller sub-PRs. |
Targets #31