How to remove Relay

MEV-Boost is a sidecar protocol for extracting MEV in the current ETH network, heavily relying on a centralized participant called Relay. We propose an alternative architecture that allows for direct, cryptographically private communication between builders and proposers. This architecture is based on a novel non-interactive 'silent' threshold encryption form that can be used with the existing BLSSecret Key of validators.

Essentially, we propose the use of threshold encryption Block, which is sent to a subset of participants, to achieve privacy and data availability through the proof committee. Their proofs form a decryption Secret Key; once the required threshold is reached, the Block can be decrypted.

Our construction plan solves the privacy issue between builders and proposers, but alone cannot guarantee the validity of the Block. It can be combined with other mechanisms to fully replicate the functionality provided by Relay, including privacy and block validity. For example, trusted execution environment (TEE) proof or zero-knowledge (ZK) proof can be used, or builders can be guaranteed through encryption economic mechanisms.

By eliminating the need for Relay providers to provide privacy for builders and ensuring the validity of Blocks, we aim to reduce latency, improve the Decentralization and anti-censorship capabilities of Ethereum.

The role of MEV-Boost and Relay

MEV-Boost is a sidecar protocol that serves as an intermediary between block builders and proposers. The main role of the Relay is to provide two guarantees: 01928374656574839201.

Builder Privacy: Relay ensures that proposers cannot see the content of the Block, nor can they steal the MEV found by the builders.
Proposal Security: The Relay ensures that the builder pays the promised value to the proposer according to their bid and ensures that the Block is valid (e.g., all transaction fees pay intrinsic gas).

However, the reliance on Relay introduces significant centralization. Approximately 90% of ETH blockchain blocks pass through only a few Relays. This brings several risks:

Centralization: Builders can improve latency efficiency by deploying together with Relay instead of reflecting the geographical distribution of proposers. This directly weakens the geographical decentralization and censorship resistance that we could have obtained from a globally distributed validators set.
Income: The average end-to-end block processing latency of efficient Relay is about 5-20 milliseconds. In addition, there is also communication latency between builders and proposers. Skipping Relay will reduce latency, drop cross-chain execution risks (such as CEX/DEX), and ultimately increase proposers' MEV rewards.

TEE-Boost

One of the main proposals to replace Relay is "TEE-Boost", which relies on Trusted Execution Environments (TEEs). It is important to note that TEEs are not the core of our solution; using TEE-Boost as a teaching example for the problem we aim to solve is very helpful.

Specifically, TEE-Boost requires builders to use TEEs to create proofs that demonstrate the honesty of their bids and the validity of the Block to the proposer, without revealing the actual content of the Block to the proposer. The proposer can verify these proofs on regular hardware without having to run the TEEs themselves.

However, TEE-Boost has data availability issues: builders only share TEE proofs and Block headers with proposers, but not the actual content of the Block[1], and may choose not to release the Block content after the proposer signs the header (for example, if market conditions change unfavorably). Suggestions for addressing this data availability issue include:

TEE-Custody: TEE-Custody obtains the Block from the builder before the proposer signs it, and releases the Block after seeing the signature header.

Data Availability Layer: Builders publish the encrypted Block payload to the Data Availability (DA) layer.

Both of these methods have their drawbacks. The TEE-custody solution replicates a centralized latency dynamic similar to the existing Relay[2]. If an external DA layer is used, additional protocol assumptions will be introduced and the dynamic latency of this external protocol will be borne (which may also be disadvantageous).

In theory, if the proposer can also access TEEs, the builder can Blockencryption it to the TEE run by the proposer. The proposer's TEE will only decrypt the Block after signing. However, we believe that TEE-Boost did not consider this design, as it would require proposers (validators) to run TEEs. We hope that validators can run on ordinary hardware. ↩
If the proposer deploys TEE custody as a sidecar operation with its validators Node, it can avoid the latency movement.

However, we also do not want to enable validators to run TEEs. ↩

Threshold cryptography to achieve builder privacy

We have proposed an elegant solution to address the data availability issue of TEE-Boost: threshold encryption of the Block to the designated proportion of the verification committee for the time slot. Once enough attestations are collected, the Block can be decrypted and made available.

The core enabling technology is threshold encryption. This cryptographic technology allows for threshold encryption without the need for a prior interactive distributed Secret Key Generation (DKG) setup phase. Instead, the joint Public Key is deterministically computed based on the existing BLSPublic Key of validators and some "hints" (discussed later).

This achieves direct point-to-point communication between builders and validators, with cryptographic privacy. Validators do not need to run their own TEEs or manage any new Secret Key material.

Mechanism:

The builder builds a block and encrypts it to the validation committee.

The builder constructs a TEE proof to prove three aspects to the verification committee: the bid is honest, Block is valid, and encryption is correct.

Builders transmit the threshold encryption Block and TEE proof (including the bid value) to the proposer.[3]

The proposer signs the encryption Block constructed by the winning builder and spreads the proposal to the set of validators.

Once a validation committee with a specified proportion (e.g., n/2 or 2n/3) is designated to authenticate the Block, it will be decrypted.

The decrypted Block will proceed with final confirmation as normal.

The impact of the proposer's bandwidth requirements needs to be studied. Proposers with low bandwidth can limit their demand by conducting proof of validation before requesting the block body or adopting other heuristic filtering and intelligent download techniques. This is an open question, but solving it seems no more difficult than addressing the issue of spam propagation in a normal mempool. ↩

Notes

Performance

The performance characteristics of silent threshold encryption are quite favorable. Here, n is the maximum size of the committee we wish to support, and t is the threshold for decryption.

