Relay spam protection: require a small deposit to submit blocks as a builder

[bertmiller]

Relays have many jobs, among them is accepting blocks from many builders and figuring out which block is the most profitable for validators. One of the difficult parts of this job is that full blocks are large in size and costly to simulate. Without appropriate protections then a builder could spam many bad blocks at a relay, which would then be required to spend computational resources for no benefit. At the limit you can imagine builders actually overwhelming a relay with blocks and causing it to go down, which could have adverse effects on the overall network.

One option to prevent such spam would be to implement reputation scoring and priority queues similar to what Flashbots has done with our bundle relay on PoW ETH. That would need to be thought through and specced further.

Another option would be to require builders to deposit a small stake in a contract before they are allowed to submit blocks to a relay. The basic idea would be that if the builder starts to act maliciously then the relay can slash their stake, and the threat of this cost would act as a deterrent.

At the same time, we'd like to keep the barriers to entry for block building as low as possible. I'm not sure what a good stake requirement would be yet, but am open to ideas.

Ideally we would like to have completely permissionless submission to our relay, and this is the goal, although with a tight timeline before the merge and limited internal resources we may have to settle for slightly higher barriers to entry at the merge and permissionless submission later.

[jparyani]

One option to prevent such spam would be to implement reputation scoring and priority queues similar to what Flashbots has done with our bundle relay on PoW ETH. That would need to be thought through and specced further.

A simple way to bootstrap this would be to make it a completely manual process to get started. We could manually check which builders are landing profitable blocks and only then move them to the high priority queue. This will give us time to analyze the data and come up with a better programmatic system for reputation, and prevents the chicken and egg problem that would occur around the merge if we started with an automated system.

[bertmiller]

Would love to hear thoughts from you @jeromelaurens @sambacha @xcarlo @block-builder-22!

[sambacha]

Would love to hear thoughts from you @jeromelaurens @sambacha @xcarlo @block-builder-22!

We are implementing an RLN based authentication scheme for the purposes of preventing spam.

The requirement is that the submitter has an existing flashbots reputation. I can show you a demo if your interested @bertmiller

[jeromelaurens]

Would love to hear thoughts from you @jeromelaurens @sambacha @xcarlo @block-builder-22!

Mainly agree with @jparyani : start simple.
I would propose a signed header for authentication but without reputation scoring at the beginning + network Dos protection if it's easy to setup on your relay.
And as jason suggested, analyze manually what is a malicious behaviour before deciding the countermeasures.

Why not a stake too, but some of us may have some bugs or strange behaviour at the beginning, that is not intentionaly malicious. Those bugs would have to be fixed. But in the meantime it wouldn't be fair to slash the stake for those investing time for this.
Also I'm not in favour of stake beacause what's preventing a rich builder to build an infrastructure with many accounts and stakes, still spaming more than the others without being seen as a whole?
It is an incentive to centralization for richs

[sambacha]

Would love to hear thoughts from you @jeromelaurens @sambacha @xcarlo @block-builder-22!

Mainly agree with @jparyani : start simple. I would propose a signed header for authentication but without reputation scoring at the beginning + network Dos protection if it's easy to setup on your relay. And as jason suggested, analyze manually what is a malicious behaviour before deciding the countermeasures.

Why not a stake too, but some of us may have some bugs or strange behaviour at the beginning, that is not intentionaly malicious. Those bugs would have to be fixed. But in the meantime it wouldn't be fair to slash the stake for those investing time for this. Also I'm not in favour of stake beacause what's preventing a rich builder to build an infrastructure with many accounts and stakes, still spaming more than the others without being seen as a whole? It is an incentive to centralization for richs

The RLN solves this issue by decoupling availability from reputation: you do not get access based on some capital requirement, you get access based on your existing reputation from flashbots to boostrap it. The sybil problem is still there, however there are additional ways of mitigating this

[jeromelaurens]

The RLN solves this issue by decoupling availability from reputation: you do not get access based on some capital requirement, you get access based on your existing reputation from flashbots to boostrap it. The sybil problem is still there, however there are additional ways of mitigating this

RLN is a very good idea. 👍
I'm not completly aware of all the details of RLN, but there is something at stake in RLN ?
if yes, what did you put at stake ? the flashbot reputation?
but you cannot slash flashbot reputation, only your copy of it? only flashbot team can.
And the question remains : do the FB team have time to implement it before the merge ?

[sambacha]

The RLN solves this issue by decoupling availability from reputation: you do not get access based on some capital requirement, you get access based on your existing reputation from flashbots to boostrap it. The sybil problem is still there, however there are additional ways of mitigating this

