2024年汇聚互操作性解决方案的现状

作为一个以 Rollup 为中心的生态系统爱好者，我一直对改善 Rollup 互操作性的解决方案感兴趣。此外，我创作这项研究的唯一原因就是为了宣传 互操作性的重要性 的信息。在那之后，我意识到写文章是一种巩固我对某一主题理解的优秀方式，同时也能帮助人们理解它，现在我在这里。

在加密领域每一天都在学习新事物，因此今天从哲学角度来看，我认为自己的愿景 “Rollup 互操作性对以太坊的未来至关重要” 显得相当过时。从哲学的 POV 来看，我仍然坚持这个观点——Rollup 互操作性对以太坊的未来绝对至关重要，整个生态系统都应该致力于改善它的解决方案。然而，从技术的 POV 来看，我学到了关于这个主题的许多新思想，并改变了一些看法。

要理解下面的材料，拥有对 Rollups 和它们互操作性问题的基本理解是很有帮助的。如果你没有这种理解，我的文章 “Dr. Dankshard or How I learned to stop worrying and love rollups“ 是一个很好的介绍。

Merhaba!

伊斯坦布尔，L2DAYS，2023年11月14日。本人停留在会议大楼侧面的美食广场。Mosyo Coffee，zkCafe 就在前面。

这是11月13日晚上，Devconnect Istanbul 的第一天。作为 zkSync 的超级粉丝，我决定参加 zkSync Connect，这是我人生中的第一次活动。在那里，我遇到了一个人，我们一起前往“Mosyo Coffee”，如 zkCafe 的 Luma 页面所述。该地区有两个这样的地方，我们到晚上才找到正确的地方。

比上面照片中更黑暗，正下着倾盆大雨。在美食广场边缘的屋顶上，喝着用 Clave 免费代币买的咖啡，我向新朋友讲述了我对哈克松项目的想法。

那一杯咖啡。花了我3 WEN。

有“迷你账户” - ERC-4337（AA）账户，它们的验证逻辑不是签名检查，而是在其 L2 单个收件箱桥中验证操作哈希的存在。该哈希必须从其父地址在特定源链上发送。父地址是你在任何 L2 或以太坊 L1 上的主智能钱包。要与另一个 L2 交互，你需要：

• 在该 L2 上部署迷你账户，并将你的主钱包设置为父地址。任何人都可以进行部署，因此可以由协议或你的钱包供应商为其提供资金。
• 将你想要发送到你的 L2 收件箱桥的用户操作的哈希发送，并设置目标链 ID。
• 该哈希与其他哈希一起捆绑并发送到 L1。L1 上的智能合约将此捆绑发送到目标 L2，而收件箱桥则解开这些哈希，以便迷你账户可以读取它们。
• 发送者给其哈希添加一小笔费用，以激励协议的智能合约上的交易发起者。
• 当哈希到达目标 L2 时，你将你的用户操作发送到该 L2 的 AA 内存池。通过利用 ERC-4337 标准，我们无需重新实现自己的迷你账户内存池，协议可以很容易地与已经存在的代码库中的钱包集成。

简而言之，我打算创建一个基于 L1 的桥，将来自你 L2 上智能钱包的交易发送到你要与之交互的任何 L2。我最终在哈克松上几乎实现了它，但由于经验不足且是单干而未能完成。在向朋友解释后，他问我：

为什么不只是把钱包的网络切换一下，使用代币桥将所需资金移到所需网络呢？

我回答道：如果使用 EOA 钱包，这确实是一个绝对的选择。EOA 钱包在所有 EVM 网络中是相同的，并共享相同的地址，因此你只需在钱包设置中更改网络，就可以在所有网络中发送交易。

然而，领域正在向基于账户抽象的智能账户迁移。这些账户允许我们以编程方式向钱包添加所需的任何功能。P256 签名使我们可以使用 安全芯片 中的手机进行交易签名。通过社交恢复，我们可以将我们的亲属添加为授权恢复我们钱包的监护人，从而消除不安全的种子短语。支付方技术使我们能够用任何代币付款，甚至让其他人为我们支付费用 ，见此 。当量子计算机开始攻破经典签名方案时，我们可以在不创建新钱包的情况下，只需将我们的 AA 钱包中的方案更改为量子安全的方案。这个列表可以无止境地继续，因为账户抽象本质上使我们可以将可执行程序用作完全功能的钱包。

