本文由Radius研究员 Chanyang Ju（ wooju ）撰写。感谢Hugo对 PoC 的贡献以及AJ对本文的审阅。

1.摘要

本文介绍了状态锁定承诺，一种用于提议者-构建者分离 (PBS) 的新型区块空间承诺机制。当前基于包含的承诺无法保证执行的一致性，导致搜索者采取规避风险的策略，从而降低了市场效率。我们提出了一种超越简单包含承诺的双组分方法。首先，发出排除承诺：与构建者无关的预付预留，保证特定状态不会被冲突的交易改变。接下来，对赢得后续拍卖的捆绑包进行标准的包含承诺（预先确认）。总之，这些承诺提供了与执行承诺相当的强有力保证，使搜索者可以更有信心地竞标。该架构包括一个网关（针对提议者）和一个锁定引擎（针对构建者），使提议者能够拍卖独家状态权、防止冲突、增加收入并培育一个更稳健、更高效的 MEV 市场。

1.1 背景

提议者-构建者分离 (PBS) 将区块空间视为可交易资产，允许提议者拍卖区块构建权。这允许通过向外部参与者（例如构建者和搜索者）出售承诺来部分委托区块构建。目前，大多数此类承诺是基于纳入的（例如纳入列表和预确认），但市场仍在不断发展。

然而，由于技术和经济的限制，目前还没有广泛采用的系统能够保证 bundle 按照预期状态执行。因此：

• 即使区块中包含预先确认的捆绑包，其预期执行也可能会发生变化，或者如果状态事先发生改变，交易可能会失败。
• 由于单靠收录保证不足以保证一致执行，搜索者必须规避风险，从而阻止激进的竞价。
• 频繁的纳入但失败的执行会破坏对承诺的信任并降低市场效率，最终减少提议者的收入。

为了取得进展，区块空间承诺必须超越简单的包容性承诺，并转向确保状态一致性的执行级保证。

1.2 解决方案：状态锁定承诺

为了解决这些限制，我们引入了状态锁定承诺：这是一种机制，提议者明确承诺对区块所访问状态拥有独占执行权。此承诺超越了简单的包含，它确保区块内定义的状态范围保持不变，从而实现区块的稳定执行。

我们的方法并非强制实施全局状态锁，而是在每个区块上应用本地状态锁。这避免了全局同步或内存池范围的控制，而是仅限制可能存在冲突的状态范围。该架构的一个关键方面是，提议者必须始终向所有构建者传达特定 EVM 状态的独占执行权。换句话说，即使不同的构建者构建了不同的候选区块，此约束也必须作为所有正在考虑的选项的通用访问限制规则。

国家船闸承诺分两个阶段实施，对建筑商起到部分约束作用：

1. 排除承诺：提议者将特定的stateScope声明为锁候选者，并将其广播给所有构建者，指示他们不要包含冲突的交易。
2. 纳入承诺：一旦stateScope的拍卖结束，预先确认赢得最终区块纳入的捆绑包。

结合使用这两项承诺，可以显著提高区块束一致执行和避免冲突的可能性。在特定条件下，这可以提供强大的执行保证（执行承诺）。当排除承诺传播到所有构建者并由他们一致执行时，即使没有“我的区块束将位于区块顶部”的包含保证，搜索者也能在“无人触碰我指定状态”的假设下获得竞争优势。

因此，基于状态级约束（排除）的纳入承诺可以被视为一系列连续执行承诺的一部分。作为一种与构建者无关的约束，该机制可以重塑区块构建动态以及未来的 MEV 市场激励机制和竞争格局。

1.2.1 概述

组件和职责

程序流程

1. 提交和拍卖：搜索者向网关提交一捆物品。
2. 协调和拍卖开始：网关模拟 bundle 自动提取其stateScope （例如访问列表）并为该特定的stateScope发起拍卖。
3. 排除：拍卖进行期间，提议者（通过网关）宣布stateScope为锁定候选。这作为初始排除承诺，并广播给所有参与的建造者。
4. 竞标与预确认：建造者意识到限制，会临时构建区块，避免交易冲突。拍卖结束后，系统会向建造者发送中标区块的预确认请求。
5. 执行与构建：构建者验证已签署的承诺，并通过包含预先确认的捆绑包来确保最终区块符合stateScope约束。随后，构建者可以解除排除并继续构建区块。

