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

minor edits

Browse Source
This commit is contained in:
Sergei Tikhomirov 2025-05-14 12:09:06 +02:00
parent 63c2fb7106
commit 8c2eb13a3c
No known key found for this signature in database
GPG Key ID: 6A1F8ED9D6538027
1 changed files with 4 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -52,7 +52,7 @@ see [32/RLN-V1](https://github.com/vacp2p/rfc-index/blob/main/vac/32/rln-v1.md).
Membership registration MAY be initiated by a different entity from the one that controls the RLN `identity_secret`, Membership registration MAY be initiated by a different entity from the one that controls the RLN `identity_secret`,
which is associated with the respective RLN `identity_commitment`. which is associated with the respective RLN `identity_commitment`.
Therefore, the holder MAY be assigned to an blockchain address that does not control the `identity_secret`. Therefore, the holder role MAY be assigned to a blockchain address that does not control the `identity_secret`.
The contract SHOULD verify that the `identity_commitment` is valid. The contract SHOULD verify that the `identity_commitment` is valid.
When authorizing membership-related requests, When authorizing membership-related requests,
the contract MUST distinguish between the holder and non-holders, the contract MUST distinguish between the holder and non-holders,
@ -136,7 +136,7 @@ Memberships MUST be included in the membership set according to the following ta
| _ErasedAwaitsWithdrawal_ | No | | _ErasedAwaitsWithdrawal_ | No |
| _Erased_ | No | | _Erased_ | No |
The holder assigned blockchian address MUST NOT be transferable to a different blockchain address. The holder role MUST NOT be transferable to a different blockchain address.
A user MAY use one blockchain address to manage multiple memberships. A user MAY use one blockchain address to manage multiple memberships.
A user MAY use one Waku node[^1] to manage multiple memberships. A user MAY use one Waku node[^1] to manage multiple memberships.
@ -163,8 +163,7 @@ because the inclusion (Merkle) proof that the holder provides to RLN Relay only
Membership registration is subject to the following requirements: Membership registration is subject to the following requirements:
- The holder MUST specify the requested rate limit `r` of a new membership at registration time[^3]. - The holder MUST specify the requested rate limit `r` of a new membership at registration time[^3].
- Registration MUST fail if `r < r_{min}` or `r > r_{max}`. - Registration MUST fail if `r < r_{min}` or `r > r_{max}`.
- The holder MUST make an tranasction to the contract, - To register a membership, the holder MUST make a tranasction that locks up a deposit in the contract.
locking the deposit to register a membership.
- The amount of the deposit MUST depend on the specified rate limit. - The amount of the deposit MUST depend on the specified rate limit.
- In case of a successful registration: - In case of a successful registration:
- the new membership MUST become _Active_; - the new membership MUST become _Active_;
@ -239,7 +238,7 @@ If further upgrades are necessary,
a new contract SHOULD be deployed, a new contract SHOULD be deployed,
and the membership set SHOULD be migrated. and the membership set SHOULD be migrated.
## Implementation Suggestions ## [Implementation Suggestions](#implementation-suggestions)
### Membership Set Implementation ### Membership Set Implementation