Signal-Boost：Rollup 的 L1 互操作插件 - Layer 2

_该团队的研究重点是 Fabric 和 Commit-Boost。感谢 EF Research、Nethermind、Espresso、Taiko、OpenZeppelin、Spire、ETHGas、Gattaca、L2Beat、Labrys、Luban、Puffer 和 Interstate 的个人提供的反馈、贡献和审查。反馈、贡献和审查并不意味着认可。_

\ image1024×1024 42.1 KB

TL;DR（太长不看）

• Gwyneth 提出的 Ultra Transactions 引入了一种强大的设计，通过利用区块顶部（ToB）的 L1 交易执行、巧妙的跨域上下文切换和实时证明，来实现 L1 和Based Rollup 之间的同步可组合性。
• Nethermind 提出的 Same-Slot Message Passing 通过消息合约在单个 slot 内实现 L1→L2 通信，为原子 L1<>L2 交易奠定了基础。
• Signal-Boost 结合了这两种方法的见解，为现有的 rollup 提供灵活的 L1 同步可组合性，对其技术栈进行最小化或无需更改。
• 这使得以太坊能够立即为现有的 rollup 提供效用，同时也为随着Based Rollup 生态系统的不断成熟而转变为基于式提供了一条途径。
• 这不需要以太坊进行协议内更改，而是利用 PBS 管道、Commit-Boost 和 Constraints / Commitments API。
• 最后，我们注意到，选择成为基于式的 rollup 仍然可以从以太坊解锁 Signal-Boost 提供的额外好处。
• 一个约 100 行代码的 PoC 实现可以在 这里 找到。

动机

• 分裂仍然是 rollup 中心化路线图面临的核心挑战之一。
• 它引起了业界的关注，导致了多个旨在提高互操作性的并行努力。这些可以 broadly 地分为实现异步或同步互操作性的方法，包括意图、共享桥、共享排序、基于排序和实时证明。
• 其中，同步可组合性（“SC”）是最引人注目的解决方案，因为它允许 rollup 在执行期间以原子方式并在同一 slot 高度内读取和响应彼此的当前状态，从而使用户和应用程序能够以单个统一链的感觉跨链交互。
• 随着实时证明即将到来，以太坊将很快具备 L1 SC 的所有先决条件。
• SC 通常与共享排序相关联，在共享排序中，对多个 rollup 域具有写锁的公共排序器可以保证它们之间的协调。由于只有 L1 提议者对以太坊具有写锁，因此涉及 L1 的 SC 通常保留给使用 L1 提议者作为其 L2 排序器的Based Rollup。虽然Based Rollup 正在进入市场，但它们仍处于早期阶段，仅占生态系统的一小部分。与此同时，现有的 rollup 仍然与 L1 隔离，因此有必要依赖具有 UX 和 DevEx 权衡的异步互操作性解决方案。
• 将现有 rollup 迁移到支持基于排序可以被视为双赢。以太坊受益于减少的分裂和更强的网络效应，而 rollup 可以通过更快的 UX 访问 L1 用户和流动性。
• 尽管有这些好处，但 rollup 尚未采用基于排序是有原因的：没有“skin-in-the-game”排序器的潜在 UX 回归、没收的 L2 MEV 收入、不成熟的技术（如实时证明）以及修改其技术栈的成本和复杂性。
• Fabric 正在与社区合作实现两个目标：1) 为现有 rollup 成为基于式创建一条途径，以及 2) 使新的Based Rollup 更容易启动。
• 考虑到第一个目标，我们开始问：我们是否可以将 SC 与基于排序分离，以及我们是否可以以一种不仅今天有效，而且还为未来成为基于式创建一条更清晰的途径的方式进行？
• Nethermind 在 Same-Slot Message Passing 上的工作已经表明，L1 和 L2 之间有意义的协调是可能的，而无需将排序完全转移到 L1 提议者。尚未充分探索的是如何以最小化摩擦的方式将这种见解扩展到现有 rollup。
• 我们提出 Signal-Boost，为现有 rollup 提供一条与 L1 实现按需 SC 的途径，而无需它们成为基于式。这使得以太坊能够立即提供有价值的协调服务，同时仍然为基于式的未来铺平道路。
• 我们希望这种方法可以让 rollup 两全其美，即在不彻底改革其技术栈的情况下访问 SC。它不能替代Based Rollup，而是向前迈出的补充一步，有助于以太坊在基于生态系统持续成熟的同时吸引更广泛的市场。