1.2.2 建筑意义

与现有模型（例如 EIP-7547）相比，该架构具有显著优势，并能够实现更细粒度、更灵活的区块空间市场。具体而言，排除承诺为搜索者提供了其区块束可执行性的预先保证，并为构建者提供了明确的冲突规避标准，使其成为事实上的执行层面的承诺。

在此模型下，提议者可以并行声明多个互不冲突的排除承诺，并为每个相应的stateScope分配一个唯一的LockId 。每个锁都与一个单独的 bundle 相关联，对于任何相同或重叠的状态范围，只会选择一个获胜者并发出一个预确认。

这种结构有以下好处：

• 以状态为中心，而非以交易为中心：通过关注状态范围而非整个交易列表，提议者赋予了构建者更大的灵活性。构建者只需避开较小且定义明确的状态区域，即可自由地优化区块的剩余部分。
• 并行、无冲突的拍卖：提议者可以同时运行多个拍卖，涵盖互不重叠的状态范围。这使得单个区块中可以包含多个独立的 MEV 策略，从而最大化其价值。
• 为所有参与者提供更好的激励：
  • 搜索者：比区块时间更快地获得执行确定性，使他们能够更积极地竞标并自信地部署资本密集型战略。
  • 提议者：通过拍卖独家国家访问权来创造新的收入来源，并通过安全地包含多个高价值捆绑包来最大化区块奖励。
  • 构建者：获得清晰的早期约束，使他们无需等待完整的交易列表即可优化区块构建。与存在全局约束的场景相比，这增强了他们的战略灵活性和效率。

本质上，状态锁定承诺可以将区块空间市场从一个简单的纳入保证转变为一个复杂的以太坊状态期货市场。它为更稳定、更高效、更有利可图的 MEV 生态系统提供了必要的保障。

1.3 基础设施组件：Gateway 和 LockEngine

为了在 PBS 基础架构中实现这种基于状态约束的承诺结构，我们建议扩展现有的 Commit-Boost 功能。具体来说，我们扩展了Signer（负责处理提议者的承诺生成）和Gateway （负责协调捆绑包）的角色，以处理状态级的承诺。相应地，在构建器端引入了一个新的辅助模块LockEngine 。此设计允许一致地处理基于状态约束的预确认，而无需对现有的 PBS/MEV-Boost 基础架构进行重大修改。

1.3.1 网关

• 角色：一种链下中继基础设施，用于转发提议者的承诺请求、协调捆绑包之间的竞争，并通过与签名者的集成处理签名的收集和传递。
• 功能：
  • 根据其stateScope接收和管理包。
  • 管理争夺同一stateScope的 bundles 之间的冲突。
  • 接收并协调参与拍卖的搜索者的捆绑信息和出价。
  • 将提议者的承诺请求和签名请求转发给签名者。
  • 将承诺结果传达给建设者和搜索者。
• 特征：
  • 在核心 PBS 协议之外运行且不直接与验证器交互的链下中介。
  • 可以配置为中立中继基础设施以支持各种策略。

1.3.2 签名者

• 角色：为提议者的排除/纳入承诺生成基于签名的承诺协议。它通过代理密钥从提议者处获得委托签名权限，以处理签名创建。其目的是实现提议者和构建者之间的去信任化协作，并提高 MEV 交易的安全性和效率。
• 功能：
  • 根据stateScope处理承诺。
  • 协调 BLS 签名（提交 → 揭示 → 聚合程序）。
  • 提供防止对同一插槽进行重复提交/显示操作的功能。
  • 防止对同一LockId进行重复提交/显示操作。
• 特征：
  • 处理网关转发的请求的签名（提议者签名委托模型）。
  • 多个网关可以共享同一个签名者实例（中立性）。
  • 作为提议者节点旁边的边车安装，能够与 MEV-Boost 并行运行或集成到 MEV-Boost 中。

1.3.3 LockEngine（构建器 Sidecar）

