基于再质押实现预确认的应用

要点： 我们介绍了一个基于以太坊的 preconfirmations 协议的探索性实现，用于在亚秒级交易确认，灵感来自 Justin Drake 的提议。

感谢 @diego, William X, @ballsyalchemist, @ed, Tim Becker, @justindrake, Cooper Kunz, 以及其他人的反馈和讨论。

\ preconfirmations1024×1024 345 KB

背景

以太坊 preconfirmations，或简称 “preconfs”，是一种提议的机制，旨在实现更快的交易确认，并改善以太坊上的用户体验，进而改善 layer 2 的 Rollup 和 Validium。其核心思想是让以太坊区块提议者向用户发布签名承诺，保证用户的交易将被包含在某个区块中。用户为这项服务向区块提议者支付小费。通过从即将到来的区块提议者那里获得 preconfirmation 承诺，用户可以获得快速包含的保证，延迟低至 100 毫秒。Preconfirmations 可以应用于广泛的用例，例如具有常规节奏的 L2 的及时 blob 交易、未来区块空间的市场以及包含约束的表达性。

实现

查看 GitHub 上的实现

这个 preconfirmations 的实现利用 EigenLayer 的 AVS (Actively Validated Services) 系统来支持 slashing 机制，确保 preconfirmation 保证的安全性。希望参与 preconfirmation 服务的以太坊验证者必须通过 EigenLayer 选择加入，并运行 AVS 软件，即 preconf-operator，这使他们能够接收和确认他们将提议的区块的 preconfirmation 承诺请求。如果 preconfirmation 被违反（安全故障）或未包含在已建立的区块中（活跃性故障），则可以将故障证明发布到服务智能合约，从而导致追溯 slashing 验证者的 stake。

为了简化用户体验，我们引入了 preconf-share，它是 MEV-Share 的一个分支，充当用户和区块提议者之间值得信赖的媒人。用户将 preconfirmation 请求以及提示提交给 preconf-share 节点，然后该节点将请求传递给作为下一个区块提议者的验证者。根据请求提示和相关的小费，区块提议者决定是否承诺 preconfirmation。preconf-share 节点接收并根据用户的偏好（例如所需的和最大区块）对 preconfirmation 承诺进行排序。一旦选择了 preconfirmation 承诺，区块提议者就会收到应该包含在承诺区块中的原始交易。用户收到 preconfirmation 的收据，并且区块提议者的签名承诺将公开，如果承诺被违反（连同证明一起），则可以将其用作证据。

为了进一步增强用户体验，并使钱包能够使用 preconfirmations 而无需更改，我们为 preconf-share 引入了一个受信任的 JSON-RPC 包装器。此包装器是从 Flashbot 的 RPC 端点 分叉而来，允许用户定义其默认的 preconfirmation 首选项和提示标准。

Preconf-Operator

希望接收和承诺 preconfirmations 的验证者必须在 EigenLayer 服务中注册并运行 preconf-operator AVS 客户端。初始化后，此客户端将给定的验证者注册到服务智能合约，并开始监听由受信任的第三方运行的 preconf-share 节点的事件流。当收到 preconfirmation 请求时，客户端会评估其可用的参数，以确定是否发送承诺。例如，区块提议者可能更愿意接受包含日志或 calldata 信息的请求，即使它们的小费较低，因为这为价值提取或 OFAC 限制打开了大门。相反，信息很少的请求可以附带高额小费，以平衡信息的缺乏并获得更高的包含率。区块提议者还必须考虑他们为未来区块做出的其他 preconfirmations，以确保新的 preconfirmations 不会与从全球公共 mempool 中获得的交易发生冲突。

如果区块提议者将 preconfirmation 承诺发回给 preconf-share 节点，则 preconf-operator 客户端将等待定义的窗口时间，以防他们提供最佳承诺，并因此收到完整的 preconfirmation 信息，包括原始交易，以履行承诺。如果对特定的未来区块做出了承诺，则 preconf-operator 客户端将持有交易，直到轮到他们提议该区块为止。重要的是要注意，尽管 preconf-share 节点对用户请求和 preconfirmation 承诺都强制执行一系列检查，但如果区块提议者为他们未构建/提议的区块（或者如果他们将工作委托给未履行承诺的另一方）提供协议外的承诺，他们仍然可能被 slashing。

请求事件模式

{
    hash: string,
    inclusion: RequestInclusion,
    logs?: LogParams[],
    txs: Array<{
        to?: string,
        functionSelector?: string,
        callData?: string,
    }>,
}

• hash： 交易或请求哈希的十六进制字符串。
• inclusion：包含参数，包含区块目标、最大区块和小费。
• logs：通过使用最后状态执行交易而发出的 JSON 编码的事件日志数组。

• txs：请求中的交易，对于每个交易：

  • to：交易接收者地址
  • functionSelector：4 字节函数选择器。
  • callData：交易的 Calldata。

承诺回调方案

{
    hash: string,
    txs: Array<{
        tx: string,
    }>,
}

• hash： 交易或请求哈希的十六进制字符串。
• inclusion：包含参数，包含区块目标、最大区块和小费。
• logs：通过使用最后状态执行交易而发出的 JSON 编码的事件日志数组。

• txs：请求中的交易，对于每个交易：

  • tx：原始交易字节。

证明 & Slashing

preconf-share 节点发布签名的 preconfirmation 承诺，使任何人在目标区块通过后都可以通过发布保证金来提出异议。slashing 智能合约通过检查签名是否由有效的区块提议者正确签名来验证 preconfirmation 承诺的真实性。如果签名有效，则合约会打开一个挑战窗口，在此期间，区块提议者有机会通过提交交易包含证明来赢得争议。

该证明由区块提议者在链下构造，并传递给 slashing 智能合约，然后由该合约将其提交给 Relic Protocol 的交易证明器。证明器验证给定的交易哈希是否确实包含在指定的区块中。如果区块提议者成功证明了交易的包含，则争议者将失去其保证金，然后将其作为奖励转移给区块提议者，以奖励他们的诚实。

但是，如果区块提议者未能在指定的挑战窗口内做出回应，则争议者将自动赢得挑战。在这种情况下，区块提议者被认为违反了他们的承诺，并随后被 slashing，他们的一部分 stake 可能会作为奖励重新分配给争议者。

展望未来，Tim 提出了添加非存在证明以简化争议流程的可能性。这种方法将权衡当前设计的交互性和通信轮次，以换取更高的成本。通过利用非存在证明，争议者可以通过证明交易哈希不存在于目标区块中来直接证明区块提议者违反了他们的承诺。这种优化将减少对区块提议者积极参与争议解决过程的依赖，从而提高 slashing 机制的效率和无需信任性。与包含证明类似，非存在证明也将由争议者在链下生成，并提交给 slashing 智能合约以进行验证。

Preconf-Share

preconf-share 组件充当用户发送和接收请求以及区块提议者以极低的延迟和成本发送承诺的 API 端点。此外，preconf-share 充当用户和区块提议者之间的中介，屏蔽双方的 IP 地址。从 MEV-Share 继承的功能，例如通过隐私设置和包含条件提供的提示，有助于控制委托代理问题 (PAP)，即区块提议者可能取消请求的绑定，仅包含小费交易，而忽略请求中的其他交易。这是通过以下措施实现的：

1. 中继用户请求时，仅将交易哈希、提示、小费和偏好与区块提议者共享。
2. 签名的原始交易仅与提供最佳 preconfirmation 的区块提议者共享。

preconf_sendRequest

preconf_sendRequest 允许用户发送具有隐私设置和包含条件的签名交易的 preconfirmation 请求。

{
    inclusion: {
        desiredBlock: string,      // hex-encoded number
        maxBlock?: string,         // hex-encoded number
        tip: string,               // hex-encoded number (wei)
    },
    body: Array<
        { tx: string }
    >,
    privacy?: {
        hints?: Array<
            "calldata" |
            "contract_address" |
            "logs" |
            "function_selector" |
            "hash" |
            "tx_hash"
        >,
        operators?: Array<string>,
    }
}

• inclusion：preconf-share 节点用于对 preconfirmation 承诺进行排序和过滤的参数。

  • desiredBlock：包含此请求的最佳区块。
  • maxBlock：可能 包含此请求的最大区块高度。
  • tip：支付给区块提议者的小费，以 wei 为单位，必须与请求中的小费交易匹配。
• body：签名交易的数组。它必须包含小费交易并与 inclusion 参数中的 tip 金额匹配。

• privacy：关于应与区块提议者共享的请求数据的首选项。

  • hints：每个项目附加地指定要共享的有关请求中所有交易的数据。如果未指定提示，则不共享任何交易数据。
  • operators：有权接收此请求并提供承诺的区块提议者的地址。

preconf_confirmRequest

preconf_confirmRequest 允许区块提议者发送签名的 preconfirmation 承诺。

{
    preconf: {
        request: PreconfSendRequestParams,
        block: string
    },
    signature: string
}

• preconf：preconfirmation 的内容，由从流收到的用户请求和区块提议者将包含请求交易的区块号组成。

  • request：从 preconf-share 流收到的请求。
  • maxBlock：区块提议者将包含请求交易的区块。preconf-share 验证区块提议者既是 AVS 的运营商又是该区块的提议者。
• signature：使用区块提议者（运营商）的私钥签名的 preconf 参数。

交易流程

\ swimlanes-f8dc5a95d3307a60e4fff4dc4dfb1bbf1300×1011 71.3 KB

\ preconf-post-final4249×1908 588 KB

安全性

该协议的经济安全性依赖于使用 EigenLayer 的 AVS 实现。为了使保证被认为是安全的，腐败的成本必须超过腐败的利润，从而形成对恶意行为的威慑。在当前的以太坊设计下，staker 最多可以将其抵押的 ETH 总量的 50%（16 ETH）进行 slashing。因此，如果出现以下情况，区块提议者有动机违反 preconfirmation 承诺：

• 请求中的小费总和超过 16 ETH。在这种情况下，区块提议者可以取消请求的绑定，并且仅在一个区块中包含小费交易，从而从小费中获利，同时避免执行其他交易。
• 使用请求交易提取价值的利润总和超过 16 ETH。例如，区块提议者可以选择取消包含白帽资金救援和小费的请求的绑定，并且仅包含小费，同时用他们自己完成的救援来替换白帽救援（本质上保留救援资金和小费），从而导致部分包含。

重要的是要注意，被 slashing 的 ETH 可能会被 AVS 用于补偿受到不公正待遇的各方，例如这些情况下的受影响用户。但是，诸如 gas 费用、复杂性和机会成本之类的外部因素也会影响腐败的成本。

在 MEV 的上下文中，16 ETH 的 slashing 惩罚可能并不总是足以在经济上保护交易，这与 PBS 实现下发生的问题类似。根据 libMEV 从 2 月 23 日到 3 月 24 日的数据，有 5 个 bundle 为搜索者带来了超过 16 ETH 的利润：22.33 ETH, 32.53 ETH, 59.19 ETH, 和 124.36 ETH。然而，值得注意的是，在此期间登陆链上的 183,440 个 bundle 中，平均利润为 12.53 美元，占总价值的百分比很小。这表明绝大多数交易可以通过 16 ETH 的 slashing 罚款在经济上得到保障。

为了增强单个 preconfirmation 承诺的安全性，可以探索三种潜在的方法：

1. 实施一个除了 slashing 机制之外还提供额外保证的 attestation 系统。
2. @diego 的一个想法是扩展 AVS 或 EigenLayer 智能合约，以允许区块提议者 stake 额外的 ETH，从而增加违反 preconfirmation 承诺的潜在成本。
3. 正如 @ed 指出的那样，使用 enshrined execution tickets 实施 preconfirmations，其目的也旨在解决经济安全问题。

展望未来

在本地网络上开发和测试了该协议之后，自然的下一步是在测试网环境中部署它。这将为系统各种组件和动态如何在更实际的环境中发挥作用提供有价值的见解。

一个需要探索的关键领域是 preconfirmations 和 mev-boost 之间的交互。在当前的实现中，区块提议者既充当区块构建者又充当提议者。但是，将 preconfirmations 与 mev-boost 集成可能会扩大区块提议者的范围并提高系统的效率。为了实现与 mev-boost 的兼容性，需要建立一个通信渠道，使区块提议者能够与构建者共享其 preconfirmation 承诺，然后构建者可以将它们包含在其正在构建的区块中。

重要的是要注意，这种方法引入了一个信任假设，因为区块提议者需要依赖构建者将他们的承诺包含在构建的区块中，而包含列表提供了一种无需信任的替代方案。缓解这种信任假设的另一种潜在解决方案是利用在受信任的执行环境 (TEE) 下运行的构建者，例如 SUAVE 中的构建者。preconf-share 节点也被信任不会发布未选择的签名 preconfirmations，因此最终应该分散化（类似于 mev-boost 中继）。

要考虑的另一个方面是成为区块提议者的复杂性。对于许多 EigenLayer AVS 用户来说，有效作为区块提议者进行操作所需的复杂性可能非常高。另一方面，构建者已做好承担这一角色的准备，因为他们已经拥有区块构建所需的专业知识和基础设施，并且开发了内部算法来优化交易包含。因此，不太复杂的区块提议者可能会选择将 preconfirmation 职责分担给专业的各方。

为了进一步增强协议并探索其潜力，可以进行几个领域的研究和开发：

1. 调查 AVS 的经济激励和博弈论方面，以确保稳定和安全的系统。
2. 开发更高级的区块提议者算法，以优化交易包含并最大化其奖励。
3. 探索与 mev-boost、MEV-Share 和块内条件（例如块顶部的 preconfirmations）的潜在交互。

参考文献

• Justin Drake 的 基于 preconfirmations
• Ellie Davidson 等人的 分析 BFT & 提议者承诺的 Preconfirmations
• Flashbots 的 MEV-Share

查看 GitHub 上的实现

• 基于提议者的承诺 - 以太坊提议者承诺市场
• 可信中立的 Preconfirmation 抵押品：Preconfirmation 注册表

• 原文链接： ethresear.ch/t/towards-a...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～