AtHeartEngineer/rfc-index
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc-index.git synced 2026-01-07 23:04:09 -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

692
vac/raw/decentralized-messaging-ethereum.md
View File

File diff suppressed because it is too large Load Diff

110
vac/raw/gossipsub-tor-push.md
View File

@@ -18,21 +18,31 @@ Tor Push adds sender identity protection to gossipsub.
**Protocol identifier**: /meshsub/1.1.0
Note: Gossipsub Tor Push does not have a dedicated protocol identifier.
It uses the same identifier as gossipsub and works with all [pubsub](https://github.com/libp2p/specs/tree/master/pubsub) based protocols.
This allows nodes that are oblivious to Tor Push to process messages received via Tor Push.
It uses the same identifier as gossipsub and
works with all [pubsub](https://github.com/libp2p/specs/tree/master/pubsub)
based protocols.
This allows nodes that are oblivious to Tor Push to process messages received via
Tor Push.
## Background
Without extensions, [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
does not protect sender identities.
A possible design of an anonymity extension to gossipsub is pushing messages through an anonymization network before they enter the gossipsub network.
A possible design of an anonymity extension to gossipsub
is pushing messages through an anonymization network
before they enter the gossipsub network.
[Tor](https://www.torproject.org/) is currently the largest anonymization network.
It is well researched and works reliably.
Basing our solution on Tor both inherits existing security research, as well as allows for a quick deployment.
Basing our solution on Tor both inherits existing security research,
as well as allows for a quick deployment.
Using the anonymization network approach, even the first gossipsub node that relays a given message cannot link the message to its sender (within a relatively strong adversarial model).
Taking the low bandwidth overhead and the low latency overhead into consideration, Tor offers very good anonymity properties.
Using the anonymization network approach,
even the first gossipsub node that relays a given message
cannot link the message to its sender
(within a relatively strong adversarial model).
Taking the low bandwidth overhead and the low latency overhead into consideration,
Tor offers very good anonymity properties.
## Functional Operation
@@ -44,17 +54,20 @@ because Tor Push uses the same Protocol ID as gossipsub.
Messages are sent over Tor via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928).
Tor Push uses a dedicated libp2p context to prevent information leakage.
To significantly increase resilience and mitigate circuit failures,
Tor Push establishes several connections, each to a different randomly selected gossipsub node.
Tor Push establishes several connections,
each to a different randomly selected gossipsub node.
## Specification
This section specifies the format of Tor Push messages, as well as how Tor Push messages are received and sent, respectively.
This section specifies the format of Tor Push messages,
as well as how Tor Push messages are received and sent, respectively.
### Wire Format
The wire format of a Tor Push message corresponds verbatim to a typical [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message).
The wire format of a Tor Push message corresponds verbatim to a typical
[libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message).
```
```protobuf
message Message {
optional string from = 1;
optional bytes data = 2;
@@ -67,12 +80,15 @@ message Message {
### Receiving Tor Push Messages
Any node supporting a protocol with ID `/meshsub/1.1.0` (e.g. gossipsub), can receive Tor Push messages.
Receiving nodes are oblivious to Tor Push and will process incoming messages according to the respective `meshsub/1.1.0` specification.
Any node supporting a protocol with ID `/meshsub/1.1.0` (e.g. gossipsub),
can receive Tor Push messages.
Receiving nodes are oblivious to Tor Push and
will process incoming messages according to the respective `meshsub/1.1.0` specification.
### Sending Tor Push Messages
In the following, we refer to nodes sending Tor Push messages as Tp-nodes (Tor Push nodes).
In the following, we refer to nodes sending Tor Push messages as Tp-nodes
(Tor Push nodes).
Tp-nodes MUST setup a separate libp2p context, i.e. [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch/),
which MUST NOT be used for any purpose other than Tor Push.
@@ -81,29 +97,38 @@ The Tp-context MUST NOT share any data, e.g. peer lists, with the default contex
Tp-peers are peers a Tp-node plans to send Tp-messages to.
Tp-peers MUST support `/meshsub/1.1.0`.
For retrieving Tp-peers, Tp-nodes SHOULD use an ambient peer discovery method that retrieves a random peer sample (from the set of all peers), e.g. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md).
For retrieving Tp-peers,
Tp-nodes SHOULD use an ambient peer discovery method
that retrieves a random peer sample (from the set of all peers),
e.g. [33/WAKU2-DISCV5](../../waku/standards/core/33/discv5.md).
Tp-nodes MUST establish a connection as described in sub-section [Tor Push Connection Establishment](#connection-establishment) to at least one Tp-peer.
To significantly increase resilience, Tp-nodes SHOULD establish Tp-connections to `D` peers,
Tp-nodes MUST establish a connection as described in sub-section
[Tor Push Connection Establishment](#connection-establishment) to at least one Tp-peer.
To significantly increase resilience,
Tp-nodes SHOULD establish Tp-connections to `D` peers,
where `D` is the [desired gossipsub out-degree](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#parameters),
with a default value of `8`.
Each Tp-message MUST be sent via the Tp-context over at least one Tp-connection.
To increase resilience, Tp-messages SHOULD be sent via the Tp-context over all available Tp-connections.
To increase resilience,
Tp-messages SHOULD be sent via the Tp-context over all available Tp-connections.
Control messages of any kind, e.g. gossipsub graft, MUST NOT be sent via Tor Push.
#### Connection Establishment
Tp-nodes establish a `/meshsub/1.1.0` connection to tp-peers via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928) over [Tor](https://www.torproject.org/).
Tp-nodes establish a `/meshsub/1.1.0` connection to tp-peers via
[SOCKS5](https://www.rfc-editor.org/rfc/rfc1928) over [Tor](https://www.torproject.org/).
Establishing connections, which in turn establishes the respective Tor circuits, can be done ahead of time.
Establishing connections, which in turn establishes the respective Tor circuits,
can be done ahead of time.
#### Epochs
Tor Push introduces epochs.
The default epoch duration is 10 minutes.
(We might adjust this default value based on experiments and evaluation in future versions of this document.
(We might adjust this default value based on experiments and
evaluation in future versions of this document.
It seems a good trade-off between traceablity and circuit building overhead.)
For each epoch, the Tp-context SHOULD be refreshed, which includes
@@ -112,7 +137,9 @@ For each epoch, the Tp-context SHOULD be refreshed, which includes
* Tp-peer list
* connections to Tp-peers
Both Tp-peer selection for the next epoch and establishing connections to the newly selected peers SHOULD be done during the current epoch
Both Tp-peer selection for the next epoch and
establishing connections to the newly selected peers
SHOULD be done during the current epoch
and be completed before the new epoch starts.
This avoids adding latency to message transmission.
@@ -120,42 +147,54 @@ This avoids adding latency to message transmission.
### Fingerprinting Attacks
Protocols that feature distinct patterns are prone to fingerprinting attacks when using them over Tor Push.
Protocols that feature distinct patterns are prone to fingerprinting attacks
when using them over Tor Push.
Both malicious guards and exit nodes could detect these patterns
and link the sender and receiver, respectively, to transmitted traffic.
As a mitigation, such protocols can introduce dummy messages and/or padding to hide patterns.
As a mitigation, such protocols can introduce dummy messages and/or
padding to hide patterns.
### DoS
#### General DoS against Tor
Using untargeted DoS to prevent Tor Push messages from entering the gossipsub network would cost vast resources,
because Tor Push transmits messages over several circuits and the Tor network is well established.
Using untargeted DoS to prevent Tor Push messages
from entering the gossipsub network would cost vast resources,
because Tor Push transmits messages over several circuits and
the Tor network is well established.
#### Targeting the Guard
Denying the service of a specific guard node blocks Tp-nodes using the respective guard.
Denying the service of a specific guard node
blocks Tp-nodes using the respective guard.
Tor guard selection will replace this guard [TODO elaborate].
Still, messages might be delayed during this window which might be critical to certain applications.
Still, messages might be delayed during this window
which might be critical to certain applications.
#### Targeting the Gossipsub Network
Without sophisticated rate limiting (for example using [17/WAKU2-RLN-RELAY](../../waku/standards/core/17/rln-relay.md)),
attackers can spam the gossipsub network.
It is not enough to just block peers that send too many messages,
because these messages might actually come from a Tor exit node that many honest Tp-nodes use.
Without Tor Push, protocols on top of gossipsub could block peers if they exceed a certain message rate.
because these messages might actually come from a Tor exit node
that many honest Tp-nodes use.
Without Tor Push,
protocols on top of gossipsub could block peers
if they exceed a certain message rate.
With Tor Push, this would allow the reputation-based DoS attack described in
[Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022).
#### Peer Discovery
The discovery mechanism could be abused to link requesting nodes to their Tor connections to discovered nodes.
The discovery mechanism could be abused to link requesting nodes
to their Tor connections to discovered nodes.
An attacker that controls both the node that responds to a discovery query,
and the node who’s ENR the response contains,
can link the requester to a Tor connection that is expected to be opened to the node represented by the returned ENR soon after.
can link the requester to a Tor connection
that is expected to be opened to the node represented by the returned ENR soon after.
Further, the discovery mechanism (e.g. discv5) could be abused to distribute disproportionately many malicious nodes.
Further, the discovery mechanism (e.g. discv5)
could be abused to distribute disproportionately many malicious nodes.
For instance if p% of the nodes in the network are malicious,
an attacker could manipulate the discovery to return malicious nodes with 2p% probability.
The discovery mechanism needs to be resilient against this attack.
@@ -163,8 +202,11 @@ The discovery mechanism needs to be resilient against this attack.
### Roll-out Phase
During the roll-out phase of Tor Push, during which only a few nodes use Tor Push,
attackers can narrow down the senders of Tor messages to the set of gossipsub nodes that do not originate messages.
Nodes who want anonymity guarantees even during the roll-out phase can use separate network interfaces for their default context and Tp-context, respectively.
attackers can narrow down the senders of Tor messages
to the set of gossipsub nodes that do not originate messages.
Nodes who want anonymity guarantees even during the roll-out phase
can use separate network interfaces for their default context and
Tp-context, respectively.
For the best protection, these contexts should run on separate physical machines.
## Copyright

78
vac/raw/rln-interep-spec.md
View File

@@ -10,54 +10,76 @@ contributors:
## Abstract
This spec integrates [Interep](https://interep.link) into the [RLN](../32/rln-v1.md) spec.
Interep is a group management protocol that allows for the creation of groups of users and the management of their membership.
This spec integrates [Interep](https://interep.link)
into the [RLN](../32/rln-v1.md) spec.
Interep is a group management protocol
that allows for the creation of groups of users and
the management of their membership.
It is used to manage the membership of the RLN group.
Interep ties in web2 identities with reputation, and sorts the users into groups based on their reputation score.
Interep ties in web2 identities with reputation, and
sorts the users into groups based on their reputation score.
For example, a GitHub user with over 100 followers is considered to have "gold" reputation.
Interep uses [Semaphore](https://semaphore.appliedzkp.org/) under the hood to allow anonymous signaling of membership in a group.
Therefore, a user with a "gold" reputation can prove the existence of their membership without revealing their identity.
Interep uses [Semaphore](https://semaphore.appliedzkp.org/)
under the hood to allow anonymous signaling of membership in a group.
Therefore, a user with a "gold" reputation can prove the existence
of their membership without revealing their identity.
RLN is used for spam prevention, and Interep is used for group management.
By using Interep with RLN, we allow users to join RLN membership groups without the need for on-chain financial stake.
By using Interep with RLN,
we allow users to join RLN membership groups
without the need for on-chain financial stake.
## Motivation
To have Sybil-Resistant group management, there are [implementations](https://github.com/vacp2p/rln-contract) of RLN which make use of financial stake on-chain.
To have Sybil-Resistant group management,
there are [implementations](https://github.com/vacp2p/rln-contract)
of RLN which make use of financial stake on-chain.
However, this is not ideal because it reduces the barrier of entry for honest participants.
In this case, honest participants will most likely have a web2 identity accessible to them, which can be used for joining an Interep reputation group.
By modifying the RLN spec to use Interep, we can have Sybil-Resistant group management without the need for on-chain financial stake.
In this case,
honest participants will most likely have a web2 identity accessible to them,
which can be used for joining an Interep reputation group.
By modifying the RLN spec to use Interep,
we can have Sybil-Resistant group management
without the need for on-chain financial stake.
Since RLN and Interep both use Semaphore-style credentials, it is possible to use the same set of credentials for both.
Since RLN and Interep both use Semaphore-style credentials,
it is possible to use the same set of credentials for both.
## Functional Operation
Using Interep with RLN involves the following steps -
1. Generate Semaphore credentials
1. Generate Semaphore credentials
2. Verify reputation and join Interep group
3. Join RLN membership group via interaction with Smart Contract, by passing a proof of membership to the Interep group
3. Join RLN membership group via interaction with Smart Contract,
by passing a proof of membership to the Interep group
### 1. Generate Semaphore credentials
Semaphore credentials are generated in a standard way, depicted in the [Semaphore documentation](https://semaphore.appliedzkp.org/docs/guides/identities#create-deterministic-identities).
Semaphore credentials are generated in a standard way,
depicted in the [Semaphore documentation](https://semaphore.appliedzkp.org/docs/guides/identities#create-deterministic-identities).
### 2. Verify reputation and join Interep group
Using the Interep app deployed on [Goerli](https://goerli.interep.link/), the user can check their reputation tier and join the corresponding group.
Using the Interep app deployed on [Goerli](https://goerli.interep.link/),
the user can check their reputation tier and join the corresponding group.
This results in a transaction to the Interep contract, which adds them to the group.
### 3. Join RLN membership group
Instead of sending funds to the RLN contract to join the membership group, the user can send a proof of membership to the Interep group.
This proof is generated by the user, and is verified by the contract.
The contract ensures that the user is a member of the Interep group, and then adds them to the RLN membership group.
Instead of sending funds to the RLN contract to join the membership group,
the user can send a proof of membership to the Interep group.
This proof is generated by the user, and
is verified by the contract.
The contract ensures that the user is a member of the Interep group, and
then adds them to the RLN membership group.
Following is the modified signature of the register function in the RLN contract -
Following is the modified signature of the register function
in the RLN contract -
```solidity
/// @param groupId: Id of the group.
@@ -83,19 +105,29 @@ Messages are verified the same way as in the [RLN spec](../32/rln-v1.md/#verific
## Slashing
The slashing mechanism is the same as in the [RLN spec](../32/rln-v1.md/#slashing).
It is important to note that the slashing may not have the intended effect on the user, since the only consequence is that they cannot send messages.
This is due to the fact that the user can send a identity commitment in the registration to the RLN contract, which is different than the one used in the Interep group.
It is important to note that the slashing
may not have the intended effect on the user,
since the only consequence is that they cannot send messages.
This is due to the fact that the user
can send a identity commitment in the registration to the RLN contract,
which is different than the one used in the Interep group.
## Proof of Concept
A proof of concept is available at [vacp2p/rln-interp-contract](https://github.com/vacp2p/rln-interep-contract) which integrates Interep with RLN.
A proof of concept is available at
[vacp2p/rln-interp-contract](https://github.com/vacp2p/rln-interep-contract)
which integrates Interep with RLN.
## Security Considerations
1. As mentioned in [Slashing](#slashing), the slashing mechanism may not have the intended effect on the user.
1. As mentioned in [Slashing](#slashing),
the slashing mechanism may not have the intended effect on the user.
2. This spec inherits the security considerations of the [RLN spec](../32/rln-v1.md/#security-considerations).
3. This spec inherits the security considerations of [Interep](https://docs.interep.link/).
4. A user may make multiple registrations using the same Interep proofs but different identity commitments. The way to mitigate this is to check if the nullifier hash has been detected previously in proof verification.
4. A user may make multiple registrations using the same Interep proofs but
different identity commitments.
The way to mitigate this is to check if the nullifier hash has been detected
previously in proof verification.
## References

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

166
vac/raw/rln-v2.md
View File

@@ -9,17 +9,26 @@ contributors:
## Abstract
The protocol specified in this document is an improvement of [32/RLN-V1](../32/rln-v1.md), being more general construct, that allows to set various limits for an epoch (it's 1 message per epoch in [32/RLN-V1](../32/rln-v1.md)) while remaining almost as simple as it predecessor.
Moreover, it allows to set different rate-limits for different RLN app users based on some public data, e.g. stake or reputation.
The protocol specified in this document is an improvement of [32/RLN-V1](../32/rln-v1.md),
being more general construct, that allows to set various limits for an epoch
(it's 1 message per epoch in [32/RLN-V1](../32/rln-v1.md))
while remaining almost as simple as it predecessor.
Moreover, it allows to set different rate-limits
for different RLN app users based on some public data,
e.g. stake or reputation.
## Motivation
The main goal of this RFC is to generalize [32/RLN-V1](../32/rln-v1.md) and expand its applications.
The main goal of this RFC is to generalize [32/RLN-V1](../32/rln-v1.md) and
expand its applications.
There are two different subprotocols based on this protocol:
* RLN-Same - RLN with the same rate-limit for all users;
* RLN-Diff - RLN that allows to set different rate-limits for different users.
It is important to note that by using a large epoch limit value, users will be able to remain anonymous, because their `internal_nullifiers` will not be repeated until they exceed the limit.
It is important to note that by using a large epoch limit value,
users will be able to remain anonymous,
because their `internal_nullifiers` will not be repeated until they exceed the limit.
## Flow
@@ -29,11 +38,13 @@ As in [32/RLN-V1](../32/rln-v1.md), the general flow can be described by three s
2. Signaling
3. Verification and slashing
The two sub-protocols have different flows, and hence are defined separately.
The two sub-protocols have different flows, and
hence are defined separately.
### Important note
All terms and parameters used remain the same as in [32/RLN-V1](../32/rln-v1.md), more details [here](../32/rln-v1.md/#technical-overview)
All terms and parameters used remain the same as in [32/RLN-V1](../32/rln-v1.md),
more details [here](../32/rln-v1.md/#technical-overview)
## RLN-Same flow
@@ -41,13 +52,11 @@ All terms and parameters used remain the same as in [32/RLN-V1](../32/rln-v1.md)
The registration process in the RLN-Same subprotocol does not differ from [32/RLN-V1](../32/rln-v1.md).
### Signalling
#### Proof generation
Signalling
For proof generation, the user needs to submit the following fields to the circuit:
```
```js
{
identity_secret: identity_secret_hash,
path_elements: Merkle_proof.path_elements,
@@ -59,11 +68,11 @@ For proof generation, the user needs to submit the following fields to the circu
}
```
#### Calculating output
Calculating output
The following fields are needed for proof output calculation:
```
```js
{
identity_secret_hash: bigint,
external_nullifier: bigint,
@@ -74,7 +83,7 @@ The following fields are needed for proof output calculation:
The output `[y, internal_nullifier]` is calculated in the following way:
```
```js
a_0 = identity_secret_hash
a_1 = poseidonHash([a0, external_nullifier, message_id])
@@ -85,29 +94,36 @@ internal_nullifier = poseidonHash([a_1])
## RLN-Diff flow
### Registration
Registration
**id_commitment** in [32/RLN-V1](../32/rln-v1.md) is equal to `poseidonHash(identity_secret)`.
The goal of RLN-Diff is to set different rate-limits for different users.
It follows that **id_commitment** must somehow depend on the `user_message_limit` parameter, where 0 <= `user_message_limit` <= `message_limit`.
**id_commitment** in [32/RLN-V1](../32/rln-v1.md) is equal to `poseidonHash(identity_secret)`.
The goal of RLN-Diff is to set different rate-limits for different users.
It follows that **id_commitment** must somehow depend
on the `user_message_limit` parameter,
where 0 <= `user_message_limit` <= `message_limit`.
There are few ways to do that:
1. Sending `identity_secret_hash` = `poseidonHash(identity_secret, userMessageLimit)` and zk proof that `user_message_limit` is valid (is in the right range).
This approach requires zkSNARK verification, which is an expensive operation on the blockchain.
2. Sending the same `identity_secret_hash` as in [32/RLN-V1](../32/rln-v1.md) (`poseidonHash(identity_secret)`) and a user_message_limit publicly to a server or smart-contract where `rate_commitment` = `poseidonHash(identity_secret_hash, userMessageLimit)` is calculated.
The leaves in the membership Merkle tree would be the rate_commitments of the users.
This approach requires additional hashing in the Circuit, but it eliminates the need for zk proof verification for the registration.
Both methods are correct, and the choice of the method is left to the implementer.
1. Sending `identity_secret_hash` = `poseidonHash(identity_secret, userMessageLimit)`
and zk proof that `user_message_limit` is valid (is in the right range).
This approach requires zkSNARK verification,
which is an expensive operation on the blockchain.
2. Sending the same `identity_secret_hash` as in [32/RLN-V1](../32/rln-v1.md)
(`poseidonHash(identity_secret)`) and a user_message_limit publicly to a server
or smart-contract where
`rate_commitment` = `poseidonHash(identity_secret_hash, userMessageLimit)` is calculated.
The leaves in the membership Merkle tree would be the rate_commitments of the users.
This approach requires additional hashing in the Circuit, but
it eliminates the need for zk proof verification for the registration.
Both methods are correct, and the choice of the method is left to the implementer.
It is recommended to use second method for the reasons already described.
The following flow description will also be based on the second method.
### Signalling
#### Proof generation
Signalling
For proof generation, the user need to submit the following fields to the circuit:
```
```js
{
identity_secret: identity_secret_hash,
path_elements: Merkle_proof.path_elements,
@@ -119,76 +135,92 @@ For proof generation, the user need to submit the following fields to the circui
}
```
#### Calculating output
Calculating output
The Output is calculated in the same way as the RLN-Same sub-protocol.
### Verification and slashing
Verification and slashing in both subprotocols remain the same as in [32/RLN-V1](../32/rln-v1.md).
The only difference that may arise is the `message_limit` check in RLN-Same, since it is now a public input of the Circuit.
The only difference that may arise is the `message_limit` check in RLN-Same,
since it is now a public input of the Circuit.
### ZK Circuits specification
The design of the [32/RLN-V1](../32/rln-v1.md) circuits is different from the circuits of this protocol.
The design of the [32/RLN-V1](../32/rln-v1.md) circuits
is different from the circuits of this protocol.
RLN-v2 requires additional algebraic constraints.
The membership proof and Shamir's Secret Sharing constraints remain unchanged.
The ZK Circuit is implemented using a [Groth-16 ZK-SNARK](https://eprint.iacr.org/2016/260.pdf),
using the [circomlib](https://docs.circom.io/) library.
using the [circomlib](https://docs.circom.io/) library.
Both schemes contain compile-time constants/system parameters:
* DEPTH - depth of membership Merkle tree
* LIMIT_BIT_SIZE - bit size of `limit` numbers, e.g. for the 16 - maximum `limit` number is 65535.
The main difference of the protocol is that instead of a new polynomial (a new value `a_1`) for a new epoch, a new polynomial is generated for each message.
The user assigns an identifier to each message; the main requirement is that this identifier be in the range from 1 to `limit`.
* DEPTH - depth of membership Merkle tree
* LIMIT_BIT_SIZE - bit size of `limit` numbers,
e.g. for the 16 - maximum `limit` number is 65535.
The main difference of the protocol is that instead of a new polynomial
(a new value `a_1`) for a new epoch, a new polynomial is generated for each message.
The user assigns an identifier to each message;
the main requirement is that this identifier be in the range from 1 to `limit`.
This is proven using range constraints.
### RLN-Same circuit
#### Circuit parameters
**Public Inputs**
- `x`
- `external_nullifier`
- `message_limit` - limit per epoch
Public Inputs
**Private Inputs**
- `identity_secret_hash`
- `path_elements`
- `identity_path_index`
- `message_id`
* `x`
* `external_nullifier`
* `message_limit` - limit per epoch
**Outputs**
- `y`
- `root`
- `internal_nullifier`
Private Inputs
* `identity_secret_hash`
* `path_elements`
* `identity_path_index`
* `message_id`
Outputs
* `y`
* `root`
* `internal_nullifier`
### RLN-Diff circuit
In the RLN-Diff scheme, instead of the public parameter `message_limit`, a parameter is used that is set for each user during registration (`user_message_limit`); the `message_id` value is compared to it in the same way as it is compared to `message_limit` in the case of RLN-Same.
In the RLN-Diff scheme, instead of the public parameter `message_limit`,
a parameter is used that is set for each user during registration (`user_message_limit`);
the `message_id` value is compared to it in the same way
as it is compared to `message_limit` in the case of RLN-Same.
#### Circuit parameters
Circuit parameters
**Public Inputs**
- `x`
- `external_nullifier`
Public Inputs
**Private Inputs**
- `identity_secret_hash`
- `path_elements`
- `identity_path_index`
- `message_id`
- `user_message_limit`
* `x`
* `external_nullifier`
**Outputs**
- `y`
- `root`
- `internal_nullifier`
Private Inputs
* `identity_secret_hash`
* `path_elements`
* `identity_path_index`
* `message_id`
* `user_message_limit`
Outputs
* `y`
* `root`
* `internal_nullifier`
## Appendix A: Security considerations
Although there are changes in the circuits, this spec inherits all the security considerations of [32/RLN-V1](../32/rln-v1.md).
Although there are changes in the circuits,
this spec inherits all the security considerations of [32/RLN-V1](../32/rln-v1.md).
## Copyright
@@ -196,6 +228,6 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
## References
- [1](https://zkresear.ch/t/rate-limit-nullifier-v2-circuits/102)
- [2](https://github.com/Rate-Limiting-Nullifier/rln-circuits-v2)
- [3](../32/rln-v1.md/#technical-overview)
* [1](https://zkresear.ch/t/rate-limit-nullifier-v2-circuits/102)
* [2](https://github.com/Rate-Limiting-Nullifier/rln-circuits-v2)
* [3](../32/rln-v1.md/#technical-overview)

7
vac/raw/url-scheme.md
View File

@@ -10,7 +10,8 @@ contributors:
## Abstract
This document describes URL scheme for previewing and deep linking content as well as for triggering actions.
This document describes URL scheme for previewing and
deep linking content as well as for triggering actions.
## Background / Rationale / Motivation
@@ -53,7 +54,9 @@ A standard track RFC in `stable` status MUST feature this section.
A standard track RFC in `raw` or `draft` status SHOULD feature this section.
Informational RFCs (in any state) may feature this section.
If there are none, this section MUST explicitly state that fact.
This section MAY contain additional relevant information, e.g. an explanation as to why there are no security consideration for the respective document. -->
This section MAY contain additional relevant information,
e.g. an explanation as to why there are no security consideration
for the respective document. -->
## Discussions