以太坊 - Keystore Rollup介绍

在以太坊上的扩展和账户抽象工作交汇之处，即三大转变中的两个，密钥库 Rollup 可能会成为支持全球规模以太坊的关键基础设施。最近，Vitalik 最初关于专用于密钥库的最小 Rollup的提案已经由 Base 进行了迭代，并提出了更正式的规范。虽然现有的文章已经很详细，但我还是想为那些不太熟悉底层密码学的人提供一个介绍。这篇文章试图介绍密钥库 Rollup 的思想和基本逻辑块，而不涉及实现它所需的底层尖端密码学。

密钥库 Rollup 解决了什么问题？

首先，简单介绍一下目前使用以太坊的状况。由于需要降低交易成本，Rollup 已经开始成为部署新 dApp 的默认位置。不幸的是，这给用户带来新的摩擦，他们首先需要将 ETH 桥接到 Rollup 中，才能支付网络上的交易费用。账户抽象，特别是 EIP-4337 的实现，有望通过为用户提供新的方式来减少摩擦地支付 gas 费用，甚至可能获得完全的补贴，从而帮助解决这个问题。随着 Rollup 选项数量的加速增长（在模块化 DA 和 L3 等模式的帮助下），智能合约账户必须继续部署在用户想要交易的每个新网络上。

我们的根本问题始于 Rollup 的状态与其他 Rollup 的隔离。具体来说，账户需要验证用户操作的状态，例如所有者密钥。智能合约账户持有状态的能力增强了密钥轮换和恢复等功能，但也带来了跨所有网络同步状态更新的复杂性。

在下面的示意图中，假设我们的用户刚刚在他们的手机上添加了一个Passkey，以便随时随地控制一个账户。这个更改已经在 Optimism 网络上应用，但没有在 Base 或 Scroll 上应用。

如果一个用户在多个网络上拥有智能合约账户，并且想要更改他们的权限，如何安全且廉价地将更改应用到所有地方？

现有的解决方案

目前解决这个问题的方法是将相同的状态更改传播到所有链。如果用户在任何网络上更改状态，钱包提供商有责任将相同的更改应用到所有其他网络（希望给用户一种只签署一个批准的方式，该批准可以在每个网络上重复使用一次）。

虽然最初令人满意，但这种传播过程会遇到一些问题。

首先是复杂性问题。由于用户不应该承担跟踪跨网络权限的负担，开发人员需要构建一种提交这些交易、管理待处理状态逻辑、处理失败提交的回退等等的方法。虽然用户没有直接承担这个成本，但他们以更少的开发团队支持这样的功能以及其他改进的机会成本的形式承担了。

其次是成本问题。如果账户提供商为用户在所有网络上提交交易，则每笔交易都会产生费用。如果 Rollup 与以太坊相比提供 10-100 倍的成本节省，但权限更改需要传播到 10-100 个网络，那么我们实际上并没有节省任何费用。为了解决这个问题，提供商仅在用户在网络上进行下一次交易时，才根据需要提交权限更改。这在近期缓解了成本问题，同时 Rollup 的采用仍处于起步阶段，但如果我们拥有 10-100 个用户参与的 Rollup 的未来，将会遇到同样的问题。这种优化也增加了我们的第一个问题，即开发人员的复杂性。

第三个是安全问题。按需提交权限更新在添加新权限时是安全的，就像我们的移动Passkey示例一样，但是如果密钥泄露并且需要删除会发生什么？如果这些权限撤销更改未在网络上应用，则会让用户容易受到攻击。即使权限撤销立即应用，仍然需要账户提供商团队尽职尽责地在未来发布的未知网络上积极应用更改。考虑尚未存在的网络也会反馈到复杂性和成本问题中。

考虑下面的示例，其中账户在 Base 网络上轮换原始控制密钥，但 Optimism 和 Scroll 保持不变。

从根本上讲，这种方法是有缺陷的，因为用户发起的权限更改与在他们使用的网络上应用更新的规模不同（1 个更改，N 个网络）。现有的调整和优化只是围绕这种不匹配的权宜之计。

密钥库 Rollup

为了预见日益增长的多链用户体验，账户权限的未来是将账户状态集中在一个网络上，即密钥库 Rollup。所有账户，无论它们需要在哪些其他网络上进行交易，都参考密钥库 Rollup 来验证用户。与其在账户智能合约中存储可变权限，不如存储指向“虚拟账户”id 的不可变链接，该 id 包含密钥库 Rollup 上的实际权限数据。

通过在一个地方集中状态，更改这个真理来源可以自动反映在所有其他网络上。通过消除跨多个网络管理状态和传播重复交易以进行权限更改的需求，从而降低了复杂性。通过消除这些重复的交易费用，降低了成本。通过保证立即应用删除的权限并消除链下权限更改请求的数据可用性假设，从而提高了安全性。

但这并非没有新的问题，首先是克服前面提到的 Rollup 之间的状态隔离。

我们如何在其他 Rollup 中使用密钥库 Rollup 的状态？

执行用户操作

这就是我们的神奇密码学发挥作用的地方，它使用了零知识证明。本节将有意省略实现细节，同时尝试保留验证过程的不同组件的直觉。考虑在 L2 上执行用户操作的具体示例，该示例需要使用密钥库 Rollup 进行验证过程。

在高层次上，我们在执行用户操作时需要验证 4 件事：

1. 用户操作由一个或一组密钥签名
2. 密钥或密钥集对虚拟账户有效
3. 虚拟账户的状态由以太坊验证
4. 虚拟账户控制我们的账户智能合约

验证签名密钥

就像普通的智能合约账户一样，用户操作被转换为消息哈希（在 EIP-4337 中定义），并且这个哈希由私钥签名，从而产生签名。支持多个私钥和签名方法，例如使用 secp256k1 椭圆曲线的普通以太坊钱包或使用 secp256r1 椭圆曲线的 Webauthn Passkey。使用椭圆曲线密码学，可以将公共签名和消息哈希一起使用来恢复用于签名的公钥。因此，给定用户操作和签名，我们可以验证签名它的公钥。

验证虚拟账户上的密钥

验证一个或一组密钥控制虚拟账户可以通过两种方法完成，分别称为“包含”和“排除”。

包含是指虚拟账户的状态为非空，并且我们比较密钥在其中的成员资格。忽略此状态的模式和位置，可以将其视为从虚拟账户 ID 到字节数组的映射。对于拥有账户的单个密钥的简单示例，只需将从我们的用户操作签名中提取的密钥与存储的值直接进行比较。对于验证一组密钥，例如用户拥有的密钥和服务拥有的密钥（用于双因素身份验证），请比较这两个密钥是否存在于字节数组中。制作其账户实现的不同团队可以选择他们想要如何组织此存储的数据以实现其验证产品功能。

请注意，此方法依赖于虚拟账户的状态存在于密钥库 Rollup 中。虽然是使用该系统的有效方法，但我们也希望支持验证虚拟账户，而无需首先向其映射写入任何状态。我们希望这样做是为了完全兼容 EIP-4337 关于首次账户创建的目标：

此提案的一个重要设计目标是复制 EOA 的关键属性，即用户无需执行某些自定义操作或依赖现有用户来创建他们的钱包；他们可以简单地在本地生成一个地址并立即开始接受资金。

为了实现这一点，我们需要支持无需新交易即可进行验证，因此在密钥库 Rollup 中没有任何虚拟账户的状态。

排除——验证一个或一组密钥控制没有附加任何状态的虚拟账户——是通过有意构造虚拟账户 ID 来执行的。只需哈希虚拟账户的预期初始状态，我们就可以生成一个有效地保证与初始状态对应的标识符。如果有人要更改初始状态，则哈希输出将更改，从而代表不同的账户。然后，我们的验证过程显示（1）虚拟账户状态为空，以及（2）我们的密钥包含在生成虚拟账户 ID 的初始状态中。无需显式存储即可验证虚拟账户状态的能力意味着我们只需要在首次更新状态时才将账户添加到密钥库 Rollup，即首次添加或轮换密钥。这降低了开始使用密钥库 Rollup 的成本，因为不需要初始化交易。

