用基于预确认的方式增强以太坊交易

概述

基于预确认（preconfs）代表了以太坊交易处理的重大进展，为用户提供了快速可靠的执行。通过链上基础设施、提议者问责机制和灵活的承诺获取过程的结合，预确认有望显著提升用户在以太坊交互中的体验。这项技术不仅减少了交易延迟，还引入了生态系统中前所未有的安全和效率层次^1。

预确认的构建

预确认依赖于两个基础的链上基础设施组件：

• 提议者削减（Proposer Slashing）： 提议者可以选择额外的削减条件，以确保可靠性和问责性。该设置假定使用 EigenLayer 风格的重新质押来支持削减机制。

• 提议者强制纳入（Proposer Forced Inclusions）： 提议者有权强制将交易纳入区块链。在提议者与构建者分离（PBS）使得自建不可行的情况下，这一点尤为重要。该机制假定使用纳入列表来实现。

层级 1（L1）提议者通过选择两个特定的预确认削减条件，成为“预确认者”。预确认者向用户提供签名的预确认承诺，并为履行这些承诺获得小费。预确认者之间的优先级由它们的插槽位置决定，插槽编号较小的优先级更高。

已经收到预确认承诺的交易有资格被任何在承诺发出者之前的提议者立即纳入链上并执行。预确认者的主要责任是履行其插槽中的所有未尽承诺，利用纳入列表。

承诺故障分为两类，均需接受削减：

1. 活性故障（Liveness Faults）： 如果一个预确认者错过其插槽，且承诺的交易未曾在链上纳入，则会发生。

2. 安全故障（Safety Faults）： 当预确认者的插槽未被错过，但承诺与链上已纳入的交易相矛盾时，会出现。

为优先处理预确认交易，引入了一条用于非预确认交易的执行队列，确保带有预确认承诺的交易先执行。

预确认获取的关键要素

图：承诺获取过程流程。来源：Justin Drake

对于寻求预确认交易的用户，初步步骤涉及从下一个排队的预确认者那里获取承诺。该过程涵盖多种考虑因素，包括：

• 端点（Endpoints）： 预确认者可以提供点对点的 API 端点或利用点对点（p2p）传播通道来接收和发出承诺，在延迟和可访问性之间取得平衡。

• 延迟（Latency）： 直接连接可以实现低至 100 毫秒的预确认延迟。

• 引导（Bootstrapping）： 需要相当比例的 L1 验证者参与作为预确认者，以确保至少有一个预确认者可能在前瞻中。

• 活性回退（Liveness Fallback）： 用户可以通过从多个预确认者处获取承诺来降低活性故障的风险。

• 并行化（Parallelization）： 系统能够支持多种类型的承诺，从对后执行状态的严格承诺到更灵活，基于意图的承诺。

• 重放保护（Replay Protection）： 确保交易免受重放攻击，对于维持预确认交易的完整性和安全性至关重要。

• 单一秘密领导者选举（SSLE）： 在前瞻中促进预确认者的隐秘发现，使预确认者能够证明其角色，而不损害其身份。

• 委托预确认（Delegated Preconf）： 为带宽或计算资源有限的提议者提供解决方案，允许他们委托预确认责任，确保承诺发行保持高效。

• 公平交换（Fair Exchange）： 解决提议者不公正收取小费的潜在问题，建议实时承诺广播或可信的中继来确保用户与预确认者之间的公平交换。

• 小费定价（Tip Pricing）： 倡导对预确认小费谈判的动态方法，考虑交易对提议者从最大可提取价值（MEV）机会中预期价值的潜在影响。

• 负小费（Negative Tips）： 引入负小费的概念，对于可能增加预确认者 MEV 的交易，鼓励提议者优先处理这些交易。

以上每个要素在基于预确认的功能和效率中起着至关重要的作用，确保交易不仅快速处理，而且在以太坊生态系统中安全、公平。

预确认获取过程流程

图：承诺获取过程流程

sequenceDiagram
    participant User as 用户
    participant Preconfer as 预确认者
    participant Blockchain as 以太坊

    rect rgb(191, 223, 255)
    用户->>+预确认者: 确定并发送承诺请求
    Note over 用户,预确认者: 用户根据插槽位置选择下一个预确认者并发送交易承诺请求。

    预确认者->>-用户: 评估请求
    Note over 用户,预确认者: 预确认者评估请求，考虑网络情况、预确认小费和 MEV 潜力。
    end
    rect rgb(177,176,159)
    预确认者->>+用户: 发出预确认承诺
    Note over 用户,预确认者: 如果接受，预确认者将签名的预确认承诺反馈给用户。
    end
    rect rgb(191, 223, 255)
    用户->>预确认者: 转移预确认小费
    Note over 用户,预确认者: 用户将约定的预确认小费转给预确认者作为补偿。
    end
    rect rgb(177,176,159)
    预确认者->>+区块链: 包括并执行交易
    Note over 预确认者,区块链: 在指定插槽中，预确认者将交易纳入其区块提案以执行。

    区块链->>-用户: 验证交易执行
    Note over 用户,区块链: 一旦在链上执行，用户和预确认者都将验证承诺的履行。
    end

承诺获取过程在以太坊的顺序和预确认机制中是一个关键方面，确保交易从提议者或顺序者那里获得预确认或“承诺”。该过程涉及多个步骤，每一步对确保承诺交易将在指定时间框架内被纳入和执行至关重要。以下是承诺获取过程流程的详细说明：

1. 用户确定下一个预确认者

• 起点： 用户或智能合约通过识别以太坊网络前瞻窗口中下一个可用的预确认者（已选择提供预确认服务的提议者）来启动该过程。

• 选择标准： 该选择基于提议者在提议者前瞻中的插槽位置，在此提议者已通过发布抵押品声明其能力和愿望。

2. 向预确认者发送承诺请求

• 启动： 用户向识别出的预确认者发送承诺请求。该请求包括所需预确认的交易的详细信息，以及任何特定的条件或要求。

• 通信通道： 请求可以通过预确认者建立的各种链下通信通道发送，例如专用 API 端点或点对点消息传递系统。

3. 预确认者评估请求

• 评估： 收到请求后，预确认者根据多个因素评估该请求，包括当前网络状况、用户提议的预确认小费金额以及执行该交易的整体风险。

• 决策： 预确认者决定是接受还是拒绝承诺请求。此决策可能涉及计算潜在的 MEV 并评估交易是否符合预确认者的标准。

4. 发出预确认承诺

• 承诺生成： 如果预确认者决定接受请求，他们将生成签名的预确认承诺。该承诺包括预确认者在其即将到来的插槽中确保交易的纳入和执行的承诺，遵循约定的条件。

• 承诺沟通： 预确认承诺随后反馈给用户，为他们提供交易执行的保证。使用的通信方式与初始请求类似，以确保安全和可验证的交付。

5. 支付预确认小费

• 小费转移： 收到预确认承诺后，用户将约定的预确认小费转给预确认者。该小费作为提供服务的补偿，并激励预确认者兑现承诺。

• 托管机制： 在某些实施中，小费可能在承诺履行之前由托管持有，为用户增加了一层额外的安全性。

6. 交易的纳入与执行

• 链上履行： 预确认者在其指定插槽中将预确认的交易纳入其提案区块中，并根据预确认承诺中概述的条款执行。

• 履行验证： 一旦交易在链上纳入并执行，预确认者和用户都可以验证承诺已成功履行，完成这一过程。

额外考虑：

• 回退机制： 如果出现意外问题或首次预确认者未能包含交易，用户可能会有回退选项，例如并行请求来自多个预确认者的承诺。

• 争议解决： 系统可能包含用于解决争议的机制，以处理承诺是否已充分履行的分歧。

参考文献

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