对于L1和L2使用完全相同的机制。一旦量子计算机成为问题，或者一旦证明Merkle分支变得足够高效，Verkle树可以使用适用于SNARK的哈希函数在原地替换为二进制哈希树。 聚合 如果N个用户进行N个交易（或更现实地说，N个ERC-4337 UserOperations）需要证明N个跨链声明，我们可以通过聚合这些证明来节省大量的gas：将这些交易组合成进入区块或打包到区块中的构建者可以创建一个单一的证明，同时证明所有这些声明。 这可能意味着： N个Merkle分支的ZK-SNARK证明 KZG多证明 Verkle多证明（或Verkle多证明的ZK-SNARK） 在这三种情况下，每个证明的成本仅为几十万个gas。构建者需要为每个使用该区块的L2中的用户制作一个这样的证明；因此，为了对构建者有用，整个方案需要具有足够的使用量，以便在多个主要L2上的同一区块中往往至少有几个交易。 如果使用ZK-SNARK，主要的边际成本仅仅是在合约之间传递数字的“业务逻辑”，因此每个用户可能需要几千个L2 gas。如果使用KZG多证明，证明者需要为每个包含L2的keystore-holding L2添加48个gas，因此每个用户的方案边际成本将在此基础上再增加约800个L1 gas（而不是每个用户）。但是，这些成本远远低于不聚合的成本，后者不可避免地涉及每个用户超过10,000个L1 gas和数十万个L2 gas。对于Verkle树，你可以直接使用Verkle多证明，每个用户增加约100-200个字节，或者你可以创建Verkle多证明的ZK-SNARK，其成本与Merkle分支的ZK-SNARK类似，但证明成本要低得多。 从实现的角度来看，最好通过ERC-4337帐户抽象标准让捆绑器通过自定义方式聚合跨链证明。ERC-4337已经为构建者聚合UserOperations的部分提供了机制。甚至已经有一个用于BLS签名聚合的实现，这可以将L2上的gas成本降低1.5倍到3倍，具体取决于包括哪些其他形式的压缩。 早期版本ERC-4337 BLS聚合签名工作流 直接状态读取 最后一种可能性，仅适用于L2读取L1（而不是L1读取L2），这是修改L2，使其能够直接对L1上的合约进行静态调用。 这可以通过一种操作码或预编译来实现，它允许调用L1中的地址，gas和calldata，并返回输出，尽管因为这些调用是静态调用，它们不能实际上改变任何L1状态。L2已经意识到L1以处理存款，因此从技术上讲，没有任何阻止实现这种机制的根本原因（参见：Optimism提供支持静态调用进入L1的RFP）。 请注意，如果密钥库位于L1上，并且L2集成了L1静态调用功能，那么根本不需要证明！但是，如果L2不集成L1静态调用，或者如果密钥库位于L2上（一旦L1变得对用户使用甚至稍微使用都太昂贵时可能会发生这种情况），那么将需要证明。 L2如何获取最新的以太坊状态根 为了处理从L1到L2的消息（尤其是存款），所有的L2都需要一些功能来访问最新的L1状态。实际上，如果一个L2具有存款功能，那么你可以使用该L2原样将L1状态根移动到L2上：只需让L1上的合约调用BLOCKHASH操作码，并将其作为存款消息传递到L2。L2端可以接收到完整的区块头，并提取其状态根。然而，每个L2都最好有一种明确的方式来直接访问最新的L1全面状态或最近的L1状态根。 优化L2接收最新L1状态根的主要挑战是同时实现安全性和低延迟： 如果L2以延迟方式实现“直接读取L1”功能，只读取已最终确定的L1状态根，则延迟通常为15分钟，但在极端情况下，如不活跃泄漏（必须能够容忍），延迟可能长达几周。 L2确实可以设计成读取更近期的L1状态根，但因为L1可能发生回滚（即使是在单槽最终确定性的情况下，也可能在不活跃泄漏期间发生回滚），因此L2也需要能够回滚。从软件工程的角度来看，这在技术上是具有挑战性的，但至少Optimism已经具备了这种能力。 如果使用存款桥将L1状态根带入L2，则简单的经济可行性可能要求存款更新之间有较长的时间间隔：如果一个存款的全部成本为100,000个gas，并假设以太坊价格为$1800，手续费为200 gwei，每天将L1状态根带入L2一次，那么每个L2每天的成本为$36，或者每个L2每年的成本为$13,148，用于维护系统。如果延迟为一小时，这个成本将增加到每个L2每年$315,569。在最好的情况下，一些急于支付的富有用户会为更新费用支付，并使系统保持最新状态，以服务其他用户。在最糟糕的情况下，某个无私的参与者将不得不自己支付费用。 “预言机”（至少在一些DeFi人士眼中被称为“预言机”）在这里不是一个可接受的解决方案：钱包密钥管理是非常关键的底层功能，因此它应该最多依赖于一些非常简单、具有密码学信任的底层基础设施。 另外，反向（L1读取L2）： 在optimistic rollup中，状态根需要一周的时间才能到达L1，这是由于欺诈证明的延迟。在零zkrollup中，由于证明时间和经济限制的结合，目前需要几个小时，但未来的技术将减少这一时间。 在L1读取L2的情况下，使用“预确认”（来自排序器、认证者等）并不是一种可接受的解决方案。钱包管理是一个非常关键的安全性低级功能，因此L2->L1通信的安全级别必须是绝对的：甚至无法通过接管L2验证者集合来推送错误的L1状态根。L1应该信任的唯一状态根是L2在L1上的状态根持有合约已经接受为最终的状态根。 有些跨链操作的速度对于许多DeFi用例来说太慢了；对于这些情况，我们确实需要更快速的桥接方案，但这些方案的安全性模型可能不够完善。然而，对于更新钱包密钥的用例，较长的延迟更可接受：你不是将交易延迟几个小时，而是将密钥更改延迟。你只需要将旧密钥保留更长时间。如果要更改密钥是因为密钥被盗，那么你将面临相当长的漏洞期，但可以通过一些措施来减轻风险，例如，钱包可以具备冻结功能。 总的来说，最小化延迟的最佳解决方案是L2以最佳方式实现直接从内部读取L1状态（或至少状态根）的能力，其中每个L2区块（或状态根计算日志）包含指向最近的L1区块的指针，因此如果L1回滚，L2也可以回滚。密钥库合约应该放置在主网上或是ZK rollup L2上，这样可以快速提交给L1。 其他链需要与以太坊保持多少连接以维护基于以太坊或L2根的钱包 出人意料地，这个连接并不需要太多。它甚至不需要成为一个正式的L2，如果是一个L3或validium，只要该链直接访问以太坊状态根，并在以太坊发生回滚时重新组织或硬分叉的技术和社会承诺。 一个有趣的研究问题是确定一个链与多个其他链（例如以太坊和Zcash）之间在多大程度上具有这种形式的连接。直接而幼稚的方法是可能的，即如果以太坊或Zcash回滚，密的链将不得不重组（并在以太坊或Zcash硬分叉时进行硬分叉），但然后你的社区将具有双重技术和政治依赖性（或者如果将你的链与许多其他链绑定，依赖性将更多）。基于ZK桥接的方案对51%攻击或硬分叉不具备鲁棒性。可能有更聪明的解决方案。 隐私保护 理想情况下，我们还希望保护隐私。如果你有许多由同一个密钥库管理的钱包，那么我们希望确保： 公众不知道这些钱包彼此相互关联。 社交恢复监护人不知道他们正在监护的地址是什么。 这会引起一些问题： 我们不能直接使用 Merkle 证明，因为它们不能保护隐私。 如果我们使用 KZG 或 SNARKs，那么证明需要提供验证密钥的盲化版本，而不泄露验证密钥的位置。 如果我们使用聚合，那么聚合器不应该以明文形式了解位置；相反，聚合器应该接收盲化证明，并有一种方式来聚合这些证明。 我们不能使用“轻量级版本”（仅使用跨链证明更新密钥），因为它会泄露隐私：如果由于更新过程导致多个钱包同时更新，时间上的泄露将暗示这些钱包可能相关。因此，我们必须使用“重量级版本”（每个交易都使用跨链证明）。 对于 SNARKs，解决方案在概念上很简单：证明默认是隐藏信息的，聚合器需要生成递归 SNARK 来证明这些 SNARKs。 这种方法的主要挑战是聚合需要聚合器创建递归 SNARK，而这在当前情况下速度相对较慢。 对于 KZG，我们可以以非索引泄露 KZG 证明的工作为起点（也可参考：Caulk 论文中对该工作的更正式版本）。然而，盲化证明的聚合是一个需要更多关注的开放问题。 不幸的是，直接从 L2 内部读取 L1 并不能保护隐私，尽管实现直接读取功能仍然非常有用，既可以最小化延迟，也可以用于其他应用程序。 总结 要实现跨链社交恢复钱包，最现实的工作流程是在一个地方维护一个密钥库（keystore），并在许多位置维护多个钱包（wallets），其中钱包要么（i）读取密钥库以更新其本地验证密钥视图，要么（ii）在验证每个交易时读取密钥库。 实现这一目标的一个关键因素是跨链证明。我们需要努力优化这些证明。最好的选择可能是ZK-SNARKs、等待出现的Verkle证明，或者自行构建的KZG解决方案。 长期而言，聚合协议将是必需的，聚合器将作为创建用户提交的所有UserOperations捆绑包的一部分生成聚合证明，以最小化成本。这可能需要与ERC-4337生态系统整合，尽管可能需要对ERC-4337进行一些修改。 L2应该优化以最小化从L2内部读取L1状态（或至少状态根）的延迟。L2直接读取L1状态是理想的，并可以节省证明空间。 钱包不仅可以部署在L2上，还可以放置在与以太坊连接较低的系统上（L3，甚至仅同意包括以太坊状态根并在以太坊回滚或硬分叉时重新组织或硬分叉的独立链）。 然而，密钥库应该放置在L1或高安全性的ZK rollup L2上。放置在L1上可以节省很多复杂性，尽管从长远来看，即使这也可能太昂贵，因此需要在L2上放置密钥库。 保护隐私将需要额外的工作并增加一些困难。然而，我们应该朝向保护隐私的解决方案发展，并确保我们提出的任何解决方案都能与保护隐私保持前向兼容。 来源：金色财经lg...
北美站