用于验证账户单个所有者密钥的示例伪代码：

state[account] == key || // 包含条件
state[account] == bytes("") && account == hash(key) // 排除条件

在以太坊上验证虚拟账户

在以太坊上验证此虚拟账户的状态（无论是否为空）涉及更深入地了解区块链状态如何通过 Merkle 树 和 Rollup 架构构建。对于想要了解更多细节的人，建议阅读 Vitalik 深入探讨此步骤的证明方案选项。作为一个简单的解释，我们将继续使用 Merkle 树模型，并将其他证明选项理解为本质上使用不同方法证明相同关系的黑盒。

以太坊的所有状态都可以表示为一个巨大的 Merkle 树，其根和分支可用于证明以太坊上的任何状态。以太坊状态的一个子集属于我们的密钥库 Rollup 智能合约，该合约存储 Rollup 的 Merkle 根。在密钥库 Rollup 根中，我们有我们的密钥库智能合约，该合约存储包含所有虚拟账户状态的 Merkle 树。要证明给定的虚拟账户状态位于以太坊中，需要（1）证明该状态在密钥库合约根中的包含或排除，（2）证明密钥库合约的根包含在密钥库 Rollup 的根中，以及（3）证明密钥库 Rollup 的根包含在以太坊的根中。

有了以太坊根的声明，我们正在执行用户操作的 Rollup 如何验证此根是否正确？

同样，Vitalik 深入探讨访问最近的以太坊状态根将提供更完整的细节。

虽然目前在 Optimism 的研发 中，但对于 L2 智能合约开发人员来说，最简单的选择是直接在 Solidity 中访问状态根，作为一种新的关键字，从而可以直接与我们的证明的声明根进行比较。

如果没有这种便利，默认方法是利用 Rollup 堆栈的现有存款/消息传递功能，通过桥定期推送新的以太坊根。这需要在以太坊上提交一个新的交易，由索引器拾取并使用新的 L2 交易转发。虽然功能正常，但这种方法需要频繁更新，这意味着频繁的昂贵的 L1 交易。

对此方法的一个潜在改进是利用像共识证明这样的工具。通过使用零知识证明，我们可以用链下证明层替换 L1 消息交易。Rollup 托管轻客户端智能合约以验证这些证明并更新最新的以太坊根。这样，只需要在 L2 上进行一次交易，从而消除了消息桥模式中昂贵的 L1 原始交易。

在已部署的账户上验证虚拟账户

鉴于我们使用密钥库 Rollup 构建账户的方式，账户与虚拟账户 ID 不可变地绑定，例如通过存储不可变变量的构造函数参数。如果我们需要检查虚拟账户是否控制我们的智能合约账户，我们只需将输入值与我们存储的值进行比较。

更新密钥库 Rollup 状态

更新账户状态很幸运地简单得多，因为我们都在同一执行环境中验证和应用请求。实际上，我们只关心用户操作验证过程的前两个步骤：

1. 用户操作由一个或一组密钥签名
2. 密钥或密钥集对虚拟账户有效

第一步涉及从请求的签名和哈希中解析签名密钥。第二步涉及通过包含（非空状态比较）或排除（空状态，哈希比较）进行证明。如果两个步骤都通过，我们的用户就可以更新他们的虚拟账户的权限。

更新虚拟账户上的权限将更改密钥库智能合约的状态根，从而更改密钥库 Rollup 根，并最终更改以太坊的根。这会使未来任何尝试使用无效账户状态提交用户操作的行为无效，从而保证我们的新权限适用于所有网络。

其他考虑因素

确切的 Rollup 构造将受到优化之前提到的相同复杂性、成本和安全性维度以及其他因素的影响。为了提出一些问题：

• 将如何选择和激励排序器和证明者？
• Rollup 如何具有抗审查性？
• Rollup 如何扩展以支持通过 隐形地址 实现的隐私？

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