Zerokit/RLN Command Line API

[oskarth]

Problem

As a dapp developer I'm required to know and deal with a lot of different runtimes/domains (JS/Circom/Solidity/Rust/ZK etc). Minimizing cognitive overhead would be useful.

Context

Also see https://github.com/vacp2p/zerokit/issues/69

As well as https://book.getfoundry.sh/forge/tests for Foundry forge tool. Might make sense to "bundle" foundry or similar based scripts for interacting with smart contracts.

Acceptance criteria

• [ ] Proposal of MVP CLI API that allows for interacting with RLN - e.g. create groups, adding members, etc. -- separate out must have for MVP and nice to have future work

[oskarth]

cc @s1fr0 @richard-ramos

[s1fr0]

Did I understand correctly that in practice this issue is asking to develop a binary that signals by attaching RLN proofs, after successfully registering a credential to a membership smart contract or after restoring a pre-registered credential (let's skip slashing for now since this involves group dynamics)? In other words, some sort of local chat2 RLN without chat and without waku?

[oskarth]

The issue is asking for what is in the acceptance criteria:

Proposal of MVP CLI API that allows for interacting with RLN - e.g. create groups, adding members, etc.

[oskarth]

Another example is geth https://geth.ethereum.org/docs/interface/command-line-options - people don't write go code to use geth and interact with Ethereum

[staheri14]

Since it was also mentioned in our today call re RLN-Relay refactoring, I'd like to share my read of this issue (according to my conversation with @oskarth) to get to a shared understanding:

We shall develop a CLI that supports the major and recurring RLN functionality e.g., keyGen, Proof, and Verify, as well as Merkle tree-related services like CreateGroup, AddMember, or DeleteMeber. The Merkle tree part is completely offline with no on-chain interaction.

However, the following part is not clear yet:

Might make sense to "bundle" foundry or similar-based scripts for interacting with smart contracts.

• I understand that adding support for smart contract interaction is optional "Might make sense ", so it is not a hard requirement for the acceptance criteria of this issue, right?

• Zerokit RLN module does not have already any support for smart contract interaction, so adding a CLI for that in fact, implies two steps: 1- Integrating smart contract interaction inside zerokit 2- Providing a CLI for the smart contract interaction So is this the path we MAY want to follow? Also, please keep in mind that the smart contract interaction is originally being managed in nwaku i.e., a higher-level protocol that utilizes the RLN zerokit module. (shifting this to the RLN zerokit can also impact how we are thinking about the development of RLNP2P)

[oskarth]

Might make sense to "bundle" foundry or similar-based scripts for interacting with smart contracts.

Yes it isn't a hard requirement for initial MVP, but it should probably be part of consideration for next iteration of CLI.

As a developer to make good use of RLN probably requires the use of smart contracts, deploying etc. It seems like this can be provided for by leveraging existing tools

For example, here's how RLN has a script that makes it easier to build circuits using other tools like snarkjs https://github.com/Rate-Limiting-Nullifier/rln_circuits/blob/master/scripts/build-circuits.sh This is then wrapped in package.json like so https://github.com/Rate-Limiting-Nullifier/rln_circuits/blob/master/package.json#L6

Here's another example of making it easy to interact with RLN contracts by using scripts https://github.com/Rate-Limiting-Nullifier/consensus-layer-rln-registration/blob/main/package.json#L9-L23

Something similar could be done be done with Foundry, but whatever already works (existing flow) is a good start too.

The advantage of Foundry is that it makes it easier to have an integrated development experience. This means for people working on e.g. RLN, or any other ZK construct, they can focus on Solidity (e.g. not having to do testing/tooling with JS) + Circom and that might be it. As opposed to currently having to write JS and also Rust.

This also makes the toolchain less complex, since you don't need to install all these npx etc Javascript tooling just to run basic scripts that we call from Zerokit CLI (e.g.), so dependencies/binary is kept more clean. In general, moving from e.g. Hardhat to Foundry should be fairly straightforward from what I've heard. That said, this might be more of a "next step" though, and might belong in a different issue, but it is related so mentioning it here.

smart contract interaction is originally being managed in nwaku

My understanding of stock RLN is that there's (usually) a need for a smart contract regardless, but I agree the MVP CLI proposal would have to look into exact differences a bit more in detail.

---

Taking a step back, all of these questions can basically be answered by asking ourselves the following set of questions:

1. As a developer who wants to use Zerokit RLN to make something useful, what would be the ideal CLI interface? What requires the least amount of effort for this developer as a user?

2. After that, you look at what are the current steps involved. If I want to make, say, a decentralized captcha, what commands do I have to run? What software do I have to install? What knowledge do I need?

3. Then you basically take that ideal usage and current usage, and find the biggest bang for buck, i.e. what is the 80/20 to iteratively work towards the ideal usage.

It isn't much more complicated than that, and understanding this is more important than any details for how I (e.g.) currently see this evolving. It applies to any kind of developer tooling that we might be building.

[tyshko-rostyslav]

As of what we have now, I suggest the following

Proposal for MVP CLI API:

• Creating an RLN instance: The API should allow to create a new instance of the RLN by specifying the tree height and resources directory path, where ZK circuit, proving key and the verification key would be situated.
• Creating an RLN instance using binary data: The API should allow to create a new instance of the RLN by specifying the tree height and paths to binary files of ZK circuit, proving key and the verification key.
• Initialising the internal Merkle tree: The API should allow to initialise the internal tree with default values.
• Setting a leaf on the Merkle tree: The API should allow to set a leaf value at position index in the internal Merkle tree by specifying the path to the file where the serialised value of the leaf should be situated.
• Setting multiple leaves on the Merkle tree: The API should allow to set multiple leaves starting from position index in the internal Merkle tree by specifying the index of the first leaf to be set and the path to the file where the serialised values of the leaves should be situated.
• Resetting the Merkle tree with multiple values: The API should allow to reset the tree state to default and sets multiple leaves starting from index 0 by specifying the path to the file where the serialised values of the leaves should be situated.
• Setting the next leaf: The API should allow to set a leaf value at the next available never-set leaf index by specifying the path to the file where the serialised value of the leaf should be situated.
• Deleting the feaf: The API should allow to delete the value at a specified index.
• Getting the root to a file: The API should allow to get the root of the Merkle tree to the file, the path to which should be able to be specified.
• Returning a proof at an index: The API should allow to return the Merkle proof of the leaf at position index.
• Proving RLN proof: The API should allow to compute zkSNARK RLN proof by specifying the paths to input and output data files.
• Verifying RLN proof: The API should allow to verify zkSNARK RLN proof by specifying the path to input data file.
• Generating RLN proof: The API should allow to generate RLN proof from the identity secret, the Merkle tree index, the epoch and signal by specifying the paths to input and output data files.
• Verifying with roots: The API should allow to verify a zkSNARK RLN proof against the provided proof values and a set of allowed Merkle tree roots by specifying paths to a file with the serialization of the RLN zkSNARK proof concatenated with a serialization of the circuit output values and the signal information, and a file for the serialization of a vector of roots.

The MVP CLI API should be implemented using a well-documented and maintained library, most probably clap. The API should also provide clear and concise documentation, including usage examples and code samples.

As this is an MVP, we should focus on delivering the basic functionality first and consider adding more advanced features in future versions.

[rymnc]

Yes! this sounds good to me @tyshko-rostyslav, thanks for that. Please note that there may be some duplicated work with https://github.com/Rate-Limiting-Nullifier/rln-cli

We can do 2 things -

• develop the zerokit cli as you mentioned
• develop the rlnp2p cli later, which has specific on-chain interactions etc. wdyt?

[tyshko-rostyslav]

I've taken a look at rln-cli repo, and actually didn't see a lot of duplicated work.

[rahulghangas]

@rymnc if the mvp proposal makes sense, maybe we should close this issue in favour of #155 #156 #157 and #158

[rymnc]

I would prefer if this serves as a larger tracking issue, but if it makes things easier, please feel free to close it :)

[rymnc]

We can close this issue since the MVP is done! cc: @rahulghangas