Offloading RLN in Waku with Trusted Execution Environments

Introduction

Waku employs Rate Limiting Nullifiers (RLN) to enforce user rate limits in a fully decentralized, privacy-preserving manner. A rate limit is defined by the number of messages a user may send within a given time period. Membership is managed via a publicly registered identity set on a blockchain, represented by its Merkle root.

When a user wants to send messages on the Waku network, they generate a zero-knowledge RLN proof demonstrating both:

  • Membership in the on-chain identity set, and
  • Compliance with the agreed rate limit.

Any node can verify this proof, enabling decentralized enforcement of rate limits without sacrificing user privacy.

The Problem

Generating an RLN proof today poses two significant challenges:

  • High Computational Cost: Proof generation can take several hundred milliseconds on a modern laptop and substantially longer on mobile devices leading to poor performance and increased battery drain.
  • Witness Acquisition: Producing the proof also requires a Merkle proof (the witness) to confirm inclusion in the tree. Users must either index blockchain events locally or rely on a blockchain RPC to retrieve this witness data.

For true self-sovereignty, each user must both generate their own RLN proof and compute their own witness. Delegating either task to an external service undermines RLN’s privacy guarantees and decentralization. But generating the proof is not practical.

The Solution

How can we offload these tasks without compromising RLN’s core properties? By leveraging Trusted Execution Environments (TEEs), we can safely delegate proof generation.

A server equipped with a TEE performs the heavy cryptographic work, sparing users’ devices. The TEE queries the local tree to fetch the Merkle proof without learning the users commitment id. The code runs in hardware-enforced enclaves where even a malicious host OS cannot access data inside the enclave.

In other words. An untrusted third party can generate the RLN proof for a user while maintaining the user commitment private.

We recommend that Waku explores integrating TEEs to scale RLN proof generation, by providing a service to do so using TEEs.

This approach would relieve users of computational and indexing/RPC burdens while preserving the privacy, security, and decentralization that RLN guarantees.

We suggest two different incremental milestones:

  • First, use the TEE to privately provide the merkle proof to the user. Some kind of private information retrival. But proof generation is still in the user side. This maintains privacy as the service won’t know the commitment.
  • Second, use the TEE to both provide the merkle proof and generate the RLN proof.
2 Likes

Thanks for this suggestion!

I certainly take your point about reliance on an RPC provider (or worse, having to maintain a synced copy of the tree) when computing the witness. I’m not sure that proof generation is such a significant overhead anymore, at least not for the relatively low-rate use case that Waku is designing for in the near future. This may change of course as the network and application of Waku scales.

One concern I had is if a TEE service would not in fact increase reliance on a third party? Of course, for on-chain Merkle proofs we already “rely” on an RPC provider, but this is arguably not a fundamental point of centralisation - just a temporary convenience until we have light clients (if these things are ever truly temporary…). If nodes rely more fundamentally on third party TEE servers in order to publish messages, likely run by only a few incentivised operators, they’d be open to more direct censorship attacks. Presumably the communication between the node and the TEE would be a different set of trust assumptions too.

I take your point on not considering to offload RLN proof computation to a 3rd party.

But if the user generates its own RLN proof, it still needs the witness (merkle proof) from an RPC (using the smart contract call that returns the proof of an index). Since the index of the tree is an input here, the user is revealing its identity to the RPC provider.

So the added value of the TEE is not about decentralization but privacy, since it will return the merkle proof encrypted, without learning which index the user requested.

so not about centralization but privacy.

2 Likes