EIP-7804 深度解读基于执行请求的验证者提款凭证更新机制【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-7804Withdrawal Credential Update Request提出了一种全新的协议机制允许验证者Validator通过执行层Execution Layer发起的新型执行请求类型0x03来更新自己的提款凭证Withdrawal Credentials包括更换执行地址以及在0x01ETH1 地址型与0x02复利型两种凭证前缀之间切换。本文将以 EIPS/eip-7804.md 为骨架结合仓库中 EIPS/eip-7685.md通用执行请求框架、EIPS/eip-7002.md执行层触发的提款请求与 EIPS/eip-7251.md复利凭证与合并请求等关联规范完整剖析其设计动机、执行层/共识层规范、授权模型与安全考量帮助读者理解提款凭证可更新对质押生态带来的能力变化。为什么需要更新提款凭证从 Capella 到 Electra 的能力缺口Capella 引入的一次性提款凭证以太坊在 Capella 升级中引入了 BLS 提款凭证0x00向执行地址凭证0x01的单向、一次性迁移能力。但自那时起社区最常被问到的问题之一就是提款凭证未来还能再改吗无论是出于安全目的例如凭证轮换、冷钱包密钥泄露后的应急处理还是为了探索新的质押管理方式例如将合约地址设为凭证都天然存在更改提款凭证的需求。EIP-7804 的动机部分明确指出当初未提供该选项的核心原因在于技术复杂度在执行层Execution Layer与共识层Consensus Layer之间建立这样一条通信通道非常复杂——这一点可以从 Eth1 桥Eth1 bridge的历史经验中得到印证。Electra 执行请求打开新的大门转折点出现在 Electra 升级。协议引入了执行请求Execution Requests体系——存款deposits、提款withdrawals和合并consolidations——并在此基础上建立了通用执行请求框架 EIP-7685大幅降低了从执行层向共识层新增一种请求的复杂度。执行请求在执行层创建的特性为验证者管理方式带来了全新可能执行请求可以通过智能合约创建从而探索去中心化、链上的管理机制验证者可以在执行地址凭证0x01与复利凭证0x02由 EIP-7251 引入之间迁移同时遵循质押总量相关的正确变更速率churn约束。当前设计对 EOA 凭证验证者的限制要让一条执行请求在共识层获得授权验证者的提款凭证必须与 EVM 处理交易时的msg.caller一致。这意味着验证者的提款凭证必须是创建请求的智能合约地址而非交易发送者的地址或者该合约需要使用DELEGATECALL确保CALLER地址与验证者提款凭证中的地址一致已使用合约地址作为提款凭证的验证者可以通过更新自身合约来满足这一要求前提是合约可升级。问题在于目前提款凭证设置为 EOA 账户的存量验证者将永远无法借助智能合约创建执行请求因为现有设计不允许这些凭证被更改。EIP-7804 正是要打破这一僵局——允许验证者更新提款凭证意味着他们可以自由选择加入或退出不同的质押管理方案与策略从而促进质押领域的实验与创新。在 EIP-7804 之前唯一的替代方案是退出当前验证者再以新的提款凭证重新创建一个验证者成本极高。请求格式类型0x03的执行请求EIP-7685 请求框架回顾要理解 EIP-7804 的请求格式必须先了解 EIP-7685 定义的通用请求模型。EIP-7685 规定一个requests对象由一个request_type字节作为前缀后接不透明的字节数组request_datarequests request_type request_data其中request_data包含零个或多个编码后的请求对象每种请求类型自行定义其request_data格式。同时EIP-7685 在执行区块头中新增了一个 32 字节的承诺值requests_hash其计算方式是对块请求列表中所有非空请求元素按request_type升序排列后逐一做 sha256 哈希再对中间哈希列表做 sha256def compute_requests_hash(block_requests: Sequence[bytes]): m sha256() for r in block_requests: if len(r) 1: m.update(sha256(r).digest()) return m.digest() block.header.requests_hash compute_requests_hash(requests)这正是 EIP-7804 中0x03类型请求所依附的传输与承诺机制请求由执行层产生最终暴露给共识层处理。0x03 请求的三个字段EIP-7804 定义的新型提款凭证更新请求是 EIP-7685 请求类型前缀为0x03由以下字段组成pubkeyBytes48—— 待更新凭证的验证者公钥old_addressBytes20—— 旧的执行地址请求契约会将其设置为msg.callernew_addressBytes20—— 新的执行地址。其 EIP-7685 编码计算方式如下request_type WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_TYPE request_data read_withdrawal_credential_update_requests()即类型字节为0x03request_data由系统调用返回的请求列表编码得到。执行层规范预部署契约与块处理流程配置常量一览EIP-7804 的执行层配置参数如下表所示| 名称 | 值 | 说明 | | - | - | - | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_PREDEPLOY_ADDRESS|0x09Fc772D0857550724b07B850a4323f39112aAaA| 提款凭证更新机制的调用与状态存储地址 | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_TYPE|0x03| EIP-7685 类型前缀 | |SYSTEM_ADDRESS|0xfffffffffffffffffffffffffffffffffffffffe| 用于在契约上触发系统操作的地址 | |EXCESS_WITHDRAWAL_CREDENTIALS_UPDATE_REQUESTS_STORAGE_SLOT| 0 | 超额请求计数存储槽 | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_COUNT_STORAGE_SLOT| 1 | 请求计数存储槽 | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_QUEUE_HEAD_STORAGE_SLOT| 2 | 请求消息队列头指针 | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_QUEUE_TAIL_STORAGE_SLOT| 3 | 请求消息队列尾指针 | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_QUEUE_STORAGE_OFFSET| 4 | 链上请求消息队列的起始存储槽 | |MAX_WITHDRAWAL_CREDENTIALS_UPDATE_REQUESTS_PER_BLOCK| 4 | 每个区块最多出队dequeue的请求数 | |TARGET_WITHDRAWAL_CREDENTIALS_UPDATE_REQUESTS_PER_BLOCK| 1 | 目标请求数 | |MIN_WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_FEE| 1 | 最小请求费用 | |WITHDRAWAL_CREDENTIALS_UPDATE_REQUEST_FEE_UPDATE_FRACTION| 17 | 费用更新分数 | |EXCESS_INHIBITOR|2**256-1| 首次系统调用前用于计算费用的超额值 |值得说明的是这套参数结构与 EIP-70020x01提款请求和 EIP-72510x02合并请求的配置保持高度一致都采用存储槽 0~3 管理超额值/计数/队头/队尾、槽 4 起存放队列数据的布局并通过EXCESS_INHIBITOR抑制首次系统调用前的费用计算。EIP-7804 在此基础上调整了每块最大出队数4高于合并请求的 2与目标数1。另外规范中还定义了激活时间常量FORK_TIMESTAMP值标注为TBD用于主网并定义FORK_BLOCK为区块链中timestamp大于或等于FORK_TIMESTAMP的第一个区块。预部署契约的三条代码路径提款凭证更新请求契约与其他执行请求契约Deposits、Withdrawals、Consolidation类似共包含三条代码路径可概括为添加请求Add request要求输入恰好为68字节——验证者公钥48 字节拼接新的提款凭证地址20 字节超额请求读取器Excess requests getter当输入长度为零时返回当前超额请求计数系统处理System process当由系统地址调用时从队列中弹出当前区块的提款凭证更新请求。对比 EIP-7002 的提款请求契约56 字节输入 48 字节公钥 8 字节大端uint64金额以及 EIP-7251 的合并请求契约96 字节输入 源验证者公钥 48 字节 目标验证者公钥 48 字节可以看到 EIP-7804 的 68 字节输入中少了金额字段、多了新旧地址字段反映了凭证更新这一操作不涉及金额转移的本质。注EIP-7804 当前仍为 Draft 状态规范中以注释形式保留了 TODO——add sudo code / bytecode / deployment / etc (very similar to existing request contracts)即契约的伪代码、字节码与部署细节将参照现有请求契约可参考 EIPS/eip-7002.md 中完整的汇编字节码与反推部署交易示例补齐。区块处理末尾系统调用在block.timestamp FORK_TIMESTAMP的任意执行区块处理结束时即处理完所有交易并完成区块体请求验证之后客户端软件必须以SYSTEM_ADDRESS身份、携带空输入数据调用该预部署契约以触发系统子例程执行。调用返回的响应将按照 EIP-7685 被当作新的请求类型0x03处理。这一区块末尾系统调用模式与 EIP-7002 完全同构——EIP-7002 明确规定系统调用拥有 3000 万专用 gas 上限、不计入区块总体 gas、不遵循 EIP-1559 费用销毁语义调用不转移任何价值、且若预部署地址无代码或调用失败则区块必须被标记为无效。可以推断 EIP-7804 的0x03系统调用将沿用这些规则尽管正式规范尚未完整写出。区块验证承诺哈希一致性执行层必须检查执行区块头中的承诺哈希与共识层在验证执行区块时发送的执行请求列表包含新定义的0x03类型请求的哈希是否一致。这是 EIP-7685requests_hash机制对新增请求类型的直接延伸保证执行层与共识层对本块产生了哪些请求达成一致。共识层规范从请求到凭证更新的处理链EIP-7804 的共识层部分同样标注为TODO但给出了明确的变更概要新增容器WithdrawalCredentialUpdateRequest区块处理新增方法process_withdrawal_credential_update_request信标状态Beacon State新增变更方法update_withdrawal_credentials。请求容器class WithdrawalCredentialUpdateRequest(Container): validator_pubkey: BLSPubkey old_address: ExecutionAddress # request contract will set this to msg.caller new_address: ExecutionAddress注意old_address的注释——该字段并非验证者自行声明而是由请求契约在执行层设置为msg.caller即实际调用方地址共识层据此完成授权校验。请求处理函数def process_withdrawal_credential_update_request(state: BeaconState, withdrawal_credentials_update_requests: WithdrawalCredentialUpdateRequest) - None: validator_pubkeys [v.pubkey for v in state.validators] # Verify pubkey exists request_pubkey withdrawal_credentials_update_requests.validator_pubkey if request_pubkey not in validator_pubkeys: return index ValidatorIndex(validator_pubkeys.index(request_pubkey)) validator state.validators[index] # Verify withdrawal credentials has_correct_credential has_execution_withdrawal_credential(validator) is_correct_old_address ( validator.withdrawal_credentials[12:] withdrawal_credentials_update_requests.old_address ) if not (has_correct_credential and is_correct_old_address): return credential_type withdrawal_credentials_update_requests.type is_eth1_type credential_type ETH1_ADDRESS_WITHDRAWAL_PREFIX is_compounding_type credential_type COMPOUNDING_WITHDRAWAL_PREFIX # Verify valid type if not (is_eth1_type or is_compounding_type): return; update_withdrawal_credentials(state, index, credential_type, withdrawal_credentials_update_requests.new_address)该函数的关键特征在于静默失败语义与来自执行层的存款请求类似验证失败公钥不存在、凭证不匹配、类型不合法时函数直接return而不会使区块失败。处理流程依次为校验请求中的公钥存在于验证者集合中校验验证者当前持有执行型提款凭证has_execution_withdrawal_credential且凭证中的地址withdrawal_credentials[12:]与请求中的old_address一致——这是核心授权校验校验目标凭证类型必须是ETH1_ADDRESS_WITHDRAWAL_PREFIX0x01或COMPOUNDING_WITHDRAWAL_PREFIX0x02由 EIP-7251 定义通过全部校验后调用update_withdrawal_credentials更新状态。值得指出的草稿瑕疵容器定义只含validator_pubkey、old_address、new_address三个字段但处理函数中引用了withdrawal_credentials_update_requests.type这一未定义字段。从上下文可以推断设计意图是依据new_address或独立类型字段判断目标凭证类型这是该 Draft 规范后续需要澄清与修正之处。状态变更函数def update_withdrawal_credentials(state: BeaconState, index: ValidatorIndex, new_credential_type: Bytes1, new_withdrawal_credentials: ExecutionAddress) - None: old_credential_type validator.withdrawal_credentials[:1] validator state.validators[index] validator.withdrawal_credentials ( new_credential_type b\x00 * 11 new_withdrawal_credentials ) # If moving from 0x01 to 0x02 if (old_credential_type ETH1_ADDRESS_WITHDRAWAL_PREFIX and new_credential_type COMPOUNDING_WITHDRAWAL_PREFIX) { #TODO: in this case we need to ensure we put them through the churn/likely re-using some of the exiting rules switch_to_compounding_validator(state, index) }该函数将验证者的提款凭证重写为new_credential_type 11 个零字节 new_withdrawal_credentials的标准 32 字节结构。特别地当验证者从0x01迁移到0x02复利型时需要确保其经过合理的变更速率churn约束规范注释指出这很可能需要复用现有的退出规则——这一点与 EIP-7251 中普通余额向 2048 ETH 最大有效余额靠拢须遵循变更速率的设计一脉相承。授权模型谁有权更新提款凭证EIP-7804 的授权模型建立在执行层消息发送者即凭证所有者的等价性之上与 EIP-7002 的安全模型保持一致——EIP-7002 明确说明系统契约使用 EVMCALLER操作Solidity 的msg.sender作为目标地址即调用系统契约的地址必须与信标状态中记录的0x01提款凭证匹配。映射到 EIP-7804 上若验证者的提款凭证是 EOA 地址则必须由该 EOA 直接调用预部署契约或由DELEGATECALL语义保证CALLER为该地址若验证者的提款凭证是合约地址则该合约调用预部署契约时msg.caller即合约自身地址与凭证匹配天然具备授权资格因此EIP-7804 的落地将直接解锁此前被锁死的场景以 EOA 为提款凭证的验证者终于可以通过更新凭证把自己的验证者接入智能合约管理的各类新方案。与现有执行请求家族的横向对比当前协议中已存在/提出的 EIP-7685 执行请求类型可汇总如下| 类型 | 来源规范 | 用途 | 关键字段 | | - | - | - | - | |0x00| EIP-6110 | 存款请求 | 公钥、凭证、金额、签名 | |0x01| EIP-7002 | 提款/退出请求 | 源地址、公钥、金额 | |0x02| EIP-7251 | 合并请求 | 源地址、源公钥、目标公钥 | |0x03| EIP-7804 | 提款凭证更新请求 | 公钥、旧地址、新地址 |EIP-7804 位于这条请求家族链的末端为上述请求提供前置能力只有凭证可更新验证者才能自由地在 EOA 管理、合约托管、复利型等不同质押方案之间迁移。它也顺应了 EIP-7251 所倡导的方向——提高质押管理的灵活性更大的有效余额、复利奖励、更灵活的质押增量而凭证更新正是这种灵活性在身份层的延伸。安全考虑EIP-7804 的安全分析围绕所有权定义展开所有权的界定基于对提款凭证账户的控制——对于 EOA 账户即持有私钥对于智能合约即控制该地址上的合约。因此允许凭证更新本身不应带来新的安全影响只有当前凭证的合法控制者才能发起更新请求这一前提由共识层对old_address与验证者当前凭证的严格比对来保证。不过规范明确声明Further discussion needed需要进一步讨论安全分析尚未完成。可以预见围绕0x01 → 0x02迁移的变更速率约束、费用机制的滥用防护参照 EIP-7002 的 EIP-1559 式动态费用防 griefing 设计、以及旧凭证泄露后的轮换时效性等问题都将是后续讨论的重点。现状与后续工作截至本仓库收录的版本EIP-7804 处于Draft状态status: Draft创建于 2024-10-31作者为 Lucas Saldanha 与 Mikhail Kalinin。规范的以下部分仍标注为 TODO读者在跟进该提案时需重点关注执行层契约的伪代码、字节码与部署细节注释明确说明与现有请求契约高度相似可先行参考 EIPS/eip-7002.md 的完整实现共识层完整规范当前仅有变更概要、容器与两个关键函数的伪代码FORK_TIMESTAMP主网值待定Rationale设计动机论证、Backwards Compatibility向后兼容性与 Test Cases测试用例章节均未完成。对于希望深入研究的读者建议按以下路径继续探索本仓库EIPS/eip-7685.md通用执行请求框架理解requests_hash承诺与请求编码基础EIPS/eip-7002.md0x01提款请求的完整规范含系统调用细节、费用机制、契约字节码与部署交易示例EIPS/eip-7251.md0x02复利凭证与合并请求理解COMPOUNDING_WITHDRAWAL_PREFIX与变更速率背景EIPS/eip-6110.md0x00存款请求理解执行请求家族的起点。EIP-7804 若最终落地将完成以太坊质押管理凭证层的最后一块拼图验证者不再需要退出重建即可切换管理方案质押生态的去中心化治理与创新空间将被显著拓宽。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考