• 角色：一个 sidecar 模块，协助构建者遵守提议者在区块构建期间设置的stateScope约束。
• 功能：
  • 验证签名者签发的承诺签名。
  • 检测每个stateScope的冲突并相应地过滤交易。
  • 主动从构建者的内存池中删除冲突的交易。
  • 支持交易重新排序和捆绑重组。
• 特征：
  • 可以作为 sidecar 运行，无需修改构建器的核心逻辑。
  • 从提议者或网关接收承诺和stateScope信息。
  • 确保在执行前阶段避免stateScope冲突。

1.4 关键部件定义

• 提议者
  • 在信标链上提出区块。
  • 通过代理密钥将签名权委托给签名者。
  • 根据从网关收到的搜索器包及其相应的访问列表（ stateScope ），声明对无争议状态范围的锁定（即请求排除+包含承诺）。
  • 要求签名者签署中标拍卖结果。
• 网关
  • 从搜索者接收捆绑包并通过 EVM 模拟提取其访问列表 ( stateScope )。
  • 确定访问相同状态范围的捆绑包之间的冲突。
  • 将所有捆绑包和相关元数据转发到中继。
  • 将中标方案告知提议者。
  • 将提议者的承诺签署请求转发给签名者。
  • 记录并传播所有承诺请求及其处理结果。
• 中继
  • 从网关接收所有捆绑包和投标信息。
  • 将有关选定捆绑包的信息传播到网关和提议者。
  • 区块提交后，验证建造者是否真正履行了提议者承诺（例如，包含、避免状态冲突、包含在指定高度内）。
  • 如果不合规，它可以收集削减证明并将其转发给 AVS 或监控网络。
• 签名者
  • 应提议者的要求，以可验证的方式为建筑商签署排除/纳入承诺。
  • 在提议者的授权下处理签名（例如，使用 BLS）。
• 建造者
  • 构建符合通过 LockEngine 接收的基于stateScope的约束的块。
  • 必须包含预先确认中指定的捆绑包，并且不得包含（或必须重新排序）与stateScope冲突的交易。
  • 违反这些条件将面临削减或阻止拒绝等处罚。
• 锁引擎
  • 与构建器节点一起运行的 sidecar 模块。
  • 从网关接收预先确认和状态约束信息（ stateScope 、 LockId等）。
  • 监控构建器的内存池以过滤或重新排序与stateScope冲突的交易。
  • 协助确保预先确认的捆绑包包含在区块中。
  • 允许构建者遵守提议者的约束，而无需修改其核心逻辑。
• 搜索者
  • 识别链下的 MEV 机会、构建捆绑包并将其提交给网关。
  • 不需要为其包明确指定stateScope ；网关会自动提取它。
  • 与其他搜索者竞争相同的状态范围，获胜者将获得最终的预先确认。
  • 由于执行失败的风险降低，可以对承诺的捆绑包采用更积极的竞价策略。

2. 主要特点

2.1 本地状态锁定（排除承诺）

在发出预确认之前，提议者会声明对特定 bundle 所访问的状态范围 ( stateScope ) 的排他访问约束，以保证其执行。此声明的功能类似于排除承诺。它作为一种先发制人的机制，通过提议者单方面通知构建者指定状态已禁止访问来防止冲突。

在此模型中，无需与建造者事先协商即可建立国家锁，并按照以下流程应用：

1. 排除承诺包含以下字段：
   • LockId
   • stateScope //基于访问列表的一组账户
   • inclusionHeight // 从搜索者的角度定义状态
   • signature
2. 在分析了给定bundle的状态范围后，提议者会为该范围声明一个独占访问约束。stateScope是bundle内交易访问状态stateScope地址列表。
3. 此声明通过网关广播给所有建设者。
4. LockEngine （在构建器端）接收此消息并将其作为本地状态访问限制。
5. 当LockId处于活动状态时，构建器不得在其块中包含任何冲突的交易。

2.2 预先确认（纳入承诺）

预先确认是提议者做出的加密承诺，承诺将特定区块打包到指定区块中。它的作用相当于区块空间拍卖的最终结果——纳入承诺。该承诺建立在排除承诺的基础上，这意味着其可执行性已得到预先保障。

