构建者也要有自己的进出通道：EIP-8282 的两份请求合约

如果 EIP-7732 设想的“内置提议者-构建者分离”（ePBS）落地，出块流水线里会多出一个新角色：构建者（builder），一个质押入场、专职拼块的共识参与者。EIP-8282 处理的就是这个角色的“户口问题”——它怎么注册、质押怎么追加、想退怎么退。方案是在执行层放两份预部署合约，用 EIP-7685 定义的通用请求总线各挂一种请求类型，让构建者的进入与退出各走专门的通道，而不再借 validator 存款和退出的流程“夹带”。这份提案目前是 Review 状态，创建时间是 2026 年 5 月下旬；它依赖的 EIP-7732 本身也还停在 Review，两者都未上主网。

现在的设计：借验证者的壳

在 EIP-8282 之前，EIP-7732 草案里构建者的生命周期是复用验证者流程的：注册靠一笔 validator deposit，在提款凭证的字节前缀里放一个 EIP-7732 定义的构建者专用前缀来表明身份；退出则走自愿退出操作里的构建者分支。这种“借壳”思路能跑，但有两个别扭的地方。第一，共识层要靠检查凭证前缀来分辨这笔存款到底是在注册验证者还是注册构建者，角色信息藏在数据字节里而不是请求类型里。第二，两类注册共用同一条请求通道，验证者存款那套高负载限额与排队规则会原样传导到构建者身上。

新的设计：两种请求类型、两份合约

EIP-8282 定义两种新的 EIP-7685 请求类型与对应的预部署合约，模式上沿用 EIP-7002（执行层发起提款请求）与 EIP-7251（合并质押）确立的请求总线：一笔请求在执行层被记录，下一轮由共识层消费。构建者存款合约负责初始注册与质押追加，构建者退出合约允许构建者的执行地址触发全量退出。收益在提案里写得很直白：从请求类型本身就能读出这是哪种角色，共识层不再靠翻凭证前缀做路由，验证者注册表与构建者注册表也各自独立键控。

一个容易忽略的差别：验签时机

validator 存款的 possession proof（提款凭证与签名密钥关系的证明）不是当场验证的，而是排进有换手速度限制的 pending_deposits 队列里慢慢核。EIP-8282 让构建者存款的 possession proof 在处理时就地验证。这少了一层排队依赖，但也意味着构建者通道上的验证开销要即时结算——这是设计取舍而不是纯粹的改进，读提案时值得注意这一段。

一分钟对照表

可以把这三份提案摆成一排读：EIP-7685 是总线——规定执行层怎么把请求攒起来交给共识层；EIP-7002 是总线上第一个跑通的场景——执行地址发起质押退出；EIP-7251 把合并操作也挂上总线；EIP-8282 则证明这套模式能继续给新角色复用。以后每多一种共识参与者，就多两个小合约、多两种请求类型，而不必再发明一条新通道。这也是读 ePBS 系列文本的捷径：所有新 lifecycle 请求最后都会问同一个问题——谁挂总线上的哪一种类型。