4.1 KiB
| title | name | category | editor | contributors | sidebar_position | |
|---|---|---|---|---|---|---|
| RLN-STEALTH-COMMITMENTS | RLN Stealth Commitment Usage | Standards Track | Aaryamann Challani <aaryamann@status.im> |
|
1 |
- Category: Standards Track
- Editor: Aaryamann Challani <aaryamann@status.im>
- Contributors::
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:
- Applications can add users to the 32/RLN-V1 membership set in a batch.
- 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.