mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

透过最新上线的zkRouter,看Multichain理想中的跨链未来

Collect
Share

2 月 22 日, 跨链 路由协议 Multichain 宣布已在测试网上推出了基于零知识证明的跨链基础设施 zkRouter ,并实现了从以太坊到 Fantom 的测试网跨链转账。

作为跨链赛道的龙头项目之一,为了更好地满足用户日渐增长的跨链活动需求,Multichain 迄今为止已推出了不同层级的多款产品。其中,资产跨链桥 Bridge/Router 现已覆盖了 81 条区块链,支持 3000 多个币种、坐拥 19.3 亿美元流动性,累积交易量高达 983.5 亿美元,市场占有率高居第一;消息跨链协议 anyCall 也已集成至 Curve Finance 等头部 Dapps,在跨链通信场景提供稳定、高效的服务。

而这一次推出的 zkRouter,则是 Multichain 在资产跨链、消息跨链外的另一层级所作出的全新尝试。

 

透过最新上线的zkRouter,看Multichain理想中的跨链未来

 

MBI: Multichain 眼中的跨链层级

在理解 zkRouter 之前,我们需要先行了解该产品在跨链服务层级中的位置。

在 Multichain 看来,随着多链并行成为大势所趋,“原生跨链 Dapps”也将成为链上应用的发展方向。不同于当前广泛存在的“多链部署式 Dapps” —— 比如部署在以太坊、 Arbitrum Polygon 等多条链上的 Uniswap Aave 等等 —— “原生跨链 Dapps” 将内嵌跨链功能,而不再需要依赖于外部桥或路由来补足跨链功能。

举个简单的例子,前段时间 Uniswap 选择 BNB Chain 跨链桥时的治理大战曾闹得沸沸扬扬,由于 Uniswap 并不具备原生的跨链功能,所以每当其部署至一条新链之时,就必须集成至一条跨链桥以供治理结果能够顺利地从以太坊向新链传递,这一过程耗时且繁琐,而“原生跨链 Dapps”则完全无需担心此类问题,仅需在内部调用消息跨链功能即可。

想要实现“原生跨链”的功能,仅仅依靠应用之间的组合并不足够,而是需要在更底层的位置提供完备的支持。结合自身在跨链领域多年的耕耘经验,Multichain 提出了一个名为 MBI(Multiple Blockchain Interaction)的多链交互总体架构。

 

透过最新上线的zkRouter,看Multichain理想中的跨链未来

MBI 从上往下共分为三层。 其中第一层为“应用层”,我们最熟悉的资产跨链桥就属于这一层级;第二层为数据层,消息跨链协议 anyCall 即属于这一层级;第三层则为信任层,所对应的产品除了多方信任机制 fastMPC Network 之外,另一个正是我们今天的主角 zkRouter。

在 MBI 的结构中, Multichain 针对从上至下的每个层级均向上封装了可供调用的功能实现,向下则屏蔽了相应的 技术 实现细节 。 开发者 可以基于其中的任一层构建自己的“原生多链 Dapps”,专注于其应用功能的实现和创新,而不必关注更底层机制的具体实现。

 

zkRouter:零知识证明的魅力

从定位上看,zkRouter 可以理解为一种采用零知识证明( ZKP )技术构建的链间信任机制。

ZKP 指的是证明者能够在不向验证者提供任何有用的信息的情况下,使验证者相信某个论断正确的一种数学证明机制。由于其数学可证明的特性,ZKP 一直被区块链行业视为解决信任问题的“圣杯”。

然而,由于图灵完备的 ZKP 技术一直处于待完善状态,且相关的开发工作需要极其深厚的密码学基础,同时配套的 SDK 开发难度也较高,因此这些年采用该技术的项目在进度上并不是很理想。不过对于 Multichain 而言,作为拥有着可持续收入的跨链服务龙头,其并不需要像熊市中的多数项目那样收紧预算,反而拥有着充足的资源来支撑复杂的研发工作。

最终的结果就是,基于理论及实践上的经验积累,Multichain 依托着优秀的开发资源和丰富的社区力量,在 Groth 16 与 Plonk 的研究进展之上推出了采用 ZKP 技术的链间信任层协议 zkRouter。

zkRouter 在 MBI 的结构中被归属于信任层,其效用是以无需信任、去中心化的方式在多链之间实现跨链共识的传递。零知识证明的机制下存在三个主要参与角色 -- 证明者(Prover),中继者(Relayer)和验证者(Verifier),证明者的作用是生成源链共识 ZKP,中继者负责将 ZKP 中继到目标链,验证者的作用则是确定证明者提供的 ZKP 是否是真实的。反映在 zkRouter 的运行机制内, 证明者可以同时是中继者,验证者是目标链轻客户端,担任证明者的中继节点需要在无法篡改数据的情况下构建出可被验证的证明,担任验证者的轻客户端基于 ZKP 证明,可以轻松独立地完成对接收内容真实性的校验。

zkRouter 运行机制的特性决定了 Proof 的生成和传递不会对内容的可信度产生任何影响,从而就实现了无需信任的共识传递。更具象的来说,这意味着 zkRouter 可以接受任何人来作为中继节点, 因此无论由谁来部署和运营 zkRouter,都不会干预到 zkRouter 的运作,更不可能影响其结果。

Multichain 补充介绍称,zkRouter 在设计上使用了优化后的 zk-SNARK 来生成简洁的 ZKP,支持目标链以较低的成本验证证明。该方案具有电路复杂度较低、存储开销成本较少、通用性较好等特点。

此外基于 Multichain 目前的预研,zkRouter 可以实现对 POS 和 POW 的共识传递,这意味着 zkRouter 可以应用于异构链之间的共识传递,也为该机制的未来发展带来了更多可能性。

 

有了 fastMPC Network,为何还要 zkRouter?

在前文的 MBI 框架中,我们可以看到除了 zkRouter 之外,Multichain 在信任层还有着另一套解决方案 fastMPC Network。那么,这二者之间又有何不同?有了 fastMPC Network 并基于该机制已搭建起了成熟的上层应用之后,为何 Multichain 还要费如此大的工夫来挑战复杂且困难的 ZKP 呢?

从运行原理来看,fastMPC Network 虽然与 zkRouter 一样同属于链间信任机制,但二者的技术基础并不相同。fastMPC Network 系基于多方 安全 计算(MPC)技术,该技术允许多组用户以他们的隐私数据为输入,共同计算一个函数,并且所有用户只能得到这个函数的输出,无法得到其他的任何信息。

MPC 的特点在于有着较高的计算安全性,但由于该技术包含复杂的密码学操作,计算开销大,性能损耗大,因此往往会存在一定的效能限制。不过,fastMPC Network 已就此做了相当大的效能优化,较之 Multichain 早期的 MPC 1.0 阶段已提升了快 4-5 倍的执行速度。

再看 zkRouter,作为 ZKP 的技术实现,其最大的特点在于利用数学证明实现了密码学意义上的安全,同时解绑了对中继节点的信任限制,做到了链间状态传递的完全去信任化。这也意味着 zkRouter 在安全性和工作效率上都会具有显著优势。

从应用角度来说,fastMPC Network 和 zkRouter 固然会存在一定的场景重叠,但 zkRouter 的天然优势决定了其拥有着更好地适配“原生跨链 Dapps”需求的潜力,这也是为什么 Multichain 会在定位上将 zkRouter 视为下一代产品服务的核心组件。

展望未来,Multichain 将在技术、产品、生态三个维度继续推进对 zkRouter 的研究、开发及合作推广,争取让 zkRouter 服务于更多的项目方和开发者,应用于更多场景,提供更多更细 颗 粒度的功能服务。

 

zkRouter 并不仅属于 Multichain,而是整个跨链生态的基石

在关于 zkRouter 的多篇介绍性文章中,Multichain 曾说过一句令我们记忆深刻的话:“ zkRouter 从来就不是 Multichain 自己的事情,而是所有认同‘原生跨链 Dapps’,认同 MBI 体系架构,认同 zkRouter 跨链基础设施关键组成定位的所有人的事情。

在 Multichain 看来,zkRouter 并不仅仅是该项目的一个产品,更是服务于整个跨链生态系统的关键基础设施。从某种层面上来看,zkRouter 对于跨链生态系统的意义甚至还要大于 Multichain 本身。

去年 12 月,Odaily星球日报曾采访过 Multichain 联合 创始人 Alfred Xu。在问及如何看待跨链赛道未来的发展趋势时,Alfred 回答称,正如 2020 年是资产跨链的元年一样,Multichain 坚信 2023 年将是 Dapps 跨链的元年……未来我们或将一起见证跨链 DEX 、跨链聚合、跨链借贷等创新型 Dapps 从被逐渐开发到日渐成熟,最终再通过相互组合构建出一个创新且繁荣的多链生态。

时隔两个月左右,zkRouter 正式诞生。这就像是 Multichain 播种下了一颗种子,虽然暂时还未来得及被广泛采用,但随着“原生跨链 Dapps”的日渐发展,其或许会在不远的将来爆发出惊人的势能。

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content