这一切都是有代价的：由于除了通过桥转移资金之外，它需要重新部署整个账户及所有密钥、监护人和设置，因此无法轻易将钱包迁移到另一个链。在某些情况下，这可能过于复杂，甚至无法实现——例如，在不支持 P256 预编译 的 Rollup 中，这种签名方案可能使用起来非常昂贵。

这就是我创建该协议的原因。实质上，你在许多 L2 上拥有 AA 账户。要发送来自它们的交易，你必须通过将意图哈希从特定 L2 上的主账户发送到这些“迷你账户”来验证你的意图，通过 L1 桥消息传递。实际上，这样你并没有摆脱多个钱包；你只是在单一的“父”账户上移动所有验证逻辑。

这种协议的另一个有趣细节是，它允许与 L2 以及所有 L1 侧链的互操作性，因为它们与以太坊有嵌入式桥接——Polygon PoS、Ronin、Gnosis 和 Avalanche 是我能想到的。然而，它设计为以 Rollup 为中心的互操作性协议，所以这只是一个有趣的技术事实。

尽管项目的构想相当巧妙，但实际实现存在一个显著缺陷：速度。

整个设计依赖于连接到以太坊 L1 的规范性 Rollup 桥。Rollup 桥的特殊之处在于，它们向以太坊的智能合约证明其状态，从而继承其安全性。正如你可能已经知道的，乐观和 ZK 验证是实现此目的的两种最流行方式。

乐观验证通过打开一个“挑战窗口”来工作，通常是七天，在此期间，挑战者可以发送指向交易批次中任何无效部分的欺诈证明。如果该证明有效，Rollup 将其区块链重组，以删除此批次。在七天内没有欺诈证明后，该批次将自动被视为有效，所有消息和提取最终在以太坊上确认。

你可能已经猜到了。由于向 L1 发送消息的 7 天延迟，从乐观 Rollup 发送跨链交易是一个糟糕的主意。为什么？那么，你会等你在 DEX 上的交易一周吗？到那时价格会发生什么变化？..

将跨链交易发送到乐观 Rollup 则要好得多。尽管 OP Stack 排序器会在处理消息之前等待几个区块以尽量减少重组的可能性，但等待几分钟才处理事务对于某些任务已经是可接受的。此外，以太坊社区目前正在致力于实现 单槽最终性，这将使每个区块单独确认，使其在下一个区块无法逆转。实施后，从 L1 到 L2 的消息传递将大约需要 12 秒。

在 ZK Rollups 上托管此类账户会更好，但仍然不太可用。从下面的统计数据可以看出，ZKsync Era 的确认时间为 21 小时，Linea 为 5 小时，Starknet 为 9 小时等等。

来自 l2beat.com/scaling/finality 的截图

但是，为什么会这样呢？强大的集群上不是 ZK 证明生成很快吗？简而言之，有两个问题：

• 一些 ZK Rollups，比如 ZKsync Era，设置了执行延迟，以便安全委员会有时间在其证明系统出现错误的情况下回滚一些批次。zkEVM 是非常复杂的技术片段，由于这份复杂性，利用多个证明系统同时概率性地防止错误目前尚不可行。
• 尽管 ZK 证明验证相较于其证明的计算非常轻，但在链上验证仍然相当昂贵。根据证明系统的不同，每次验证可能需最多达到一百万个 gas。以均价为 9 gwei 和今天 ETH 价格来算，单次证明在 L1 上的验证成本约为 30 美元。现代 ZK Rollups 通过为多个批次每隔一段时间生成一个证明从而减少这些费用，但这也减缓了桥的最终确认速度。每个区块执行批次并证明一次的成本为每个区块 30 美元，或 每天 216,000 美元。在每秒100笔交易的情况下，仅验证费用大约为每笔交易 0.025 美元。而且，我们还必须生成证明并在链上发布批次！

等待一两个小时进行交易仍然太久了。我们该怎么做？

首先，让我们忘掉我八个月大的哈克松项目，努力消除每笔交易都需要从我们的主智能钱包发起的思维模式。我们为什么还要在每个 Rollup 中共享我们的智能钱包逻辑？为什么我们不只是生成临时 EOA，将资金从我们的主智能钱包转移到那里，做我们想做的事，然后将剩余部分桥接回来呢？

我在查看 Clave UI 时想到了这个想法

我的 Clave（或你正在使用的任何智能钱包）具有安全区签名和社交恢复，因此即使我丢失了手机，我也可以对我的资金保持安全。而谁更关心这些临时账户发生什么呢？我已经完成了从这些账户中做的事情，所有资金现在都在我的 Clave 里。

然而，这种方法存在一个根本问题：假设你无法定期在其他链上使用相同的钱包，这会严重限制你可以在其上完成的任务数量。例如，你无法在本地借贷平台上创建存款，因为你不能将其迁移到你的主网络 (在这种情况下是 ZKsync Era)。你无法获取在你的主网络上没有非同质化等价物的代币（例如，如果它们是在该网络上原生铸造的）。你不能参与本地 DAO，因为你的投票必须保留在那个临时账户中。实际上，作为用户，你所能做的就是为多个接收者分散资金，而无需每次都进行桥接，并为兑换到可以桥接回主链上的代币提供更好的流动性。

因此，若要使这些钱包有用，我们必须使用主智能钱包所用的相同规则来访问它们——安全区、社交恢复等。所以，我们回到了上述想法及其不可行性。然而，有一个 可行的权宜之计，可以使这些迷你账户仅具有我们主钱包的 恢复 功能：

我们创建与之前描述的相同的迷你账户，但允许一个密钥直接从它们发送交易。我们的父钱包现在可以通过基于 L1 的桥更改此密钥，或让迷你账户从父 L2 的状态中读取该密钥。这样，如果临时密钥丢失，父钱包可以通过缓慢但原子的 L1 桥发起密钥更改。

原子性——一种操作特性，允许其在执行过程中不失败。它不是未被发起，就是已经完成了。 基于 L1 的桥是原子的，因为如果发送该消息是无法丢失的。顺序、可用性和真实性都由以太坊 L1 保证。

这好得多！现在，普通交易只需时间进行代币桥接。就在代币到达目的地后，发送交易的速度就像在你的主链上一样快。如果你丢失密钥，根据你的父钱包的链可能需要等待几个小时到 7 天，但你不会很频繁地使用它，因此对于大多数用例来说，这样的权衡是可以接受的。此外，即使在今天也可以在钱包中实现这项功能。我甚至做了我自己的实现，但这绝对不是安全的，也不适合生产使用，仅用于可视化目的。

类似的技术也用于 Web3 期货交易平台：你向智能合约批准代币以配对（通常是 USDC），并为花费分配一个临时密钥，该密钥存储在平台的前端。这使用户能够快速执行操作，而无需使用其主钱包为每个操作签名。如果你更改设备或清除浏览器数据，则可以使用主钱包重新分配密钥。

但正如加密中的一切，这种方法也不是完美的。它有两个缺陷：

• 尽管迷你账户可以符合 ERC-4337 标准，从而支持所有功能，例如批处理、支付方、支出限额等，但这些功能不再从父账户继承。实际上，父账户仅充当迷你账户的单个社交恢复监护人，但监护人是用户自己。
• 代币桥接必须通过外部桥实现。通过跨链交易发起，我们可以携带我们的代币与消息一起原子性地接收它们几乎 1:1。但是，使用此解决方案则不再是选项，因此外部桥是唯一剩下的快速选择。

尽管现代桥接 可以在几秒钟内转移资金，它们a) 会收取费用，对于大额转账而言可能变得 极其高昂，b) 并不是原子的，也不继承以太坊的安全特性。

在这一点上，有关安全特性的值得一提。使用外部桥来转移代币在某种程度上是可以接受的，不同于使用它们来传递消息以操作迷你账户。原因在于它们的最坏情况，可能因攻击而引起：

• 在代币桥接中，最糟糕的情况是你不会收到发送的代币。在这种情况下，你损失了 X 代币，而你想要桥接并且转向另一个桥。
• 在跨账户消息传递中，最糟糕的情况是所有【迷你账户】都可以拥抱通过桥传递的假消息而被盗。在这种情况下，你在所有链上的钱包及其所有价值都会丧失，除了主钱包。

因此，对于代币桥接来说，依赖外部桥基本上是一个选项，只要没有有效的方法以原子方式使其桥接到 L1 。

假设我们想要在单一地方 验证 所有交易，例如，在账户之间本地传输代币或通过唯一预编译验证签名。此时，我们将面临当前 ZK Rollup 的延迟最终性问题。

