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

define holder/keeper distinction

Browse Source
This commit is contained in:
Sergei Tikhomirov 2024-08-19 11:47:57 +02:00
parent 9caa26c1e1
commit ecdd7b3ed6
No known key found for this signature in database
GPG Key ID: 6A1F8ED9D6538027
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -44,6 +44,11 @@ The contract MUST provide the following functionalities:
- extend a membership;
- withdraw a deposit.
A membership _holder_ is the entity that controls the secret of the respective RLN commitment.
A membership _keeper_ is the entity that controls the Ethereum address that registered that membership.
The holder and the keeper MAY differ for the same membership.
The contract SHOULD only distinguish between the keeper and non-keepers when authorizing membership-related requests.
Contract parameters and their RECOMMENDED values for the initial mainnet deployment are as follows:
| Parameter | Symbol | Value | Units |
@ -126,7 +131,7 @@ Membership registration is subject to the following conditions:
- if a new membership A overwrites an _Expired_ membership B:
- membership B MUST become _ErasedAwaitsWithdrawal_;
- the current total rate limit MUST be decremented by the rate limit of membership B;
- the contract MUST take all necessary steps to ensure that the holder of membership B can withdraw their deposit later;
- the contract MUST take all necessary steps to ensure that the keeper of membership B can withdraw their deposit later;
- registration MUST fail if the total rate limit of _Active_, _GracePeriod_, and _Expired_ memberships, including the one being created, would exceed the maximum total rate;
- registration MUST fail if the requested rate limit for a new membership is lower than the minimal allowed rate limit;
- the user MUST lock-up a deposit to register a membership;
@ -143,17 +148,17 @@ Membership registration is subject to the following conditions:
Extending a membership is subject to the following conditions:
- extension MUST fail if the membership is in any state other than _GracePeriod_;
- the membership holder MUST be able to extend their membership;
- any user except the membership holder MUST NOT be able to extend a membership;
- the membership keeper MUST be able to extend their membership;
- any user except the membership keeper MUST NOT be able to extend a membership;
- after a successful extension, the membership MUST become _Active_.
Holding a membership means controlling the private key from which the RLN commitment ID (i.e., public key) was derived.
### Withdraw the deposit
Deposit withdrawal is subject to the following conditions:
- the membership holder MUST be able to withdraw their deposit;
- any user except the membership holder MUST NOT be able to withdraw its deposit;
- the membership keeper MUST be able to withdraw their deposit;
- any user except the membership keeper MUST NOT be able to withdraw its deposit;
- a deposit MUST be withdrawn in full;
- a withdrawal MUST fail if the membership is not in _GracePeriod_, _Expired_, or _ErasedAwaitsWithdrawal_;
- a membership MUST become _Erased_ after withdrawal.
@ -233,7 +238,7 @@ On the one hand, longer epochs allow for better accommodating short-term usage p
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 RLN Relay node must keep in memory a nullifier log for the current epoch.
Each RLN Relay node must store in memory a nullifier log for the current epoch.
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.
This corresponds to: