Multisig for RLNv2 Contract

The purpose of this post is to discuss the multisig setup for the RLNv2 contract.

Background

RLN is a core component of Waku that rate-limits resource usage within the network. The central feature of RLN is a set of on-chain smart contracts that manage memberships. Users can purchase memberships, allowing them to send a specified number of messages per unit of time. Message senders prove their membership using zero-knowledge proofs, which preserves their privacy.

In 2024, a new version of the RLN smart contract, called RLNv2, was developed. This version introduces enhanced membership management functionality, as detailed in the specification.

RLNv2 is currently deployed on the Linea Sepolia testnet, which is an Ethereum-based rollup. As of January 2025, RLNv2 has not yet been integrated into nwaku or any other Waku implementation. According to the roadmap (see issue 258), we plan to deploy it on the Linea mainnet.

Owner Privileges in the RLNv2 Contract

The RLNv2 contract currently has an Owner with the following privileges:

In the current implementation (see README):

  • Set specific contract parameters, such as the price of one message per epoch and the maximum total rate limit.

Additionally, according to the specification (not yet implemented as of January 2025):

  • Pause all membership-related functionalities (e.g., register, extend, erase, withdraw).

Furthermore, to be specified in the future:

  • Withdraw and distribute funds from the contract balance.

Problem Statement

This post aims to open a discussion about how control over the contract Owner should be distributed.

According to the specification, the contract should eventually become ownerless. However, this transition may take time. Centralized control over the contract is beneficial during testing and integration, but the contract should not be controlled by a single party upon mainnet deployment.

The primary goal of distributing control over the Owner is to prepare for mainnet deployment while minimizing centralization risks.

The setup should:

  1. Utilize well-tested software.
  2. Allow for changes in quorum configuration.
  3. Enable the replacement of signers in case of key loss.
  4. Not hinder testing, especially during earlier (testnet) development stages.
  5. Incorporate best practices from the ongoing management of the Status multisig.

Multisig vs. MPC-based Threshold Signature Schemes (TSS)

Multisig and TSS are two techniques that enable distributed control over a cryptographic entity.

  • Multisig: A smart contract is jointly controlled by multiple keys.
  • Threshold Signature Scheme (TSS): A cryptographic scheme that allows parties to perform multi-party computation (MPC) to collaboratively sign a message without reconstructing the private key.

The key difference between the two techniques lies in how signers are coordinated.

Multisig

In a multisig setup, a smart contract serves as an on-chain coordinator:

  1. A smart contract is deployed to implement access control logic.
  2. n potential signers are assigned.
  3. Any t of the n signers independently sign payloads authorizing an action within the contract.
  4. The last signer combines the payloads into a transaction and broadcasts it (and pays the transaction fee).

In our setup, the multisig contract would act as the Owner of the RLNv2 contract. It is possible to designate one contract as the Owner of another (Ownable) contract.

TSS

In an MPC-based TSS, a coordination protocol operates off-chain. The resulting signature is indistinguishable from one produced by a single key:

  1. Private key shares are generated and distributed among n potential signers.
  2. Any t out of n signers use a multi-party protocol (MPC) to collaboratively sign a transaction.
  3. The signed transaction is then broadcast.

Unlike multisig, TSS does not require deploying additional contracts on-chain and is network-agnostic, meaning it does not depend on specific smart contract implementations. (However, multisig setups can also be considered network-agnostic if we consider well-tested implementations deployed on EVM-based networks.)

Key Differences

Feature Multisig TSS
Owner-related logic is on-chain (better transparency, worse privacy) Yes No
Widely used and tested software exists Yes Maybe?
Granular control over Owner’s actions on-chain Yes No
Network-agnostic Kinda? Yes

Defining Our Setup

Choosing a Multisig (or TSS) Implementation

Potential multisig implementations include:

An example of a TSS implementation is Totalsig.

We need to evaluate the security model to make an informed choice. Key considerations include:

  • For TSS-based setups, who facilitates coordination? Will we rely on a third-party coordinator?
  • For multisig setups, what are the risks if the official frontend becomes unavailable? Can transactions still be prepared locally without assistance from multisig implementation developers?

Choosing a Quorum

In a multisig setup, any t out of n keys are required to authorize a transaction, referred to as a quorum (t-of-n).

Common quorum configurations include 2-of-3 and 3-of-5. The value of t should be strictly less than n to avoid freezing ownership if a single key is lost.

For our purposes:

  • A more permissive quorum (lower t) should be used during early development and testing to simplify processes.
  • A stricter quorum (higher t) should be adopted as we approach mainnet deployment.

Considerations for Multisig Parametrization

  1. Balance development/testing simplicity with minimizing the risk of freezing the contract due to key loss.
  2. Implement key rotation procedures to replace signers if a key is lost, a person leaves Waku, or other unforeseen circumstances arise.

A written protocol should outline processes such as:

  • Signing transactions.
  • Verifying the authenticity of data to be signed.
  • Key rotation and backup restoration.

Signers must familiarize themselves with this document and adhere to all outlined steps. At least one signer (responsible for broadcasting finalized transactions) must hold native tokens (e.g., ETH on Ethereum mainnet) to pay transaction fees.

Assigning Signers

During the testing phase, most (if not all) signers should be Waku developers and researchers. As we approach mainnet deployment, additional signers from Status, IFT, or independent parties should be included.

Draft Proposal

As a starting point, we propose the following setup:

  • Protocol type: Multisig.
  • Implementation: Safe.
  • Quorum: 2-of-10.
  • Signers: To be determined.

Action Items

This post aims to initiate a discussion around the following questions:

  • Does the overall reasoning make sense?
  • What arguments exist for and against multisig vs. TSS?
  • What implementations are worth considering?
  • What quorum configurations should be preferred?
  • What additional considerations should we account for?
  • What other uses can we find for the multisig? (e.g., signing releases)

Feedback and suggestions are welcome!

3 Likes

Would it be fair to say that choosing TSS instead of multisign would allow more flexibility in what can be signed since it’s off-chain?

Signing releases would be cool and also curated lists of bootstrap nodes.

Can Waku be used to enhance privacy in this case?

Demonstrating that Waku can be used for aggregating TSS signatures would be very cool!

However I am concerned with the amount of additional infrastructure and coordination necessary to properly implement TSS.

It might make more sense to use a multisig to maintain an on-chain registry of public keys which are considered valid release signers or bootstrap nodes.

imo if a multisig doesn’t have an open source frontend we shouldn’t use it. It looks like Safe has options for interacting with the multisig locally ( GitHub - safe-global/safe-cli: Command line utility for Safe ) as claimed on their website:

1 Like

Thanks @sergei-tikhomirov for detailing the options that can be used for Multisig! I learned about TSS and multisig a little bit because of this post.

imo going ahead with onchain and using safe seems like a good option as it would involve less effort at this point. and as @arseniy pointed out we should use a multisig that allows us to run and access front-end locally so that we don’t depend on hosted front-end.

I also like the point @SionoiS made about curating bootstrap nodes. In future this can be extended to decide more network level params for Waku as well

2 Likes

I would say so, yes.

Thinking about it, there are two goals that are somewhat orthogonal:

  1. security of contract actions (potentially including funds management);
  2. public accountability.

On one hand, TSS is indeed more flexible, as it is not tied to any on-chain logic. On the other hand, for additional use cases like signing releases or bootstrap nodes lists, we would also need to involve some kind ot PKI. The user must not only verify that e.g. a node list is signed by 3-of-5 keys, but also that these were the right keys.

I think there are different definitions of privacy at play here. When I say that a multisig provides worse privacy, I’m referring to the fact that the contract logic is on-chain, and which signers participated in authorizing a given transaction will also be visible on-chain. This can be seen as worse privacy, but at the same time better accountability (which may be more important here - let’s discuss).

I could indeed see Waku being used as part of TSS coordination protocol for better privacy. If the end result is just one signature, hiding the network traces of intermediate communication between signers seems to provide them with more privacy (e.g., hide who participated in a given signature). In the multisig, however, I’m not sure Waku would substantially benefit privacy, as the signers are visible on-chain in the end anyway.

1 Like

Indeed, for me it looks like a great idea for the Waku Idea Board!

Agree, more research is needed on what trust assumptions is needed in the TSS coordination providers.

The web version can also be run locally. Safe used to have a standalone Electron app as well, but they’ve discontinued it. In any case, it’s worth testing for ourselves whether a given setup works locally before committing to it.

Thanks for the informative approach! Some comments on your questions/action points:

Yes, I think so and I agree with the draft solution of a simple 2/10 multisig using Safe. I think we have good reason to go for the simplest option here as we have simple use case (for now). With “simple” I mean the option that is best understood and therefore carries least amount of risk.

  • What arguments exist for and against multisig vs. TSS?

In this case, the strongest argument for a multisig is its wide usage and well-trusted implementations (e.g. Safe).

  • What implementations are worth considering?

Might be interesting to understand what the Status multisigs use or get some insights from IFT contributors who may have had some exposure to other implementations.

  • What quorum configurations should be preferred?

2/10 sounds easy for the (currently) low-risk use case of RLN contract ownership. Once the multisig start controlling funds/assets, I would either change the quorum to a stricter quorum or create a new multisig of which this multisig is just one signer.

What additional considerations should we account for?
What other uses can we find for the multisig? (e.g., signing releases)

Signing releases is a great use case (in fact, any published public artifacts). As mentioned above, we should keep in mind that the multisig may own assets in future.

I agree with multisig using Safe.

Best if signers are agreed in private.
Not sure 10 makes sense though. Let’s review who inside the team would need to update contract parameters for testing purposes + a few backups.