ZK 跨链通信协议:安全低成本构建全链 DApp 的未来
ZK 为跨链通信提供了一种安全,低成本的方式
跨链通信协议仍处于早期阶段,但有望允许 DApp 访问不同链上的数据
DeFi,全链 DApp 将从跨链 DApp 的发展中受益
跨链 DApp 的影响预计在未来几年内会非常大,就像全球化的影响一样。
开发人员正在努力探索构建跨链 DApp 的最佳模式
延迟,安全和成本是 ZK 跨链信息协议的主要指标
ZK 跨链协议四个主要的组件是:生成存储证明,结合存储证明和 ZKP,中继 ZKP, 展开承诺
文末还提供了由本文训练的AI,你可以提出与本文有关的任何问题。
前言
以前只有以太坊和比特币。他们拥有最多的流动性,最多的用户,最多的应用和最多的交易。2020 年后,出现了许多新的区块链,如 Avalanche,Polygon 和 BSC。
在这些链的主网推出后,我们看到了从以太坊和比特币到 ALT Chain 的范式转变。用户从以太坊转移到 ALT Chain 来寻找新的机会。开发者从以太坊转移到 ALT Chain 来分叉现有项目。这些开发者为寻求高回报的用户创造了新的机会。
以太坊曾经拥有加密货币世界中除比特币之外的所有流动性。在 2020 年底,以太坊 TVL 占比急剧下降到 60% 左右。以下是 165 个链的 TVL 数据。
今天,各大链 TVL 饼图看起来是这样的。以太坊占据了大部分的流动性。Tron 和 BSC 占据第二和第三的位置。
在将资产和流动性分散到不同的链上后,用户开始考虑如何在不同的链上管理和移动资产。资产发行者也考虑如何通过扩展到不同的链来扩展他们的用户。
跨链资产桥在 2022 年开始流行。用户不再使用 CEX 作为跨链桥,而是尝试转向去中心化的跨链桥。资产跨链桥有时会卡住,并容易受到攻击,但它更容易使用和用来转移大量资金。
然而,资产跨链桥还处于早期阶段,并且不能满足 DApp 开发者的需求。资产跨链桥只能让相同的资产在不同的网络之间流动。这对于开发者来说用处过于局限。开发者正在寻找一种更加通用的跨链方式。
跨链通信拥有强大的自定义性。开发者完全可以基于跨链通信开发全链 DApp。DApp 构建者希望在不同链之间传递消息并获取必要的区块信息。有了这些的特性,全链 DApp 的构建范式从互不通信,转向分布式的设计。在互不通信,相互独立的模型中,不同链上的 Dapp 实例无法彼此共享数据。在分布式设计中,Dapp 实例可以相互通信,并可以定期将数据同步到一个实例。该实例获取所有数据并可以修改其他实例上的参数。
借助 ZK 驱动的跨链通信,因为 ZKP 可以提供简洁的证明,它可以消耗更少的存储,将源链状态中继到目标链。此外,在目标链上验证 SNARK 证明相对便宜。ZKP 的这两个重要特性可以实现低成本的跨链消息和状态传递。在目标链上的验证源链状态可以实现 IBC 风格的跨链桥接。这大大增加了跨链的安全性。
当下
大多数区块链网络相互隔离,无法直接交换资产或代币。跨链资产桥允许用户在不同的区块链网络之间转移资产或代币。
随着 Wormwhole、cbridge 和 Stargate 等项目的推出,跨链资产桥的概念在过去几年开始受到关注。这些项目旨在创建可互操作的区块链桥,用户可以无缝地交换资产和代币。
跨链资产桥无法满足开发者的需求。开发人员正在寻找一种更通用的跨链方法,即跨链消息协议。为了满足开发者的需求,这些跨链桥大多都有自己的跨链消息协议,例如 Celer IM、LayerZero、Multichain 的 anyCall、Connext 的 xcall。他们提供了类似这样的 API
跨链消息通信协议是基于其跨链资产协议实现的。通过一些修改,这些跨链资产协议现在可以在链之间传递消息。这使得他们很难为跨链消息协议实现定制功能,因为整体设计需要兼容跨链资产转移。它们缺乏构建跨链应用程序的一些关键功能,例如将消息从一条链广播到不同链上的所有其他部署合约。这使得开发人员很难构建实用的全链 DApp。
跨链消息通信协议仍处于早期阶段。没有大型全链 DApp 完全建立在这些跨链通信协议之上。
为什么需要 ZK?
虽然这些跨链桥带来了很多便利好,例如提高资金利用率和改善用户体验,但它们也带来了安全风险。针对跨链桥的攻击给用户造成了巨大的经济损失。这使得安全性成为跨链桥开发的重中之重。这些攻击使用户损失了超过 15 亿美元。
一年内,跨链桥在黑客事件中的总损失约为 13 亿美元。跨链桥的使用手续费用在 5‱ 左右。Multichain 是跨链桥中的头部项目。Multichain 的 30 天交易量为 $1.7B,手续费收入为 $635K。那么一年的交易量约为 204 亿美元,手续费收入为 760 万美元。按照这样预估,跨链桥市场的手续费总收益远小于被黑客盗走的资金。
通过验证源链区块头,ZKP 跨链消息协议可以缓解部分安全问题。用户可以直接在目标链上访问源链证明并自行验证证明。如果没有 ZKP,这将很难做到。在传统项目中,这种验证成本太高,用户无法承受。
设计
在这一部分,我们将讨论 ZKP 是如何实现低成本,安全的跨链信息通信。
将 ZKP 用来中继消息的想法很直观,但详细设计可能很复杂。整个工作流程可以分解为以下步骤:
决定将哪些数据传递给目标链
获取存储证明(证明数据存在 EVM 存储中)
根据存储证明生成 ZK 证明
将 ZK 证明从起始链传递到目标链
在目标链上展开 ZK 证明
在目标链读取跨链信息
生成存储证明
大多数 EVM 兼容链都提供了这个功能。一旦用户明确了存储槽位,他们就可以使用 RPC 调用此方法来生成存储证明。
EVM 兼容链使用 Merkle Tree 来存储账户和数据。这使得创建 Merkle Proof 来验证这些数据变得相对简单。
Merkle Tree 是计算机科学中使用的一种数据结构。在密码学和区块链中的使用较多。它以其发明者 Ralph Merkle 的名字命名,也被称为二叉哈希树。Merkle Tree 背后的基本思想是将大量数据分成较小的部分,对每个部分进行哈希处理,然后组合哈希值以形成单个根哈希值。此根哈希充当整个数据集的指纹,允许对数据的完整性进行高效和安全的验证。
在区块链中,Merkle Tree 用于汇总和验证区块中的交易。每笔交易都经过哈希处理并添加到树中,哈希值以特定方式组合形成单个根哈希值,然后添加到区块头中。这允许以一种高效且安全的方式来验证区块中大量交易的有效性,而无需单独验证每个交易。如果交易中的任何数据发生变化,根哈希也会发生变化,表明数据已被篡改。
Merkle 证明,也称为 Merkle path,是一种密码学证明,证明特定数据包含在 Merkle Tree 中。Merkle Tree 证明提供了一种验证交易或其他数据真实性的方法,而无需下载和验证整个 Merkle Tree。
在 Merkle 证明中,用户提供了从 Merkle Tree 底部到根哈希的一系列哈希,以及要验证的具体数据。通过从特定数据开始并沿着树向上,接收者可以计算根哈希并将其与存储在块头中的根哈希进行比较。如果计算出的根哈希值与存储的根哈希值匹配,则接收者可以确信特定数据包含在块中并且未被更改。
Merkle 证明是确保区块链网络的效率和可扩展性的重要组成部分。通过允许在无需下载和验证整个 Merkle Tree 的情况下验证特定数据。Merkle Proof 减少了需要传输和处理的数据量,从而提高了网络的整体性能。
结合存储证明和 ZKP
将整个存储证明发布到目标链上是不切实际的,因为它太大了,大约 4kb。对于证明进行验证也很昂贵。在以太坊上进行验证需要 600k gas。如果 gas 价格为 30 gwei,则总费用为 0.018 ETH(30 美元)。
在这种情况下,ZKP 可以提供压缩和可组合性。开发者可以基于 Merkle Tree Proof 创建 ZKP。这可以大大减少证明的大小,并且使证明更容易验证。验证 Plonk 大约需要 290k gas。如果 gas 价格为 30 gwei,则总费用为 0.009 ETH(15 美元)。一次 Groth16 验证使用了大约 210k gas。如果 gas 价格为 30 gwei,则总费用为 0.006 ETH(10 美元)。
借助可组合性,开发人员甚至可以将不同的存储证明组合到一个 ZKP 中以节省资源。
中继 ZKP
为了安全地将相关承诺,如状态根或相关的 ZKP 传递到目标链,我们需要设计一个共识机制。
中继 ZKP 有 3 种常见的方式:
消息传递:使用一些消息传递协议传递 ZKP,并通过 OP CODE 获得相关承诺
共识验证:通过运行共识算法来验证相关承诺
Optimistic MPC relayer:部分思路与我们在很多跨链资产桥和 OPRU 设计中看到的类似。初始链和目标链之间有一个委员会。委员会的参与者决定中继承诺的有效性。任何人都可以挑战有效性。但是当挑战发生时,桥不能像 Rollup 那样回滚。需要一组单独的挑战者真正阻止恶意消息的传递。在这种情境下,挑战成本高,且延迟高,因为这涉及不断将根哈希和所有 CALL DATA 上传到初始链。并且它也只能以点对点的方式工作。
中继 ZKP 最为重要的是以下因素:
延迟
成本
信任
链下计算
消息传递的延迟相当高,因为消息传递需要时间来确认。在区块产生后,用户才能确认传递成功。在成本方面,消息传递需要与两个链进行交互,因此比较高。这种方式需要的信任较少,因为安全性等同于链的安全性。这种方式没有进行任何的链下计算。
共识验证是一种可行的方法。它与信息传递具有类似的延迟,信任假设和成本。然而,它必须在链外验证签名。这引入了大量链外计算的开销。但共识验证今天也可以通过 ZKP 完成。
Optimistic MPC relayer 牺牲了一些信任,但获得了更低的延迟。用户只需要将交易发布到中继器网络。具体的延迟取决于具体的 optimistic MPC relayer 机制。挑战期可能会导致更大的延迟。用户需要对中继网络有最小的信任。这种方式没有大量的链外计算,但需要在中继网络中进行通信和欺诈证明。
展开承诺
在得到承诺后,目标链上的用户可以展开承诺,访问初始链过去的状态。
三种常见的展开方式是:
链上积累
链上压缩
链下压缩
链上积累是一种在区块链网络中展开承诺的方法。在这种方法中,从承诺中重新创建区块头的整个过程直接在区块链上执行。正确编码的区块头作为交易中 CALL DATA,由区块链来执行计算。这种方法的好处是在证明时间方面没有额外开销。并且延迟很低,因为证明不需要在区块链之外进行验证。然而缺点是成本可能很高,因为计算可能是消耗很多资源。
链上压缩是一种减少需要存储在区块链上数据量的方法。它用于最小化在区块链上存储大量数据的成本。链上压缩背后的想法是使用压缩算法来减小数据的大小,从而减少它在区块链上占用的空间。这可以通过从数据中删除冗余或不必要的信息,或使用针对空间效率优化的数据结构来完成。然后将压缩后的数据存储在区块链上,需要使用时可以解压。
链上压缩具有降低存储成本和提高区块链可扩展性的优势。但是,它也有一些缺点。例如,压缩和解压缩数据的过程在计算上可能很昂贵,这会增加区块链的延迟。此外,所使用的压缩算法可能会对数据的安全性产生负面影响,因为它可能容易受到篡改或攻击。
链下压缩和链上压缩类似。
下面是这三种方法的对照表:
相关项目
很多 ZK 桥项目希望能提高不同链的互操作性,降低潜在的黑客风险。
这一领域有很多项目,例如:
Succinct Labs
Lagrange
zkBridge
Herodotous
=nil; Foundation
Succinct Labs 使用轻客户端方法。它使用轻客户端在目标链验证起始链共识层的共识。ZKP 用于生成共识证明。
Lagrange Labs 构建非交互式跨链状态证明。Lagrange Attestation Network 负责创建状态根。每个 Lagrange Node 都包含一部分分片私钥,用于证明特定链的状态。每个状态根都是一个阈值签名的 Verkle Root,可用于证明特定链在特定时间的状态。状态根是完全通用的,可以在状态证明中使用,以证明链中任何合约或钱包的当前状态。
Herodotus 使用 ZKP 的存储证明来为智能合约提供对来自以太坊的链上数据的访问。它有一个 MPC Optimistic Relayer 来中继承诺。它采用链下压缩,在链下展开中继的区块链标头并创建证明。
zkBridge 使用 MPC 中继网络生成区块头的 ZKP 并将其中继到目标链。它使用 deVrigo 和递归证明来实现非常快的证明时间,但 MPC 部分有较高的复杂度。
第一个用户发起跨链消息请求。初始链中的发送者接着将区块头转发到中继网络。中继网络中的验证者生成区块头的证明,并将其传递给更新合约。更新合约验证证明后, 接受证明。更新合约将证明转发给接收者,接收者将其转发给目标链中的应用程序和用户。
=nil; Foundation 也致力于 ZK 跨链消息协议。它使开发人员能够在以太坊上访问 Mina 的状态。他们在 2021 年底推出了一个演示,可以在以太坊上验证 Mina 状态。该基础设施允许以太坊上的智能合约验证 Mina 状态的有效性。有了这个基础设施,智能合约就有能力识别无效的跨链交易。
Mina 有自己的状态证明,但在以太坊上验证它们的成本很高。=nil; Foundation使用自己的 Placeholder 证明系统来生成辅助状态证明,这种证明在以太坊上验证起来很便宜。该基础设施使以太坊智能合约能够完全在链上验证 Mina 状态证明。未来跨链应用可以直接通过这个基础设施来验证跨链交易的合法性。
一个基于此的资产跨链桥将包含以下几个步骤:
跨链桥在 Mina 上锁定 $Mina
此基础设施生成 Mina 状态证明
此基础设施将 Mina 状态证明提交至以太坊上
以太坊链上合约验证状态证明的有效性
以太坊链上合约接收并存储 Mina 状态证明,如果证明有效
跨链桥在以太坊链上检验 Mina 和交易状态,释放 $WMINA
后来=nil; Foundation正在努力解决单向性问题。之前的 demo 中只支持单向的跨链通信。现在他们理论上支持双向桥接。初始链上的状态证明将在 Placeholder 证明系统中生成,并再次用 Kimichi 证明系统生成一个证明。然后再将证明提交给 Mina 验证者。验证者会将起始链状态证明视为 Mina 原生 zkApp 生成的证明。
=nil; Foundation 还发布了 Proof Market。用户/项目方在其中购买/出售大部分 SNARK 证明。目前有两种交易对,ARITHMETIC-EXAMPLE 和 MINA-STATE。
这是这些项目的详细比较:
应用场景
借助基于 ZK 的跨链消息中继协议,开发者可以轻松地将应用扩展到不同的区块链。
过去,合约部署主要集中在一条链上。当扩展到另一个链时,必须重新部署应用程序。使用基于 ZK 的跨链消息中继协议,将实现从单链应用到跨链应用的范式转变。大型项目可以轻松扩展到不同的链。这将产生与全球化类似的效果。我们希望看到更多的国际公司或大型跨链 DApps。
低延迟/实时和低成本的跨链消息中继协议将打开具有多种可能性的市场。DeFi、DID,治理和开发将从中受益
DeFi
DeFi 可以从中获益良多。跨链消息中继协议可以帮助 DeFi 产品整合来自不同链的流动性。
DEX、跨链交易和聚合器可以提供更好的用户体验、更低的滑点和更高的交易对流动性。不同链上的同一个交易对将有一个统一的流动性池。不同链 DEX 之间的价格差异会更小。DEX 显然可以聚集更多的流动性并提供堪比 CEX 的用户体验。
Farming 可以有更灵活的策略。他们现在可以在不同的链上寻找更多的获利机会。
借贷协议可以与不同链上的更多 DeFi 协议合作,并接受更多不同链上不同代币的存款。
链上衍生品将在流动性方面受到很大益处。通过安全的跨链通信,衍生品市场可以接触到更多不同链上的潜在客户,并且聚集更多的流动性。这可以提供更好的交易体验。
资金管理应用可以访问更多来自不同链上的资产。他们还可以访问来自不同链上的衍生品。这使理财经理可以使用更多的投资策略。
应用链
应用链 或 自定义 Rollup 为 Dapps 提供了更多的自由。Dapp 开发人员可以自定义应用链以满足他们自己的需求,例如性能或一些技术特性。Dapp 开发人员还可以自定义手续费结构以激励用户。Cosmos 上有很多应用链,因为 Cosmos 具有更好的互操作性。ZK 支持的跨链协议将是连接非 Cosmos 应用链与 EVM 或 layer2 生态系统的更好工具。许多正在开发的 Rollup SDK 可以受益于 ZK 支持的跨链协议。
Cosmos 生态在 APP 链上领先于其他所有主要生态。Cosmos 在跨应用链共享安全方面取得了良好进展。ZKP 可能会促进 Cosmos 生态系统的扩展。Composable finance 正在努力将 Cosmos 扩展到 Polkadot 和 NEAR。Electron Labs 和 zkBridge 正在将 Cosmos 带到以太坊。
利用不同链的特性
没有一条区块链是完美的。它们以牺牲其他功能为代价为一个目的而优化。借助跨链消息传递协议,开发人员可以利用每个区块链的优势并避免其缺点。
DApp 开发人员可以在不同的链中部署他们的 DApp 组件。例如,由于计算费用低,某些链可能是计算的不错选择。一些链可能针对隐私进行了优化,这将作为 Dapp 的隐私功能。有些链可以托管文件,有些则适合提供前端。跨链消息传递协议可以将这些组件粘合在一起,并允许开发人员充分利用每个区块链。
总结
ZKP 为跨链通信提供了一种全新的方式。它虽然不能完全解决传统跨链桥的安全问题,但借助 ZKP 的力量,安全的跨链消息通信现在大大降低了成本。证明的大小比以前小得多。链上验证成本也降低了很多。能够在目标链上验证源链状态,可以实现类似 IBC 式的共享安全性。在过去是不可能低成本的实现的。
ZK 跨链通信协议赋予不同链上协议互相交流的能力。开发者能够基于 ZK 跨链协议开发全链 DApp。DeFi,应用链将从中受益。
跨链通信协议仍处于起步阶段。开发人员正在努力开发这些协议,诸如如何在不同链之间实时同步状态等问题仍然没有解决。调试跨链 DApp 也可能很痛苦。开发者在探索构建跨链 Dapp 的最佳模式,我们将在未来几年看到跨链 Dapp 的影响。作为连接不同区块链的跨链通信协议,它将与全球化一样具有影响力。
戳这里调戏AI?https://glazec-zkbridge-streamlit-app-ord6v2.streamlit.app/
参考
https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86
https://www.youtube.com/watch?v=8mE_0qZNVjo
https://www.ingonyama.com/blogs/bridging-the-multichain-universe-with-zero-knowledge-proofs
微信扫描关注公众号,及时掌握新动向
2.本文版权归属原作所有,仅代表作者本人观点,不代表比特范的观点或立场
2.本文版权归属原作所有,仅代表作者本人观点,不代表比特范的观点或立场