MEV-Boost, the current sidecar protocol for MEV extraction in Ethereum, relies heavily on centralized actors called relays.

We propose an alternative architecture that allows for direct, cryptographically private communication between builders and proposers. It is based on a novel, non-interactive form of “silent” threshold encryption that can use validators’ existing BLS keypairs.

Essentially, we piggyback on the attestation committee for privacy and data availability by threshold encrypting block proposals to a fraction of attesters for the slot. Their attestations form the decryption key; once the desired threshold has attested, the block can be decrypted.

Our construction addresses privacy between builders and proposers but does not alone guarantee block validity. It can be combined with other mechanisms to fully replicate the functionalities provided by relays—both privacy and block validity. For example, proof schemes like Trusted Execution Environment (TEE) proofs or Zero-Knowledge (ZK) proofs, or cryptoeconomic mechanisms to collateralize builders.

By removing the need for relays to provide builder privacy and ensure block validity, we aim to reduce latency and improve Ethereum’s decentralization and censorship resistance.

MEV-Boost and the Role of Relays

MEV-Boost is a sidecar protocol that intermediates between block builders and proposers. The main role of the relay is to provide two guarantees:

• Privacy for Builders: The relay ensures that proposers cannot see block contents and steal the MEV found by the builder.
• Safety for Proposers: The relay guarantees that the builder pays the value promised to the proposer in the builder’s bid and that the block is valid (e.g., all transactions pay intrinsic gas).

The reliance on relays, however, introduces significant centralization. Approximately 90% of blocks on Ethereum are delivered through just a handful of relays. This poses a few risks:

• Centralization: Builders can be latency-efficient by colocating with relays rather than reflecting the geographic distribution of proposers. This directly undermines the geographic decentralization and censorship resistance we would otherwise gain from a large, globally distributed validator set.
• Revenue: The average end-to-end block processing latency of efficient relays is around 5-20 milliseconds. Then, there is communication latency between the proposer and builder. Skipping relays will reduce latency, lower cross-domain execution risks (e.g. CEX/DEX), and ultimately increase proposers’ MEV rewards.

TEE-Boost

One of the leading proposals to replace relays is “TEE-Boost“, which relies on TEEs (Trusted Execution Environments). Note that TEEs are not essential to our scheme; it’s just helpful to use TEE-Boost as a pedagogical example of the problems we aim to solve.

Concretely, TEE-Boost has builders use TEEs to create proofs that demonstrate to proposers the honesty of their bids and the validity of their blocks without revealing the actual block contents to proposers. Proposers can check these proofs without running TEEs themselves on commodity hardware.

However, TEE-Boost has a data availability problem: builders only share TEE proofs and block headers with proposers, not the actual block contents,^[1] and may choose not to release the block contents even after the proposer signs the header (e.g., if market conditions change unfavorably). The suggested approaches to solving this DA problem are:

• [ ] TEE-Escrow: A TEE-escrow gets the block from the builder before the proposer signs it and releases it once they see the signed header.
• [ ] Data Availability Layers: Builders post encrypted block payloads to a Data Availability (DA) layer.

Both approaches have drawbacks. The TEE-escrow solution replicates centralizing latency dynamics similar to those of existing relays.^[2] Using an external DA layer introduces an extra-protocol assumption and bears the latency dynamics of that external protocol (which are also likely unfavorable).

1. Theoretically, if proposers also had access to TEEs, the builders could encrypt their blocks to a TEE run by the proposer. The proposer’s TEE would only decrypt the block after they had signed it. However, we think TEE-Boost doesn’t consider this design because it would require proposers (validators) to run TEEs. We want validators to be able to run on commodity hardware. ↩

2. The latency dynamic can be avoided if the proposers themselves run TEE-Escrow as a colocated sidecar to their validator node. However, again, we don’t want to make validators run TEEs. ↩

Threshold Cryptography to Achieve Builder Privacy

We propose an elegant solution to TEE-Boost’s DA problem: threshold encryption to the attester committee. Specifically, the builder threshold encrypts the block to a specified fraction of the attester committee for that slot. Once enough attestations are gathered, the block becomes decryptable and available.

The core enabling technology is Silent Threshold Encryption. This cryptographic technique allows threshold encryption without requiring an interactive Distributed Key Generation (DKG) setup phase, which previous constructions required. Instead, the joint public key is computed deterministically from the attester’s already-existing BLS public keys plus some “hints” (discussed later).

This achieves direct single-hop communication between the builder and validator with cryptographic privacy. The validators are not required to run TEEs themselves or to manage any new key material.

Mechanics:

The builder constructs a block and encrypts it to the attester committee.

The builder constructs a TEE proof demonstrating three things to the attester committee: that the bid is honest, the block is valid, and it is encrypted correctly.

The builder communicates the threshold encrypted block and the TEE proof (which includes the bid value) to the proposer.^[3]

The proposer signs the winning builder’s encrypted block and gossips this proposal to the validator set.

Once the specified fraction (e.g. n/2 or 2n/3) n-attester committee for the slot attests to the block, it is decrypted.

The decrypted block proceeds to finalization normally.

1. The effect on proposer bandwidth requirements would need to be studied. Low-bandwidth proposers could limit needs by verifying proofs before requesting the block body, or with other heuristic filtering and smart download techniques. This is an open question but seems probably no harder to solve than normal mempool gossip spam issues. ↩

Considerations

Performance

The performance characteristics of Silent Threshold Encryption are pretty favorable. Here

n is the maximum size of the committee that we wish to support and t is the threshold for decryption.

