logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-08 17:13:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

minor edits

Browse Source
This commit is contained in:
Sergei Tikhomirov 2024-08-14 17:37:47 +02:00
parent 9eab39c88a
commit 3cac3f0459
No known key found for this signature in database
GPG Key ID: 6A1F8ED9D6538027
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
standards/core/rln-contract.md
View File

@ -20,6 +20,10 @@ It might later evolve into a full-fledged contract specification.
RLN is only deployed on Sepolia testnet ([source code](https://github.com/waku-org/waku-rlnv2-contract/blob/main/src/WakuRlnV2.sol)) as of August 2024. RLN is only deployed on Sepolia testnet ([source code](https://github.com/waku-org/waku-rlnv2-contract/blob/main/src/WakuRlnV2.sol)) as of August 2024.
This document aims to outline the path to its mainnet deployment. This document aims to outline the path to its mainnet deployment.
## Syntax
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
## Background ## Background
Rate-Limiting Nullifier (RLN) is a ZK-based gadget used for privacy-preserving rate limiting in Waku. Rate-Limiting Nullifier (RLN) is a ZK-based gadget used for privacy-preserving rate limiting in Waku.
@ -28,14 +32,10 @@ The smart contract stores the RLN tree that contains all currently existing memb
Users interact with the contract to manage their memberships Users interact with the contract to manage their memberships
and to get the necessary data for proof generation and verification. and to get the necessary data for proof generation and verification.
Sending messages is handled by Waku Relay nodes. Sending messages is handled by Waku RLN Relay nodes.
To send a message, the sender MUST attach a ZK-proof to the message. To send a message, the sender MUST prove its validity in terms of RLN.
A Relay node MUST relay a message unless: An RLN Relay node MUST relay a message unless it is invalid.
- the message belongs to any epoch other than the current one; or See [17/WAKU2-RLN-RELAY](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/17/rln-relay.md) for the full specification of RLN Relay.
- the user has exceed their allowed rate limit for the current epoch; or
- the ZK-proof fails to prove that the sender holds a membership.
The full specification of Relay is out of scope for this document.
## Contract overview ## Contract overview
@ -113,7 +113,7 @@ Availability of membership-specific functionalities MUST be as follows:
| Withdraw the deposit | No | Yes | Yes | Yes | No | | Withdraw the deposit | No | Yes | Yes | Yes | No |
Sending a message is included here for completeness, Sending a message is included here for completeness,
although it is part of the Relay protocol and not the RLN contract. although it is part of the RLN Relay protocol and not the RLN contract.
### Register a membership ### Register a membership
@ -210,8 +210,8 @@ and would either extend their memberships or withdraw their deposits.
### Can I send messages when my membership is _Expired_? ### Can I send messages when my membership is _Expired_?
An _Expired_ membership allows sending messages for some time. An _Expired_ membership allows sending messages for some time.
Sending messages is managed by Relay nodes. Sending messages is managed by RLN Relay nodes.
The RLN proof that message senders provide to Relay nodes doesn't prove the state of that membership. The RLN proof that message senders provide to RLN Relay nodes doesn't prove the state of that membership.
_Expired_ memberships are not erased from the tree proactively. _Expired_ memberships are not erased from the tree proactively.
An _Expired_ membership is only erased when either a new membership overwrites it, An _Expired_ membership is only erased when either a new membership overwrites it,
@ -236,10 +236,10 @@ There is a trade-off between short and long epochs.
We chose an epoch length of `10` minutes as a reasonable middle-ground. We chose an epoch length of `10` minutes as a reasonable middle-ground.
On the one hand, longer epochs allow for better accommodating short-term usage peaks. On the one hand, longer epochs allow for better accommodating short-term usage peaks.
On the other hand, long epochs increases memory requirements for Relay nodes. On the other hand, long epochs increases memory requirements for RLN Relay nodes.
Each message contains a nullifier that proves its validity in terms of RLN. Each message contains a nullifier that proves its validity in terms of RLN.
Each Relay node must keep in memory a nullifier log for the current epoch. Each RLN Relay node must keep in memory a nullifier log for the current epoch.
Each nullifier plus metadata is `128` bytes (per message). Each nullifier plus metadata is `128` bytes (per message).
With a `10`-minute epoch, one high-tier user with a `1` message per second rate limit generates up to `600 * 128 / 1024 = 75 KiB` of nullifier log data per epoch. With a `10`-minute epoch, one high-tier user with a `1` message per second rate limit generates up to `600 * 128 / 1024 = 75 KiB` of nullifier log data per epoch.
This corresponds to: This corresponds to: