为什么 PBS 架构中需要 Relay 层

一、根本问题：Proposer 和 Builder 之间没有原生信任

PBS（Proposer-Builder Separation）的核心思路是把"打包区块"和"提交区块"拆开：

Builder：负责搜集交易、构造能榨取最多 MEV 的区块。
Proposer（验证者）：负责签名并广播区块。

但这里有一个绕不开的死结——Proposer 必须先承诺出块，才能拿到区块内容，否则就会出现两种作弊：

Proposer 偷 MEV（unbundling attack）：如果 Builder 把完整区块直接发给 Proposer，Proposer 看完内容，提取里面的套利机会，自己重新打包一个块出去，Builder 的钱被白嫖。
Builder 发无效块：如果 Proposer 先签了 header 才知道 body，万一 body 是无效的（gas 超限、状态根错误），Proposer 就会因为"缺席出块"而被罚。

这两种攻击互为对偶，所以需要一个双方都信任的第三方来做"中介托管"。这就是 Relay。

二、Relay 的四个核心职责

职责	解决的问题
验证 Builder 提交的区块	确保 Proposer 不会签到一个无效块（数据有效性、签名、gas、状态根）。
托管 payload，仅暴露 header 给 Proposer	Proposer 只能看到 header（含 fee、blockHash），看不到内部交易顺序，无法 unbundle。
凭 Proposer 签名换取完整 payload	Proposer 一旦签字承诺出这个 header，Relay 才把 body 释放回来，形成原子交换。
抗 DoS / 准入控制	Builder 数量多、提交频繁，Validator 没能力逐个校验，Relay 作为漏斗过滤掉垃圾提交。

三、为什么不能让 Builder 直连 Proposer

设想没有 Relay 的世界：

Builder ──(完整 block)──> Proposer ──签名──> 网络

Proposer 拿到完整 block 后可以反悔：把里面的三明治交易抠出来自己做，Builder 没有任何救济手段。
没有任何协议层机制能强制 Proposer "看完不偷"——共识层只校验签名和合法性，不校验"是不是别人构造的"。

加上 Relay 之后：

Builder ──block──> Relay ──header──> Proposer ──签名──> Relay ──block──> 网络
                     ▲                                       │
                     └────────── 校验 + 托管 ─────────────────┘

Relay 同时面对 Builder 和 Proposer 收押金式的承诺：

对 Builder：保证只有当 Proposer 真签字时，区块才被发布。
对 Proposer：保证签字之前看不到内部交易，签字之后能拿到合法 payload。