2.2.1 预确认生成流程

1. 提议者对中标捆绑包发出预先确认，然后通过签名者签名并交付给建造者。
2. 包容承诺包含以下字段：
   • LockId // 与排除承诺中的 LockId 匹配
   • bundleTxs
   • inclusionHeight
   • signature

2.2.2 作用与效果

• 提议者：负责将 bundle 包含在包含承诺中指定的inclusionHeight处。
• 构建器：根据排除承诺和包含承诺的约束来构建区块。
• LockEngine：根据排除承诺对状态范围实施访问控制。

虽然排除承诺（国家冲突预防）和包容承诺（区块包容承诺）是不同的组成部分，但它们协同作用时会产生以下效果：

• 对于搜索者：保证他们提交的捆绑包将在特定状态下执行，并且不会因状态冲突而失败。
• 对于提议者：提供一个框架来并行组合不冲突的捆绑包。
• 对于建造者来说：可以灵活地提前建造模块，而无需等待完整的捆绑包。

2.3 构建器约束处理

构建者会从提议者那里收到两种类型的约束：针对某个stateScope状态访问限制（排除承诺）以及针对特定区块束的包含承诺（包含承诺，即预先确认）。这些约束是结构性约束，必须遵守这些约束才能使区块被提议者视为有效候选区块。这不仅仅是一个建议，而是一个强制性条件。承诺通过以下途径交付：

提议者 → 网关 → 中继 → 构建者（通过 LockEngine sidecar）

中继确保提议者承诺一致地传播给整个网络的所有构建者，防止任何单个构建者单方面忽略或规避约束。

2.3.1 提议者承诺约束

建造者必须根据以下两个约束来建造其区块：

1. StateScope 排除约束
   • 提议者创建一个锁（承诺），以禁止特定stateScope状态冲突。
   • 网关接收此锁声明，并通过中继将其传播到构建器网络。每个锁都由唯一的LockId标识。
   • 构建器必须通过以下方式之一处理访问此范围的任何事务：
     • 不包括它（严格排除）。
     • 在确认捆绑后进行订购，以确保不会发生状态冲突。
2. 预先确认包含约束
   • 提议者以加密方式承诺（预先确认）特定的捆绑包将被包含在指定的区块高度（ inclusionHeight ）中。
   • 构建器必须将此 bundle 添加到指定位置。否则，从提议者的角度来看，该区块将无效。

这两个条件是相辅相成的。如果其中一个被违反，提议者可以拒绝接受该区块，或者对建造者施加惩罚。

2.3.2 约束执行与验证

中继器和第三方验证器（例如，网关、AVS）可以根据以下标准独立验证构建者的区块是否忠实地反映了提议者的承诺。此验证假设排除承诺和包含承诺中的信息都是公开的，并附有提议者的加密签名。

• 排除承诺验证

  • 承诺信息：
    • LockId
    • stateScope
    • inclusionHeight
    • 提议人签名
  • 验证程序：
    1. 中继站接收并存储提议者发出的排除承诺。
    2. 它模拟或静态分析构建者提交的块候选，以提取其中的交易访问的状态集。
    3. 它检查提取出的访问状态集是否与提交的stateScope相交。
       • 发现交叉点 → 排除违规。
       • 无交叉路口 → 排除已完成。
  • 违规证明：
    • 中继器可以通过提交违规区块以及相应的排除承诺来生成削减证明，证明“该区块违反了提议者明确锁定的stateScope ”。

• 纳入承诺验证

  • 承诺信息：
    • LockId
    • bundleTxs
    • inclusionHeight
    • 提议人签名
  • 验证程序：
    1. 中继器根据inclusionHeight检查构建者提交的区块高度。
    2. 它验证区块中是否包含完全相同的交易包。
    3. 它确认纳入顺序和执行位置满足承诺中定义的条件（例如，放在顶部，锁定后执行）。
       • 未包含或顺序不正确 → 包含违规。
       • 正确包含 → 包含已完成。
  • 违规证明：
    • 中继器可以通过提供提交的区块头和交易列表作为“构建者未能在指定的区块高度包含承诺的捆绑包”的证据来生成包含违规证明。

