以太坊的新前沿 - ePBS设计规范的全面指南

目录

• ePBS设计规范
  • 规范概述
  • 详细流程与时间线
  • 时间槽结构
  • 包含列表时间线
  • 执行负载时间线
  • 负载证明时间线
  • 信标区块时间线
  • 诚实验证者行为
  • 诚实构建者行为
  • 提议者与构建者交互的安全分析
  • 选择分叉考虑
• ePBS中的开放问题
  • “旁路能力”的含义是什么？
  • 确立目的是为了实现什么？
  • 不确立的确切含义是什么？
  • ePBS的真实需求是什么？
  • 我们能多大程度上依赖利他主义和社会层面？
  • 在未来有L2和OFA的场景中，L1 ePBS的重要性如何？
  • 在其他协议升级的背景下，ePBS应优先考虑什么？
• 参考文献

ePBS设计规范

注意： 如果你对ePBS（确立的提议者构建者分离）或以太坊的PBS（提议者构建者分离）不太了解，或者希望刷新你的理解，我之前关于ePBS的文章是一个很好的起点^15。

当前的确立的提议者构建者分离（ePBS）或本地提议者构建者分离规范^12 处理了以太坊当前实现PBS的一个关键问题^1。传统上，提议者和构建者必须依赖中介通过MEV-Boost^3，这引入了信任和审查的问题，如上所述。ePBS框架通过将中介的必要性（“必须”）转换为一种选择（“可以”），改变了这一动态，允许以太坊生态系统内更无信任的交互^5^7。它结合了EIP-7251和EIP-7002，这两者是其实施的重要组成部分。

EIP-7251旨在将以太坊验证者的最大有效余额（Max EB）提高到2048 ETH，同时保持最低质押32 ETH，减少总验证者数量而不妨碍安全性。EIP-7002引入了一种机制，允许验证者使用其执行层（0x01）提取凭据从信标链中触发退出，以增强质押操作的灵活性和安全性。

规范概述

ePBS规范的主要改进：

信任最小化：它通过允许提议者和构建者更独立地操作，减少对中介的信任需求，从而降低操控与信任依赖的风险。

兼容性所需的最小变化：该设计实施了保持与当前共识和执行客户端操作兼容所需的最少数量的变化。遵循现有的12秒槽时间，确保网络操作的连续性与稳定性。

防审查性：它通过根据EIP-7547引入前向强制包含列表来增强防审查性，确保某些交易必须被包含，从而帮助维护网络完整性。

层增强：变化主要发生在共识层（CL），对执行层（EL）的调整最小，主要与处理包含列表相关。

安全保证：

• 提议者安全：确保提议者防范通过共谋的提议者和构建者进行的1槽重组攻击，即使这些攻击者控制了最高20%的质押。
• 构建者安全：为构建者提供防止连续提议者共谋和操控的保障，包括确保被扣留悉被泄露负载安全的措施。
• 拆分保证：构建者在所有攻击场景下受到保护，确保交易处理和执行的完整性。

验证者的自我构建能力：验证者保留自我构建他们的负载的能力，这对于维护独立性和灵活性至关重要。

可组合性：该规范旨在与其他机制，如时间槽拍卖或执行票证拍卖，可组合，增强灵活性并促进未来创新的潜力。

实施细节：

ePBS规范引入了特定的角色和职责：

• 构建者：提交负载承诺的出价的验证者。
• PTC（负载及时性委员会）：一个新的委员会，用于验证负载的及时性和有效性。

在每个槽期间，提议者收集出价，并在选择出价后提交带有构建者签名承诺的区块。然后，验证者根据这些承诺调整构建者和提议者之间的财务信用。构建者随后揭示他们的执行负载，履行其义务。根据区块的生成和揭示，槽的结果可以变化——错过、空或者满，PTC在确定槽的结论性质方面起着关键作用。

详细流程与时间线

时间槽结构

sequenceDiagram
    participant Proposer
    participant EL as Execution Layer
    participant Builders
    participant Validators
        participant Aggregators
    participant PTC as Payload Timeliness Committee
    participant Network as P2P Network

    Note over Proposer: 槽开始前的准备
    rect rgb(191, 223, 255)
    Proposer->>EL: 请求完整包含列表
    EL-->>Proposer: 提供交易和地址
    Proposer->>Proposer: 填写并签署包含列表摘要
    Proposer->>Network: 广播包含列表

    end

    Note over Proposer: 槽开始，时间t=0秒
    rect rgb(191, 223, 255)
    Note over Builders: 构建者准备出价
    Builders->>Proposer: 通过p2p网络或直接发送出价
    Proposer->>Proposer: 选择构建者的出价

    Proposer->>+Validators: 准备并广播含构建者出价的SignedBeaconBlock

    Note over Validators: 在t=0到t=3秒之间
    Validators->>Validators: 独立运行状态<br>转换函数在信标块上
    Validators->>-EL: 验证提议者签名和验证包含列表
    end

    Note over Validators: t=3秒
    rect rgb(191, 223, 255)
    Validators->>+Validators: 对信标块和包含列表的存在进行证明
    Validators->>-Network: 广播证明    
    end

    Note over Builders: t=6秒
    rect rgb(191, 223, 255)
    Aggregators->>+Aggregators: 聚合并提交<br>证明聚合
    Aggregators->>-Network: 提交聚合

    Builders->>+Builders: 监测子网，决定<br>负载保留情况
    Builders->>-Network: 广播执行负载
    end

    Note over PTC: t=9秒
    rect rgb(191, 223, 255)
    PTC->>PTC: 评估执行负载的及时性和状态
    alt 负载状态
        Note over PTC: PAYLOAD_PRESENT ==> 如果负载信封及时被看到<br>且payload_withheld = False
        PTC-->>Network: 投票PAYLOAD_PRESENT
        Note over PTC: PAYLOAD_WITHHELD ==> 如果负载信封及时被看到<br>且payload_withheld = True
        PTC-->>Network: 投票PAYLOAD_WITHHELD
        Note over PTC: PAYLOAD_ABSENT ==> 如果信标块未见或<br>负载未见 
        PTC-->>Network: 投票PAYLOAD_ABSENT
    end
    end

    Network-->>Validators: 导入和验证所有数据：IL、信标块、<br>证明、负载证明、完整执行负载    
    rect rgb(191, 223, 255)
    alt 状态选项
        Note over Validators: 完整区块 ==> 信标块和<br>执行负载均已成功导入
        Note over Validators: 空区块 ==> 信标块已导入，<br>负载未及时透露

        Note over Validators: 跳过槽 ==> 本槽期间未导入任何共识区块
    end
    end
    rect rgb(191, 223, 255)
    Validators->>Validators: 根据上述结果评估区块链的新头<br>    
    end
    Note over Validators: 槽结束

图 – 基于ePBS规范的新槽结构流程。

基于ePBS规范的新槽结构流程解释：

槽前的准备：

• 提议者通过请求执行层的完整包含列表、填充并签署摘要，然后将其广播到p2p网络来准备。

ePBS新内容：IL是提议者在执行层中保证网络的防审查性的一个新组成部分。它基于前向包含，提议者和验证者交互，以确保交易有效且高效地向前推进。

包含列表容器：

• InclusionListSummary：包含提议者的索引、槽和一组执行地址。
• SignedInclusionListSummary：包含上述摘要及提议者的签名。
• InclusionList：包含签名的摘要、信标块的父区块哈希和交易列表。

从EL请求IL：

• 提议者通过调用函数get_execution_inclusion_list从执行层获取待包括的交易，确保它们根据当前状态有效。返回的是一个容器GetInclusionListResponse，其中包含transactions（所需的交易对象列表）和summary（transactions的摘要，包括诸如“from”地址的关键信息）。 构建IL：
• 提议者调用函数build_inclusion_list将接收的交易组织成结构化格式，为签署准备摘要，并确保符合网络标准。返回的容器为InclusionList，包含SignedInclusionListSummary（签名交易摘要），以验证真实完整性以及transactions（待包括的已验证交易列表）。 广播IL：
• 一旦IL准备好并签署完毕，提议者通过p2p将其广播到整个网络。

槽开始，时间t=0秒：

• 构建者准备出价，并通过p2p网络或直接将其发送给提议者。
• 提议者选择构建者的出价，并准备广播播发包含构建者出价的SignedBeaconBlock。

ePBS新内容： inclusion_list_summary属性被包含在ExecutionPayload中。该字段与区块内某些交易的包含摘要相关，提供对区块内所包含内容的控制。

构建者：准备和发送出价

• 构建者使用ExecutionPayloadHeader容器准备出价，该容器包含必要的细节，如父区块哈希、费用接收者和提议的交易费用等。
• 构建者创建SignedExecutionPayloadHeader，生成签名的ExecutionPayloadHeader并广播。
• 出价要么直接发送给提议者，要么通过p2p网络通过execution_payload_header主题发布。

提议者：选择出价并广播已签名的信标区块

• 提议者根据几个标准评估出价，例如出价金额和构建者的可靠性或过去的表现，以选择出价。
• 提议者构造一个BeaconBlockBody，其中包含signed_execution_payload_header及其他标准元素。
• 函数process_block_header处理区块头，确保所有元素符合共识规则，并在当前链上下文中区块有效。
• 现在包含选定的执行负载头，区块由提议者签名以生成SignedBeaconBlock。
• 已签名的区块被广播到p2p网络，使用beacon_block主题，供所有网络参与者访问。
• 在提议者准备的BeaconBlockBody内，ExecutionPayloadHeader包含的parent_block_hash链接到执行层中的父区块，确保链的连续性，并且block_hash将最终链接到构建者生成的ExecutionPayload的哈希，对于验证者验证链的完整性和连续性至关重要。

在t=0到t=3秒之间：

• 验证者独立运行状态转换函数，以验证信标块，验证提议者的签名和验证包含列表。

验证者：验证信标块和包含列表

• 收到SignedBeaconBlock后，验证者调用process_block函数，全面处理块处理的不同方面，包括头验证、RANDAO、提议者惩罚、证明等。
• 对于ePBS，特别关注process_execution_payload_header，验证块内的执行负载头。
• 验证者验证与ExecutionPayloadHeader引用的IL。如果区块和IL成功通过验证，状态转换函数state_transition更新信标状态以反映新区块。这包括更新验证者状态，调整基于证明和惩罚的余额，轮换委员会。

在t=3秒左右：

• 验证者对信标块和IL的存在进行证明，以确保这一点。

验证者：对信标块进行证明

• 验证者调用函数process_attestation验证和处理针对信标块的每个证明。这包括验证信标块的槽、证明委员会，并根据共识规则确保证明数据的正确性。

在t=6秒左右：

• 聚合者聚合并提交证明聚合。
• 构建者构建并广播他们的执行负载。构建者监测网络子网，并决定是否根据网络条件和投票保留他们的负载。
• 构建者将执行负载打包，包含所有交易执行所需的信息，打包为容器ExecutionPayloadEnvelope。这种封装确保负载为纳入信标链做好准备。他们将payload_withheld字段设置为false。
• 此外，诚实的构建者可以在没有及时看到所需共识区块的情况下，通过设置payload_withheld为true来保留负载。
• 他们运行函数process_execution_payload，在当前状态下处理执行负载以确保其有效性。这涉及验证交易、确保状态转换的正确性，并检查负载是否符合共识规则。
• 然后，他们签署容器ExecutionPayloadEnvelope，以生成SignedExecutionPayloadEnvelope，再通过p2p网络向execution_payload主题广播。

在t=9秒左右 - 负载及时性委员会（PTC）：

• 在槽的第9秒，PTC评估执行负载的及时性。该委员会由512名验证者组成，基于对执行负载的存在和相对于共识区块的时间的观察进行投票。

ePBS新内容：PTC是ePBS规范中引入的新组成部分。

• 组成和功能：
  • 委员会组成：PTC成员从每个信标槽委员会中随机挑选非构建者的前几名成员。这确保委员会仅由不同时期作为构建者的验证者组成，从而最大程度减少利益冲突。
  • 证明奖励和惩罚：PTC成员因对负载的存在或缺失作出正确证明而获得标准奖励。准确的证明与实际负载状态一致（full或empty），验证者因此获得完整的证明信用（目标、来源和头部及时）。不准确的证明将导致类似漏证明的惩罚。
  • 证明处理：PTC成员对CL块的证明不予考虑，专注于负载验证任务。
  • 在块中包含证明：对槽N+1的提议者负责将槽N的PTC证明包含在该块中。对于进入不当证明没有直接的激励，因此通常只有一个PTC证明每块是必要的。
• 聚合和广播： 导入PTC证明有两种方法。聚合的证明（PayloadAttestation）被包含在前一槽的区块中，而未聚合的证明（PayloadAttestationMessage）实时广播并处理。

PTC验证者评估并投票执行负载的及时性

• 每个PTC验证者独立检查他们是否从按时应该揭示负载的构建者接收到有效的ExecutionPayload。PTC验证者根据负载的存在和接收时间投票负载的及时性。

广播负载及时性证明

• 如果确认执行负载是存在且及时的，PTC验证者生成并广播负载及时性证明，确认这些观察结果。容器PayloadAttestation记录验证者关于负载的及时性和存在的证明。
• get_payload_attesting_indices函数确定哪些PTC验证者在证明负载的存在和及时时投票，通过检查他们在PayloadAttestation中的汇聚标志。
• 证明在p2p网络上通过payload_attestation_message主题进行广播。

聚合并将负载证明包含在信标块中

• 聚合者收集单个PayloadAttestation消息，进行聚合，并确保它们包含在即将到来的信标块中，以记录和最终确认验证者对负载及时性的共识。这些证明被聚合到一个IndexedPayloadAttestation容器中，其中包括证明的验证者索引、负载证明数据及一个集体签名。

根据证明更新信标链状态

• process_payload_attestation函数由信标链调用，用于处理和验证传入的负载证明。它确保证明数据是正确的，并且签名有效，将这些信息整合到信标状态中。信标链状态根据负载证明更新。
• 这些证明通过影响各块的权重影响选择分叉，最终可能由于感知到的负载及时性和存在导致不同的链重组。

奖励计算与分配：对于每个正确证明负载状态的验证者，将设置参与标志并根据预定义权重计算奖励（PARTICIPATION_FLAG_WEIGHTS）。奖励被汇总，证明的提议者按比例获得奖励，计算考虑到协议规范中的各种权重和分母（WEIGHT_DENOMINATOR、PROPOSER_WEIGHT）。

提议者奖励：最终计算提议者的奖励并通过调用increase_balance方法更新提议者的余额。

槽结束：

• 随着槽结束，验证者完成几个关键任务：
  • 导入和验证：验证者确保导入并验证包括清单、共识区块、所有单比特和聚合证明、负载证明以及完整执行负载。
  • 评估区块链的新头：基于验证的数据，验证者对链的状态做出重要决策。他们判断该槽结果是否为：
  • 完整区块：共识区块和相应的执行负载均已成功导入。
  • 空区块：共识区块已导入，但相关的执行负载未及时揭示。
  • 跳过槽：在该槽期间未导入任何共识区块，导致跳过槽场景。
• 选择分叉函数get_head根据最新的块提议、负载证明及其他相关信息，如证明和余额的权重，确认链的头部。
• 所有节点依照所选分叉的结果进行状态同步，确保网络一致性。此同步包括应用所有已证明区块和执行负载的状态转换和更新。

包含列表时间线

Gossip层检查：

• 验证包含列表的时机，确保与当前槽或下一个槽相关。
• 每个提议者-槽对在网络上限制广播一个包含列表，尽管提议者可以向不同的对等体发送不同的列表。
• 交易数量必须与摘要计数匹配，且不超出MAX_TRANSACTIONS_PER_INCLUSION_LIST设定的最大值。
• 验证包含列表签名是否与提议者的密钥匹配，确认其预定的槽。

风险与缓解措施：

• 在头变化之前为即将到来的槽广播包含列表可能导致可用性问题，尽管该列表仍被视为可用。

on_inclusion_list处理程序：

• 作为执行引擎API调用的桥梁，假设相应的信标块已被处理。
• 如果信标块的父块为空，则任何新的包含列表会被自动忽略，以防止积压。

信标状态跟踪：

• 跟踪最新和前几个IL的提议者和槽，以管理满足情况并在新的有效块上更新。

EL验证：

• 检查inclusion_list.transactions的交易是否有效且可包括，以当前状态进行。
• 确保摘要inclusion_list.signed_summary.message.summary准确列出所包含交易的“from”地址。
• 验证交易的总气体限制不超过最大允许值MAX_GAS_PER_INCLUSION_LIST。
• 确保列出的账户中有足够的资金支付潜在的Gas费用(base_fee_per_gas + base_fee_per_gas / BASE_FEE_MAX_CHANGE_DENOMINATOR) * gas_limit。

执行负载时间线

在ePBS系统中，执行负载的处理包括分布在gossip、共识和执行层的几个关键步骤：

Gossip 执行负载通过execution_payload发布主题共享，需进行关键验证：

• 确保与负载相关的信标块是有效的。
• 验证与信标块的构建者索引和负载哈希。
• 验证构建者签名。

共识状态转换 在gossip后，负载通过on_execution_payload选择分叉处理程序进行共识验证：

• 签名验证：确保负载签名的完整性。
• 提取和包含列表验证：确认提取的正确性和遵循信标状态指定的包含列表。
• 负载一致性和EL验证：检查所有负载元素与信标状态承诺的一致性，并将负载发送到执行层进行进一步验证。
• 状态更新与验证：更新信标状态记录，并验证新的状态根，以确认准确的状态转换，latest_block_hash和latest_full_slot。

执行层状态转换 执行层扩展其角色以验证InclusionListSummary的满足情况：

• 交易和余额验证：跟踪交易或余额变动中所涉及的地址。
• 包含列表满足情况：确保每个被列在InclusionListSummary中的地址在负载中活跃，考虑当前和以前负载的交易和余额变动。
• 特殊情况处理：管理由EIP-3074等启用的独特场景。

负载证明时间线

Gossip 负载证明由PTC成员通过PAYLOAD_ATTESTATION_MESSAGE对象广播，传播前需经过严格检查：

• 当前槽验证：仅对当前槽的证明进行传播。
• 负载状态验证：证明必须具有有效的负载状态方能传播。
• 每个成员单一证明：每位PTC成员仅分享一个证明。
• 信标块根存在：证明必须与已知信标块根的槽链接。
• PTC成员资格检查：必须确认验证者是PTC的成员。
• 签名验证：证明必须具有有效签名。

选择分叉处理程序 在通过gossip验证后，负载证明通过on_payload_attestation_message处理程序在选择分叉中进行处理，包含：

• 信标块验证：确认相关的信标块在选择分叉存储中。
• PTC槽验证：验证证明者是否在指定槽的PTC中。
• 槽匹配：检查信标块是否对应于证明槽。
• 当前槽和签名检查（如果不是来自块）：对于直接广播，验证槽是否当前并验证签名。
• PTC投票更新：更新在给定区块根中跟踪的PTC投票。

信标块时间线

Gossip

• 初步验证：SignedBeaconBlock通过gossip或RPC进入，关键验证主要集中于父信标块的合法性。

on_block处理程序

• 信标块验证：根据两个父元素验证块：共识层（通过block.parent_root）和通过signed_execution_payload_header项在BeaconBlockBody推导的执行层。
• BeaconBlockBody调整：BeaconBlockBody中的修改包括移除执行负载与块KZG承诺、添加signed_execution_payload_header以及新的payload_attestations。

状态转换

• 修改的函数：process_block现在根据ePBS的变更进行调整，包括对应提取处理的修改，以及与父负载的同步。
• 提取：在两个阶段内管理；在共识块处理期间进行扣减，并在执行负载处理期间进行履行验证。
• 执行负载头：验证构建者的签名、资金和提议金额的即时转移至提议者，状态调整记录在信标状态中。

负载证明 负载证明PayloadAttestation代表信标块处理中的一个重要组成部分，为执行负载增加了PTC的验证层。

• PTC委员会组成

  • 委员会选择：get_ptc函数设计用于通过从现有信标委员会选择验证者来组建PTC，特别定位在每个委员会列表的结尾选择验证者，以形成PTC。选择过程确保PTC得到充分填补，同时对标准信标委员会的结构和功能影响最小。

• 处理负载证明

  • 证明要求：负载证明需与前一槽相关并匹配父信标块根，以确保其及时并准确引用正确的信标状态。
  • 奖励与惩罚：
  • 一致性检查：每个证明被检查以确定其连贯性。连贯的证明（例如，PAYLOAD_PRESENT在槽确实满时）将导致提议者和证明验证者均能获得奖励。这确保了其激励与负载状态准确和诚实报告相一致。
  • 奖励计算：对一致的证明，给予参与标志PARTICIPATION_FLAG_WEIGHTS，并根据证明者的基本奖励计算proposer_reward，确保验证者积极并正确参与PTC。
  • 不一致的惩罚：如果发现证明不一致（例如，于PAYLOAD_ABSENT时证明负载的存在），将施加惩罚。提议者和证明者均会受到惩罚，以防止包含不准确或误导的证明。提议者的惩罚proposer_penalty则显著加倍，以防止提议者与证明者之间的潜在共谋，即他们可能通过同时包含一致和不一致的证明而获益。

• 实现与理由

  • 避免削减条件：PTC证明的等量等操作并不设有削减条件，以防止过度严厉的惩罚措施可能打击参与意愿。然而，惩罚结构确保未有任何净利益提及相互矛盾的证明。
  • 加倍提议者惩罚的理由：加倍提议者惩罚的理由是，确保形成的场景下不会出现惩罚和奖励相互抵消的交换，从而维持抵制引入冲突证明的杠杆。

诚实验证者行为

由于引入诸如选择分叉考虑、执行负载验证和包含列表时间等新机制，验证者的角色和行为得以进一步明确，特别是提议者和PTC成员。

提议者职责

• 执行负载与包含列表准备：

  • 在指定槽之前，提议者需要从构建者选择SignedExecutionPayloadHeader并请求或构建包含列表。
  • 这些活动可在槽开始前进行，以确保准备充分和高效。

• 广播时机：

  • 提议者被激励提前广播IL，以增加其区块被证明的可能性，从而确保其区块在链中的地位。

• 构建者交互：

  • 验证者可以作为自己的构建者（自我构建）或可能与外部构建者交互。鼓励与构建者直接进行交互（非协议方法），以便实时获得最具竞争力的出价。

• 战略考虑：

  • 由于潜在MEV机会，提议者可能战略性地推迟选择或请求构建者的出价，直到进入广播区块为止。此策略是为了尽量争取可用交易池中的MEV。

提议者确定头部

• 基本原则：在槽N开始时，提议者必须有效确定链的头部，从而有效提议新的区块。这涉及评估多种情境，例如跳过槽、缺失负载和延迟负载，基于最新有效区块数据作出决策。

PTC成员职责

• 负载及时性证明：

  • PTC成员负责验证当前槽的执行负载及时性，并根据观察结果进行payload_attestation证明：
  • PAYLOAD_PRESENT：如果观察到有效的当前槽共识块和相应的执行负载。
  • PAYLOAD_WITHHELD：如果观察到有效的当前槽共识块与构建者发出payload_withheld = true的消息。
  • PAYLOAD_ABSENT：如果观察到有效共识块而没有相应的执行负载。
  • 如果未观察到当前槽的共识块则不进行证明。

• 证明条件：

  • PTC成员只会导入他们所观察到的第一个共识块，并以此为基础进行行动，确保每槽的响应都是单一、连贯的。

构建负载证明

• 操作窗口：
  • PTC成员准备于槽的约9秒内进行证明，评估执行负载是否及时并准确同步至共识块。
  • 这包括评估负载是否被正确保留，确保其证明反映实际的负载可用性或缺失状态。

验证者考量

• 验证者必须灵活应变，身兼提议者、PTC成员或一般证明者的各种角色，导航ePBS机制和维护网络完整性和安全性的复杂性。这涉及到战略决策、及时行动和遵循协议，以优化其在网络中的影响力和奖赏。

诚实构建者行为

准备多个负载

• 适应性：构建者应准备针对多种潜在父头的不同负载。这种准备使他们能够在最后时刻适应选择分叉中的变化。
• 多重出价：构建者可以提前为自己的槽提交多个出价，以增加被提议者选中的机会。

出价提交策略

• 广播出价：构建者可以通过协议外服务直接向提议者提交出价。这种策略允许构建者不断更新与优化其出价，而不必向整个网络暴露，避免被包含不太理想负载的风险。
• 首次显示消息规则：验证者仅对特定（构建者，槽）的首次有效显示消息进行gossip，这鼓励构建者尽早提交最佳出价。

直接出价请求

• 加强API规范：通过SignedBidRequest机制直接请求出价，将允许验证者向构建者直接请求执行头。这一对构建者API的小修改可以利用现有客户端代码，提高验证者和构建者之间的直接交互能力。

class BidRequest(container):
    slot: Slot
    proposer_index: Validator_index
    parent_hash: Hash32
    parent_block_root: Root

class SignedBidRequest(container):
    message: BidRequest
    signature: BLSSignature

• 密码绑定：直接请求机制可设计为将请求与验证者进行密码绑定，防止构建者根据其他人提供的出价调整自己的出价，从而降低构建者之间共谋和卡特尔化的风险。

Gossip作为备用

• 备用机制：尽管直接出价请求具有优势，但维持招标gossip的公用主题提供了一个重要的后备措施。这一系统支持在低端硬件运行的验证者或者希望优先选择社区驱动构建者的验证者，确保他们能够接触到竞争性出价。
• 防审查和防卡特尔措施：通过设定公共最小出价的方式，迫使中心化构建者如若希望审查特定交易需要超过这些社区参与的最低出价方能最终获得，确保招标提交上的竞争与透明度。
• 防止垃圾邮件：在此全局主题的加入有助于防止垃圾邮件，只允许针对给定父区块哈希的最高出价消息进行广播，并且限制每个构建者每槽只发送一条消息。

提议者与构建者交互的安全分析

构建者揭示安全性

• 场景：提议者之间进行共谋，重新组织及时揭示其负载的构建者的负载。
• 结果：安全设计确保，只要攻击者的质押不中400%，构建者所揭示的负载不能被后续提议者重新组织。
• 关键方程：若(RB > PB)，则已揭示的负载保持安全，其中(RB)为构建者的揭示加成，(PB)为提议者加成。

构建者保留安全

• 场景：构建者决定保留负载以避免入伍惩罚气候共识区块的迟到到达。
• 结果：(块，槽)投票机制支持构建者决定在区块不是链头或迟迟到达时能够选择不惩罚的状况将有效负载保持。
• 有效安全性：可以防止提议者操控区块时机，迫使负载提前揭示，确保构建者不在条件安全揭示不满足的情况下被迫交付。

提议者安全性

• 场景：与构建者协作，通过故意重组链尝试。
• 结果：分析表明，只要攻击者亦不掌控20%的质押，诚实行动的提议者及时揭示其区块将在链上视作含有。
• 详细分析：证明系统在对抗封锁及避免网络限制中，保持诚实提议者的区块的完整性，便于社区对提议者信任度重建。

总体安全考虑

• 提出的设计通过确保只有在PTC决定一致性的链中投票，从而有效应对应不同负载状态。
• 包含列表的角色起了决定性作用，加强了附有事务的链条影响并提升了功效。
• 负载加成（揭示与保留）在选择分叉时起到了关键的支持作用，影响横道权重利用其的不同状况来计入重组链与稳定性设计考虑上。

选择分叉考虑

ePBS分叉的介绍，带来了对选择分叉规则的复杂变更，特别针对构建者和提议者的安全。这些变更旨在适应网络延迟和诸如负载保留这些战略性行为。

ePBS forkchoice的关键概念：

• （区块，时隙）投票：

  • 该机制确保如果一个区块迟到，验证者将支持最后一个及时的区块，而不是迟到的区块。
  • 一致地，迟到的区块会因为验证者继续支持较早的及时区块而积累较少的权重。

• 有效负载状态处理：

  • 有效负载的状态（缺失、空、完整）会影响验证者对链的支持。
  • 投票支持与有效负载状态的 PTC 决策一致的链，以确保有效负载基于及时的可用性被包含或排除。

• 包含列表可用性：

  • IL 的存在和验证至关重要。验证者可能根据具有完全验证的 IL 的最新区块来判断头部。
  • 这种考虑确保建立在适当包含的交易上的区块受到青睐，从而增强链的完整性。

• 有效负载提升的安全性分析：

  • 构建者的公开提升（RB）和隐瞒提升（WB）被引入以根据构建者在公开或隐瞒有效负载方面的行动来奖励或保护他们。
  • 这些提升显著影响分叉选择，通过改变权重计算，可能导致链的再组织或基于有效负载的可用性和完整性进行稳定化。

实际示例：

• 正面案例显示所有区块和有效负载按时到达并获得全面支持的正常操作。
• 迟到的区块和有效负载展示了验证者将支持转向早期区块的场景，从而影响潜在链分叉的权重分布。
• 有效负载状态场景展示了投票如何根据有效负载的可用性支持或排除某些区块，从而与 PTC 投票保持一致。
• 包含列表考虑强调了这些列表在确定规范头部方面的影响，特别是在缺失或延迟包含数据的情况下。

ePBS 的未解问题

在以太坊协议中，Mike 在确立 PBS（ePBS）时提出了一些有趣且具有挑战性的未解问题^5。

绕过性意味着什么？

绕过性突出了过渡到 ePBS 的一个关键挑战：验证者和构建者可能会继续依赖外部中继或解决方案，而非确立的协议。这里的担忧有两个方面：首先，如果网络中大部分参与者选择不参与，这对 ePBS 的有效性提出了质疑；其次，它探讨了设计一个无法被绕过的系统的可行性，而不会对验证者的自主性或以太坊的去中心化精神施加不合理的限制。

确立的目标是什么？

确立 PBS 的目标是为以太坊协议引入一个中立、无信任的中继，以标准化和保护提议者与构建者之间的关系。该倡议旨在缓解诸如 MEV-Boot 等协议外解决方案所固有的中心化风险，增强审查抵抗，并可能作为更系统性地解决与 MEV 相关问题的基础步骤。确立 PBS 尽管面临绕过问题，但仍然可以提供一个可靠的后备机制，鼓励更多的验证者直接参与该协议，并与长期目标（如 MEV 重新分配机制，例如 MEV-burn）保持一致。

不确立的确切影响是什么？

选择不确立 PBS 实质上将区块构建和 MEV 分配的重大控制权交给外部系统，可能加剧中心化和安全脆弱性。这一让步可能需要优先为中立中继提供资金和支持，作为维护公平竞争环境和保护 MEV 市场抵御垄断行为的关键基础设施。

ePBS 的实际需求有多大？

ePBS 在以太坊生态系统中的实际需求来自多个因素，这些因素旨在解决当前限制并为网络的可扩展性、安全性和去中心化做好准备。这些需求源于以太坊区块生产的不断演变及 MEV 机会日益复杂的局面。量化 ePBS 的实际需求是一项重大挑战，但这是以太坊社区针对当前挑战并预判未来需求的更广泛需求的一个反映。

我们在多大程度上可以依赖利他主义和社会层面？

社会层面，以太坊社区的规范和价值观，扮演着引导行为的关键角色，而这些行为仅凭协议机制是无法强制执行的。尽管利他主义或长期自利可能驱动一些大型 ETH 持有者支持确立的解决方案，但单纯依赖这些动机并不可靠。以太坊的完整性和去中心化理应由稳健的、可执行的机制支撑，而不是对理想的自愿遵守。

L1 ePBS 在有 L2 和 OFA 的未来中有多重要？

随着以太坊路线图的发展，L2 解决方案的活动逐渐增加以及 OFA 的开发，L1 MEV 的直接影响可能会减弱。然而，由 ePBS 提出的原则和基础设施仍可能在构建安全和去中心化的 MEV 管理机制方面发挥至关重要的作用，从而保持 ePBS 在多层生态系统中的相关性。

鉴于其他协议升级，ePBS 应有多高的优先级？

考虑到复杂的格局和以太坊 MEV 动态可能发生的重大变化，ePBS 相对于其他升级（例如，审查抵抗增强，单时隙确定性）的优先级需要一种战略方法。社区可能会考虑集中精力关注具有更清晰即时收益和较低实施风险的升级，同时继续研究和开发 ePBS 框架，以便在需求更加迫切时能迅速部署。

参考文献

• 原文链接： github.com/thogiti/thogi...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～