Future work for RLN on mainnet spec

[s-tikhomirov]

In the context of drafting the RLN on the mainnet raw spec (#30), several questions were discussed for future consideration. I'm outlining these questions here for the record.

State Bloat in the ErasedAwaitsWithdrawal State

If a user does not withdraw their deposit associated with a membership, this could lead to state bloat. Even though the membership is erased from the tree and replaced by a new membership (transitioning from Expired to ErasedAwaitsWithdrawal), the contract must then store an additional data structure (e.g., a mapping) that allows the keeper of the membership to withdraw their deposit at any point in the future.

Possible solutions include:

• Allowing the contract Owner to forcibly return old deposits;
• Introducing a withdrawal deadline, after which the deposit is burned (or a variation: gradually burning the deposit over time).

This may be a temporary issue, relevant only as long as the user can withdraw the deposit in full, as per the current raw spec.

Withdrawal from the Active State

The spec currently only permits withdrawals in the GracePeriod state or later (if not extended). However, from a UX perspective, it may be preferable to allow withdrawals at any time, including from the Active state. Without restrictions, this could lead to a pattern where deposits and withdrawals occur in quick succession. A possible solution is to introduce a minimal holding period, e.g., a certain percentage of the membership duration, after which withdrawal from the Active state would be permitted.

RLN Relay Nodes Sync with Frequent Tree Updates

Each membership movement in and out of the RLN tree triggers a root update. If these movements occur too frequently, e.g., every block, RLN Relay nodes may fall out of sync with the latest root, which would, in turn, affect the validation of the messages they transmit.

Support for Meta-Transactions and Indirect Calls

The spec currently defines a membership keeper as the sender (msg.sender) of registration transaction. This is only guaranteed to work if the user sends a transaction directly to the RLN contract from an externally-owned account (EOA). There are at least two use cases where this is unlikely to work properly:

1. The user calls the RLN contract indirectly, via a chain of calls to other contracts. In that case, msg.sender would refer to the last contract in the chain, i.e., the contract that immediately called the RLN contract. Hence, the address of that contract would be considered the keeper of the respective membership. This may or may not be what the user intended.
2. In the context of meta-transactions and paymasters, a user sends a transaction via a relayer, which actually sends it to the blockchain. In this setup, msg.sender would refer to the relayer's address. This is undesirable, as the relayer (a third-party service) would end up controlling RLN memberships of everyone who uses it for publishing transactions. Peoperly supporting this use case would involve encoding user authentication into transaction data, and decoding it in the smart contract. This is possible via either erecover (signing unstructured data) or, preferably, EIP-712 (Typed structured data hashing and signing). If we decide to implement it, we would have to change the definition of membership keeper in the spec.

For now, the spec explicitly states that only support for direct transactions from EOAs is obligatory (MUST), whereas support for indirect calls or relayers is optional (MAY).