The time for encryption and partial decryption is constant. Using a simple implementation, encryption takes less than 7 milliseconds and can be parallelized. Partial decryption takes less than 1 millisecond.

Ciphertext is 768 bytes larger than Plaintext, which is a constant additional factor (for any n and t).

Partial decryption aggregation (i.e., decryption) depends on the size of the committee. When n=1024, the simple implementation takes less than 200 milliseconds. We expect that when n=128 (the size of the authentication committee per timeslot), this time will be reduced by 10 times, and the implementation can be further optimized.

It is important that the encryption time is a key performance indicator compared to Relay latency. This is something builders must calculate in the "critical path" of Block generation. This time is lower than the existing Relay's Block processing latency and avoids multi-hop communication.

Data Release

The silent threshold encryption is not completely free. It does require a common reference string, in the form of: (g, gτ, gτ², …, gτⁿ⁻ᵗ), similar to the content used for the KZG polynomial commitment scheme.

In addition, each validators with the form g⁽ˢᵏ⁾ BLSPublic Key publishes a set of group elements we call "hints": (g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ). These hints are only required when aggregating Public Key and decrypting Ciphertext. encryption only uses a constant size of aggregated Public Key.

As of the time of writing this article, there are approximately 1 million validators. If we set n=128 and t=n/2, each validator needs to publish about 3KB of hints. Therefore, storing all the hints from validators requires 3GB of space.

With the activation of MaxEB, this requirement may significantly drop, allow controlling validators holding more than 32 ETH under the same Secret Key to hold a larger balance (instead of dispersing it to multiple 32 ETH deposits) MaxEB allows. The reduction of the implemented validators set still needs to be discussed. We may drop to about 1GB.

Finally, based on the future changes in the Ethereum Consensus architecture (e.g., further reduction of the validators' set size or replacement of the finality pipeline), the required hint size may be further reduced.

Vitality

ETH hopes to remain online under unfavorable network conditions. One issue with this approach is that due to a specified proportion of the committee being offline, there may be Blocks that cannot be decrypted.

One solution is to allow builders to determine the acceptable committee ratio (t) for decryption. There is a trade-off between privacy (potential for unpacking and MEV theft) and the probability of committee threshold online. For builders, maximizing income is to have their block included in the chain rather than forked, so they should find an optimized threshold setting.[4]

In addition, the use of this encryption scheme should be voluntary. Under adverse network conditions, if there is no committee of an acceptable scale that can remain online continuously, the proposer and builder can fall back to using Relay, self-construction, or other mechanisms chosen based on the nature of the adverse environment.

Specifically, the expected value of a builder's Block being forked is negative (they don't receive any income from it), while the expected value of being unpacked is very negative. If builders are allowed to choose t between [0, 128], they should naturally be incentivized to choose a high enough t to drop the risk of unpacking and increase the probability of being satisfied (at least t committee members online). Under normal network conditions, some Blocks may be forked, but we note that this has already occurred in a time game, and the liveness of the chain remains acceptable. ↩

Unavailable block

In addition, the committee may be online, but the builder may be able to create a situation where the Block cannot be decrypted or is invalid when decrypted (for example, using fraudulent proofs).

From the perspective of protocol, it is possible to fork out these Blocks. A broader set of validators simply cannot prove such Blocks or any Blocks referring to them. The best way to handle this error may be to make the Consensus client aware of this possibility and able to fail gracefully. Further research is needed on this.

Market Structure

Winning builders know the content of the Block before reaching the threshold, which may result in unfair advantages in subsequent periods. However, the proof committee should take action before the end of the next period, and most of the value of the Block is concentrated at the end of the period, so the impact of this advantage should be minimized as much as possible.

Pure Cryptographic Proof

In the long run, there may be an opportunity to replace TEE proof with Zero-Knowledge Proof (ZK proof). Currently, the speed of ZK proof is too slow, but progress in cryptography, software, and application-specific integrated circuits (ASICs) may eventually make it feasible to generate ZK proof within the necessary latency limits. It is worth noting that ZK proof has already become a core part of Ethereum's long-term roadmap with Block. ETH's VitalikButerin stated.

Adopt

Based on the current scale and growth rate of validators, this solution may not be worth the amount of data required to be published on L1. However, Ethereum has already planned to significantly reduce the number of validators through MaxEB.

The best approach may be to upgrade before or after MaxEB, enabling the Consensus client to be aware of the possibility of the encryptionBlock semantics and encouraging validators to issue alerts. For example, after MaxEB, new validators can be required to issue alerts, while existing validators can be incentivized to upgrade.

Once a sufficient proportion of validators adopt this mechanism, builders will start using it to ensure a sufficient committee size (i.e., balancing privacy and possibility of decryption).

If our method is indeed superior to multihop forwarding in terms of latency, the market should adopt it spontaneously without the protocol being forced to use or specify specific parameter settings.

Basic Principles

Relay is one of the most important centralized sources of Ethereum, leading to rent-seeking opportunities and distorting the geographical Decentralization of the protocol. We need to remove Relay and consider it a relatively elegant solution. It requires changes to the consensus layer, but validators do not need to provide new hardware or Secret Key materials.

The downside is that this is a complex change to the consensus layer, and this mechanism (if selectively adopted as suggested) may or may not be accepted by the market. However, many potential MEV pipeline changes also face similar adoption and profit optimization issues (e.g., including the list). In addition, future use cases may depend on validators having a threshold encryption infrastructure.

Statement:

This article is reproduced from [paradigm]，著作权归属原作者[Charlie NoyesGuru, Vamsi Policharla]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
The other language versions of the article are translated by the Gate Learn team, and may not be copied, disseminated, or plagiarized without mentioning [Gate.io].