背景

Same-Slot L1→L2 消息传递

Nethermind 的研究通过两条链上的配对消息合约实现 same-slot L1→L2 消息传递。这允许 rollup 在同一 slot 内对某些 L1 操作（例如 L2 存款）做出反应。这足以实现同步和原子的跨链捆绑，“例如从 L1 存入 ETH，在 L2 上将其换成 USDC，然后提取回 L1。”

重要的是，他们得出了一个关键的见解，即“L2 提议者不必是 L1 构建者。”这意味着这些交互不需要基于排序，而是需要 L2 和 L1 之间一定程度的协调。

但是，它有一个主要的限制：L2 无法读取任意的 L1 状态，只能读取已写入 L1 消息合约的内容。

Ultra Transactions

Gwyneth 提出的 Ultra transactions 实现了 L1 和Based Rollup 之间的 SC。

• 它们将 L1 和 L2 交易捆绑到一个巨大的原子 L1 交易中（通过由“主构建者”进行帐户抽象来构建），该交易始终插入到区块的顶部 (ToB)，以保证从最新的 L1 状态开始的干净执行。
• 提议的 XCALLOPTIONS 预编译启用了无缝跨域调用，包括在 L2 域中模拟和执行 L1“元交易”的能力，从而实现了同步的 L1->L2 调用。
• 一个大型证明伴随该捆绑包，验证所有 L2 状态转换和元交易执行。
• 这种结构允许 L1 和 rollup 同步读取状态并跨彼此的域调用合约。

Ultra transaction 模型的两个关键见解是：

1. ToB 执行对于确保所有状态转换都从已知的、干净的 L1 状态开始是必要的
2. 帐户抽象是一种强大的原语，用于批量处理跨域交易。

L1→L2 消息传递的 Push vs Pull 语义

Same-slot 消息传递本质上是 push-based：L1 必须显式地将数据写入 SignalService 合约，以便 L2 在同一 slot 中读取它。相比之下，ToB 执行启用了 pull-based 访问，其中 L2 可以同步读取任意的 L1 状态——但只能在区块的最开始，限制了用例。

在 EIP-7814 等提案生效或对技术栈进行彻底修改以支持 L1 元交易之前，push-based signaling 是在区块中期执行期间访问当前 L1 数据的最佳方式。

L1 Reorgs

与 L1 的 SC 要求 rollup 读取未确认的 L1 状态，而不是已确认或最终确定的状态。从未最终确定的 L1 数据构建其状态的 Rollup 受到 L1 重组风险的影响，即先前消耗的 L1 输入可能不再存在，从而导致相关的 L2 状态发生变异，他们必须接受或选择回滚 rollup 的状态。

为了缓解这种情况，大多数 rollup 故意滞后于 L1 head。例如，OP Stack 使用 4 个区块的 SequencerConfDepth，而其他 rollup 则等到 L1 最终确定。此缓冲区有助于 L1 输入在消耗前稳定，使 rollup 能够提供更可信的预确认。但是，引入任何滞后都与 L1 SC 根本不兼容。

这不一定是一个二元决策，而是一个范围：

• 更多的 L1 耦合 = 更好的互操作性，更高的重组风险
• 更多的 L1 解耦 = 更差的互操作性，更少的重组风险

Signal-Boost 的目标是该范围的中间，以便在 L1 重组风险合理时允许按需 SC，但默认选择风险较低的选项。

Signal-Boost 概述

我们的目标是让 L2 实时接收并响应 L1 状态。Same-slot 消息传递通过允许 L2 在同一 L1 slot 中消耗 L1 上写入的数据来实现这一点。但这仅适用于显式写入 SignalService 合约的 L1 数据。

这造成了一个关键的限制：像 Chainlink 或 Uniswap 这样的协议需要主动将其数据推送到 L2，这需要更改其合约逻辑。

Signal-Boost 通过采用 request-before-push 模型来解决此问题。任何人都可以查询任意的 L1 view 函数，并以可验证的方式将结果推送到 SignalService 合约，而不是要求 L1 合约发出信号。在实践中，这在 L2 排序器完成时尤其有用。

通过解锁对实时 L1 数据的访问，而无需更改上游合约，这大大提高了 same slot 消息传递的效用。但是，它带来了新的挑战：如果信号在 slot 中期发生更改会发生什么？L2 用户如何响应或验证？

为了解决这些问题，Signal-Boost 结合了 Ultra transactions 的思想，包括 EIP-7702 智能帐户用于委托执行，以及 ToB 包含用于状态保证。

SignalBoost 合约

为了使 same-slot 消息传递更容易采用，我们需要一种将 L1 数据转换为 L2 可以信任的可验证信号的方法。SignalBoost 合约通过允许任何人查询 L1 view 函数并将结果以下游 L2 合约可以立即使用的格式在链上提交来实现此功能。

1. 你准备一个要在 L1 上进行的只读查询列表，例如：

   • “这个 Chainlink 合约中的价格是多少？”
   • “这个地址的余额是多少？”
   • “这个金库是否活跃？”

查询被编码为 SignalRequest

// SignalRequest 的定义
struct SignalRequest {
    // 要查询的 L1 合约
  address target;
  // view 函数的函数选择器
  bytes4 selector;
  // 任意函数输入
  bytes input;
}

2. 你将此列表提交给 SignalBoost 合约，该合约：

   • 使用它们的 view 函数调用所有 L1 合约
   • 将输入与结果哈希
   • 从数据构建一个 Merkle 树
   • 将该树的根（称为 signalRequestsRoot）发布到 L1 上的 SignalService 合约

// SignalBoost L1 合约中的函数
function writeSignals(SignalRequest[] memory requests) external {
    bytes32[] memory leaves = new bytes32[](requests.length);

    for (uint256 i = 0; i < requests.length; i++) {
        // 使用 selector 和 input 编码调用
        bytes memory payload = abi.encodeWithSelector(
            requests[i].selector,
            requests[i].input
        );

        // 调用 view 函数
        (bool success, bytes memory output) = requests[i].target.call(payload);
        require(success, "SignalBoost: call failed");

        // 创建 Merkle 叶子节点
        leaves[i] = keccak256(abi.encode(requests[i], output));
    }

    // 计算 Merkle 根
    bytes32 signalRequestsRoot = merklize(leaves);

    // 写入 SignalService 合约
    SignalService.sendSignal(signalRequestsRoot);
}

3. 现在 L2 排序器可以：
   • 从 L1 读取 signalRequestsRoot
   • 将其包含在 L2 发布中
   • 允许 L2 智能合约使用 same-slot 消息传递中描述的相同技术在同一 L1 slot 中验证通过 Merkle 证明的单个信号。

从 L2 开发人员的角度来看，他们可以验证 L1 output 来自正确的 L1 合约调用。以下是一个读取 L1 Oracle 数据的示例，该数据可以被其他 L2 合约使用。

// L2 上的示例函数
function readL1Pricefeed(bytes calldata output, bytes32 signalRequestsRoot, bytes[] calldata proof) external returns (uint256) {
    // 验证信号已写入 L2 SignalService
    require(SignalService.verifySignal(signalRequestsRoot), "Signal not found");
    // 为此上下文重建 SignalRequest
    SignalRequest memory request = SignalRequest {
            target: L1_ORACLE_ADDRESS,
            selector: bytes4(keccak256("getPrice()")),
      input: bytes("")
        };

    // 重建 Merkle 叶子节点
    bytes32 leaf = keccak256(abi.encode(request, output));

    // 验证 Merkle 证明
    require(verifyProof(signalRequestsRoot, leaf, proof), "Invalid Merkle proof";

    // 解码 Oracle 价格
    uint256 price = abi.decode(output, (uint256));

    return price;
}

智能帐户

为了确保信号尽可能与 L1 保持最新，我们希望在发布 L2 批处理之前立即执行 SignalService.writeSignals()。

使用 EIP-7702 智能帐户有助于协调这一点。它们允许 L2 排序器将其自己的交易与预签名的用户交易捆绑在一起（假设用户的智能帐户支持委托），所有这些都在单个 L1 调用中完成。这允许原子性和对执行顺序的严格控制。

方便的是，这与 OP Stack 中不将其 blob 发布到可能允许捆绑的合约的排序器兼容，而无需修改技术栈。

区块顶部执行

存在一个微妙但重要的风险：SignalService.writeSignals() 的输出可能会根据包含它的捆绑包在 L1 区块中_执行的位置_而变化。

如果此输出与 L2 排序器预期的输出不同，则 L2 合约使用的 signalRequestsRoot 和相应的 proof 将无效，导致 L2 交易回滚。

有几种方法可以缓解这种情况：

1. 最后交易执行

捆绑包可以放置在 L1 区块的末尾，以确保它反映所有先前的状态更改。但是，这限制了它的实用性。那时，等待下一个区块并异步访问最终确定的 L1 状态会更简单。

2. 执行预确认

L1 提议者可以承诺执行 L1 区块，以便捆绑包产生预期的 signalRequestsRoot。如果他们偏离，他们可能会被削减。这提供了一种经济保证，不依赖于特定的区块位置。

3. 区块顶部执行

在 ToB 执行捆绑包可确保来自先前 L1 区块的干净的后状态。如果 SignalService.writeSignals() 在捆绑包中的所有相关交易之后运行，则生成的 signalRequestsRoot 将反映最新的 L1 状态。另请注意：

• 在实践中，实施 ToB 包含预确认很简单。有关最小的工作示例，请参见 Tobasco。
• 如果 ToB 定价是一个问题，则该捆绑包可以包括正常的 MEV 策略（例如 CEX-DEX 套利）来抵消其成本。
  4. 基于排序

基于排序器可以强制执行其捆绑包以预期的结果执行，因为它们对 L1 和 L2 具有写锁。从本质上讲，他们可以给自己与上述 2) 和 3) 相同的保证，但无需与任何人协调。由于 Signal-Boost 的目标之一是允许现有 rollup 实现与 L1 的 SC，因此我们将在本文的其余部分中假设我们使用 ToB 执行。

将所有内容放在一起

通过 SignalBoost、EIP-7702 智能帐户和 ToB 执行，我们现在拥有从 L2 合约实时访问任意 L1 数据的关键要素。

但是，仍然存在一个挑战：当信号在同一 slot 中写入时，L2 交易如何访问其对应的信号证明？

由于 signalRequestsRoot 仅在执行 SignalBoost.writeSignals() 后才知道，因此用户无法提前包含其 Merkle 证明。有几种解决方法：

• 通过 EIP-7702 委托构造

用户预先签署他们的 L2 交易，允许排序器在执行期间注入 signalRequestsRoot 和 proof。这使得交易可以在运行时完全构建，同时仍然强制执行正确性。如果信号或证明无效，则 L2 交易将回滚。

• 排序器辅助证明

在 L1 slot 期间，用户可以向排序器查询最新的 signalRequestsRoot 和相应的 proof。这避免了任何特殊的智能帐户逻辑，但需要用户和排序器之间的协调。

• 排序器注入的数据

了解 signalRequestsRoot 和所有 Merkle 证明后，排序器可以简单地将所有证明发布到验证然后存储 output 数据的 L2 合约。然后，L2 合约可以直接从 L2 存储访问输出，而无需了解 signalRequestsRoot 或证明。这完全抽象了 L2 用户的细节，但将成本负担推给了排序器。

假设中间选项，使用 same-slot 消息传递 的端到端流程为：

\ image1806×933 149 KB

1. L2 排序器收集任意的 L1 交易，由他们自己或其他使用具有委托 EOA 执行的智能帐户的人创建
2. L2 排序器从 L2 用户收集 SignalRequests
3. L2 排序器将 L1 交易与对 SignalBoost.writeSignals() 的调用捆绑在一起
4. L2 排序器模拟捆绑包的执行直到这一点，允许他们了解 signalRequestsRoot 并生成 Merkle 证明。signalRequestsRoot 被导入到 L2 的 SignalService 合约中
5. L2 用户向 L2 排序器查询 signalRequestsRoot 和其特定信号的 proof
6. L2 用户发送消耗这些信号的 L2 交易
7. L2 排序器创建一个 L2 批处理并将其添加到捆绑包中，导入 signalRequestsRoot
8. 假设实时证明，排序器可以选择在有效性证明中捆绑以结算 rollup 以及消耗 L2 状态的任何 L1 交易（即 L2→L1 提款）
9. 捆绑包在 L1 区块的顶部进行排序

FAQ

我可以用它做什么？

Signal-Boost 解锁了从 L2 合约同步访问任意 L1 数据，而无需进行重大的上游协议更改。这实现了一系列新的用例，例如：

• 跨 L2 协议的贷款迁移

用户可以通过以下方式在其贷款之间无缝迁移 L2 借贷协议：

• 利用 L1 流动性来获取闪电贷（例如 USDC）
• 同步处理 L1→L2 存款，这可以通过实时信令实现
• 偿还现有的 L2 贷款以解锁他们的 ETH 抵押品
• 在不同的 L2 协议上以更好的条款使用该 ETH 开立新贷款
• 将 USDC 提取回 L1 并使用它们来偿还闪电贷

所有这些都在单个 L1 slot 中以原子方式执行。没有 Oracle 复制或延迟桥接，只有与 L1 的同步可组合性和实时证明！

• 跨域套利

充分利用 same-slot 消息传递和 ToB 执行的双重套利：

• 在 Signal-Boost 捆绑包的顶部捕获 L1 套利
• 通过 SignalBoost 合约将更新的 Oracle 数据从 L1 转发到 L2
• 根据新提供的价格捕获 L2 套利
  • 使用意图的即时 L1↔L2 交换

即使没有实时证明，也可以使用意图进行 same-slot 消息传递即时 L1<>L2 提款 如 Nethermind 所述。

这些示例仅仅是冰山一角，任何依赖于及时访问 L1 数据的 L2 合约都可以从中受益。

这如何在 OP Stack 上工作？

OP Stack 没有 SignalService 合约或锚定交易的概念，这些交易在 same-slot 消息传递设计中使用。相反，OP Stack 的推导管道读取通过 CrossDomainMessenger.sendMessage() 函数传输的所有 L1 消息（L1 存款/任意函数调用），并将它们插入到 L2 区块的顶部。

可以调整 SignalBoost 合约以使用 signalRequestsRoot 值调用 sendMessage()，而不是写入 SignalService 合约。无需更改即可添加锚定交易，因为 OP Stack 已经支持类似的功能。

此外：

• L2 排序器必须是 Signal-Boost 捆绑器，因为推导管道期望 blob 交易由规范的 batchSubmitterAddress 提交。
• 为了同步读取这些 L1 消息，L2 排序器的 SequencerConfDepth 值需要设置为 0 才能实时跟踪 L1 head。

TL;DR 更改一个配置值并调整 SignalBoost 合约

这会损害Based Rollup 的价值主张吗？

不会。Signal-Boost 有助于扩大同步可组合性的市场，但Based Rollup 仍然提供独特的优势：

• 使用Based Rollup，Signal-Boost 更简单，从而放宽了 ToB 或执行预确认要求。
• Ultra transactions 使用Based Rollup 来实现最强大的同步可组合性形式。
• 共享排序对于同步的跨集群 L2 ↔ L2 可组合性仍然是必要的。
• 新的 rollup 可能更喜欢作为基于 appchain 启动，以避免运行中心化排序器的复杂性负担（即基础设施成本、活跃度、监管风险等）。
• 使用验证器作为基于排序器可提供最大的可组合性
• 优先考虑活跃度的 WW3 级 rollup 将选择基于排序器。

采用 Signal-Boost 是否需要 rollup 修改其现有技术栈？

不会。Signal-Boost 旨在实现低摩擦采用。Rollup 不需要彻底改革其技术栈或进行重大协议升级。排序器可以选择加入，并且仅在需要同步访问 L1 状态时才构建捆绑包。

应该注意的是，不同的技术栈的摩擦会更少，具体取决于它们当前如何处理 L1 输入数据和重组。

Signal-Boost 是否需要复杂的预确认？

保证 ToB 执行需要一个简单的包含预确认，与 L1 或 L2 执行预确认相比，它更容易证明安全故障（请参见 PoC Tobasco）。

可以放宽 ToB 要求并使用执行预确认来保证在 L1 上报告预期的 signalRequestsRoot。这也很容易证明，但这需要预确认者执行的更大程度的完善。

Signal-Boost 是否要求 rollup 放弃排序控制或 MEV？

不，Signal-Boost 与排序无关。无论是使用基于排序，经典排序，共享排序还是 rollup 生态系统（即 SuperChain），rollup 都保留对交易排序，MEV 捕获和费用市场的完全主权。Signal-Boost 仅仅是一种允许 rollup 同步访问 L1 状态的技术。

Signal-Boost 可以在两个 rollup 之间实现同步可组合性吗？

Signal-Boost 的设计考虑了L1 ↔ L2 的可组合性，允许排序器向用户提供对 L1 状态的同步访问。对此最简单的实现是使用中心化排序器，也就是说，存在重要的细微差别：

• Signal-Boost 与排序器无关，因此 rollup 可以继续使用它们自己的互操作解决方案（例如 SuperChain）来在其集群内实现 L2 ↔ L2 的可组合性。
• Signal-Boost 捆绑包可以包含任意数量的 L2 批处理，从而允许 L2 ↔ L2 的可组合性；但是，对于跨集群的可组合性（即 Base <> Scroll），我们仍然需要一个共享排序器来协调。基于排序器仍然是这个角色最中立和灵活的候选者。

Signal-Boost 和 Ultra transactions 之间有什么区别？

Ultra transactions 提供了跨链可组合性的最完整的愿景。它们假定 L1 和 rollup 技术栈已修改为支持诸如 XCALLOPTIONS 预编译之类的功能以及与 L1 的 EVM 等效性，从而允许执行在域之间流畅地移动。这使得任意的 L1 ↔ L2 函数调用，对状态的同步访问以及由单个证明验证的捆绑交易的原子执行成为可能。

Signal-Boost 是此想法的简化但务实的改编，目的是使某些技术今天可供现有 rollup 使用。

Signal-Boost 和 same-slot 消息传递之间有什么区别？

Same-slot 消息传递 通过将数据写入 L2 可以在同一 slot 中读取的消息合约来实现 L1 → L2 通信。它不支持任意的 L1 读取，仅支持已写入 L1 SignalService 合约的信号。Signal-Boost 采用了相同的技术，但试图通过 SignalBoost 合约来解决其局限性。

这真的是同步可组合性吗？

是的，但有一个重要的警告。从严格意义上讲，Signal-Boost 实现了同步可组合性：L1 和 L2 状态可以在同一 L1 slot 中交互，并且一个域可以读取另一个域的状态并以原子方式做出反应。这满足了 Jon Charbonneau 使用的定义，其中同步性意味着 same-slot 协调，而可组合性意味着反应性状态访问。

Ultra transactions、实时证明和 EIP-7814 等提案允许完全的双向可组合性：任意的跨域读取和写入/交错的函数调用，这严格来说比 Signal-Boost 可以提供的更好。

鉴于风险，rollup 为什么会发生 L1 重组？

重组风险是实时互操作性的代价。

一个潜在的解决方案是按需模型：rollup 默认情况下使用安全缓冲区运行以减轻 L1 重组风险，但是在需要同步 L1 访问时可以暂时将缓冲区减少到 0。在 OP Stack 的情况下，这可以通过动态调整排序器配置中的 SequencerConfDepth 值来实现。

可以对 L1 重组风险 采取什么措施吗？

是的，一些发展可能会降低 L1 重组的频率。从上下文中看，大多数重组是由缓慢或较晚的区块传播引起的，通常是由于时序游戏或带宽限制（在此处阅读更多 here）。

• 预确认： 随着预确认的成熟，它们为提议者提供可靠地传递区块的激励，尤其是在实施削减惩罚的情况下。
• 证明者-提议者分离（APS）： APS 将区块生产转移到专门的高带宽提议者，从而减少了由于网络限制而导致的遗漏或延迟区块。
• Slot 期货： 如果提议者通过预确认出售未来的区块，则买方（例如，rollup 排序器）和预确认者都受到激励，以确保区块按时到达。

ToB 不会很昂贵吗？

是的，ToB 是优质区块房地产。

幸运的是，没有什么可以阻止将正常的 MEV 交易插入到 Signal-Boost 捆绑包的顶部，从而允许排序器抵消成本。此外，如果将来实施了 EIP-7814，它将允许任意的 L1 读取而无需 SignalService 合约。

Based Rollup 不需要 ToB 或执行预确认。 由于它们对 L1 区块进行排序，因此它们可以确保没有意外的交易会使预期的 signalRequestsRoot 无效，从而使它们可以在区块中的任何位置安全地执行 Signal-Boost 捆绑包。

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