---
# System prepended metadata

title: 'Validators vs Builders, trust assumptions'

---

# Validators vs Builders, trust assumptions

Often times we want to make statements of the form, if x% of validators are honest, property P holds, or equivalently, under the supposition that an attacker holds less than y% of the total stake, statement Q is true. 

Examples of these are of the form: "With a proposer boost of 40% then an attacker with more than 60% of the stake can reorg arbitrarily the block right before he's assigned to propose". "If 90% of the validators are honest, and we have seen all attestations and all blocks in the last two epochs, then the head of the chain cannot be reorged", etc. 

These statements become much harder to make in the context of PBS, where trust assumptions on validators may become trust assumptions on builders, which is a much more reduced set.

## CL data vs EL data

In a context where most validators defer their execution payload, data blobs, or any future non-pure consensus part of the block to an external builder. The builder may have a final decision on certain aspects of blocks, thus whatever trust assumptions we are making on honesty of validators may cease to be true. 

In other cases, the builder has zero or very little impact. For example, a trust assumption of the form: "x% of validators are not willing to arbitrarily fork blocks". The validity of this statement is the same under PBS or not, builders have very little bearing on the LMD weight of a given chain, validators alone decide their attestation targets. 

However, a sentence of the form "x% of validators are not willing to censor transactions" becomes completely different when builders have complete and final decisions on which transactions make in on-chain. 

## An example: Censoring transactions 

Let us consider the situation of censoring transactions. Let's say that x=10% of validators are not willing to censor transactions. That is, 10% of validators would not purposedly prevent certain transactions to enter on their execution payload. So if for example their running EL would by default include these transactions by being the ones that paid the most, these validators would not alter their software to prevent inclusion. However, let us consider the situation where they defer construction of their execution payload to an external builder. Be it because we are in a situation where home stakers no longer can produce an execution block, or the protocol enforces PBS in a way that the proposer has to be registered as a builder, or simply by operator ignorance he just doesn't know that he's using a censoring relayer/builder. To put it in simpler terms: let us suppose that 10% of validators are willing to run a stock unadulterated version of geth and prysm but they are still sending their blocks through MEV-Boost or a relayer to earn more money on their blocks. 

Notice that the 10% value here is not chosen at random, it seems in principle as a reasonable assumption, but the fact is that even though it may be reasonable to expect that 10% of validators are running unadulterated software, over 95% of blocks are currently produced by external builders, whose software is not known. 

For the sake of this example, let us assume that 100% of builders want to censor a particular transaction. It does not matter than 10% of validators were running stock software, if the builders decide the execution content, those transactions will be censored. 

Here comes the first mitigation factor: the local unadulterated software will revert to local execution if its highest paying transaction has been valid for over a few slots and has not been included. Or in simpler terms, if the local payload pays above a certain threshold, or whatever mechanism. This converts the above problem back to "10% of validators are not willing to censor". 

So we see in the above mitigation a way of going back to our original assumption about validators being censoring or not. There are however more methods to censor transactions. For example, if you see a block that has included transactions you want to censor, you may want to treat that block as invalid, and simply try to reorg it. It is reasonable to assume that there may be validators that are willing to censor (say are not willing to give away their MEV earnings and continue to submit their blocks to external builders even knowing that they will be censoring) but are not willing to run adulterated software that will send wrong attestations in order to reorg a block but will still run a fork that will force an external builder. We could therefore say that "at least y% validators are not willing to reorg blocks for purpose of censoring". This number y could be anything as long as it's higher than x (validators that are not willing to censor will definitely not reorg blocks to censor). 

So let us analyse the extreme case when y = x. This means that whenever a non-censoring block is produced, it will have to be reorged by the censoring cartel. In the "reasonable" assumption x=10% above, since 90% of validators are willing to censor by reorgs, and 90% of the stake is enough to do a pos-anti reorg of an arbitrary block, the attacking cartel is guaranteed to succeed. 

But how about a more "reasonable" assumption that y > 40%^?. In this case, the censoring cartel cannot reorg arbitrarily a past block (under the assumption of proposer boost less or equal than 40%) and they have to resort to more involved attacks like ex-anti sandwiches and the such. Notice that I am using 40% here to make the analysis easier, but any number higher than 10 would do, with the change that the censoring cartel may be able to reorg arbitrary past blocks if y < 40%. Not only do these attacks require a more involved technical setup, but they are also detectable on-chain: the censoring blocks need to reorg not-only the non-censoring blocks containing the undesired transactions, but also those blocks produced by the censoring validators that were not willing to reorg them. One can do a statistical analysis as to how many blocks are expected to be produced by non-censoring validators (namely x% in the long term) and how many of the neighboring blocks would be produced by the validators in the set bounded by y%. It turns out that it is very likely that the censoring cartel would have to do a 2-block reorg under very mild assumptions (that is in less than 30 minutes for x=10% and y=40%). 

### Bad relayers or bad PBS bypass this

So we have reached a point where, if x% of validators are unwilling to censor and y%>x% of validators are unwilling to reorg valid blocks, then in principle we can detect this on-chain because any censoring cartel would need to reorg at least 2-chains in a very short time, something that very rarely happens on mainnet. 

Let us analyse the situation where the validator in the set that are unwilling to censor (that is those that are less than x%) are still encouraged for some reason to send their blocks to an external builder. This could for example happen if we have inclusion lists. Then a validator that is not willing to censor but wants to reap benefits of MEV, would submit their blocks to external builders, with a transaction list attached that he is requiring the builder to include. There are many variations of this, whether or not the builder is required to include them or can prove that his block is full, in any case those variations are irrelevant for the following argument.

If the implementation of inclusion lists on PBS or on the current MEV-Boost approach allows a builder to not release the block without any major consequences (for example, if all that the builder loses is his own stake in the system). Then a builder, at a cost, can prevent any block from the non-censoring set from being included. This for example is the case with the proposed "optimistic relayer" from flashbots, and in many CR-lists approaches to PBS: the builder, even if paying a stake, may be encouraged to no release his payload, preventing the censored transactions from being included. 

**What does this have to do with the original problem we stated above?** the connection lies in that under these conditions, the problem has become mathematically equivalent to y=x. Even though some validators (say 40% were unwilling to fork), the censoring builders can simply remove the non-censoring blocks (that are x=10%) at a fixed cost (their stake) allowing them a two-fold win: they prevent the transactions from being in, and also prevent on-chain detection since they can simply reorg arbitrary blocks as if the censoring-by-reorg stake was 90% = 100% - x%. 

### A possible solution. 
A possible solution to this last problem is to allow the proposer to specify either a full valid execution payload that would be included if the builder fails to include his, or include the CR list in the beacon/execution state after the CL block has been accepted, forcing the next proposer to include those transactions (if still valid) in its own inclusion list/execution payload. This way, builders do not receive the same benefits that they would have with 90% of the stake, as they will not be able to make a single reorg to make the non-censoring block dissapear. 