AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-08 15:23:58 -05:00
Code Issues Packages Projects Releases Wiki Activity

Fix Files for Linting (#94)

Browse Source
This commit is contained in:
Jimmy Debe
2024-09-13 10:51:09 -04:00
committed by GitHub
parent 0b4d151638
commit 3ab314d87d
77 changed files with 6814 additions and 3371 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
vac/raw/rln-stealth-commitments.md
View File

@@ -9,42 +9,57 @@ contributors:
## Abstract
This specification describes the usage of stealth commitments to add prospective users to a network-governed [32/RLN-V1](./32/rln-v1.md) membership set.
This specification describes the usage of stealth commitments
to add prospective users to a network-governed
[32/RLN-V1](./32/rln-v1.md) membership set.
## Motivation
When [32/RLN-V1](./32/rln-v1.md) is enforced in [10/Waku2](../waku/standards/core/10/waku2.md),
When [32/RLN-V1](./32/rln-v1.md) is enforced in [10/Waku2](../waku/standards/core/10/waku2.md),
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,
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,
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](./32/rln-v1.md) 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.
allowing a counterparty to utilize [32/RLN-V1](./32/rln-v1.md)
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](./32/rln-v1.md) protocol,
consists of a smart contract that stores a `idenitityCommitment` in a membership set.
The [32/RLN-V1](./32/rln-v1.md) 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](https://eips.ethereum.org/EIPS/eip-5564).
This specification is an implementation of the [ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) scheme,
This specification is an implementation of the
[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) scheme,
tailored to the curve that is used in the [32/RLN-V1](./32/rln-v1.md) protocol.
This can be used in a couple of ways in applications:
1. Applications can add users to the [32/RLN-V1](./32/rln-v1.md) membership set in a batch.
2. Users of the application can register other users to the [32/RLN-V1](./32/rln-v1.md) membership set.
This is useful when the prospective user does not have access to funds on the network that [32/RLN-V1](./32/rln-v1.md) is deployed on.
1. Applications can add users
to the [32/RLN-V1](./32/rln-v1.md) membership set in a batch.
2. Users of the application
can register other users to the [32/RLN-V1](./32/rln-v1.md) membership set.
This is useful when the prospective user does not have access to funds
on the network that [32/RLN-V1](./32/rln-v1.md) is deployed on.
## Wire Format Specification
The two parties, the requester and the receiver, MUST exchange the following information:
The two parties, the requester and the receiver,
MUST exchange the following information:
```protobuf
@@ -55,14 +70,16 @@ message Request {
// 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.
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:
Once the membership set is updated,
the receiver SHOULD exchange the following as a response to the request:
```protobuf
@@ -81,18 +98,22 @@ message Response {
```
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,
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](https://github.com/rymnc/erc-5564-bn254) repository,
An implementation of the Stealth Address scheme is available in the
[erc-5564-bn254](https://github.com/rymnc/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](https://eips.ethereum.org/EIPS/eip-5564) scheme.
This specification inherits the security and privacy considerations of the
[Stealth Address](https://eips.ethereum.org/EIPS/eip-5564) scheme.
## Copyright