More cost effective way to do Ethereum transactions - impacts RLN and SWAP

[staheri14]

UPDATE: Initially this issue was about member cost only. Since it isn't specific to RLN but also impacts e.g. SWAP contracts, I updated the title and added a comment at end of issue. Rest of issue is written from POV of membership cost in RLN -- oskarth

Overview

rln-relay consists of the following steps: 1- A membership smart contract must be deployed on the blockchain, the contract holds the list of current registered members (as well as deleted members) and has the API for member insertion, and deletion (slashing). Root of the tree and auth path of pubkeys are not available as part of the contract.

2- Each rln-relay enabled peer must register a public key through the smart contract. Peers need to persistently store their public and secret keys. Registered peer locks a certain amount of fund in the smart contract, which gets burned in case the peer misbehaves (spams the system). 3- Each rln-relay enabled peer must construct and maintain a Merkle Tree based on the list of current members )fetched from the membership contract). This is required for the spam protection. As scuh, peers must keep listening to the contract events (member insertion or deletion) and update their local Merkle tree accordingly. Having the Merkle tree, a peer is able to

• calculate the tree root
• its authentication path (membership proof)

4- By having access to the recent root and membership proof

• Peers can anonymously publish messages with a certain rate and prove that they are not spammers (have not violated the designated rate)

• Routing peers can authenticate the non-spam messages, and otherwise drop the message and slash the spammers (delete them from the membership contract and withdraw their deposit)

Problem

Becoming a member of rln-relay costs around 30 USD which does not seem a reasonable price. The calculation details follow:

Insertion: Inserting a member to the smart contract costs 40k gas = 0.00656 Eth = 14.34 USD (considering gas price as 164 Gwei, and each Eth is worth of 1715.46 USD).

Deletion: The same cost of 14.34 USD applies to the member deletion.

Membership fee: In addition to the cost associated with the member insertion, each peer must lock some fund in the contract for the sake of spam protection. The fund will be rewarded to the slasher for catching a spammer. Slashing a member involves deletion operation which costs 14.34 USD. Thus, for the slashing to make sense, the fund locked by each user must be more than the deletion cost i.e 14.34 USD. This yields the registration fee that is more than 2*14.34 = 28.68 USD.

This amount may/may not be considered reasonable for becoming a member of a spam protected messaging system.

References

https://hackmd.io/JoxnlDq3RT6WhtA-KBxtYg

[oskarth]

Thanks for these numbers, useful! 40k gas seems pretty low, similar to ERC20 transfer. But I agree that they are probably an order of magnitude or two off from what would be desirable. That should be doable with some L2 solution like Optimism though, or a similar route.

FWIW, the gas cost for deploying a swap contract (done once per user) is 2100308:

eth_sendTransaction                                                                   
  Contract call:       SimpleSwapFactory#deploySimpleSwap                             
  Transaction:         0xf7628153fa45d6994be14035250436e0118c8df6534f00cb4f6d4cefa43f2
72b                                                                                   
  From:                0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266                     
  To:                  0xe7f1725e7734ce288f8367e1bb143e90bb3f0512                     
  Value:               0 ETH                                                          
  Gas used:            2085828 of 2100308                                             
  Block #4:            0x8b5997038f0239685e9ba886f2194468702aee14bf4ff0637a87b3ed40e68
5f0                     

Cashing a cheque is around 100k:

eth_sendTransaction                                                                   
  Contract call:       ERC20SimpleSwap#cashChequeBeneficiary                          
  Transaction:         0xe3b174088d1b9299c9e684b84b15e44609ebc92606bf856d4411a942b9074
969                                                                                   
  From:                0x70997970c51812dc3a010c7d01b50e0d17dc79c8                     
  To:                  0xcafac3dd18ac6c6e92c921884f9e4176737c052c                     
  Value:               0 ETH                                                          
  Gas used:            102306 of 102306                                               
  Block #8:            0xb76a3b8092c9d94b9975a9b5e50365085f66aaae17ca2d87d7f7f8a488e6d
d23   

These can probably be optimized, but just to give a ballpark.

[oskarth]

I took the liberty of rewriting this issue a bit

[oskarth]

Here's what running it on Optimistic public testnet would look like (coming in March, supposedly):

• https://community.optimism.io/docs/evm-comparison.html#missing-replaced-and-custom-opcodes
• and https://community.optimism.io/docs/integration.html#introduction

We'd have to look over contracts to check opcodes etc.

As for other solutions, I don't have a clear view of timelines, capabilities or maturity of them.

[cyanlemons]

As for other solutions, I don't have a clear view of timelines, capabilities or maturity of them.

@oskarth Aztec's Noir language for private smart contracts is said to be available "over the coming months." Also, it seems like they are adding ECDSA support, so Keycard may not end up being a blocker.

This will likely be a more finicky & less mature solution in the short term, but in the long term, I think we may regret building infrastructure on L2s that don't prioritize privacy. And intuitively, I would presume that having a completely private financial entry point to Waku would eliminate entire classes of potential attack vectors.

[oskarth]

This is a good point, and private settlement is indeed a desideratum. For now, considering the complexity and many unknowns both around the solutions, and L2s in general, I'd probably err on the side of doing simplest L2 possible that would scale. Once that seems to be working, private settlement is indeed something that would be bumped up in priority.

It is also a question of specific threat models, where both RLN and SWAP don't directly tie two people talking together (nor need chat and crypto keys be tied together), say, but is more about paying a provider for some service. Ideally, this is private as well of course.

To sum up:

• it should be mentioned in specs in terms of security guarantees,
• starting with simplest possible thing and iterating from there,
• eyes on the long term goal of having private settlement