Vitalik：深入了解跨L2读取——跨链证明有哪些方案

作者：Vitalik，以太坊创始人；翻译：金色财经cryptonaitive

在《以太坊生态系统需要三个技术转型》一文中，我概述了为什么明确考虑L1 +跨L2支持、钱包安全性和隐私作为以太坊生态系统堆栈的必要基本功能，而不是作为可以由单独的钱包单独设计的附加组件的关键原因。

本文将更直接地关注一个特定子问题的技术方面：如何使从L2读取L1、从L1读取L2或从一个L2读取另一个L2变得更容易。解决这个问题对于实施资产/密钥库（keystore）分离架构至关重要，但它在其他领域也有着有价值的用途，尤其是优化可靠的L2间调用，包括在L1和L2之间转移资产等用例。

本文目录：

目标是什么？

跨链证明是什么样的？

我们可以使用哪些证明方案？

Merkle证明

ZK SNARKs

特殊目的的KZG证明

Verkle树证明

聚合

直接状态读取

L2如何获取最新的以太坊状态根？

不是L2链的钱包

隐私保护

总结

目标是什么？

一旦L2变得更加主流，用户将在多个L2和可能的L1上拥有资产。一旦智能合约钱包（多签、社交恢复或其他类型）成为主流，访问某个账户所需的密钥将会随着时间而改变，旧的密钥将不再有效。一旦这两个情况都发生，用户将需要一种方法来更改具有权限访问位于许多不同位置的许多账户的密钥，而不需要进行大量的交易。

特别是，我们需要一种处理“虚拟地址（counterfactual addresses）”的方法：这些地址尚未以任何方式在链上“注册”，但仍需要接收和安全保管资金。我们都依赖于虚拟地址：当你第一次使用以太坊时，你可以生成一个ETH地址，他人可以用来向你支付资金，而无需在链上“注册”该地址（这将需要支付交易费用，因此需要持有一些ETH）。

对于EOAs（外部账户），所有地址最初都是虚拟地址。对于智能合约钱包而言，虚拟地址仍然是可能的，主要得益于CREATE2，它允许你拥有一个ETH地址，只有与特定哈希匹配的代码的智能合约才能填充该地址。

EIP-1014 (CREATE2) 地址计算算法

然而，智能合约钱包引入了一个新的挑战：访问密钥可能会发生变化。地址（作为initcode的哈希）只能包含钱包的初始验证密钥。当前的验证密钥将存储在钱包的存储中，但该存储记录不会自动传播到其他L2。

如果用户在许多L2上有许多地址，包括（因为它们是虚设的）所在的L2不知道的地址，那么似乎只有一种方式可以让用户更改他们的密钥：资产/密钥库分离架构。每个用户都有（i）一个“密钥库合约”（在L1或特定L2上），用于存储所有钱包的验证密钥以及更改密钥的规则，和（ii）L1和许多L2上的“钱包合约”，用于进行跨链读取以获取验证密钥。

有两种实现方法：

1、轻量级版本（仅检查以更新密钥）：每个钱包在本地存储验证密钥，并包含一个函数，可以调用该函数以检查来自密钥库的当前状态的跨链证明，并更新本地存储的验证密钥。当在特定L2上首次使用钱包时，调用该函数以从密钥库获取当前验证密钥是必需的。

优点：节约使用跨链证明，因此跨链证明昂贵也没有关系。所有资金只能使用当前密钥，因此仍然安全。

缺点：要更改验证密钥，你必须在密钥库和已初始化的每个钱包（尽管不包括虚拟地址）中进行链上密钥更改。这可能需要大量的Gas费用。

2、重量级版本（每笔交易都进行检查）：每个交易都需要一个跨链证明，证明密钥当前存在于密钥库中。

优点：系统复杂性较低，更新密钥库成本较低。

缺点：每笔交易都很昂贵，因此需要更多的工程来使跨链证明的成本可接受。同时，它与ERC-4337不易兼容，因为ERC-4337目前不支持在验证期间对可变对象进行跨合约读取。

跨链证明是什么样的？

为了展示全部的复杂性，我们将探讨最困难的情况：密钥库位于一个L2，钱包位于另一个L2。如果密钥库或钱包中的任何一个位于L1，则只需要这个设计的一半。

假设密钥库位于Linea，钱包位于Kakarot。完整的钱包密钥证明包括：

一个证明，根据Kakarot所知的当前以太坊状态根，证明当前Linea状态根

一个证明，根据当前Linea状态根，证明密钥库中的当前密钥

这里有两个主要的实现问题：

1、我们使用什么样的证明？（是Merkle证明吗？还是其他什么东西？）

2、L2如何首先了解最近的L1（以太坊）状态根（或者，如我们将看到的，可能是完整的L1状态）？相反，L1如何了解L2状态根？