• 问责机制

  此验证过程可在中继层级实现自动化。如发现违规行为，可采取以下措施：

  • 削减（通过削减证明提交）：

    • 违规证明（承诺+违规区块的交易集）提交给链上合约。
    • 相应的建造者股份将被烧毁或处罚。

  • 基于声誉的排除：

    • 中继/网关网络将违规构建者标记为不可信。
    • 提议者随后拒绝向该建筑商提供区块收入机会。

  • 还可以考虑未来的扩展路径，例如 TEE 证明和基于 ZK Proof 的验证。

    验证方法	描述
    基于TEE	对在 SGX 等可信执行环境 (TEE) 中生成的区块使用远程证明。
    基于ZK	为stateScope内的交易顺序和执行路径生成零知识证明，以供 Gateway/AVS 验证。

3. Commit-Boost 的并行拍卖

3.1 序列图

Parallel_Auction_on_Commit-Boost 1920×2123 107 KB

3.2 流程

1. 拍卖启动

• Gateway宣布开始特定时段的拍卖（例如slot N ）
• 向所有参与搜索者广播StartAuction(slot N)

1. 捆绑提交和 StateScope 定义

• Searcher1 → Gateway ：提交包含以下内容的包：
  • txList1
  • bid1
  • inclusionHeight
• Gateway ：
  • 模拟捆绑并提取AccessList
  • 派生相应的stateScope
  • 为 bundle 生成唯一的LockId

1. 排除承诺请求及签署

• Gateway → Signer : RequestSig(LockId, stateScope)
• Signer ：
  • 签署ExclusionCommitment
  • 返回ExclusionSig
• Gateway → LockEngine : 发送ExclusionCommitment
• LockEngine ：
  • 验证承诺
  • 准备基于 stateScope 的交易过滤

1. StateScope 广播和过滤

• Gateway ：
  • 将stateScope广播给所有搜索者
  • 防止重复投标并鼓励策略差异化
• LockEngine ：
  • 过滤与锁定的stateScope冲突的内存池交易
  • 向构建者提供经过筛选的非冲突交易列表
• LockEngine → Builder ： DeliverFilteredTxList
• Builder ：根据过滤后的交易开始构建区块

1. 额外投标和拍卖最终确定

• Searcher2 → Gateway : 提交另一个 bundle
  • 包括：
    • txList2
    • bid2
    • inclusionHeight
• Gateway
  • 比较出价并选择获胜的捆绑包（例如Searcher2 ）
  • 宣布EndAuction并传达结果

1. 包容性承诺发布

• Gateway → Signer : RequestSig(bundleHash, inclusionHeight)
• Signer ：
  • 签署InclusionCommitment （预先确认）
  • 返回InclusionSig
• Gateway → LockEngine ：发送已签名的包含承诺

1. 最终区块建设

• LockEngine ：
  • 验证InclusionSig
• LockEngine → Builder ： Send(txList2)
• Builder ：
  • 构建包含给定交易列表的区块
  • 确保捆绑包包含在指定的inclusionHeight

1. 区块提交和包含证明

• Builder → Proposer : 提交最终区块
• Builder → Gateway : 提交InclusionProof(bundle)
• Gateway → Relay ：中继InclusionProof(bundle)
• Relay ：
  • 验证承诺的履行情况。
  • 如有必要，将证据传播到 AVS 或其他监控基础设施

4.处理竞争条件和冲突

4.1 预先确认冲突规则

• 对于同一个stateScope只能发出一个有效的预先确认。
  • 单个LockId仅分配给一个获胜搜索者。
  • 在拍卖时，网关确定是否存在状态冲突，并从竞争同一stateScope的 bundles 中仅选择一个赢家。
• 如果stateScope访问相互不相交的状态，则可以并行发出预先确认。
  • 网关可以并行运行多个LockId拍卖。
  • 构建器通过 LockEngine 并行管理多个LockId ，协调各个 bundles 在块内共存而不受干扰。

4.2 冲突检测标准和轨迹

