Consider this section from the 17/WAKU2-RLN-RELAY spec:
The messaging rate is defined by the period which indicates how many messages can be sent in a given period. We define an epoch as ⌈ unix_time / period ⌉. For example, if unix_time is 1644810116 and we set period to 30, then epoch is ⌈ (unix_time/period) ⌉ = 54827003.
From this definition, an epoch is an integer. If so, the following sentense doesn't type-check:
...only allowed to send one message per epoch
I see some clarity issues here: the term "Unix epoch" can be understood in different ways: a) the current Unix timestamp; b) midnight UTC 1-Jan-1970; c) the time period from midnight UTC 1-Jan-1970 into infinity (or until a new time standard is adopted).
What I would suggest:
- define epoch number as
⌈ unix_time / period ⌉.
- define epoch as the time interval between
unix_time and unix_time + period, where unix_time is a unix timestamp divisible by period (think carefully about boundaries being inclusive / non-inclusive).
- define rate limits in terms of "
N messages per epoch" as currently done.
Further:
NOTE: The epoch refers to the epoch in RLN and not Unix epoch. This means a message can only be sent every period, where the period is up to the application.
Note that there is a distinction between "a message can only be sent every period" and "a message can only be sent every epoch". Consider a period of 10 seconds and a rate limit of 1 message every period. Epoch 1 contains timestamps 1-10, and epoch 2 contains timestamps 11-20. Consider two messages sent at timestamps 9 and 11. By period-based rate limit, this is not allowed, but by epoch-based rate limit it is allowed, as these messages fall into different epochs.
Consider this section from the 17/WAKU2-RLN-RELAY spec:
From this definition, an epoch is an integer. If so, the following sentense doesn't type-check:
I see some clarity issues here: the term "Unix epoch" can be understood in different ways: a) the current Unix timestamp; b) midnight UTC 1-Jan-1970; c) the time period from midnight UTC 1-Jan-1970 into infinity (or until a new time standard is adopted).
What I would suggest:
⌈ unix_time / period ⌉.unix_timeandunix_time + period, whereunix_timeis a unix timestamp divisible byperiod(think carefully about boundaries being inclusive / non-inclusive).Nmessages per epoch" as currently done.Further:
Note that there is a distinction between "a message can only be sent every period" and "a message can only be sent every epoch". Consider a period of 10 seconds and a rate limit of 1 message every period. Epoch 1 contains timestamps 1-10, and epoch 2 contains timestamps 11-20. Consider two messages sent at timestamps 9 and 11. By period-based rate limit, this is not allowed, but by epoch-based rate limit it is allowed, as these messages fall into different epochs.