让我们暂时回过头来，想一想如何改善前述技术。Rollup 为什么有慢桥终值（finality）？我们将 ZK Rollup 作为目标，因为对于乐观 Rollup，原因已显而易见：

• ZK 证明系统对于功能全面的虚拟机环境非常复杂，尤其是当该环境对 ZK 不友好（EVM）时。因此，它们存在可能存在错误的较高几率。多个证明系统可以防止这一点，但实现时也非常复杂，并且对单个批次生成多个证明可能过于缓慢和昂贵。作为替代方案，Rollup 团队启用执行延迟，以使它们能够在紧急情况下回滚链。这是导致某些 Rollup（例如 ZKsync Era）桥的最终性延迟的原因。
• 提议新状态和对 L1 的 ZK 证明是非常昂贵的任务，因此为了最小化成本，Rollup 排序器每隔几小时执行，而不是每个区块执行。

不过，存在一个例外；Scroll 每分钟大约提议一次状态，但虽然 a）证明验证在几小时内进行，因此仍然未验证，b）Scroll 是今天使用的 最昂贵的 Rollup。

如果我们更简单地重新表述一下，问题就是证明费用和验证费用。让我们分别看看每个问题及其解决方法。

实质上，我们的任务是使我们的智能钱包能够快速与其他 Rollup 进行互操作，而无需外部桥带来的额外信任假设。智能钱包通常由一些常见的 AA 功能组成——支付人、社交恢复、安全区、支出限额等，以及允许我们发送链上交易的主要操作。

为什么我们需要主要操作，如果我们想通过钱包使用其他 Rollup？因为它可能被托管在多功能 Rollup 中——Arbitrum、Base、ZKsync Era——而我们也希望与此 Rollup 的用户和智能合约进行交互。

在这种特定情况下，直接使用外部代币桥将更有意义。将任务替换为，例如，在同一 Rollup 中与另一个 dApp 的交互

这种多功能性引入了 Rollup 证明系统的复杂性。验证整个虚拟机的状态以及每秒发生的大量智能合约和交易是一项相当艰巨的任务。我们希望执行两种类型的任务，这需要 Rollup 中完全不同的功能集合：对于链上交易，要求快速 L2 包含、低 L2 费用和广泛的虚拟机功能；而对于多 Rollup 交易来说，就是快速的桥接最终性。

但如果我们简单地摆脱虚拟机，构建一个只能处理智能账户和消息传递到其他 L2 的 Rollup 呢？Vitalik Buterin 在 Devconnect Istanbul 大约同时提出了一种类似的技术：

Keystore rollups

这个想法是创建一个只能存储账户密钥的 ZK Rollup，让其使用另一个密钥进行更改。此 Rollup 将包含所有这些密钥的梅克尔树根压入 L1。之后，当你想从你的 L2 上的智能账户发送交易时，你生成当前密钥的 Merkle 证明，你的账户将其与 L1 上可用的 keystore 根来验证。现在，它知道你的密钥，并可以用来验证你的签名。

添加 Merkle 或 KZG 证明检查后，造型如上

这种 Rollup 非常简单，可以方便地实现多种证明系统，因此其中存储的密钥实际上与 L1 一样安全。

除了 Vitalik 的原始设计之外，还有三种领先的 keystore rollups：

• Scroll 的 方法是将 keystore 数据存储在 L1，但允许从他们的 zkEVM rollup 更新。为此，他们引入一个 L1SLOAD 预编译，允许对 L1 存储的廉价读取。然后，其他 L2 上的 AA 账户可以读取此数据以同步它们的配置——密钥、监护人等。
• Base 团队 正在探索一种技术，其中仅将状态根存储在 L1，但通过数据调用对交易进行排序，因此该树可以随时重建。预计 L2 上的账户将使用 Merkle 证明来获取当前密钥。
• Stackr 的 设计与 Base 的或 Vitalik 的类似，但它利用其自己的“微型 Rollup”框架，具有专门的最小 VMs。

一般而言，它们在委托给链外处理的任务数量（换句话说，就是有多少事情在 L2 上处理）和它们的实现细节上有所不同。

我们可以进一步扩展这个想法，不仅处理 密钥，而且还可以处理 整个智能账户逻辑。这不会变得计算上复杂；从本质上讲，我们只需要处理这些任务：

