Skip to main content

RLN-STEALTH-COMMITMENTS

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 and related rights waived via CC0.

References​