Modify RLN Circuit: Signature as Inputs Instead of Private Key

Waku
,
1

Problem

The current RLN circuit written in circom generates a zero-knowledege proof proving (among other things) that the pre-image of a hash is a leaf of a merkle tree represented by root r.

In other words. The user pases its secret s, which is hashed hash(s) and then using the merkle proof it proves that hash(s) + merkle proof leads to a given root. A classic proof of inclusion in a merkle tree.

However, having the secret s as an input to the circuit is not ideal. That puts a liability on waku’s side, since that secret has to be taken care of. And well, a user would prefer to not reveal that information, even if the node is self hosted.

Since the user just has to prove that it knows the secret, there are better ways of doing that without revealing the secret itself. A common way is to use signatures.

Same as ethereum transactions. They are signed by the sender and the signature is verified by the node, but the node never learns about the user’s private key (secret).

Proposal

We would like to propose to modify the RLN circuit, so that instead of having the secret as an input, a signature is used. With this approach a waku node nor prover needs to know the secret anymore.

This would also allow native integration with Metamask, removing one of waku’s friction with having to bootstrap a new identity management mechanism. A waku RLN key can be handled just as any other key by Metamask. And used to sign transactions/messages.

On a high level:

  • Modify the circuit. Signature instead of secret.
  • Verify the signature in circom.
  • Benchmark the solution to see the delta.
  • Provide an integration example with metamask.
  • Use some mechanisim to prevent replay attacks (same signature being reused).

Note that the essence of RLN won’t change. The circuit will be very similar, still written in circom, and the proving system (groth 16) will be kept.

2 Likes
2

Yes, this is a change worthy considering. It was originally drafted here: RLN: Signatures instead of raw private key · Issue #113 · waku-org/research · GitHub

I think Alvaro did produce a ~PS1~ SP1 PoC for this ~but I can’t seem to find it~, I found it: Waku and ZK · Issue #112 · waku-org/research · GitHub.

I would welcome the change, but I don’t see it super high in the priority list as an engineering work around is simply to use a signature hash as the secret to remediate with the down side you listed.

edit: it’s SP1, not PS1

3

Ok I just realized that it’s all the same person :slight_smile: definitely good to have this idea enshrined in the forum.

4

Thanks for the reply. Note that this suggestion differs from the SP1 approach (which can trivially verify signatures), as that involved deep changes in RLN (new proving system). SP1 uses a zkVM which is general purpose and allows to prove rust (or LLVM) code but i) proving times + mem consumption will be significantly larger, most likely too much for waku and ii) to 100% guarantee privacy in SP1, you would need another proof (snark). Both i) and ii) make SP1 unusable if the goal is that waku users generate their own proof (eg on mobile).

The suggested approach still uses the existing RLN circom circuit and doesn’t change the prooving system (groth16). It’s not rocket science but verifying a signature can be a bit tricky.

1 Like