RLN is a very good idea. 👍 I'm not completly aware of all the details of RLN, but there is something at stake in RLN ? if yes, what did you put at stake ? the flashbot reputation? but you cannot slash flashbot reputation, only your copy of it? only flashbot team can. And the question remains : do the FB have time to implement it before the merge ?

From our Forums post on the subject:

OpenMEV RLN

OpenMEV is interested in utilizing a decentralized identity for the purposes of limiting access to its public RPC. In general, everyone should be able to submit to the RPC, however, some degree of censorship vis a vie to protect the availability and liveness of the RPC gateway is desirable (i.e. preventing DDoS, spam, etc).

It seems as if there are 3 possible ways of utilizing the zk-RLN solution:

1: Exclusively rely on it as both an identity, authentication/authorization, and reputation system

2: Use existing reputation methods to enrich RLN (is this even possible, I am unsure as there seems only to be a membership and slashing, no +positive function for improving one's score')?

3: Two-stage membership: zk-RLN for general access, with a reputation system on top for prioritizing positional priority within accepting transactions

[1]: is identity and reputation substantively different or purely semantics in the context of this system

Can this be applied to a 'two-sided market'? Basically with the RLN acting as an interchange/matchmaking mechanism?

Is there only a concept of a singular user or can there be 'collectives'/'groups'?

Can slashing be configured? What are the parameters for slashing? Was not able to find this as it relates specifically to RLN

RLN Overview

RLN (Rate Limiting Nullifier) is a construct based on zero-knowledge proofs that enable spam prevention mechanisms for decentralized, anonymous environments.

For RLN to be used, the users first need to register to the application with their public key - they’re added to a membership Merkle tree upon successful registration. After that, they can use the protocol protected by RLN, but with each action, they leak a portion of their private key, and if they break the anti-spam threshold with a predetermined frequency of requests their private key can be fully reconstructed (by the properties of Shamir’s Secret Sharing scheme 2). By having their private key revealed the user can be removed from the membership tree and their protocol-related stake can be slashed if staking is enabled for the RLN application.

It will rate limit the users based on their IP addresses, but also it will be able to verify ZK proofs that the users will generate. The users will need to be registered to the service to generate valid ZK proofs. The service will enable user registration for the users that want to avoid solving challenges manually by providing a user interface, where by using InterRep the users will be able to register to the service.

The server (RPC Gateway) will host a single membership Merkle tree for all of the users, meaning that the users are registered at the service level and not on the application level. In other words after registering users will be able to access all of the applications protected by the rate-limiting service.

If a user sends too many requests per second, the service will be able to reliably identify and remove the user from it’s membership tree, by the properties of the RLN proof system. Once slashed the users will not be able to access the applications protected by the rate-limiting service again, nor be able to register (this might be too restrictive, and we might loosen up these conditions).

Current Flashbots Reputation scheme:

$r$ : searcher reputation score.
$H_{U}$ : set of all transactions $T$ submitted by searcher $U$ to the flashbots relay eth_sendBundle RPC and successfully landed on chain.
$S_{U}$ : set of all transactions $T$ submitted by searcher $U$ to the flashbots relay eth_sendBundle and eth_callBundle RPC.
$g_{T}$ : gas used by transaction $T$.
$p_{T}$ : gas price of transaction $T$.
$\Delta_{\text {coinbase }}$ : coinbase difference from direct payment in transaction $T$.

[charlescharles]

Here’s an idea for a reputation system - so the relay really only needs to simulate the best block it’s received so far, right? How about:

• relay asks builders assert how much their blocks pay (or also other assertions the relay may care about, like not containing sandwiches or not interacting with sanctioned addresses (sorry))
• relay keeps two queues: (1) blocks from “trusted” builders in decreasing claimed payment, (2) blocks with no payment assertion provided or from “untrusted” builders in received order
• it iterates through queue 1, simulating blocks until it finds one that pays the amount claimed. Every time it finds a block that pays less than claimed, it marks that builder no longer trusted. Once it finds a block that pays the claimed amount it can stop looking at queue 1 (this must is the best block so far)
• Then it looks through queue 2 and simulates every one to check if it’s better than the best block

We also need to decide how the reputation system works. If you’re too eager to mark builders trusted, then malicious builders can generate lots of keys, get them all trusted, and then spam queue 1 during high mev times. If you’re too picky, this encourages centralization. One simple option is to mark builders trusted once they’ve successfully had a block proposed.

There are probably other things you can do too, like require builders to send you the proposer payment log event along with merkle proof of inclusion in the receipts trie of their block.