On December 31st, the Ethereum community proposed a new ETH2.0 sharding plan, and raised some issues related to the recent discussions of MEV. This scheme transforms the sharding design of block proposers with N different shards into another mode: there is already a block proposer in the beacon chain, and transactions are included in the execution load with sharded data. This simplifies the design significantly. The beacon chain block builder only needs to add one operation to its block, instead of introducing more block proposer entities and their associated committees into the combination.
The question turns into: What will happen to the memory pool in this case? Will the public memory pool expand to accommodate all these transactions of the block builder? Currently, flashbots helps to send transactions directly to the builder, thereby skipping the dark forest of memory pools. Once sharding appears, can we abandon the public memory pool completely because of scalability issues? The latest idea of ​​censorship resistance of the merged block proposer requires a public memory pool, and the performance of the memory pool in the post-sharding world should be benchmarked. In essence, Ethereum’s sharding research continues to improve, becoming more concise for client developers. Of course, there are still some unresolved issues in this new proposal.