Thanks for pointing out the Semaphore RLN, rate limiting nullifier proposal.
We seriously considered a stake-based system design for Mesh and initially ruled it out for the following reasons:
- It introduces the overhead of reaching consensus about the state of the orderbook, adding latency and throughput bounds to the network.
- It requires MMers, relayers and traders wanting to run a Mesh node to also acquire and stake a native token, adding friction to the onboarding process. This also sufficient friction for casual users of Mesh, say a browser-node from joining the network.
- The need to stake funds locks up capital participants could otherwise use for trading, something MMers are especially sensitive to since they must deploy significant capital in their trading strategies.
As the above reasons illustrate, there are numerous considerations for the p2p orderbook use-case that would require significant trade-offs when using a stake-based system. If you do have a stake-based system, you could simply make the consensus process rate-limit each participant according to their stake. We took this general idea of rate-limiting by some scarce resource and came up with an alternative proposal that precluded the need for staking but still would rate-limit peers according to ownership of a scarce asset on Ethereum. We hit some difficulties in attempting to implement this design efficiently but are continuing to explore this design space.
While we keep researching better designs, we’ve decided to settle for a simple design that we can upgrade over time. We will rate-limit each peer connections bandwidth consumption and blacklist the IPs of any peers that abuse the imposed limit. Additionally, if a peer remains below the bandwidth cap, but decides to spam the network with valid albeit useless orders, nodes at capacity will begins pruning orders furthest from expiry (the intuition here is that MMers create the bulk of useful orders and those orders tend to have low expiration times). If new orders discovered expire later then all stored nodes, they are simply dropped. For an attacker to keep up the attack, they must constantly create new orders with lower and lower expirations. Once they stop attacking, their orders are quickly pruned as they will expire quickly.
We do not think this is an optimal solution but rather one that will prevent an attacker from taking down the network or significantly impairing the network for a long period of time. We will continue to research alternative mechanisms to prevent spam and DOS attacks, including stake-based solutions, while considering their drawbacks for our particular use-case.