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

edit for clarity

Browse Source
This commit is contained in:
Sergei Tikhomirov 2024-09-25 11:33:43 +02:00
parent 0f9d6804c9
commit fd91933c47
No known key found for this signature in database
GPG Key ID: 6A1F8ED9D6538027
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -39,12 +39,14 @@ For the full specification of RLN Relay, see See [17/WAKU2-RLN-RELAY](https://gi
## Contract overview ## Contract overview
The contract MUST provide the following functionalities: Let us define membership-related functionalities (hereinafter, functionalities) as follows:
- register a membership; - register a membership;
- extend a membership; - extend a membership;
- erase a membership; - erase a membership;
- withdraw a deposit. - withdraw a deposit.
The contract MUST provide the functionalities.
A membership _holder_ is the entity that controls the secret associated with the respective RLN commitment. A membership _holder_ is the entity that controls the secret associated with the respective RLN commitment.
A membership _keeper_ is the sender (`msg.sender` in Solidity semantics) of the transaction that registered that membership. A membership _keeper_ is the sender (`msg.sender` in Solidity semantics) of the transaction that registered that membership.
The holder and the keeper MAY be different entities for the same membership. The holder and the keeper MAY be different entities for the same membership.
@ -125,7 +127,7 @@ A user MAY use one Waku node[^1] to manage multiple memberships.
## Contract functionalities ## Contract functionalities
Availability of membership-specific functionalities[^2] MUST be as follows: Availability of functionalities[^2] MUST be as follows:
| | Active | GracePeriod | Expired | ErasedAwaitsWithdrawal | Erased | | | Active | GracePeriod | Expired | ErasedAwaitsWithdrawal | Erased |
| --------------------- | ------ | ----------------- | ------- | ---------------------- | ------ | | --------------------- | ------ | ----------------- | ------- | ---------------------- | ------ |
@ -197,10 +199,7 @@ The updated parameter values MUST apply to all new memberships.
The parameters of existing memberships MUST NOT change if the _Owner_ updates global parameters. The parameters of existing memberships MUST NOT change if the _Owner_ updates global parameters.
The contract MAY restrict extensions for memberships created before the latest parameter update. The contract MAY restrict extensions for memberships created before the latest parameter update.
The _Owner_ MUST be able to pause any of the following contract functionalities: The _Owner_ MUST be able to pause any of the functionalities (see definition above).
- register a membership;
- extend a membership;
- withdraw a deposit.
At some point, the _Owner_ SHOULD renounce their privileges, At some point, the _Owner_ SHOULD renounce their privileges,
and the contract MUST become immutable. and the contract MUST become immutable.
@ -221,7 +220,7 @@ The criteria for this selection can vary depending on the implementation.
Key considerations include: Key considerations include:
- To minimize gas costs, it's better to overwrite a single high-rate membership rather than multiple low-rate ones. - To minimize gas costs, it's better to overwrite a single high-rate membership rather than multiple low-rate ones.
- To encourage timely withdrawals, it's better to overwrite memberships that have been _Expired_ for a long time. - To encourage timely deposit withdrawals, it's better to overwrite memberships that have been _Expired_ for a long time.
### Considerations for User-facing Applications ### Considerations for User-facing Applications
@ -248,9 +247,10 @@ The rationale is to make possible parameter changes that the contract _Owner_ mi
### What if I don't extend my membership within its _GracePeriod_? ### What if I don't extend my membership within its _GracePeriod_?
If a user does not extend their membership during the _GracePeriod_, If the membership is not extended during its _GracePeriod_,
they risk having their _Expired_ membership overwritten. it becomes _Expired_ and can be overwritten.
Generally, users are expected to either extend their membership or withdraw their deposit to avoid this risk. Users are expected to either extend their membership on time to avoid this risk,
or erase them and withdraw their deposit.
### Can I send messages when my membership is _Expired_? ### Can I send messages when my membership is _Expired_?
@ -260,7 +260,7 @@ only its inclusion in the membership set.
_Expired_ memberships are not proactively erased from the membership set. _Expired_ memberships are not proactively erased from the membership set.
An _Expired_ membership is erased only when a new membership overwrites it or when its deposit is withdrawn. An _Expired_ membership is erased only when a new membership overwrites it or when its deposit is withdrawn.
Once erased (i.e., _Erased_ or _ErasedAwaitsWithdrawal_), the membership can no longer be used to send messages. Once in _Erased_ or _ErasedAwaitsWithdrawal_ state, the membership can no longer be used to send messages.
### Will my deposit be slashed if I exceed the rate limit? ### Will my deposit be slashed if I exceed the rate limit?