Skip to content
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

Closed
wants to merge 16 commits into from

Conversation

s1fr0
Copy link
Contributor

@s1fr0 s1fr0 commented Aug 22, 2022

Targets #31

@s1fr0 s1fr0 linked an issue Aug 22, 2022 that may be closed by this pull request
10 tasks
@s1fr0 s1fr0 requested a review from richard-ramos August 24, 2022 08:42
Copy link
Member

@richard-ramos richard-ramos left a 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)

@s1fr0
Copy link
Contributor Author

s1fr0 commented Aug 24, 2022

@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?

@richard-ramos
Copy link
Member

Sounds good! I did not know about rust features!

@s1fr0
Copy link
Contributor Author

s1fr0 commented Aug 27, 2022

@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.

@s1fr0 s1fr0 added the track:zerokit Zerokit track (Applied ZK/Explorations) label Aug 29, 2022
@s1fr0 s1fr0 marked this pull request as ready for review September 11, 2022 22:15
@s1fr0 s1fr0 requested a review from oskarth September 11, 2022 22:15
Copy link
Contributor

@oskarth oskarth left a 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.

@s1fr0
Copy link
Contributor Author

s1fr0 commented Sep 13, 2022

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]
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor

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
Copy link
Contributor

@oskarth oskarth Sep 14, 2022

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,
Copy link
Contributor

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...

Copy link
Contributor Author

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;
}

////////////////////////////////////////////////////////////
Copy link
Contributor

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

Copy link
Contributor

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 ??

Copy link
Contributor Author

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]
Copy link
Contributor

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.

@oskarth
Copy link
Contributor

oskarth commented Sep 14, 2022

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"
Copy link
Contributor

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.

@s1fr0 s1fr0 changed the title Zerokit release v0.1 WIP: Implementations and tests for Zerokit v0.1 Sep 15, 2022
@s1fr0 s1fr0 changed the title WIP: Implementations and tests for Zerokit v0.1 WIP: New implementations and tests for Zerokit v0.1 Sep 15, 2022
@s1fr0
Copy link
Contributor Author

s1fr0 commented Sep 16, 2022

Changes in this PR were/will be merged by smaller sub-PRs.

@s1fr0 s1fr0 closed this Sep 16, 2022
@s1fr0 s1fr0 deleted the release-v0.1 branch October 17, 2022 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
track:zerokit Zerokit track (Applied ZK/Explorations)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Milestone: zerokit release v0.1
3 participants