# RLN-STEALTH-COMMITMENTS | Vac Research
- Category: Standards Track

Skip to main content

# RLN-STEALTH-COMMITMENTS

- Category: Standards Track
- Editor: Aaryamann Challani <p1ge0nh8er@proton.me>
- Contributors:
  - Jimmy Debe <jimmy@status.im>

## Abstract​

This specification describes the usage of stealth commitments to add prospective users to a network-governed 32/RLN-V1 membership set.

## Motivation​

When 32/RLN-V1 is enforced in 10/Waku2, all users are required to register to a membership set. The membership set will store user identities allowing the secure interaction within an application. Forcing a user to do an on-chain transaction to join a membership set is an onboarding friction, and some projects may be opposed to this method. To improve the user experience, stealth commitments can be used by a counterparty to register identities on the user's behalf, while maintaining the user's anonymity.

This document specifies a privacy-preserving mechanism, allowing a counterparty to utilize 32/RLN-V1 to register an `identityCommitment` on-chain. Counterparties will be able to register members to a RLN membership set without exposing the user's private keys.

## Background​

The 32/RLN-V1 protocol, consists of a smart contract that stores a `idenitityCommitment` in a membership set. In order for a user to join the membership set, the user is required to make a transaction on the blockchain. A set of public keys is used to compute a stealth commitment for a user, as described in ERC-5564. This specification is an implementation of the ERC-5564 scheme, tailored to the curve that is used in the 32/RLN-V1 protocol.

This can be used in a couple of ways in applications:

1. Applications can add users to the 32/RLN-V1 membership set in a batch.
2. Users of the application can register other users to the 32/RLN-V1 membership set.

This is useful when the prospective user does not have access to funds on the network that 32/RLN-V1 is deployed on.

## Wire Format Specification​

The two parties, the requester and the receiver, MUST exchange the following information:

    message Request {
      // The spending public key of the requester
      bytes spending_public_key = 1;

      // The viewing public key of the requester
      bytes viewing_public_key = 2;
    }

### Generate Stealth Commitment​

The application or user SHOULD generate a `stealth_commitment` after a request to do so is received. This commitment MAY be inserted into the corresponding application membership set.

Once the membership set is updated, the receiver SHOULD exchange the following as a response to the request:

    message Response {

      // The used to check if the stealth_commitment belongs to the requester
      bytes view_tag = 2;

      // The stealth commitment for the requester
      bytes stealth_commitment = 3;

      // The ephemeral public key used to generate the commitment
      bytes ephemeral_public_key = 4;

    }

The receiver MUST generate an `ephemeral_public_key`, `view_tag` and `stealth_commitment`. This will be used to check the stealth commitment used to register to the membership set, and the user MUST be able to check ownership with their `viewing_public_key`.

## Implementation Suggestions​

An implementation of the Stealth Address scheme is available in the erc-5564-bn254 repository, which also includes a test to generate a stealth commitment for a given user.

## Security/Privacy Considerations​

This specification inherits the security and privacy considerations of the Stealth Address scheme.

## Copyright​

Copyright and related rights waived via CC0.

## References​

- 10/Waku2
- 32/RLN-V1
- ERC-5564