Blockchains typically have a leader that is responsible for both building and proposing blocks during their designated leader slot. These leaders have full control over which transactions to include in the block, and how to order those transactions. Prior to a rich ecosystem of applications, selecting transactions to include in a block trivial as that could be done by prioritizing by gas fees.
Given a now abundance of transactions that interact with many applications, significant value is being transacted with allows leaders to exploit their privileged position by extracting some of that value. Block producers do this through more complex mechanisms than the simple transaction prioritization by fee paid.
The naïve economics of MEV work similarly to that of validating in PoS or mining in PoW, such that they all benefit from economies of scale. Economies of scale allow operations to be more efficient at a larger scale as more value can be accrued and extracted because of the increased efficiency and scale. This creates a positive feedback loop that compounds and centralizes value creation and extraction, against the desired decentralization properties that are at the core of blockchain philosophy.
Proposer builder separation and crLists
Rather than attempt the impossible task of completely removing MEV from the protocol, blockchains should be built around MEV such that it has as few negative impacts on the system as possible. Proposer builder separation (PBS) aims to separate block building from block proposing. The block builders would be responsible for ordering the transactions of the block and presenting bids to the proposer. The rational proposer would likely pick the block that produces the most revenue for them.
The implication of PBS on Ethereum is that the builders would require higher-cost hardware (~$4000) and high bandwidth requirements that aren’t typically accessible at home, but is commonly provided in a data centre. The motivation behind PBS is that these “super builders” are likely to appear in a sharded chain regardless of block producer fragmentation — block producers would operate on many shards benefitted by economies of scale from MEV rather than only operating on a single shard. This reinforces the idea that elements on block production can be centralized with reduced negative impacts on the chain so long as there are sufficient censorship-resistant mechanics to make it possible.
One such mechanism that can increase censorship-resistance in the face of more centralized block builders is crLists. The proposers broadcast a list of transactions in the mempool that they think should be included by the block builders. The builders then propose a block body which the corresponding list and censorship can be determined if there was free blockspace that could have been allocated to eligible transactions in the mempool as specified by the proposer. While the implementation is more nuanced, the idea is that block proposers will be able to force transaction inclusion in the event of censorship by block builders.
Decentralization
Even in the presence of mechanics such as crLists that attempt to mitigate the negative impacts of centralization, that alone cannot absolve power from block builders.
Bitcoin is secure because end users can run an inexpensive node that contributes to the security of the network. For example, a full node can be run on a raspberry pi at a minimal cost. Full nodes provide security to the network because they fully validate the chain, which they can do without an honest majority assumption for state validity.
Light clients (Bitcoin SPV nodes) are an even more minimal node that only downloads and verifies the block header, rather than the entire block. However, they don’t contribute to the security of the network because they rely on an honest majority assumption for state validity. In the event the network is 51% attacked, full nodes can verify and reject invalid blocks, but light clients can’t, with full nodes having no mechanism by which to alert light clients of invalid blocks. In this case, the security of the network is dependent on users running full nodes to secure the network.
In a blockchain construction that provides consensus and data availability but doesn’t validate transactions, only accepts them from execution layers like rollups, block verification is reduced to only data availability verification. If light clients are given the ability to conduct data availability sampling with some fraud or validity proof scheme, these light clients (we’ll refer to as light nodes for distinction) can verify state validity without an honest majority assumption. Because of this, light nodes can now provide near-equal security to that of a full node with only minimal hardware requirements.
Now, a situation is borne whereby users only need to run minimal light nodes to ensure network security, rather than a full node, and decentralization isn’t solely dependent on users operating full nodes.
The scalability trilemma
Scalability has typically been a measurement for how efficient block producers are at processing transactions.
If throughput increases with a sub-linear increase in cost, then given a constant cost of hardware the block producer would be able to produce higher throughput, hence transaction scalability. However, blockchains are more than a distributed computing system.
If an increase in scalability is met with an equal increase in the cost to operate a node that verifies the chain, such as a full node, then scalability comes at the cost of a higher barrier to entry to hold block producers accountable. At its core, blockchains are resilient because of their ability for users to operate nodes that verify the chain and contribute to its security. An inability to operate a node that verifies the chain increases the trust that must be placed in the hands of block producers and other centralized entities, to the detriment of the system.
Therefore, scalability can be rewritten as
Since light nodes have sub-linear costs with respect to block size increases, under this paradigm a block size increase can be considered scaling.
As such, decentralization can also be adjusted from the number of full nodes to the number of light nodes in the network. Finally, the security guarantee provided by light nodes can be approximately modelled as
By increasing the number of light nodes, the block size can be increased proportionally while retaining the same security guarantees and level of decentralization. However, there is still a set of block producers that are responsible for downloading and propagating the entire block, so there is a limit that the block size will hit when bandwidth becomes a bottleneck. This can be alleviated with some type of sharding, such as node sharding, where the processes of a single node can be run on a cluster of machines.
Under this construction, there would also be some other assumptions made. To increase the block size a minimum number of light nodes is required such that enough samples being stored for the entire block to be reconstructed by full nodes. If the system uses a fraud proof scheme, there is also assumed to be one honest full node that can provide light nodes with the fraud proof.
Conclusion
Blockchains are a method by which trust can be distributed rather than removed. With the impending movement towards more centralized block production, a blockchain can only be as resilient as the number of users that are able to operate a secure node that can hold block producers accountable for malicious behavior. With key technologies such as data availability sampling and fraud/validity proofs, minimal light nodes can be created that have near-equal guarantees to that of a full node. Decentralization is also dependent on light nodes rather than full nodes. Finally, light nodes only experience sub-linear costs in relation to block size increases, enabling the block size to be increased without degrading network resilience.