Web3 生态的未来一定是多链的，要想打破不同链之间数据不互通的生态孤岛，离不开底层基础设施跨链。

嘉宾：MAP Protocol Tech Lead  

Phil @Mapo_talk

Forbes Web3 Innovation Pioneer | Core Dev at MAP Protocol   

James XYC @Jmapprotocol

整理：小胡

Web3 生态的未来一定是多链的，要想打破不同链之间数据不互通的生态孤岛，离不开底层基础设施跨链。从 Vitalik 在 2016 年的一篇报告《Chain Interoperability》到现在，多链生态经过多年发展，已经衍生出了复杂的生态，跨链的实现方式也千差万别。MAP Protocol 利用 Light-Client 和 ZK 技术打造去中心化全链基础设施。

01 多链生态：Web3 的未来

Web3 生态的发展有三步。

1. 比特币生态。比特币的诞生，促进了中心化交易所的诞生。

2. 以太坊为代表的公链生态。以太坊的可编程性，使得公链、L2 和 DApp 逐渐繁荣。

3. 以跨链或全链为基础的多链生态。多条链之间的信息互通，将大大繁荣 Web3 生态。

一般来说，不同 Layer1 公链都是独立的，拥有不同的共识算法、数据结构、安全算法、账本类型。除了设计之初就模块化的公链，不同的链之间的信息原生是无法互通的。

而搭建跨链或全链的基础设施，则是希望设计一套连接多条链的系统，允许不同区块链之间相互通信和交互。我们希望用户可以将信息、元数据和资产从一条链发送到另一条链上。

但是，必须承认的是，由于我们只能在区块链的原生算法与合约之外设计，我们永远无法将同一个资产，真正意义上地转移到另一条链。区块链上的资产，就是链上状态与相关合约的统称。比如以太坊和波场上都发行了 USDT。以太坊上使用 ERC-20 合约，而波场使用 TRC-20 合约。即使我们能将两条链上的 USDT 进行相互转换，但从本质上讲两者还是不同的东西。同质化的代币尚且如此，更不要提 NFT 这种非同质化的代币。

换句话说，跨链资产的价值，完全取决于跨链过程的安全性。（哈希时间锁定除外，因为其原理类似于 Swap 交换）

如果跨链过程有漏洞，导致跨链资产增发，那么资产的价值将对应的缩水，甚至归零。

幸运的是，跨链的安全问题并非无法解决，只是需要时间的积累。随着跨链技术的逐渐进步与安全经验的丰富，跨链资产的认可度将无限逼近于原生资产。多链生态也将进一步繁荣。

02 多链生态的实现路径

从 Vitalik 在 2016 年的一篇报告《Chain Interoperability》到现在，多链生态经过多年发展，已经衍生出了复杂的生态，跨链的实现方式也千差万别。

首先，所有的跨链都需要一个中介，实现这样一个中介就是跨链的本质。

跨链的时候，原链会触发一个事件 Event，表示成功发起跨链的请求；而目标链需要验证请求，并解锁或者铸造跨链资产。理想情况下，我们希望目标链能不断地监听原链的事件，如果包含跨链的请求，就执行解锁或铸造的操作。但问题是，由于有 Gas 费的存在，大部分区块链上的智能合约，都只能通过发送交易被动地被触发，而不能像真正的电脑一样可以用无限循环运行监听程序。

所以，我们需要一个中介，承担「监听原链」和「触发目标链」的操作。

不同项目方对跨链都有不同的分类方法。我们从跨链的最本质出发，以中介的不同形式将他们分类为：中心化机构、公证人、中继链和基于轻客户端的实现。依次去中心化程度上升，安全性提高。

1 中心化机构

中介是中心化机构。比如 CEX 也可以看作某种形式的「跨链」：不同链上的不同代币可以互相交易，也可以将同一种代币提取到不同链上。但缺点也非常明显。首先适用范围非常有限，只能针对已有的代币进行交换，而且面对 NFT 一类资产也将束手无策。而 FTX 暴雷事件也给我们启示，中心化、不透明将始终是悬在人们头上的达摩克利斯之剑。

2 公证人

中介是公证人（验证者）。除了中心化交易所，比较容易实现的跨链方式是链下公证人，实现刚刚提到的「监听原链」和「触发目标链」的操作。可以将这种方式比作一座桥，两条链上要部署智能合约，相当于两个桥墩子，公证人就是中间的桥梁。跨链的时候，先将要跨链的资产锁在原链上，通过公证人通知目标链。在这种实现方式中，目标链只能假设公证人不会作恶，信任公证人的结果。

因此一个提升安全性的自然的想法，就是增强公证人的去中心化程度。公证人的安全性也是逐步提高的：

最开始的时候，公证人由一个节点承担。但是显然问题非常多，如单一节点的私钥泄露、节点作恶、容灾、宕机等等。

因此我们通过引入更多节点提升去中心化程度。

最简单的组织方式是把单签变为多签，验证所有节点的签名。由于每次签名都需要消耗 Gas 费，这种方式的成本将会是单签的数倍。因此为了节省 Gas 费，链下签名聚合成为了一种选择。

