Across V4 引入了新的和改进的跨链架构。
该系统结合了意图和零知识证明（ZKP），以更快地扩展到更多链。
以下是技术细节。🧵
之前，Across 使用了“规范桥”或链特定适配器来验证来自以太坊 HubPool 的消息。
这对于像 Arbitrum 和 Optimism 这样的 L2 来说效果很好，因为它们暴露了以太坊最终确定的状态。
但这种设计是有限制的…
对于像 BSC 这样的非 EVM 链，这种模型就不适用了。
没有标准的方法来验证以太坊状态。这意味着要么构建自定义适配器，要么根本不支持这些链。
这两种方案都不是最佳解决方案。因此，我们找到了使用 ZKP 的更好方法。
过程如下：
当中继器填写跨链订单时，交易被批量化为中继器还款捆绑包，然后由@UMAProtocol的 Optimistic Oracle 进行验证。
这总是发生在以太坊主网上。
一旦捆绑包被验证，Across HubPool 就会触发结算过程。
然后，它将还款消息哈希写入 HubPoolStore 合约的特定存储槽中。
此存储事件也发生在以太坊主网。
HubPoolStore 合约中的每个消息哈希对应于在目标链上偿还中继者的意图。
请注意，L1 → L2 消息可以表示多次偿还（包括慢填充）。这是因为它们是根捆绑。
当 HubPoolStore 合约写入存储的消息哈希时，它会发出 StoredCallData 事件。
该事件包含消息哈希和存储槽。
事件 + 存储的数据构成了下游 ZK 验证的锚点。
一个名为 finalizer 的服务监听这些事件。
一旦它检测到一个新的事件，它会启动一个过程来证明该消息哈希确实已写入以太坊。
每条消息的哈希被存储后，都有一个目标，该目标可以特定于其链。
该证明允许消息在目标链上安全执行。
但以太坊的最终性并不是瞬时的。
一旦最终确认者将数据发送到ZK API，API将在以太坊的最终性窗口中等待，然后生成证明。
要生成有效的ZK证明，以太坊同步委员会必须对特定的已最终确定区块进行签名。
如果消息在该区块中或之前被包含，则所需的签名将可用以开始生成ZK证明。
最终确认者查询 ZK API 以生成证明，证明特定消息哈希已写入已确认的以太坊区块中的已知 HubPoolStore 存储槽。
这使得在任何目标链上对中继者还款的无信任验证成为可能。
ZK API 准备了证明输入，包括（但不限于）：
- 最终的信标头
- 同步委员会签名
- 来自以太坊执行层的存储梅克尔证明
这些构成了生成证明的基础。
Across 在目标链上部署一个通用堆栈：
- 一个验证器合约（验证 ZK 证明）
- 由 @Succinct 提供的 SP1Helios（存储最终的以太坊状态）
- UniversalSpokepool 合约（在执行过程中验证消息的真实性）
一旦ZK证明被验证并且状态被确认，executeMsg()可以安全地在目标链上运行有效载荷。
无信任。安全。通用。
这意味着 Across 不再需要为每个链定制适配器。
只需一个在任何地方都能工作的管道：
在以太坊上调用 storeMsg() → ZK 证明 → 在任何能够验证 SP1Helios 证明的目标链上执行 executeMsg()。
没有信任假设。
没有集成开销。
只有意图 + ZK。
这为什么是个大问题？
它通过解锁对无法本地验证以太坊状态且没有标准桥接的长尾链的支持，显著扩大了Across的覆盖范围。
这使得入驻变得更快、更安全和更具可扩展性。
Across 不需要这些链的规范桥。它只需要能够验证以太坊状态的 ZK 证明。
这减少了集成开销，避免了中心化桥接风险，并加强了以太坊作为跨链真相之根的作用。
8,585
42
本页面内容由第三方提供。除非另有说明，欧易不是所引用文章的作者，也不对此类材料主张任何版权。该内容仅供参考，并不代表欧易观点，不作为任何形式的认可，也不应被视为投资建议或购买或出售数字资产的招揽。在使用生成式人工智能提供摘要或其他信息的情况下，此类人工智能生成的内容可能不准确或不一致。请阅读链接文章，了解更多详情和信息。欧易不对第三方网站上的内容负责。包含稳定币、NFTs 等在内的数字资产涉及较高程度的风险，其价值可能会产生较大波动。请根据自身财务状况，仔细考虑交易或持有数字资产是否适合您。