Both encryption and partial decryption are constant time. With a naive implementation, encryption takes <7 ms - and this can be parallelized. Partial decryption takes <1 ms.

The ciphertext size is a constant additive factor, 768 bytes, larger than the plaintext (for any n and t).

Aggregation of partial decryptions (i.e., decryption) depends on the size of the committee. With n=1024, a naive implementation takes <200ms. We expect that with n=128 (the size of the attestation committee for each slot), this will drop by a factor of 10 and that the implementation can be further optimized.

Importantly, encryption time is the key performance number to compare to relay latency. This is what the builder must compute in the “critical path” of block production. It’s lower than the existing relay’s block processing latency and avoids multi-hop communication.

Data Publication

Silent Threshold Encryption isn’t entirely free. It does require a common reference string of the form: (g,g^τ,g^τ2,…,g^τn−t), similar to what’s used for the KZG polynomial commitment scheme.

Additionally, every validator with a BLS public key of the form gsk publishes a set of group elements which we call “hints”: (g^sk⋅τ,…,g^sk⋅τn−t). These hints are only needed to aggregate public keys and to decrypt ciphertexts. Encryption only uses a constant-sized aggregated public key.

As of writing this post, there are approximately 1 million validators. If we set n=128 and t=n/2, each validator needs to post ≈ 3 KB of hints. Thus, storing the hints of all validators requires 3 GB.

This requirement will likely decrease substantially with the activation of MaxEB, which allows validators controlling >32 ETH to hold larger balances under the same keypair (rather than splitting them over multiple 32 ETH deposits). The reduction in the validator set that will be realized is up for debate. It seems possible that we could get down to ~1GB.

Lastly, depending on future changes to Ethereum’s consensus architecture (e.g. further reductions in the validator set size, or alternative finality pipelining) the size of the hints that must be stored could further decrease.

Liveness

Ethereum wants to remain live even under adverse network conditions. One issue with this scheme is the possibility of blocks that cannot be decrypted because the specified fraction of the committee is offline.

One solution is to allow the builder to decide on the acceptable fraction (𝑡) of the committee for decryption. There is a tradeoff between privacy (the possibility of unbundling and MEV-stealing) and the likelihood of the committee threshold being online. It’s revenue-maximizing for builders to get their blocks included, rather than forked out, so they should figure out an optimized threshold setting.^[4]

Additionally, usage of this encryption scheme should be opt-in. Under adverse network conditions, in which no acceptably-sized committee is available with any consistency, proposers and builders could fall back to using relays, self-building, or whatever other mechanism is preferable given the nature of the adverse environment.

1. The specific claim here is that it is negative EV for a builder’s block to get forked out (they recieve no revenue from it), and highly negative EV to get unbundled. If you give the builder the ability to pick t in [0,128], they should be naturally incentivized to select t high enough that there is very low risk of unbundling and high probability of being satisfied (at least t members of the committee being online). Some blocks would likely get forked out even under normal network conditions, but we’d note this already happens with timing games, and the liveness of the chain remains acceptable. ↩

Unavailable Blocks

Alternatively, the committee may be online, but a builder may be able to create a situation in which the block is either unable to be decrypted or invalid upon decryption (e.g., with fraudulent proofs).

From the protocol’s perspective, it’s fine to fork these blocks out. The broader validator set simply could not attest to them or to any blocks that reference them. The best way of handling this kind of error is likely to make the consensus client aware of the possibility and able to fail gracefully. Further study on exactly how would be needed.

Market Structure

The winning builder knows the contents of the block before others until the threshold is reached, which could create an unfair advantage in subsequent slots. However, the attester committee is supposed to act before the end of the next slot, and the majority of block value is at the end of the slot, so the effects of this advantage should be as nearly minimal as possible.

Purely Cryptographic Proofs

In the long term, it may be possible to replace TEE proofs with Zero-Knowledge (ZK) proofs. Currently, ZK proofs are too slow, but advancements in cryptography, software, and specialized hardware (ASICs) might eventually make ZK proof generation feasible within the necessary latency constraints. Notably, ZK proofs accompanying blocks are already a core part of Ethereum’s long-term roadmap.

Adoption

With the current validator set size and growth rate, this scheme may not be worth the amount of data required to be published on L1. However, Ethereum already plans to substantially reduce the validator set count with MaxEB.

The best approach would likely be an upgrade alongside or after MaxEB in which consensus clients are made aware of the possibility of encrypted block semantics and validators are encouraged to publish hints. For example, after MaxEB, it could be required that newly entering validators publish hints, and older validators could be given an incentive to upgrade.

Builders would begin to use the mechanism once a sufficient fraction of the validator set adopted it to have sufficient committee sizes (i.e., both acceptable privacy and likelihood of decryption).

If our approach does indeed have favorable latency relative to multi-hop relaying, the market should adopt it without the need for the protocol to enforce usage or enshrine a specific parameterization.

Rationale

Relays are one of Ethereum’s most significant sources of centralization, creating opportunities to rent-seek and distorting the protocol’s geographic decentralization.

We need to remove relays and think this is a relatively elegant way to do so. It requires changes at the consensus layer, but no new hardware or key material is required on the part of validators.

The downside is that it is a complex change to the consensus layer for a mechanism that (if opt-in, as suggested) may or may not be adopted by the market. However, many potential changes to the MEV pipeline bear similar adoption and revenue-optimality questions (e.g., inclusion lists). And there may be other future use cases that depend on the validator set having threshold encryption infrastructure available.

Disclaimer：

1. This article is reprinted from [paradigm]. All copyrights belong to the original author [Charlie NoyesGuru, Vamsi Policharla]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.