# 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.
Last changed by  
 
potuz
212

Read more

Validator performance tracking

We explain in detail the different components that make up an Ethereum validator's reward. We describe common situations that make stakers miss some of these rewards and show how to diagnose the -- typically uncommon-- scenarios in which there are actual problems with the software and action is required. 1. Introduction A common concern of node operators is --Is my node performing well?--, or -- Is my node performing at least as the average?--. The essence of the question is in fact --Should I be changing anything in my setup or not?--. It turns out that these questions do not really have an easy answer. There have been many attempts to trying to create a single score that would measure a validator's performance, but they all fail because of different reasons to answer the very basic questions mentioned above. Instead of trying to track a single indicator (or a ton of useless ones and be worried about some small variance on any of those), validators should analyze why their performance took a hit: did I miss an attestation due to a late block, a reorg, something else out of my control?, did I miss a proposal due to my EL being stressed or was my block reorged because it was received late by the network?. In this document, we will try to help node operators to identify warnings, their cause, and make informed decisions on when to tweak their setup. In order to do this we first start by describing, in some level of technical detail, the different components of a validator's reward. We then move to analyze each one of them separately as they are susceptible to different external factors. We finally describe how to exploit existing monitoring tools (grafana, logs, beacon explorers, etc) to diagnose causes for drops in rewards. The organization of this post is as follows. In section 2 we describe the statistical expected variance in income amongst perfectly working validators. In section 3 we describe all the components that make attestation rewards, how much to expect in different scenarios of attestation inclusion and how to diagnose a missing attestation. In section 4 we describe the analogous situation for proposals. In section [5](# 5-Sync-committee-messages) we describe quickly sync committee rewards. In section 6 we cover transaction tips. In section 7 we mention some tools to monitor performance that are available in Prysm, and finally in section 8 we mention how to get support from the Prysm team. 2. Reward variance is evil

4/4/2023
Safe Head: happy case

Basic definitions and notation We will use $S$ for slots, $B$ for blocks, $E$ for epochs. Often times we will use $S$ for the block at slot $S$ abusing notation when no confusion could arise. For example, a forkchoice diagram of the form digraph{ rankdir=RL 10 -> 9; 11 -> 10; 12 -> 11; 13 -> 11; 13 -> 12 [style=invis];

3/23/2023
Report on another bad reorg on Goerli

The following reorg was seen on Goerli Unfortunately this graph iss ordered by slot number (left to right) and not by timestamps. The lightblue epoch on the left is 155221, the other lightblue epoch on the right is 155223, the white one in the middle is (you guessed it) 155222. When epoch 155221 ends, the last block that the chain has seen is 4967101 (slot 29 in that epoch, the top branch is based on that block). This block has not enough votes to justify epoch 155221, so the chain advances keeping the justified epoch to be 155220 The chain advances on the top branch, everything is normal, all clients participating, until right after slot 4967121 After that block is imported, block 4967102 appears (4 minutes late). This is the last block in epoch 155221, in slot 30, since the block in the next slot was never proposed (or seen). The block 4967102 has enough votes to justify 155221, this splits the view of the chain: those that have deployed the witholding fix (only prysm) will not see this block as head and continue to build on top of the canonical chain. Those that didn't deploy it yet will immediately reorg to this block. Lodestar proposes block 155224 on top of that block (the first block in the bottom branch) and from there on, Lighthouse, Teku and Nimbus follow.

2/11/2023
Capella interop, Prysm - Nethermind

Build Nethermind git clone --recursive -b feature/shanghai-eip-4895-withdrawals https://github.com/NethermindEth/nethermind.git cd nethermind/src/Nethermind dotnet build Nethermind.sln -c release export NETHERMIND=$(pwd)/Nethermind.Runner/bin/Release/net6.0 Build prysm git clone --recursive -b capella https://github.com/prysmaticlabs/prym.git cd prysm bazel build //cmd/beacon-chain

11/10/2022
Read more from potuz
Published on HackMD