Context
In a vanilla proof-of-stake blockchain, the block building process is comparatively simple. Users submit their transactions to a mempool, the consensus mechanism of the blockchain repeatedly selects random users to be block proposers, who collect some number of transactions from the pool and form the next blockchain block. With the rise of MEV, the block building pipeline has become significantly more complex.
Skimming over many details, we now effectively have a set of builders , a trusted intermediary party called the relay and the proposer. Each builder construct blocks and tells the proposer ``I will pay you amount of money, if you take my block and make it be the next block''. The proposer selects the highest bidder's block and constructs it.
Two things can go wrong here. A malicious proposer may see the builder’s block and instead of using the block as is, it may use it to construct their own block. A malicious builder may win the auction, but not provide the proposer with the block.
To avoid both of these issues, the relay acts as a trusted intermediary. The builder sends their bid, the block header (a state root, which does not contain the full transaction list), and the block payload. The relay forwards the bids along with the headers to the proposer, who signs the winning bid. The relay reveals the block payload upon receiving a signature (which effectively commits the proposer to the winning bidder’s block).
Open Research Questions
Several aspects of the workflow outlined above can be worth improving:
Removing the relay:
Having a trusted party facilitate the fair exchange is undesirable, as it introduces a single point of failure in the block building pipeline. A natural question to ask is whether one can get rid of the relay, while maintaining the desired functionality and security. An initial effort in this direction has recently been made via the use of an advanced cryptographic object known as silent threshold encryption (‣). Using silent threshold encryption seems like a promising approach, but several questions remain open.
The proposed construction requires validators to hold large amounts of non-standard key material. Can their construction be modified to be compatible with the current validator keys already deployed in Ethereum?
The proposed construction formally provides a rather weak notion of static security against classical adversary. Naturally, one can ask whether one can construct a silent threshold encryption scheme, which provides some form of adaptive security against quantum adversaries.
Efficiently agreeing on the winning bid:
Assuming the relay was no more, the builders and the proposer would need a way of determining the winning bid. A naive approach would be to let all builders send their bid to the proposer, but this would potentially open up a denial-of-service attack vector on the proposer. An alternative would be to let the builders perform a parallel broadcast to agree on the winner of the auction. Performing such a parallel broadcast comes with a price tag in terms of latency and communication complexity. A natural question is to explore whether the builders can determine the winner of the auction in a more communication efficient manner.
- one option is for proposer to be able to constantly update their view of the top bid (suggests protocol should also update continuously)
- another option is for the proposer to have a one off time when they can query the protocol (maybe less involved in this version)
Hiding the builders’ bids:
In the current design, each builder reveals their bid to the relay. This may leak unnecessary amounts of information with respect to the builders’ bidding strategies. From the builders’ perspective, it would be desirable to disclose a minimal amount of information, namely only the winner of the auction along with their bid. Thus the question is: Can the builders and the proposer engage in some form of multiparty computation to determine the winner of the bid efficiently, without revealing any of the losing bids? Can this be done with concretely minimal latency and good efficiency? A natural starting point for this, could be research on Yao’s millionaire problem (http://ia.cr/2024/005), which studies a highly related question.
Related Notes
FRP-48.md
flashbots
- EPBS proposal — https://eips.ethereum.org/EIPS/eip-7732
- ‣