• 冲突标准：
  • 如果两个 bundle 访问包含相同合约地址或 slot 级项目的状态（ stateScope ），则会发生冲突。
  • stateScope可以在合约级别或 slot 级别定义；实现复杂性和可实现的并行度之间存在权衡。
• 冲突检测位置：
  • 网关：模拟搜索器捆绑并提取其访问列表。
  • LockEngine：对构建器的内存池执行实时过滤，以预先删除或重新排序冲突的交易。

4.3 承诺失败及处罚

建筑商若违反以下任何一项规定，可能会面临罚款或其他处罚：

• 未能将中标捆绑包包含在指定的inclusionHeight处。
• 通过在预先确认的 bundle之前包含另一个访问相同stateScope交易，导致 bundle 失败。
• 在构建区块时省略或操纵来自预先确认的签名信息。
• 证明提交和削减：
  • 网关或搜索者可以将相关区块和相应的承诺（排除/包含）提交给AVS或链上验证模块。
  • InclusionProof （例如，Merkle 证明）或完整的区块数据可用作证据。
• 异常处理：
  • 如果在排除承诺之后未发出纳入承诺：
    • LockEngine（构建器）可以在一定时间后自动释放锁。
    • 需要设置最大锁定时长（例如8秒内）。
    • 建造者可以继续进行区块建造，但不包括相关交易。
  • 在由于链重组等事件导致包含无效的情况下，有必要区分提议者错误和构建者错误。

5.概念验证（PoC）实施

该协议并非仅仅是一个理论提案；我们通过以本地状态锁协议的形式扩展 Commit-Boost 架构，进行了实际的概念验证 (PoC)。该设计注重尽可能地复用现有的 PBS 基础架构和 Commit-Boost 设计，同时添加新功能。

5.1实施范围

PoC 在代码中实现了以下两个关键的承诺流程：

1. 排除承诺
   • 为搜索者提交的包定义stateScope 。
   • 提议者根据此stateScope生成“冲突预防”消息，并传递给所有构建者。
   • 构建者的 LockEngine 收到此消息，从其内存池中过滤掉冲突的交易，并更新其本地状态。
2. 包容性承诺
   • 提议者通过stateScope拍卖确定获胜者。
   • 向获胜者（搜索者）发出预先确认，其中包含LockId 、 bundleHash 、 inclusionHeight等。
   • 这是通过签名模块签名并交付给建造者的。

5.2 操作流程（PoC）

PoC中实现的端到端执行流程如下：

1. 搜索者→网关：提交一个bundle并提供其stateScope规范。
2. 网关 → 提议者：收集一组 bundles 并确定冲突。对于不相交的stateScope ，它会运行并行拍卖。
3. 提议者 → 构建者：广播排除承诺。并为获胜的 bundle 发出纳入承诺。
4. 构建器（LockEngine）：通过排除冲突交易来强制执行排除承诺。通过将 bundle 纳入指定 slot 来强制执行包含承诺。

5.3 关键实验结果

• 可预测的执行保证：
  • 由于在stateScope级别应用了锁，因此搜索器包的执行不会与访问同一状态的竞争包发生冲突。
• 平行拍卖可行性的确认：
  • 我们确认，当多个 bundle 的stateScope不相交时，它们可以同时接收预确认。
• 易于构建器集成：
  • 通过将 LockEngine 作为 sidecar 实现，我们验证了可以在不对现有构建器逻辑进行重大修改的情况下应用承诺约束。

5.4 局限性和未来工作

• PoC 的实施侧重于合约级粒度而不是槽级锁定。
• 一些边缘情况，例如重组场景、锁定超时处理和削减证明的提交，仍未实现。
• 未来的工作将需要集成基于 TEE/ZK 的区块验证并定义更细粒度的stateScope 。

参考

https://github.com/radiusxyz/parallel-auction-commit-boost
https://ethresear.ch/t/state-lock-auctions-towards-collaborative-block-building/18558
https://ethresear.ch/t/commit-boost-proposer-platform-to-safely-make-commitments/20107
https://eips.ethereum.org/EIPS/eip-2930
https://eips.ethereum.org/EIPS/eip-7547