• 向 L1 发送数据： Keystore rollup 上的账户必须能够通知 L1 关于其交易意图。将整个交易存储在 L1 上并不必要；梅克尔树的根以及所有用户操作的哈希将足够。然后，从迷你账户发送交易所需的所有步骤就是从目标 L2 读取根并证明特定 AA 操作实际上是来自父账户的请求。
• 签名检查： 用户签署他们希望在特定 Rollup 上执行的用户操作的哈希。Keystore rollup 验证该签名以证明意图，并将哈希添加到树中，然后将其推送到 L1。几个签名方案，如 ECDSA、P256 和 量子安全的 签名就足够了。
• 社交恢复： 让其他有目的选择的账户，称为“监护人”，对用户账户的密钥更改进行投票。用户可以设置监护人和阈值，并在需要恢复时寻求他们的帮助。我们还可以实现 基于否决的恢复，或诸如 ZK-Email、ZK-OTP，或 Web 证明 这类替代监护人方案，以扩大社交恢复。
• 支出规则： 如果钱包被盗，监护人控制的支出规则可以大大减少用户恢复钱包之前的潜在损失。该功能对于确保资金或，例如，为孩子创建钱包非常有帮助——父母可以发送津贴，并限制可以花费的额度，以便孩子可以学会储蓄。
• 代币余额： 这可能看起来没必要，但能够在 keystore rollup 内存储加密资产通过将它们不分散到多个迷你账户，从而显著增强用户资产的安全性。此外，这还允许许多增强用户体验的功能：
• 支付方： 该 Rollup 可以提供免费交易以吸引新用户，或允许他们用任何代币支付费用，而不仅仅是 ETH。更复杂的支付方逻辑也可以实现——例如，当它被桥接回 keystore Rollup 时，序列化者可以从另一条链的 swap 中收取费用。
• 内部代币转账： 除了在 Rollup 用户之间立即发送资金外，直接转账对于使用具有过慢最终性的其他 Rollup 来实现基于意图的桥接也很有帮助，这样就无需使用 L1 从迷你账户桥接到 keystore Rollup 的父账户。因此，keystore Rollup 本质上可以充当一个枢纽，以便廉价地在众多不同的 L2 之间转移代币。

这样一个系统在技术上比完整虚拟机内部 Rollup 要简单得多，因此可以同时为多个证明系统生成证明，证明生成的复杂性仍然会大大降低。

然而，证明验证仍然是一个问题。正如我们之前计算的那样，它的 gas 成本可能高达 100 万 gas，或约 25-50 美元，具体取决于 gas 价格。该成本是固定的，并不依赖于批次中的交易数量。这意味着，如果交易数量太少，则每笔交易的费用可能会非常高。降低该成本的主要方式有两种：

Aligned Layer

Aligned 是一个 EigenLayer AVS，它利用重质押操作员廉价验证 ZK 证明。如果你不熟悉 EigenLayer，以下是如何在对齐中验证证明的简化说明：

• 用户将证明验证请求发送到网络并支付费用；
• Aligned 操作员，每个都是具有其存款绑定的以太坊验证者，在其节点上验证该证明并为其有效性签名；
• 当 2/3 的操作员为证明签名时，将聚合签名发送并在以太坊 L1 上验证。
• 如果无效的证明达到最终性，签署该证明的验证者可以通过链上验证将其划分。这种方式使证明获得与 2/3 总的 Aligned 操作员的押金相等的经济安全。

这种方法有一个明显的缺点——以太坊不再保证证明的有效性。如果 Rollup 桥的 TVL 高于 Aligned 总抵押的 2/3，攻击它会变得盈利。而且，由于我们讨论的是 1-2 个区块的最终性延迟我们无法乐观地防止攻击。

然而，只要 Rollup 不变得太大，这可能是一个相对安全的选择。当它做到这一点时，交易需求可能已经使 L1 证明验证变得值得。根据文档，使用 Aligned 验证 ZK 证明的成本约为 3000 gas，对于以太坊 L1 来说几乎是免费的。

证明聚合层

如果你不想向系统引入额外的信任假设，或者你的协议在变大但交易需求没有增加，则还有替代方案。

ZK 和 Rollup 团队最近开始积极研究证明聚合协议。如果你对 ZK 不太熟悉，证明聚合是指一个 ZK 证明证明另一个 ZK 证明的有效性（该证明在给定条件下可以证明另一个证明，等等），从而在单个证明中“聚合”它们，基本上将所有验证成本转移到证明成本上。剩下的只是在链上验证一个单独的 ZK 证明，并对它证明的所有其他 ZK 证明的有效性负责。哇！

ZK 证明的链上验证

证明聚合适用于验证费用高于生成聚合证明的情形。即，如果为十个证明生成一个证明并进行验证的成本小于独立验证这十个证明的成本，聚合就变得有利可图。这在以太坊 L1 上尤其有帮助，因为计算能力受到了严格限制。根据证明系统的不同，整个区块只能包含 最多大约 100 次证明验证，而不包括所有其他的链上活动。

通常地，有两种类型的证明聚合协议：

• 通用目的的（Universal）聚合: 此类项目通常支持几种最流行的 ZK 协议（如 Groth16、Halo2、Plonky），并征收处理费用。需要证明的 dApp 然后从协议中揭示数据并自行处理。目前正在开发的 Nebra 的通用证明聚合系统 正好做到了这一点。Aligned 也在开展有关所谓的 “慢模式”验证 的工作，实际上也是一种证明聚合系统。
• 聚合共享 Rollup 桥: 类似于优化 Rollup 中的共享排序，ZK Rollup 及其堆栈正致力于共享桥，聚合每个 ZK Rollup 的状态证明。这不仅允许在堆栈内部同便选择在共享排序的条件下进行互操作，还最大程度地降低了证明验证的成本。你可能听说过 Polygon 的 AggLayer 或 ZKsync 的 Hyperbridge，这些都是共享 Rollup 桥，在桥名内处理证明聚合。

通用聚合系统的优点在于它们对项目是不可知的，并且专门针对聚合过程，这允许快速的证明验证及较低的成本。此外，它们很可能不需要辅助功能，因为缺乏桥接组件。

聚合 Rollup 桥有助于 keystore Rollup 与已经存在的 Rollup 堆栈的同步可组合性。例如，根据 L2BEAT 的数据 现有 13 个项目 构建在 Polygon CDK 上，11 个构建在 ZK Stack 上。当它们都连接到一个共享的证明聚合桥时，将 keystore Rollup 连接到其中的一个将无缝打开许多 L2 之间的互操作，而无需触及 L1。为了实现这一点，桥必须支持不同的状态转移逻辑，因为 keystore Rollup 的逻辑与其他 L2 的逻辑不同。

不过，这些桥通常是可升级的，并受到其 DAO 或安全委员会的控制。Keystore Rollup 项目可能不喜欢同意放弃它们与连接的桥操作员之间的自主权。此外，桥可能会引入执行延迟作为辅助功能，类似于目前 ZKsync Era 的运作方式，这实际上会削弱这个 keystore Rollup 设计的整个效率。

以这种方式，keystore rollups 像其他任何 ZK rollups 一样，可以最小化证明验证成本，甚至将其与与现有 rollup 堆栈的同步可组合性结合起来。

高效的基于意图的桥接与“Keystore+” Rollups

正如之前讨论的，L2 到 L1 的桥接并不是唯一的问题。大多数 Rollup 排序器在从 L1 到 L2 发送消息时也施加了延迟。这是因为在以太坊区块创建时，它还没有最终确定，并且可以在接下来大约 64 个区块内（两个时代，大约 13 分钟）进行反转。这些区块重组的原因是网络延迟，导致某些提议在网络中出现得太晚，而某些节点已经将其视为丢失。

尽管 大多数重组的深度 不超过两个区块 （两年前甚至出现了七个块的重组 ）， Rollup 团队仍然不想承担与错过消息相关的风险，因此对从 L1 进行桥接应用了延迟。这些延迟在某些 Rollup 上约为 1 分钟（OP Stack、ZK Stack），但在某些 Rollup 上可能长达 6 分钟，比如 Arbitrum，甚至可能要求 L1 最终性，如 Linea 。

以太坊社区正在 积极致力于单槽最终性，使每个区块独立最后确定，而不是在一个时代中确认一次。但我们可以肯定地说，它未计划在下一个 Pectra 更新中实施，在 2025 年第一季度进行，因此至少需要一年才能实施 SSF。

如果实施该扩展的 keystore rollup 设计的团队对这样的交易延迟感到不满意，他们可以实现之前描述的权宜方案。每个迷你账户都有一个密钥，被授权发送交易，或者使用来自 keystore 的静态密钥（按照 Vitalik 的原始设计），但账户管理仍然在主 keystore 账户上。待 SSF 在 L1 上实施后，该 Rollup 可删除授权的支出密钥，用户将获得整个 AA 自定义功能，而无需显著降低速度。

我在这里同意 Alex 的看法； 15 秒的延迟绝对可以接受，特别是因为一旦 keystore rollup 的交易在 L1 上完成，操作就是原子的。如果谈到代币转移，接收方钱包甚至可以在 UI 层面实现“待处理”状态。然而，跨卷层代币转移仍然存在问题。如果我们在密钥存储卷层内部实现代币保险库，从中转移代币将需要1到15分钟，具体取决于接收方卷层。如果不这样做，将用户的余额拆分为多个 L2 上的迷你账户可能会导致安全风险，甚至将一些资产锁定在流动性不足的 L2 中，从这些 L2 桥接可能会成本过高或耗时过长。

作为替代方案，我们可以在卷层中集成一个基于意图的桥接，并在所有其他卷层上部署它，甚至可以重用现有基础设施，例如符合ERC-7683的协议。

基于意图的桥接是什么？

目前大多数现有的跨链桥接是基于消息协议的。例如，Stargate使用LayerZero传递关于存款到目标链的消息，依赖于它作为信任的来源。当你通过这种桥接发送代币时，它们会在一侧锁定你的代币，并在另一侧发送一条关于你存款的消息，而那里保险库会解锁相应数量的代币给你。

相反，基于意图的桥接并不会在两个链之间发送消息。相反，发送的资金会作为“跨链订单”锁定在保险库中，然后任何人都可以通过在目标链上发送请求的代币数量来满足订单。满足订单的人可以在目标链的状态最终确定后，向源链要求解锁锁定的代币，保险库在获知目标链的最终状态后即可确认转移。这可以通过等待目标链的目标（桥接）最终性，或者通过某种外部预言机协议发生。例如，Across 使用 UMA 的乐观预言机来获取未最终确定的 L2 的状态。

在这个场景中，以太坊 L1 被用作信任来源。一些协议，例如 Across，反而使用外部预言机。实际设计在现有项目中可能有所不同；这里只显示出总体思路。

我们可以采用相同的设计在这些扩展的密钥存储卷层中实现无信任、快速且低成本的双向桥接，通过密钥存储和所有其他 L2 之间的快速桥接最终性允许从其他 L2 生成的基于意图的订单几乎是免费的，因为在 L2 上证明满足条件只需几分钟。来自密钥存储的订单也可能便宜，因为 L2 上的流动性可以通过密钥存储相对快速地提供。这样，这种密钥存储卷层设计可以成为基于意图的桥接中心，使用户能够即时发送交易，而不是要等待几分钟，几乎不需要为桥接支付费用。卷层团队也可以通过密钥存储以 1:1 的比例提供桥接流动性，这不会让他们花费太多。

统一的 ENS 名称用于所有链

想象一下，有一个单一的 username.eth，可以解析到你所有的迷你账户，无论接收者在哪条链上。这个设计使这成为可能。怎么样？

如我们所知，我们的主密钥存储账户的地址，我们可以使用multichain factories和CREATE2使我们迷你账户的地址在所有字节码等效的 EVM 链上保持一致，甚至包括以太坊 L1。然后，我们将统一地址设置在 ENS 解析器中，我们的名称可以在所有 EVM L2 中使用。

然而，有两个特殊情况：

• 字节码不等效的 EVM，如 ZK Stack。 对于它们，我们可以根据它们的 CREATE2 规则生成一个自定义地址，并根据ENSIP-11将其添加到 ENS 中，并附上它们的链标识符。
• 非 EVM L2，如我们的密钥存储。 对于它们，逻辑相同，但相应地，我们根据ENSIP-9将它们的自定义地址添加到 ENS 中。

尽管这种方法非常用户友好，但它在 L1 上使用了大量昂贵的计算和存储，因为名称和地址都存储在 L1 解析器上。这个问题可以通过使用CCIP Read来解决，但我提出了另一种更高效的链上解析逻辑：

每个在密钥存储上的账户都是通过它的 ENS 名字的名称哈希注册和索引的，注册在一个具有自定义解析器的单一 ENS 名称下。当解析它的子域时，解析器合约会检查该名称哈希的账户是否存在于卷层中，并使用名称哈希生成基于 CREATE2 的迷你账户地址。当这些地址被部署时，它们会请求 L1 获取与被部署的名称哈希相关的密钥存储数据。这可以是事务意图本身，也可以只是当前的签名密钥，具体取决于密钥存储的实现。

通过这种方式，我们获得了密钥存储账户，每个账户都具有 ENS 名称解析到自身及其在每个卷层上的迷你账户。这些迷你账户反过来也会在使用密钥存储卷层进行交易验证时依赖于这个 ENS 名称。

“Keystore+” 卷层上的排序机制

由于扩展的密钥存储卷层上的桥接最终性预计为几 L1 块，我们可以完全去掉中心化排序器，将其转变为基于的卷层。正如我们之前讨论的，大约 12 秒的交易速度对于普通用户来说是可以接受的，但基于排序将使卷层在抵制审查和避免单点故障方面更具弹性。

值得考虑的是，在基于排序的情况下，内部交易所需的时间将与外部交易相同（不包括到达 L2 的时间）。这对某些团队来说可能不可接受，因为中心化排序使所有内部操作都是即时的。

卷层互操作性中的替代进展或为何我没有提及共享排序

我围绕 ZK 卷层和 ZK 技术撰写了整篇文章。这是因为Op rollup层在基础上无法实现快速的客观最终性，而只有使用 ZK 才能够达到这样的特性。如今，Op rollup层了解它们的封闭位置，并积极研究将有效性中心设计集成到它们的栈中的可行性，因此例如， Optimism 和 RISC Zero 的最近合作。

乐观设计从根本上是有限制的，因为它永远不会处理与其他卷层的互操作性。然而，在 乐观生态系统内的互操作性正在迅速发展。使Op rollup层相互之间实现互操作性的主要技术是 共享排序。简单来说，这是一种机制，排序器可以同时为多个卷层构建一个批次。如果所排序的任何卷层中的任何交易无效，整个批次都可以被争议和撤销。

这给予这个“超批次”中所有批次原子性——要么所有批次都是有效的，要么没有。这反过来允许在批次内部实现原子同步组合性。原子性—因为如果批次是有效的，那么批次中的任何内容都不能无效；同步性—因为所有的消息都在批次内部，并且同时由所有卷层的节点处理。

该技术基本上将某个乐观栈中的所有卷层转变为一个大型分片卷层。为什么只在一个栈中，而不是所有的卷层？因为为了使这一切有效，卷层必须连接到一个单一的桥接。每个栈都有各自的桥接，而没有可靠的方法同时在多个桥接中建立批量。因此，共享排序使 OP 主网可以无缝地与 Base 和 Zora 进行互操作，但无法与 Arbitrum 或 Metis 进行互操作，反之亦然。

这种整合为卷层生态系统创造了一个危险的情况。新的卷层可以选择要么加入现有的栈并与其集成，但与其他卷层不兼容，要么构建在 ZK 之上，能够与其他任何卷层集成，但与上述栈不兼容。现在没有这样的选择，因为共享排序尚未可用，每个 OP Stack 或 Arbitrum Orbit 卷层都是独立的，各自有其桥接。然而，当它们合并时，它们将在生态系统中形成两个稳固的实体，各自占据约40% 的总 L2 TVL。

— 好吧。如果它们将占据绝大多数的总 TVL，为什么我们不去掉 ZK 并在它们之上开发？

首先，共享排序是一个巨大的中心化驱动。如果你运行 OP 主网排序器，你的批处理将不会包含栈中其他卷层的交易；你在费用上的收益将减少，并最终被能够处理整个栈的较大型商业排序器所超越。

然而，最关键的问题是，在这种情况下，卷层生态系统会被封闭在寡头帝国中，各自追求自身利益，寻求对资本的更多控制，同时对生态系统的技术进步松懈。我们将不得不面对以太坊被压缩到一个分裂的区域，在那里公关和种内斗争才是重要的，而不是能够真正改变世界的科技。

“构建工具，而不是帝国。” 帝国试图捕获和圈养用户在一个围墙花园中；工具完成它们的任务，但在其他方面与更广泛的开放生态系统进行互操作。——[V

• 原文链接： research.2077.xyz/the-st...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～