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

add state transition diagram

Browse Source
This commit is contained in:
Sergei Tikhomirov 2024-08-08 15:46:19 +02:00
parent d61d6b0e2d
commit 471b479ade
No known key found for this signature in database
GPG Key ID: 6A1F8ED9D6538027
1 changed files with 17 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -38,7 +38,7 @@ In particular, the contract would require users to put down a deposit.
The aim of the deposit initially is purely to protect the system from denial-of-service attacks using bandwidth capping.
It may also be explored as a revenue stream for Waku in later versions.
## Semantics
## Membership lifecycle
This section is not intended to describe the full contract functionality.
We only focus on functions required for managing memberships.
@ -55,7 +55,7 @@ For the _Contract Owner_, the contract provides the following additional functio
The deposit is not taken away (slashed) for exceeding the rate limit.
### Membership lifecycle
## Membership state transitions
A membership can be in one of the following states:
- active;
@ -63,6 +63,17 @@ A membership can be in one of the following states:
- expired;
- erased.
```mermaid
graph TD;
NonExistent --> |"register"| Active;
Active --> |"+90 days"| GracePeriod;
GracePeriod --> |"extend"| Active;
GracePeriod --> |"+30 days"| Expired;
GracePeriod --> |"withdraw"| Expired;
Expired --> |"reuse_slot"| Erased;
```
A user locks up a deposit to register a membership, which starts its lifecycle in the _active_ state.
After the expiration term (see parameter table), a membership moves to the _grace period_ state.
During grace period, the membership owner can either extend the membership or withdraw the deposit.
@ -101,6 +112,10 @@ We do not allow extending an _active_ membership.
The rationale here is that if the _Owner_ changes some contract parameters (e.g., for security purposes),
users with extended memberships will not be affected by the changes for a long time.
Membership states are updated lazily in the contract.
Before handling any membership-specific function, the contract MUST check if the membership's state is outdated and update it as necessary.
### User actions
In more detail, user actions are handled as follows.