关注章鱼网络，开启 Web3.0 浪潮
北京时间 2 月 23 日，章鱼网络创始人 Louis 受邀参加 IBCL x Token DAO 联合主办的 Cosmos 跨链生态峰会，发表了主题为《 Making IBC Adaptive by Verification Proxies 》的演讲，对如何能够让 IBC 更加具有适应性做了深度分析并给出解决方案。
章鱼网络是一个围绕 NEAR blockchain 打造的多链网络项目，同时也是 Cosmos 生态的建设者。我们认为 IBC 是解决通用跨链最好的开放协议体系，所以从 2020 年开始，我们就在做 IBC 相关的开发。
Cosmos IBC 规范的 ICS10 是章鱼网络提出并且维护。同时我们也已经提出了 ICS11，也就是 NEAR Client，正在 Review 中，通过后也成为 IBC 协议家族的一部分。
https://github.com/cosmos/ibc
章鱼网络还组织了制作了 IBC 中文文档，有红军大叔、胡智威以及 Cosmos 中文社区的一些开发者共同翻译，覆盖所有核心 IBC 的协议。
去年年底到今年年初，由 HashKey Capital、章鱼网络、边界智能、Cosmos 中文技术社区、IBCL 社区、万向区块链实验室联合主办 Cosmos SDK 中文开发者培训，报名人数超 150 人，最终录取 35 名学员全部完成培训。这应该是首批中文 Cosmos SDK 开发者。希望我们未来华人 Cosmos 开发者社区越来越壮大，越来越活跃。
章鱼网络从 2020 年开发 Substrate IBC 开始，到现在两年多的时间。ICF Grants 一共是七个 Milestone，已经有六个通过了验收，可以说已经接近成功。完成最后一个 Milestone 之后，我们在和 Polkadot 的明星项目 Astar 在做 Polkadot 平行链到 Cosmos 的跨链桥。按照现在的计划，这个跨链桥应该是在今年二季度上线。这会是第一个 Tendermint 链到异构链的 IBC 跨链桥；同时 Octopus 也在做 NEAR IBC，把 NEAR 接入到 Cosmos 网络上。所以我们一直希望 IBC 成为真正的通用的跨链协议，不局限于 Cosmos。所以在这块我们做了很多的实践以及思考。这次分享算是总结，即如何能够让 IBC 更加具有适应性。
IBC 是开放的、分层的跨链协议体系。它的协议的 Framework，被称为 IBC TAO，在上面会有各种各样的应用。其中第一个也是用得最多的是 ICS 20，就是 Fungible Token Transfers，可以在链之间转 Fungible Token。刚才边界的小伙伴提到了 ICS721 可以在跨链里转 NFT。
在 IBC 的底层，叫 Light Client，也就是两条链 A 链跟 B 链相互在自己链上运行对方链的 Light Client，就能够直接验证对方链的共识。中间要有个 Relayer，把跨链消息以及信任根在两条链之间传来传去。信任根通常就是指的区块头，拿到了对方链的区块头而且验证它是合法的，这个就可以作为信任根来去验证具体的跨链消息。IBC 整个设计都基于 Light Client 验证，被认为是跨链安全方面的黄金标准。
但是在实际的跨链桥的设计上，我们面临的是不可能三角的问题。在区块链领域不可能三角特别的多，我们说的不可能三角，不见得是数学上证明了的三难问题。它是思维框架，就有几个主要的因素，需要在它们之间做折中，不可能鱼与熊掌兼得。
在跨链的设计里头，如果两端链确定了，就要在安全性、跨链成本和跨链时延三个方面折中。跨链 Cost 怎么来的？最大的一块就是对信任根验证成本。为什么验证成本能和跨链 Latency 做折中？因为在两条链之间去同步信任根的时候，频率越高，验证成本率越高；同步得越快，它就能够非常及时地去验证跨链消息，所以 Latency 会越小。Security 当然是要考虑的维度，如果放松验证的限制，Cost 就下降。所以在实际的跨链桥设计上总是要有所取舍，不能够把一个属性完全固定。比如说 Security 一定是最高等级的 Security ，最终就有可能出现：要么就是跨链桥贵到无法接受，甚至无法实现；要么就是慢到让用户无法忍受。
所以在实际的跨链设计里面，Cross-Chain Security 并不是只有一个点，而是一个谱。要跟其他的因素去做折中。跨链技术可以分成为 4 个大类，最重要的两个大类，Native Verification 和 External Verification。
Native Verification 就是在目标链能够直接验证源链的共识，不需要依赖于第三方。这类里面最经典的就是 Light Client 验证，是 Cosmos IBC 采用的方法。另外，现在出现了一系列的基于 ZK 的跨链设计。就是用零知识证明去提供一个跟轻客户端验证等效的零知识证明。安全等级也是基本上等同于 Light Client ，在数学上是等效的。
这其实并不是跨链安全的终极方案，还有更厉害像 ZK Rollup，Polkadot 的 XCMP，也就是两条链它是共享信任根，所以根本不需要同步信任根，就可以进行无信任跨链。另外还有出现 Full Client 跨链，就是在一条链上跑另外一条链的全节点，似乎只有 ICP 这么特殊的架构能够实现。
External Verification 就是在目标链上不直接验证原链的共识，而是由第三方验证原链的共识。目标链信任第三方，第三方有的是本身是类似链的设置，安全性来自于抵押，这类典型代表包括 Axelar、Celar、Ren、Hyperlane。还有是第三方的安全性不是来自于抵押，或者不是来自于 Token Economic 或者 Cryptoeconomic，本质上是 Reputation-Based 的。这类里面有 Wormhole， Ronin 和 Avalanche 和以太坊跨链桥，还有 Layerzero。
两个大类之间还有两小类方案。OP Verification 本质上是希望做 Native Verification，但是因为验证的成本太高，所以就不去做验证，依靠挑战排除错误。把信任根提交过去之后，留一段挑战期。挑战期内如果有人挑战成功了，提交虚假信任根的人会被 slash。如果在挑战期过后，没有人挑战，或者没有人能挑战成功，信任根就可以被用于验证。OP Rollup 和主链的跨链桥其实是 OP 验证。NEAR 的 Rainbow Bridge. 从 NEAR 到以太坊的方向上是 OP 验证。在以太坊到 NEAR 方向上是 Light Client 原生验证。Nomad 也属于乐观验证。
还有一个小类叫 Validator as Oracle，就是说目标链的每一个 Validator 都去独立地观察原链，然后在目标链上投票去决定是不是能够对原链的共识达成一致。如果能达成一致就认可信任根，因为它没有引入可信第三方，所以不属于 External Verification，还是信任这条链本身的验证人集合，像 Polygon Bridge， Gravity Bridge，包括我们的 Octopus Bridge 都是采用这种技术。但这个技术只有在特殊情况下才能考虑用，即原链要对目标链是特别重要，才有可能让每个目标链的验证人都去观察原链。所以 VaO 不是一个放之四海皆准的通用跨链技术。但是它的安全性接近于 Native Verification，而且不需要可信第三方。
所以大家看，在实际的跨链桥里面，是一定要在安全性、成本和 Latency 三者之间做好平衡。
在把 IBC 扩展到其他链上，碰到的最大问题就是 Light Client 。为什么？因为 Light Client 这个东西其实并不是为跨链而生，大家都知道从比特币就有 SPV，就是 Light Client。它是为了在资源有限的设备上去可靠的去观察和使用区块链而设计的。我们现在说的 Light Client，准确来说应该叫 On-Chain Light Client，就是在链上运行另外一条链的 Light Client。这样的设计并不是 Light Client 的经典应用。很多链在设计共识的时候会考虑到叫 Light Client Friendness，就是要轻客户端友好，但是未必考虑了 Light Client 要在另外一条链运行。这就是为什么这 Light Client Verification 在 Cosmos 运行得很好，因为 Tendermint 是为了支持区块链互联网设计的，Tendermint light client 已经考虑到了应该怎么去支持跨链，这是 Cosmos 的独特优势。
所以在把 IBC 扩展到其他链的时候，最大的问题一有没有安全 Light Client，二是 Light Client 验证成本是不是能够接受。
我们认为可以把 IBC 模型放宽一点，更灵活一点。我们引入了一个叫 Verification Proxy 角色。Relayer 拿到 A 链的信任根的时候，调用验证代理来验证，由验证代理产生一个 Proof。在 B 链上去验证代理的 Proof，而不是直接验证原链的共识。有了这样的架构之后，刚才说的各种折中技术，包括各种外部验证的的设计都可以容纳到 IBC 里面去，让 IBC 具有更强的对异构链的适应性。所以我们称之为 Adaptive IBC 架构。
Adaptive IBC 可能会受到两方面的诘难。第一个就是 IBC 的拥护者会说这不是Light Client。安全性做折中还是 IBC 吗？稍后我会回答这个问题，就是 Adaptive IBC 其实不见得会牺牲安全性。
另外一方面的诘难来自不太认可 IBC 的人。他们会说既然已经引入验证代理，何必再搞 IBC？就直接做 External Verification 的跨链桥不就完了？对这个问题，我们的回答是 IBC 是开放的分层协议。可以保持 IBC 的 App， IBC 的 Framework 不变，单独去演进验证层。比如短期内没法去实现轻客户端，可以用一个基于多签的验证代理来代替。以后多签的验证代理可以发展成基于 POS 的代理链，类似 Axelar/Thor Chain 的设计。或者等 ZKP 成熟了，能够以合理的成本去做原链共识的证明，我们就可以把验证代理升级成 ZKP。在演进过程中，可以保持对应用层的接口不变，也就是上层的应用不受影响。大家知道在区块链上去更新升级应用是非常困难的，需要有效的 Governance，还需要一些特别的设计才能够做到。如果通过分层设计，把验证层、通讯层、应用层分开，让验证层可以单独的去演进，不但能够适应更多的区块链的共识设计，而且能够随着验证技术的发展去逐步提升安全性，同时不影响应用开发。所以我们认为 Adaptive IBC 是有意义的。
当然我们做这样的模型不是为了给外部验证起个新名词，而是希望产生一个系统性的框架来思考：到底什么样的验证代理才有意义？
首先它一定要有成本优势。代理验证的成本应该远远低于直接验证的成本，方法才是有效的。
同时要考虑到 Verification Proxy 是跨链桥的一部分。既然跨链系统的去中心化程度是由最中心化的部分决定的，那验证代理本身也应该去中心化。按照这个思路，其实现在大家看到了很多验证代理都是要做成区块链，本身也要有 Trustless、Permissionless 和 Censorship Resistant 属性。所以我们可以通过 Adaptive IBC 框架去评估验证代理。
有一些跨链桥项用 TEE 来做验证代理，我是不太看好这样的设计。因为 TEE 是个黑盒子，很难做可信的初始化，状态也是不可见的。换句话说，TEE 没有公开可验证的特性。甚至一个跨链桥是不是真的运行了 TEE 你都不知道。无论对错，你都没有办法验证。所以我感觉基于 TEE 的验证代理跟区块链或者跟 Crypto 不是很相容。
我们也在考虑把验证代理做成一条专用链，还有没有可能在公链上去实现验证代理。只要成本节约的条件仍然成立，那么公链它就具有 Trustless、Permissionless 和 Censorship Resistant 这些特点。这就是为什么 Octopus 在尝试用 ICP 去做验证代理，因为 ICP 上的验证代理是公开可验证的，而且具有很高的安全性。ICP Smart Contract 的输出是可以做门限签名，验证成本 极低，很容易满足成本节约公式。
而且验证代理不见得会牺牲跨链系统的安全性。我们对去中心化系统的安全有两个视角，一个是这个叫「信任集合」视角。例如 IBC 是只需要相信原链和目标链，并且依赖 Relayer 的活性。现在放进 Verification Proxy，信任集合扩大了，所以安全性受损了，从这个视角来看，引入验证代理无论如何都是安全性下降了。
可还有另外一个视角，就是可量化的安全。攻击成本总是大于攻击收益，系统就是安全的。所以对设计良好的中心化系统，都应该能够量化攻击成本。基于 PoS/BFT 共识的区块链， Attacking Cost 有两个级别：超过 33% 的验证人串通就可以让链失活；超过 2/3 的验证人投票权重就可以控制这条链，就可以作恶。如上图，我们画一条线，原链的安全性取决于它的攻击成本，目标链的安全性也取决于它的攻击成本。如果验证代理的攻击成本高于其中的一条链，甚至高于这两条链，引入验证代理就不会降低跨链桥的安全性。
免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议。
| 往期精选 |
通过 Substrate-IBC 实现 Substrate 资产跨链
Louis 谈 dYdX “叛逃”以太坊
专用预言机 -- Substrate 应用链独有设计模式
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
