企业官网建设流程全解析

EIP-7998 深度解析：把randao_reveal改造成 BLS-VRF，为单秘密领导者选举与抗 MEV 随机性铺路

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

本文以 EIPS/eip-7998.md 为主体，结合本仓库中与其直接关联的 EIP-7956、EIP-7441、EIP-7917、EIP-8321 等提案，系统讲解这一提案的动机、规范、设计取舍与安全分析。读完本文，你将理解当前以太坊信标链 RANDAO 随机源的可预测性问题，掌握RandaoRevealSeed容器与改造后process_randao的完整逻辑，并能说清该改动为何能让区块提议者产生"跨纪元不可预测、每槽唯一"的 VRF 输出，以及它如何支撑未来 SSLE（单秘密领导者选举）与确定性交易排序等下游协议。

一、背景：现行randao_reveal为什么"可预测"

在以太坊信标链的共识逻辑中，每个区块提议者需要在区块体中附带一个randao_reveal字段（类型为BLSSignature），信标状态转换函数process_randao负责验证该签名并把它"混入" RANDAO 随机源。相关数据结构在仓库中多处可见，例如 EIPS/eip-7732.md 中的randao_reveal: BLSSignature与randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR]，以及 EIPS/eip-8015.md 中的相同定义。

问题出在签名的消息内容上：现行规则下，提议者签的是当前纪元编号（epoch number）。纪元编号是全网公开、提前确定的整数，因此任何人都可以在纪元开始前预先计算出对应签名——提议者自己更是可以提前算出自己的randao_reveal。EIP-7998 开篇就点出这一缺陷："The currentrandao_revealis a BLS signature over the current epoch number, which is predictable."（当前randao_reveal是对当前纪元编号的 BLS 签名，它是可预测的。）

可预测的随机性会带来一系列后果：RANDAO 可以被"grinding"（通过挑选有利的 reveal 来偏向随机结果），RANDAO bias 攻击向量长期存在；同时，因为随机输出可被提前获知，也无法支撑需要"每个槽位有独立不可预测随机数"的协议。

二、提案核心思路：把签名消息换成RandaoRevealSeed，让签名变成 VRF

EIP-7998 的思路非常简洁：不改变签名算法，只改变签名的消息内容。改造后，randao_reveal的签名消息从"当前纪元编号"变成一个新引入的 SSZ 容器RandaoRevealSeed，其中包含：

• 上一纪元的最后一个 RANDAO mix（previous_mix，类型Bytes32）；
• 当前槽位号（slot，类型Slot）。

由于previous_mix要到上一纪元结束时才最终确定，提议者无法提前计算未来纪元的 reveal；由于slot参与签名，同一纪元内多次出块的验证者也会产生不同的 reveal。这样一来，randao_reveal就等价于一个Verifiable Random Function（VRF）：VRF(sk, message)，其中message就是RandaoRevealSeed的 SSZ 序列化结果，sk为验证者的 BLS 私钥。

为什么 BLS 签名天然可以当 VRF 用？EIP-7998 指出：在Computational Diffie-Hellman (CDH) 假设（而非 Decisional Diffie-Hellman 假设）下，把 BLS 签名当作 VRF 是可靠的；而且BLS 验证过程本身就证明了 VRF 输出的正确性，无需额外提供 proof——验证者用验证者的公钥验证签名，即同时验证了"这个随机输出确实由该私钥持有者产生且未被篡改"。签名输出（压缩格式下均匀分布的 G2 点）可直接视为一个伪随机数。

三、规范（Specification）逐项解读

3.1 新增 SSZ 容器RandaoRevealSeed

提案在分叉后引入一个新的 SSZContainer作为randao_reveal签名的消息：

class RandaoRevealSeed(Container): previous_mix: Bytes32 # last RANDAO mix of the previous epoch slot: Slot # current slot number

• previous_mix：上一纪元的最后一个 RANDAO mix，即get_randao_mix(state, previous_epoch)的返回值；
• slot：当前槽位号，即state.slot。

这两个字段共同决定了每个槽位的签名消息都是唯一的，且对未来不可预知。

3.2 修改后的process_randao

提案修改信标状态转换中的process_randao函数。设FORK_EPOCH为网络升级（硬分叉）发生的纪元，改造后逻辑如下（原文代码）：

def process_randao(state: BeaconState, body: BeaconBlockBody) -> None: epoch = get_current_epoch(state) # Verify RANDAO reveal proposer = state.validators[get_beacon_proposer_index(state)] if epoch < FORK_EPOCH: signing_root = compute_signing_root(epoch, get_domain(state, DOMAIN_RANDAO)) else: previous_epoch = get_previous_epoch(state) previous_mix = get_randao_mix(state, previous_epoch) seed = RandaoRevealSeed(previous_mix, state.slot) signing_root = compute_signing_root(seed, get_domain(state, DOMAIN_RANDAO)) assert bls.Verify(proposer.pubkey, signing_root, body.randao_reveal) # Mix in RANDAO reveal mix = xor(get_randao_mix(state, epoch), hash(body.randao_reveal)) state.randao_mixes[epoch % EPOCHS_PER_HISTORICAL_VECTOR] = mix

对这段代码的逐行解读：

1. 获取纪元与提议者：epoch = get_current_epoch(state)得到当前纪元；proposer = state.validators[get_beacon_proposer_index(state)]拿到本区块提议者的验证者记录（含公钥）。
2. 分叉前后双轨逻辑：
   • 若epoch < FORK_EPOCH（分叉前），保持旧规则：签名消息是epoch本身，compute_signing_root(epoch, get_domain(state, DOMAIN_RANDAO))。
   • 否则（分叉后），取previous_epoch = get_previous_epoch(state)与previous_mix = get_randao_mix(state, previous_epoch)，构造seed = RandaoRevealSeed(previous_mix, state.slot)，签名消息改为该容器的签名根。
   • 两种分支都使用DOMAIN_RANDAO域隔离签名用途，保证该签名不会被复用到其他域。
3. 验证签名：assert bls.Verify(proposer.pubkey, signing_root, body.randao_reveal)。由于消息不可预测，提议者必须等到上一纪元结束、看到previous_mix之后才能真正完成签名。
4. 混入随机源（保持原逻辑不变）：mix = xor(get_randao_mix(state, epoch), hash(body.randao_reveal))，把本次 reveal 的哈希与当前纪元 mix 异或后写入state.randao_mixes[epoch % EPOCHS_PER_HISTORICAL_VECTOR]。注意：RANDAO mix 的更新方式并未改变，改变的只是 reveal 的签名内容。

从仓库现状看，process_randao这一处理入口也是后续相关提案关注与修改的焦点。例如 EIPS/eip-8321.md 在process_randao中同样保留了randao_reveal的 BLS 验证分支与mix = xor(get_randao_mix(state, epoch), hash(body.randao_reveal))的混入逻辑（同时引入RandaoCommitmentRegistration作为过渡方案），可作为理解该函数在更长期演进中定位的参考。

四、设计动机（Rationale）：为什么选previous_mix+slot

4.1previous_mix：不可提前计算的关键

previous_mix是本提案的核心。因为上一纪元的最终 mix 要到该纪元结束时才被确定，提议者无法在纪元进行中提前算出未来纪元的randao_reveal。这直接抹掉了现行方案"提前算好、grinding"的空间。

4.2slot：保证每槽唯一

slot的加入保证每个槽位的 reveal 都是唯一的，且对其他验证者不可预测。原文特别指出：如果不加入slot，同一纪元内被选中出块多次的验证者会产出完全相同的 reveal——这对于需要"每次实例都有独立随机数"的协议（如 SSLE）是不可接受的。

4.3 备选方案：为什么不用"最新 mix"

提案也考虑过用最新（latest）的 RANDAO mix 而非上一纪元的 mix，以获得逐槽不可预测性。但这样做会引入**分叉歧义（fork ambiguity）**问题：一旦未来用randao_reveal实现 SSLE，依赖"最新 mix"会导致在分叉场景下对 reveal 合法性的判定产生分歧。因此最终选择previous_mix，以可预测性换取清晰的分叉语义。

五、下游协议：EIP-7956 如何消费这份"每槽随机性"

EIP-7998 的第二个直接受益者就是同仓库中的 EIPS/eip-7956.md（Tx Ordering via Block-level Randomness）。该提案在requires: 7998中显式依赖本提案，并定义：

R = body.randao_reveal[0:32] : bytes32

即把每个槽位的randao_reveal的前 32 字节作为槽级随机数R，用于对区块内交易做确定性排序：按主键H(tx) ⊕ R升序、次键H(tx)升序排列。EIP-7956 的安全分析里也多次引用本提案的成果："A block proposer can not change itsrandao_revealoutput after EIP-7998"——即改造后提议者无法再操纵 reveal 输出，从而压缩了 RANDAO bias 与基于重排序的 MEV 空间。可以说，EIP-7998 是 EIP-7956 所需"每槽新鲜随机性"的供给方。

六、更远的图景：SSLE 与秘密领导者选举

提案的动机之一是为**秘密提议者选举（SSLE）**铺路。仓库中相关的探索包括：

• EIPS/eip-7441.md：将区块提议者选举机制升级为 Whisk——一种单秘密领导者选举协议。该提案指出当前提议者公开预知，足以招致针对下一位提议者的顺序 DoS 攻击，而 SSLE 可让下一位提议者在出块前保持秘密。
• EIPS/eip-7917.md：在"Single Secret Leader Election Compatibility"小节讨论未来 SSLE 机制与proposer_lookahead字段的兼容方式。

而 EIP-7998 提供的"跨纪元不可预测、每槽唯一"的 VRF 输出，正是这类协议所依赖的随机性基石：它同时消除 RANDAO bias 攻击向量，并在未来启用 SSLE 时降低 MEV。这也是为什么 EIP-7998 在 Security Considerations 中强调：slot目前对 revealer 本身而言并不能带来逐槽不可预测性（只对其他验证者不可预测），但在未来实现秘密提议者选举和/或 EIP-7956 时会变得至关重要。

七、向后兼容性与激活方式

EIP-7998 明确这是一项破坏共识规则的向后不兼容改动，必须作为**计划中的网络升级（硬分叉）**激活：

• FORK_EPOCH之后产出的区块，若randao_reveal签名未使用新的RandaoRevealSeed结构，则SHALL 视为无效区块；
• 分叉前的区块继续按旧规则保持有效。

因此部署路径是：通过FORK_EPOCH这个常量配置触发规则切换，所有共识客户端在同一纪元同步升级，分叉点前后各按各的规则验证。

八、安全考量

8.1 VRF 安全性

将 BLS 签名用作 VRF，其安全性建立在目标群上的Computational Diffie-Hellman (CDH) 假设之上——这是标准密码学假设。签名输出（压缩格式下均匀分布的 G2 点）可当作伪随机数使用。BLS 的验证过程内在地证明 VRF 输出的正确性，无需额外 proof。

8.2 防 Grinding（无磨削元素）

randao_reveal是确定性的，无法被操纵：它必须用验证者对应的私钥计算，并通过公钥验证。提案明确断言"There are no grindable elements"——不存在可被磨削的输入自由度。

8.3 逐槽不可预测性的边界

提案诚实地区分了两类不可预测性：

• 对其他验证者：加入slot后，每个槽位的 reveal 对他们而言是不可预测的；
• 对revealer（提议者本人）：由于previous_mix在上一纪元结束时已确定，提议者在签名时刻其实是知道消息内容的，因此当前阶段并不能做到对 revealer 本人的逐槽不可预测。

这一点在当下是"多余的"，但在未来实现秘密提议者选举与 EIP-7956 时将成为关键。它不影响当前安全性，却为后续协议预留了正确的随机性语义。

九、总结

EIP-7998 用最小的改动——只改签名的消息，不改签名算法、不改 RANDAO 混入逻辑——把randao_reveal从"可提前预测的纪元编号签名"升级为"跨纪元不可预测、每槽唯一、可公开验证"的 BLS-VRF 输出。这一改动：

1. 消除了 RANDAO bias 攻击向量，为秘密提议者选举（SSLE，见 EIPS/eip-7441.md、EIPS/eip-7917.md）铺平道路；
2. 为依赖可验证随机性的下游协议提供随机源，尤其是 EIPS/eip-7956.md 的区块级确定性交易排序；
3. 保持与现有 BLS 基础设施、DOMAIN_RANDAO域隔离、randao_mixes历史向量结构完全兼容，只需在FORK_EPOCH硬分叉点切换签名消息。

从本仓库 EIPS/eip-7998.md 原文出发，结合 EIP-7956、EIP-7441、EIP-7917、EIP-8321 等相邻提案，可以清晰地看到一条演进主线：以太坊正在把"可预测的随机性"一步步改造成"真正的 VRF 随机性"，为更安全的提议者选举与更公平的交易排序生态奠定密码学基础。

本文内容以 EIPS/eip-7998.md（Status: Draft, Standards Track, Core，创建于 2025-08-03）为唯一事实主体，涉及源码与相邻提案的引用均来自本仓库实际存在的文件，版权声明遵循 LICENSE.md（CC0）。

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs