[draft] RAILGUN usage of Waku RLN

[D4nte]

This is a draft, it is an attempt to gather RAILGUN's requirements regarding the usage of RLN. No action needed from Vac until clarifications are complete

RAILGUN uses Waku for communications purposes. Waku is used for 2 functionalities.

Actors

There are 2 actors to be considered:

1. A Relayer: Runs RAILGUN NodeJS software along side nwaku. Gets paid for submitting Wallet User's transactions on Ethereum L1 (other L1s are also supported).
2. Wallet User: Pays Relayers to submit a transaction on L1 so they can preserver their anonymity and not link said transaction to their Ethereum address. Current Wallet is Web based, with an implementation in progress for a React Native wallet (using go-waku).

Functionalities

The 2 functionalities for which Waku is used are:

1. Relayer's fee broadcast

Relayers are paid by Wallet Users within the RAILGUN zk smart contract so that Wallet Users do not reveal their Ethereum address when paying a relayer. Relayers can be paid in any token and can set their own price to relay transaction on L1.

Hence, a Relayer regularly broadcast their fee over Waku Relay. This enables Wallet User to select the best fee to get their transaction to be relayed, given the token they which to use to pay said fee.

Such messages are sent over /railgun/v1/${chainID}/fees/json content topic.

2. Wallet User transaction and payment

When a Wallet User wants to get a transaction relayed, they select a Relayer based on advertised price (see (1)) and local reputation. They then send a message to the selected Relayer over Waku. The message contains the payment and the (unsigned) transaction to broadcast on L1. The message is encrypted for the relayer. It is sent on /railgun/v1/${chainID}/transact content topic.

Relayers attempt to decrypt all messages on said content topic.

3. Transaction Response

The relayer broadcasts the success/failure status of the transaction over /railgun/v1/${chainID}/transact-response/json. This message is encrypted using the same client-generated shared key.

Usage of RLN

1. Relayer's fee broadcast

Currently, the only mechanism (see question 4 in clarifications section) to enable a Wallet User knowing whether a relayer fee is genuine is local reputation. The Wallet software remembers whether using a given Relayer in the past was successful.

Because of that, Wallet Users can be spammed by malicious nodes that make up fake relayer's fee messages.

I believe in this instance, the usage of RLN could be useful and would look something like that:

• Relayer joins RLN contract, submit fee messages on a RLN content topic, must attach proof at every message as RLN protocol.
• The RLN epoch would dictate how often a relayer can update their fee.
• Wallet User verifies RLN proof before processing RLN message.

Notes:

• Wallet User does not really need to verify proof for this to work, as the Waku nodes with RLN enabled would drop messages with duplicate RLN proof as per RLN protocol
• Only Relayer would need to pay the RLN fee to participate, which is fair as Relayer are incentivized to participate to earn fees from relaying RAILGUN transactions.
• While it does not prevent a node to still send "fake" relayer fee messages, it adds an initial cost for the spammer to do so.

2. Wallet User transaction and payment

For this functionality, Relayers could be spammed by non-genuine Wallet Users.

TODO: see (5) in clarifications section.

3. Transaction Response

Spam protection does not seem needed for this functionality as messages on this topic are encrypted by keys only known to a given user and relayer. Only potential attack vector would be a relayer trying to spam one of its previous user.

Clarifications needed from RAILGUN

1. ~I assume the relayers use one content topic for price broadcast. Is it one per accepted token? L1?~
2. ~Do Wallet User encrypt their message to the Relayer? If so, what encryption is used?~
3. ~I assume each relayer listen to a specific content topic for inbound messages?~
4. Is there currently any mechanism for a Wallet User to verify that a price broadcast is valid apart from local reputation?
5. Considering that a Wallet User needs to owner assets in the RAILGUN contract to pay a Relayer, what is the impact of spam attacks on Relayers? I imagine the first check that a Relayer does when receiving a relay transaction is whether the sender attached a valid zk payment to the message, is it costly?

[dao]

Thanks! I'll review further in the morning but you will find several clarifications in this outline of relayer network functionality https://github.com/Railgun-Privacy/Protocol/wiki/RAILGUN-Relayer-Network-Protocol

[oskarth]

cc @staheri14