This document contains my notes and some thoughts on Censorship resistance in Ethereum. Topics discussed here will be mainly based on the current PoS architecture and will not consider the PoW architecture. We will also consider mostly PBS(with trusted relays) and not enshrined PBS which is in a very early stage as of now.
I might have made some errors below, please do forgive my ignorance and do correct me where I went wrong
Ethereum is an immutable database which is populated when user transactions are commited to it. These user transactions can range from simple ethereum transfers to arbitrary code execution(smart contracts). User transactions are batched up into blocks which is added to chain when voted by more than 2/3rd of validators in the system.
In PoS, we have a proposer builder seperation model where we can treat the proposer and the builder seperately. This allows the proposer(i.e validator) to defer block building to external builders using a relay as a broker. Proposer's prefer transactions which give them the most value. They would prefer transactions from external builders who tend to be more sophisticated and also have private orderflows which opens them up to a market of searchers who bundle up very profitable transactions. This sophistication has decreased homestakers competitiveness in the builder market. The main competitiveness of homestakers is that they can propose blocks in a fast and reliable way. Using external relays can sometimes cause validators to publish late blocks if the there is high latency in the software or miss block production altogether if the relayer fails to give a block.
Below we attempt to describe how block builder competitiveness could have been reduced as the type of transactions in ethereum evolved.
As Ethereum evolved, the type of transactions had evolved too. From simple ethereum transfers, we soon had DeFi applications like AMMs, Lending markets, on-chain trading derivatives etc. This opened up various markets to buy tokens, to lend tokens, to borrow tokens, to auction liquidations etc. This opened up opportunities for block builders to arbitrage b/w AMMs, sandwich attacks etc. Now builders were incentivised to use sophisticated algorithms to re-order their tx mempools to gain the highest profit. If builders gained too much power, they could remove certain txs from the mempool which could potentially cause a loss to them, e.g a large dump of a token held by the builder in significant quantities. Builders started creating sophisticted algorithms to re-order the mempool to increase their profits. Not all builders were able to create these sophisticated algorithms. Through this a certain %ge of the builders became uncompetitive in the builder market.
With full danksharding coming up, a new tx type called blob transactions has been introduced. Blob txs contain objects called blobs which are just opaque binary data to the protocol. These binary data only mean anything to the sender of the tx. The senders will usually be rollups who will use blobs to store the batched up txs. Someone who want to send a fraud proof can pick up these blobs and create a fraud proof. Blobs are much cheaper than calldata. Blob txs also don't compete with regular txs for gas as they have their own seperate market. Full danksharding is bound to put a lot of strain on regular homestakers to build blocks as it increase n/w bandwidth requirements by a lot and also might involve expensive KZG commitment related computations. Through this a lot of homestakers end up becoming uncompetitive in the builder market.
According to rated, ~70% of external blocks built by ethereum is done by 3 builders. This is a lot of power to a few builders which can potentially bite the n/w back through censoring transactions, stopping the n/w by producing empty blocks, by removing regular txs from mempools and builders placing their own txs.
Censorship resistance is clearly an important problem which has to be solved for the health of the n/w.
Below, we will try to develop a few ways we can think of censorship and slowly try to develop the intuition as to why the market will get more and more centralized.
In the Ethereum n/w, blocks are broadcasted throughout the entire n/w to all the participants. Each participant applies the block to their current state to transition to the latest state. Applying a block means sequentially executing the transactions of the block. Note that the order is very important. If the orders are changed, then we can potentially get a different state i.e transaction execution in ethereum has to be deterministic.
So, how is the sequence of transaction determined?
It is whatever the block builder wants it to be! This flexibility in ordering the tx mempool how ever a block builder wants it allows block builder to remove certain txs and prioritise certain txs. As long as the final set of txs chosen by the block builder is sequentially applied to the state, it really doesn't matter how its chosen.
A proposer doesn't validate the quality of the transactions. The proposer just applies the txs sequentially and as long we generate the same state root as in the block header post applying of the txs, the proposer is happy.
Imagine, if ethereum had enforced a FIFO like tx mempool processing where each transaction has a uuid and if there was a gap in the tx uuid, the block producer would get penalized. Will censorship be possible in such a system?
If we assume the proposer and builder as 2 seperate entities in the blockspace market. We can define their roles as proposer being the one who is trying to sell blockspace and builder trying to bid for blockspace to get their built payloads in the block and earn their rewards for it. It is a capitalistic market of sorts where the various builder compete with each other to give the highest bid to the proposer. In this market a relay acts like a trusted broker b/w the builder and proposer. The relayer ensures that the blocks which are submitted by the builder are valid and the relayer also ensures that the proposer commits the particular block submitted by builder i.e it doesn't steal the transactions from the builder.
The relayer is not really responsible for examining the quality of the transactions submitted by the block builder, it is only responsible for ensuring the sanity of the block submitted.
Summary
In both the above 2 models to think of censorship, we can see how builders have most of the power in dictating the quality of transactions. And as we also explored above, as the protocol is evolving a lot of builders are loosing their competitiveness due to increasing demands from the protocol. We can easily visualize a builder market with a few players and a lot of power. We can end up with an dishonest minority group with a lot of power.
An important note is that, in an ideal case we assume that the proposers will be an honest majority since we should move in a direction where it ll be easy to become a proposer easily. And builders should be an honest minority since builders require more higher end machinery which ends up becoming an economy of scale.
In the above 2 sections, we have tried to slowly develop our intuition as to how the builder market can get centralized. In this section, we try to list down a few issues with a centralized builder market.
The following are design goals which we should consider when we are designing censorship resistant solutions:
1. Inclusion lists
Inclusions lists and partial block auction is an idea suggested in [2], [4] and [6] by Vitalik and Franceso from EF Research. The fundamental idea is that, the builder will not have a complete say in which txs will enter the block. The proposer will inform the builder of certain txs that they feel should be included in the block.
As suggested in [5], in a non-PBS world, we can have a scheme where proposer of slot n publishes a list to the p2p n/w and attestors of slot n+1 enforce the list for block proposed in slot n+1.
Vitalik Buterin suggests a similar idea in [9]. He adds the constraint of enforcing only 1 tx per sender in the inclusion list. The proposer publishes a crList summary of the txs which includes tx.sender, tx.gasLimit for every tx in the crList. The builder must include the cr list summary in their block. Validators can validate the block by checking if either the sender in the crlist has sent some other tx in the block or if block.gasUsed + tx.gasLimit > block.gasLimit.
Partial Block Auction
In [6], Franceso suggests splitting a block into priority and regular area, where the prioirity area can be built by the block builder and the regular area can be built by proposers. To acheive this, it is proposed to an in protocol definitions to priority transactions vs regular transactions. Priority txs would get executed in the first position of the block to extract priority MeV(which is MeV which gets extracted based on the previous block state).
Socializing the inclusion list
A proposer needs a good incentive to add a decent amount of txs to the inclusion list since a proposer will ideally want a block with large value. Since a builder will be better equipped to build more valuable blocks, a proposer could potentially send empty inclusion lists. We could mitigate this by having proposers not participating in block building propose an inclusion list a few slots prior which will be used by builders to build a block. But despite this, there is no real incentive for a proposer to put in the work to do this. A malicious validator could put a lot of invalid tx in the inclusion list which could potentially reduce the block rewards for the proposer.
One potential solution could be to have a socialized inclusion list mempool from which builders pick transactions to add(The question on why they will have to add the tx will be discussed in the next section). When blocks are proposed using these txs, the block rewards for these paricular txs can be socialized across the validators who have participated in adding txs to the socialized pool. This can potentially give incentives for validators to keep adding transactions to the socializing mempool every slot or so.
Enforcing a dynamic split of proposer and builder txs in a block in-protocol
The protocol could potentially enforce a dynamic split b/w proposer and builder txs in a block. The split %ge can be determined by various factors such as:
The proposer txs can be picked from a socialized mempool as discussed in the previous section. We can maintain a merkle tree of the mempool or some other cryptographic commitment. Builders will have to prove that they have included the transactions from the socialized mempool by providing some proofs. If they fail to provide valid proofs, they will be slashed.
By enforcing a split in-protocol, we can potentially reduce the capacity for censorship or bad acting.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe