尧图网站建设 
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让签名变成 VRFEIP-7998 的思路非常简洁不改变签名算法只改变签名的消息内容。改造后randao_reveal的签名消息从当前纪元编号变成一个新引入的 SSZ 容器RandaoRevealSeed其中包含上一纪元的最后一个 RANDAO mixprevious_mix类型Bytes32当前槽位号slot类型Slot。由于previous_mix要到上一纪元结束时才最终确定提议者无法提前计算未来纪元的 reveal由于slot参与签名同一纪元内多次出块的验证者也会产生不同的 reveal。这样一来randao_reveal就等价于一个Verifiable Random FunctionVRFVRF(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 numberprevious_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对这段代码的逐行解读获取纪元与提议者epoch get_current_epoch(state)得到当前纪元proposer state.validators[get_beacon_proposer_index(state)]拿到本区块提议者的验证者记录含公钥。分叉前后双轨逻辑若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域隔离签名用途保证该签名不会被复用到其他域。验证签名assert bls.Verify(proposer.pubkey, signing_root, body.randao_reveal)。由于消息不可预测提议者必须等到上一纪元结束、看到previous_mix之后才能真正完成签名。混入随机源保持原逻辑不变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_mixslot4.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.mdTx 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 输出。这一改动消除了 RANDAO bias 攻击向量为秘密提议者选举SSLE见 EIPS/eip-7441.md、EIPS/eip-7917.md铺平道路为依赖可验证随机性的下游协议提供随机源尤其是 EIPS/eip-7956.md 的区块级确定性交易排序保持与现有 BLS 基础设施、DOMAIN_RANDAO域隔离、randao_mixes历史向量结构完全兼容只需在FORK_EPOCH硬分叉点切换签名消息。从本仓库 EIPS/eip-7998.md 原文出发结合 EIP-7956、EIP-7441、EIP-7917、EIP-8321 等相邻提案可以清晰地看到一条演进主线以太坊正在把可预测的随机性一步步改造成真正的 VRF 随机性为更安全的提议者选举与更公平的交易排序生态奠定密码学基础。本文内容以 EIPS/eip-7998.mdStatus: Draft, Standards Track, Core创建于 2025-08-03为唯一事实主体涉及源码与相邻提案的引用均来自本仓库实际存在的文件版权声明遵循 LICENSE.mdCC0。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7998 深度解析：把 `randao_reveal` 改造成 BLS-VRF，为单秘密领导者选举与抗 MEV 随机性铺路
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让签名变成 VRFEIP-7998 的思路非常简洁不改变签名算法只改变签名的消息内容。改造后randao_reveal的签名消息从当前纪元编号变成一个新引入的 SSZ 容器RandaoRevealSeed其中包含上一纪元的最后一个 RANDAO mixprevious_mix类型Bytes32当前槽位号slot类型Slot。由于previous_mix要到上一纪元结束时才最终确定提议者无法提前计算未来纪元的 reveal由于slot参与签名同一纪元内多次出块的验证者也会产生不同的 reveal。这样一来randao_reveal就等价于一个Verifiable Random FunctionVRFVRF(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 numberprevious_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对这段代码的逐行解读获取纪元与提议者epoch get_current_epoch(state)得到当前纪元proposer state.validators[get_beacon_proposer_index(state)]拿到本区块提议者的验证者记录含公钥。分叉前后双轨逻辑若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域隔离签名用途保证该签名不会被复用到其他域。验证签名assert bls.Verify(proposer.pubkey, signing_root, body.randao_reveal)。由于消息不可预测提议者必须等到上一纪元结束、看到previous_mix之后才能真正完成签名。混入随机源保持原逻辑不变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_mixslot4.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.mdTx 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 输出。这一改动消除了 RANDAO bias 攻击向量为秘密提议者选举SSLE见 EIPS/eip-7441.md、EIPS/eip-7917.md铺平道路为依赖可验证随机性的下游协议提供随机源尤其是 EIPS/eip-7956.md 的区块级确定性交易排序保持与现有 BLS 基础设施、DOMAIN_RANDAO域隔离、randao_mixes历史向量结构完全兼容只需在FORK_EPOCH硬分叉点切换签名消息。从本仓库 EIPS/eip-7998.md 原文出发结合 EIP-7956、EIP-7441、EIP-7917、EIP-8321 等相邻提案可以清晰地看到一条演进主线以太坊正在把可预测的随机性一步步改造成真正的 VRF 随机性为更安全的提议者选举与更公平的交易排序生态奠定密码学基础。本文内容以 EIPS/eip-7998.mdStatus: Draft, Standards Track, Core创建于 2025-08-03为唯一事实主体涉及源码与相邻提案的引用均来自本仓库实际存在的文件版权声明遵循 LICENSE.mdCC0。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考