随着节点个数和资产的增加，多签的方式也不够高效和安全了。多签依旧可能发生节点之间互相串通的情况。这时我们引入了多方安全计算（门限算法）。上图中对两种算法进行了比较。这篇隐私计算英雄传从安全发展的角度，有趣地讲解了多方安全计算的演进。

以上的逻辑都没有跳出公证人的范畴，只不过一步步地通过去中心化，减少公证人作恶的可能。而我们可以将「公证人链」看作去中心化的最终版本，即将所有公证人组成一条链。

3 公证人链

中介是公证人链。在公证人中，我们逐步实现了参与方的去中心化；当随着节点个数进一步增加，每次要汇总所有节点的私钥已经不再现实。而且我们不能保证节点之间串通的可能性。去中心化、可信…… 这正是区块链可以大展身手的地方。

我们将所有公证人组织成一条区块链，并且选择对应的共识算法，比如 PoS 算法。具体的来说，我们可以将所有的公证人节点进行随机分组，每一段时间后又会将分组打乱，以保证安全性。同时，由于公证人链本身具有经济属性，整个公证人概念的安全性被进一步加强了。

03 基于轻客户端的实现

1 中继节点与轻客户端

中介是中继与轻客户端。轻客户端是 Vitalik 提出的一种算法，可以作为智能合约部署在区块链上，用来验证某个交易是否属于另一条链。比如如果我们从 A 链跨资产到 B 链，那么我们可以在 B 链上部署轻客户端，只要验证到 A 链上的特定资产被锁住，那么轻客户端就可以在 B 链上释放或者铸造对应的资产。此时，中继节点不再像公证人一样，中继节点不需要被信任。中继节点只起到「触发目标链」的作用，而不承担任何证明的职能。

但是，轻客户端在 Gas 费消耗上并不「轻」。通过刚刚的描述，我们直观的感受是，如果将整套验证算法作为智能合约部署在区块链上，其 Gas 费消耗会由于逻辑的复杂性而变得很高。尤其是当某些链没有内置特定的预编译合约，如果采用手动部署的合约，Gas 费又将上涨一个数量级。比如如果 B 链上的轻客户端需要验证 A 链上的资产，那么就需要计算哈希值是否正确。但不同区块链采用的哈希算法可能不同，如果 B 链上没有预编译 A 链采用的哈希算法，Gas 就会被大量消耗。（比如以太坊截至目前还没有实现 ECDSA 算法）

2 类轻客户端：时间哈希锁定

这里我们再提一种类似于轻客户端的实现方式，尽管这种方式在实际应用中已经不是特别活跃了。轻客户端获取原链的区块头，直接验证交易是否在链上，而时间哈希锁定则通过在原链上生成的一个随机值，利用哈希函数在安全时间内无法破解的性质，验证随机值是从原链生成的。

3 中继链与轻客户端

似乎到目前为止，「中继节点 + 轻客户端」的实现，除了 Gas 费的消耗有点高以外，已经非常完美了。但实际情况往往并不是这样，「中继节点 + 轻客户端」还有他的缺点。由于有一些链的智能合约并不具备图灵完备性（比如 BTC），我们无法在链上实现轻客户端。而且，这种方式的实现难度以及 Gas 费其实超乎人们的想象。由于轻客户端是架设在两条 A 和 B 链之间的设施，如果要实现 N 条链之间的两两跨链，那么至少需要 N 平方个轻客户端。平方级的增长将很快变成一个庞大的数字，限制多链生态的真正繁荣。

那么类似 Layer2 的机制，是否可以将轻客户端放在某一条 Gas 费非常低、且智能合约是图灵完备的第三方链上呢？中继链的概念应运而生。

我们只需要将 N 条链分别与中继链相连，部署 2N 个轻客户端即可满足跨链的要求。

目前最有名的跨链项目有 Cosmos 和 Polkadot，两者采用的都是基于中继链的多链多层架构。

04 MAP Protocol 的实现方式

MAP Protocol 基本采用了中继链加轻客户端的实现方式。在这基础上，MAP Protocol 使用 ZK 优化了轻客户端的证明过程。

南洋理工大学网络安全实验室主任刘杨教授提到：

中继链的架构不但可以进行多链扩展，也避免了跨链消息不安全的风险；独有的基于零知识证明的轻客户端设计，减少了异构链开发难度的同时保证了跨链消息传输的安全性。通过兼容几乎所有的区块链并支持 DApps 在中继链上的原生部署，使 MAP Protocol 成为了跨链操作的核心组件，并有机会被证明为是跨链方案真正的未来。

详细解析请点击下方链接观看：《如何用 Light Client & ZK 技术实现无特权角色跨链技术？》

参考资料：

https://www.panewslab.com/zh/articledetails/6sznqfc7.html

https://foresightnews.pro/article/h5Detail/19308

https://learnblockchain.cn/article/1553

https://www.btcfans.com/article/61115