原文标题:《Cosmos 上线主网了,但是「为什么需要跨链」依然有待探寻》

写在前面

Cosmos 上线了。

回想了一下,上次和创始人 Jae 交流还是去年 10 月份。记得那时在采访的末尾,笔者曾问,Cosmos 前面还有什么困难吗?Jae 想了想,掰着手指头数还需要做哪些组件,数完发现,这些好像基本都快做完了,于是他抬头笑了一下,说:it is been a long way。

是啊。从 2014 年到现在,转眼 4 年过去了,Cosmos 终于上了主网。

我很喜欢 Jae 聊天时候的真诚。10 月份写完那篇采访文章后,我印象最深的是,Jae 从心底相信这个世界始终会存在两种力量,一种是朝着中心化的、集群的方向(比如出现一条大一统的公链),另一种是人们想要某种可替代性,或者第二选择(比如自己可以很轻易的发一条链)。这两股力将会不停地互相 push,而 Jae 选择了不那么明了的那一边。

这个世界需要不同的人试验各种不同的理念。Jae 希望让每个应用、每个组织、甚至是每个人,都能拥有一条链。我们甚至可以不要 Cosmos 的主网,只是采用他们的工具,自己做一个 hub,然后找周围一些朋友来做 zone,这样一个小群体就可以拥有一个小的区块链组网,这个组网甚至不需要跟外界任何的公链挂钩,它完全在内部运行——我觉得这样的概念很有趣,像是让一小群人打造一个只和自己有关的局域网,一个属于自己的小岛。同时,这个小岛如果需要的话,也能和外界互联互通。

但问题是,我不确定这样的理念是否能得到人们真实需求的支撑。也许矿工和验证节点这些资源可以通过共享的方式,一定程度上解决资源浪费的问题,但自己运营一条链的成本和难度依然是不低的。也许我们以后大概率不会拥有太多的 layer 1,还是会出现一个大一统的公链,它的性能和架构足够安全稳固,人们在稳固的东西上面再继续搭建新的应用,但现在这样一个公链还没有出现,也许还要很久,而我们目前其实只有两个真正非常 solid 的价值池:比特币和以太坊。

抛开这两个价值池,把其他那些并不稳固的网络连接起来,真的有意义吗?人们需要这么做吗?哪怕是比特币和以太坊,我也想象不出它们互相连接的场景是什么,为什么需要连接。如果只是涉及到代币价值的交换,这个问题不是已经部分被交易所解决了吗?如果是针对去中心化交易所的代币交换,是不是应该有更简洁、针对性更强的解决方案,或者换到其他层上解决?

我喜欢 Cosmos 的尝试,但跨链本身的技术难度,往往取代了一些其他问题的讨论,以至于我们看到的讨论,似乎都以「默认 layer1 跨链的必要性」为前提了。但关于跨链的场景问题,我确实始终没想明白。我希望能听到一些其他的看法,解决这些困惑。如果你有更好的理解,欢迎评论一起交流。

对于那些并不了解 Cosmos 的朋友,作为弄懂 Cosmos 原理的介绍,笔者去年 10 月份写的这篇文章依然值得一读。我们一直希望生产那些拥有更长生命周期的内容,所以下面这篇文章,决定再发一遍。

对话 Cosmos:未来是所有人都用一条公链,还是每个人都有自己的链?

Cosmos 是一个很有意思的项目。如果要总结它的思想的话,这个 2014 年成立的项目,初衷是让每个人都可以轻松地拥有一条属于自己的链。

在大部分人忙着打造公链、一统江湖的时候,Cosmos 的创始人 jae 有一些自己独特的想法。他相信在大一统的公链之外,人们仍然需要有可替代的选择,总有一部分人希望拥有一条属于自己的链。甚至从其他角度来说,许多去中心化的应用本身也应该是一条独立的链——比如,加密猫应该是一条链,fomo3d 也应该是一条链,而不是公链上的应用。

为此,Cosmos 团队创造了许多工具,让开发者可以像开发 dapp 那样轻松开发自己的链。最终,当许多「小而美」、「定制化」、「专业化」、「针对性特别强」的链,像无数江河流海涌现出来时,Cosmos 会通过跨链协议和更大的网络生态系统,为这些不同的链提供互相连接的能力。cosmos 的目标是让这些江河流海汇聚成区块链的大海洋。

这篇文章希望用通俗易懂的语言介绍 Cosmos 到底是干什么的,它有趣的地方在哪,介绍完这些基础信息后,文章末尾还有一部分笔者和 Cosmos 创始人 jae 及其核心技术团队对话的内容,从中也许你能更深刻地理解 Cosmos 的理念。

Cosmos 的起源:Tendermint

在技术发展早期,人们对如何开发一个去中心化的公共账本并不会有太多的认识和思考。比特币和以太坊就像一台整体焊死的电脑,上面所有的元件都集成在一起,其中的逻辑错综复杂,没有任何分层的技术栈可言。你很难对它进行改动,里面的零件也没法拔出来做升级。当人们对公链有各种各样完全不同的想法之后,很多人开始想开发自己的链。这个时候你会发现,即使比特币和以太坊开源了,你也很难进行代码的复用。除了把比特币代码拷过来,改个参数,换个名称,弄出一个山寨币之外,做不了太多事情。

在这样的背景下,有人就想,我能不能做一个工具,让大家使用这个工具能更好更快的开发自己的链呢?就好像组装电脑一样,键盘、鼠标、显示器、内存条,这些东西都是现成的、可独立拆卸的,一个不懂计算机原理的人也能像拼积木一样,制造各种各样不同性能的电脑。

Cosmos——准确的说,是 Cosmos 里的 Tendermint ——就这样诞生了。

Tendermint 是 Cosmos 里面最重要的组成部分之一,它也是整个 Cosmos 生态的基础。要理解 Cosmos,需要先弄懂 Tendermint。

简单的说,Tendermint 是一个通用的区块链开发框架。你可以借助这个框架,快速定制开发自己的链。

不妨设想一下,如果让你来设计这样一套开发工具,你会怎么设计?很显然,第一步需要先把所有链都要用到的功能抽象出来。就像你要帮助别人制造一台电脑,需要先搞清电脑都有 cpu、内存、以及显示器这些东西一样。

一条链的必要组成部分都包括哪些呢?

Cosmos 团队认为可以这样划分:

  1. 网络层:用来确保,在一个点对点的网络里,每个节点都能接收和传输一笔交易。
  2. 共识层:用来确保每个节点选出同一笔交易,这个交易将被允许对节点的状态进行修改。在比特币里面,所谓「状态」就是一系列账户的余额(虽然是 utxo 模型,但为了简化理解,我们可以这样认为),矿工们就一笔交易达成共识,如果有效,这笔交易就会修改所有账户的余额。
  3. 应用层:用来确保交易的处理。所谓「交易的处理」指的是:输入一笔交易和一个状态,这个应用就会返回一个新的状态。在以太坊上,应用层其实就是所谓的 evm 虚拟机。所有的交易进入虚拟机,虚拟机会根据调用这笔交易的智能合约的指示来修改状态。

大一统还是可替代性?Cosmos 坚定不移地选了第二条路

Cosmos 团队认为,这个三层结构基本就可以概括一条链的所有东西了。同时,大部人想开发自己的链,其实都不太关心网络层和共识层,他们自己想定义的是应用层的东西,因为这层负责业务逻辑。

所以,Tendermint 的目标就变成了:

打造一个通用的网络层和共识层,让大家可以轻松在上面搭建自己的应用层,节省很多不必要的开发时间。

Tendermint 包含两部分的东西:

  • 第一部分叫 Tendermint Core。这部分把共识层和网络层封装在了一起,变成一个通用引擎,这个引擎用来确保:交易按照一致性和安全性的原则被复制到各个节点的机器上——也就是说,相同的交易以相同的顺序被记录在链上;
  • 第二部分叫 ABCI 协议,Application Blockchain Interface。这部分是 Tendermint Core 引擎和上面开发者自定义的应用层之间的接口。通过这个接口,应用层可以和底下的共识层和网络层进行通信对话。ABCI 协议的特点,是让一笔交易可以被不同编程语言和任何编程环境下的应用处理。

接下来,我们详细看看这两部分的东西:

Tendermint Core

Tendermint Core 包括网络层和共识层:网络层方面使用的是 gossip 协议,这块不重要,我们重点来看看共识层。

共识方面,Tendermint 使用的是拜占庭共识算法+pos。

拜占庭算法是一类解决共识的算法,它要求网络里的验证节点一轮一轮地进行广播和投票,最终达成整个网络的一致性,以此来抵消节点离线、网络通信延迟、恶意节点捣乱等问题。拜占庭算法需要至少 2/3 的节点是诚实节点,在 Tendermint 里面,这个 2/3 的节点不是指的节点的数量,而是指的节点所拥有的权益,也就是「钱」的数量——因为是 pos 机制,这个和我们 [之前介绍过的 algorand 是一样的。

此外大家都知道,拜占庭共识算法比如 PBFT,是要求验证节点必须是事先预设的一组固定的节点,但在 Tendermint 里,验证节点可以动态变化,只不过这个动态没法像比特币 POW 那么灵活,你想加入就可以加入,想退出就可以退出。每次 Tendermint 增加或者退出一组验证节点,都需要经过至少 2/3 的节点的投票才能决定。

最后,如果验证节点太多的话,形成共识的时间是会变慢的。所以,Tendermint 在创世的时候把节点数设定为 100 个。在这 100 个验证节点之外,其他的用户则可以使用轻节点来访问网络。根据他们的计划,这 100 个节点数会按每年 13% 的速度增加,10 年后稳定为 300 个节点。那么,100 个节点对去中心化到底有没有什么影响?这个问题属于见仁见智了。Cosmos 认为是没问题的,他们的白皮书里有这样一组数据:

64 个节点,横跨 5 个大洲,7 个数据中心,使用商用的云计算实例,可以提供超高的处理性能,每秒钟处理上千笔交易,延迟在 1-2 秒之间。而且这种性能是在严苛的敌手假设里也能够成立的,哪怕系统里有恶意节点故意投票作弊,也能保证一定的容错性。

大一统还是可替代性?Cosmos 坚定不移地选了第二条路

可以看到,Tendermint 的好处体现在性能、安全这些方面。除此之外,Tendermint 的另一个优点在于它不会分叉,因为 pos 拜占庭共识算法都是出块后就立即达成最终确定性的。

ABCI 协议

有了 Tendermint Core 这个大杀器,你就可以在上面搭建各种各样的链了,不管是公链、联盟链还是私有链。

之所以能做到这一点,是因为 Tendermint Core 是不知道上面应用层具体是什么样的,它不关心应用层的实现。Tendermint 把许多无关的细节都忽略了,只抽象出关键的东西,做成通用的接口。这个接口就叫 abci 协议,用来连接应用层和 Tendermint Core 之间的通信。

大一统还是可替代性?Cosmos 坚定不移地选了第二条路

abci 协议是一个 socket 协议,不管你使用哪一种编程语言、运行在什么样的编程环境下,只要你符合这个协议的标准,应用层和 Tendermint Core 就能通信。Cosmos 官方已经实现了一个 abci 协议的版本,名叫 Tendermint Socket Protocol (TSP, or Teaspoon),当然你也可以实现自己的版本。

abci 协议包括几种不同的消息类型。Tendermint Core 会创建 3 个 ABCI 连接到应用层:一个用于内存池中广播交易的验证;一个用于共识引擎运行,用于新的区块的提议;最后一个用来查询应用层的状态。

以太坊的 Solidity ,以及 Java, C++, Python,Go 这些语言都可以用来写出确定性的区块链交易处理逻辑。需要注意的是,区块的处理必须是即时确定的,不能是像比特币 pow 那种概率性确定,否则 Tendermint Core 达不成共识。pos 和 poa (proof of authority)共识算法都是即时确定的。

流程图

整个 Tendermint 的工作流程(在技术上)可以简化成下面一张图来表示

大一统还是可替代性?Cosmos 坚定不移地选了第二条路
高清版点这里查看:https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf

我们用一个更具象的例子来看看 abci 协议和应用层的关系,可能会更直观一点。

比如说,我们想要以 Tendermint 为基础实现一个「假的比特币」:比特币就是一个记录虚拟货币交易记录的区块链,网络中每个节点维护一个经过所有人完全审计的 UTXO 数据库。

我们需要利用 abci 做一个符合类似定义的系统。那么 Tendermint Core 主要负责这些事情:

  • 在节点间共享区块的信息,交换一笔笔交易;
  • 建立一个权威的、不可被篡改的交易记录(也就是一条链)

我们需要编写的应用层的东西则需要负责:

  • 维护 UTXO 数据库
  • 验证交易的密码学签名
  • 防止出现「花费不存在的交易」
  • 允许客户查询 UTXO 数据库

Cosmos SDK

好了,我们大概了解了 Tendermint 到底是个什么东西。

可以看到,编写一个 abci 还是挺麻烦的。为了进一步方便用户进行区块链开发,Cosmos 还提供了一个工具叫 Cosmos SDK,这个工具把区块链中的一些通用模块标准化,这些通用模块覆盖了大部分应用层需要具备的功能,比如:staking (抵押机制)、slashing (惩罚机制)、IBC (跨链功能),账户 accounts、治理、奖励 & 手续费等。

大一统还是可替代性?Cosmos 坚定不移地选了第二条路

有了 Cosmos SDK,用户只需要在 SDK 的基础上实现其他插件模块,处理一些链特有的业务。

Cosmos 团队自己也利用这套 sdk 实现了一个例子叫 Cosmos Hub,这个例子我们后面会涉及到。

跨链

我们已经了解了 Cosmos 最核心的技术 Tendermint,也知道了 Cosmos sdk 是干什么。接下来我们看看 Cosmos 跨链这块的技术。这也是 Cosmos 未来最重要的想象空间。

当我们没有很多条链的时候,跨链这个问题其实是不存在的。但随着现在公链越来越多,跨链就成了需要解决的问题。两条链需要彼此进行对话,比特币和以太坊彼此要进行交易、传送价值、交换各自的代币,这个东西怎么解决呢?

有这么一个思路:

假设 A 链想要给 B 链发送 10 个 x token,首先,这 10 个 x token 就会被锁在 A 链上,不能动。然后,这 10 个 x token 被锁定的密码学证据从 A 链传输给 B 链,B 链跟踪 A 链上的验证节点,如果这个密码学证据被至少 2/3 的验证节点签名过,那么这笔跨链交易就是有效的,B 链上就会产生相应的 10 个
x token。注意,B 链上的 10 个 x token 其实并不是真的 x token,因为 x token 只存在于 A 链上,B 链上的 x token 只是 A 链上的 x token 的代理而已,这个代理 token 需要配合一个证明了这些币在 A 链上确实已经被锁定了的密码学证据。当这些 token 从 B 链上返回到 A 链,也是采用类似的机制。

这套机制抽象出来,就是 Cosmos 在使用的跨链通信协议——IBC 协议,Inter-Blockchain
Communication。IBC 就像一座桥,让不同的链可以互相连通。关于 IBC 更详细的定义可以查看这里:
https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/ibc

不过遗憾的是,目前 IBC 协议只支持简单的价值传递,就是跨链发送 token,还不支持逻辑、代码或者其他数据的传输。

区块链网络

有了 IBC 这个跨链通信协议,我们如何构造一个互联互通的区块链网络?

一种最直接的做法是,让网络中的每一条公链都和其他不同的公链之间建立 IBC 通信协议。这种做法简单有效,但它有一个大问题:不具备扩展性。假设网络中有 100 条不同的链,他们两两互联就需要建立 4590 个链接。一旦链的数量增加,建立链接的数量也会迅速增加。

那可不可以不要彼此互联,直接把所有链全部串联起来呢?

这样如果有 100 条链,他们总共只需要建立 99 条链接。但采用这种方式会面临另一个问题:信任成本增高,一笔跨链交易出现双花的风险也将大大增加。为什么呢?如果 A 链发给 B 链的 token 是在 A 链上产生的,那么 B 链只需要信任 A 链的验证节点,但如果这个 token 是在 C 链上产生的,从 C 传到 A 再传到 B,那么 B 链就需要同时信任 A 和 C 的验证节点,最终这种跨链交易的验证会非常麻烦。

为了避免上面这两种类型的问题,Cosmos 采用另一种办法跨链。他们采用一种模块化的架构来建立整个区块链网络的连接,这个架构包括两个组成部分:一个叫 hub,一个叫 zone。

zone 和 hub 都是基于 Tendermint 的区块链:hub 是跨链连接的中心,所有跨链的交易都通过 hub 统一处理;zone 则是不同的子链。zone 通过 ibc 协议和 hub 连接在一起,不同的链彼此要进行跨链交易,只需要通过 hub 来代理就能完成。

大一统还是可替代性?Cosmos 坚定不移地选了第二条路

Cosmos 团队实现了第一个官方版的 hub,名叫 Cosmos hub,也就是我们上文提到的利用 Cosmos SDK 打造出来的产品。Cosmos hub 有自己的一套原生代币叫 atom,zone 上的验证者需要在 hub 上质押一部分的 atom 代币,以此来规范自己的行为。一旦 zone 验证节点作恶,hub 就会没收 zone 的代币,这叫做 slashing 机制。你可以把 hub 简单理解成整个网络的中央代币管理机构,而 zone 则相当于网络里的节点。

这种跨链的架构,很容易让人马上想到另一个问题:所有跨链的通信都通过 hub 这个中心代理完成,这样会不会违背区块链去中心化的初衷?

值得一提的是,虽然跨链的确是大量依赖于 Cosmos hub 的,但每个人都可以运行自己的 hub,并不一定需要通过官方的 Cosmos hub。因此一定程度上也能保证跨链的去中心化。有点类似于:你可以自己运行一个 hub,然后和几个要好的朋友自己组成一个局域网,同时局域网和局域网之间又可以通过不同的 hub 连接起来。哪怕连接外网的 hub 瘫痪了,局域网内部的通信也不受影响。

非 Tendermint 的链可以互相连接吗?

到目前为止,我们有了 Tendermint,有了 Cosmos sdk,可以只关心应用层的业务逻辑,不去管底层的网络与共识层,快速地开发自己的链。除此之外,我们还有 Cosmos hub 和 zone,可以让这些基于 Tendermint 打造的许多条不同的链互相连接在一起,拥有互操作性。

那么,不基于 Tendermint 的链,也可以互联吗?

这里分两种情况:如果是拥有即时确定性的链(比如采用 POS 和 POA 共识),只要适配 IBC 就可以接入 Cosmos 的网络生态;如果是采用 POW 共识的概率确定性的链,那么情况就要复杂一点。

Cosmos 针对后者的跨链需求,在 zone 的基础上推出了新的组件——Peg-Zone。Peg-Zone 其实就是一个代理链,用来追踪原始链的状态。

Peg-Zone 本身是基于 Tendermint 的链,所以它拥有即时确定性,同时适配了 ibc。Peg-Zone 负责跟踪原始链,在代理链上保证区块的确定性。因此 Peg-Zone 需要事先设定一个规则,用这个规则来确认区块的确定性,比如这个规则可以是:

在当前区块增加了 100 个新的区块后,那么这个当前区块就是稳定的,可以被视为确定性得到保证,不会分叉。

我们可以看一个现阶段以太坊(还在使用 POW 共识)的例子:

假设要为以太坊做一个 Peg-Zone,那么需要先在以太坊上部署一个智能合约。以太坊的用户要转 100 个 token 给 Cosmos 的话,就是把 token 转进这个智能合约里面。然后智能合约会把这 100 个 token 锁起来,在当前区块又增加了 100 个新区块之后,Peg-Zone 上的代理链上就开始释放 100 个代理 token。

Peg-Zone 上的代理链也可以向以太坊的原始链发送 token,采用的机制类似。这时候 Peg-Zone 上的 token,在以太坊上就会以一个 ERC20 的代币形式出现。

不过,Peg-Zone 这种代理链的模式也有自己的问题:需要为每一条接入的链做特殊的定制。为以太坊建一个 Peg-Zone 的代理链还是比较容易的,因为以太坊是基于账户类型的,同时它有智能合约。如果要为比特币做一个 Peg-Zone 的代理链,那就很复杂了——虽然是可行的,但是需要做很多额外的工作。

小结

到这里我们基本捋清了 Cosmos 整个项目是做什么的了。

总结来说,Cosmos 希望通过 Cosmos sdk 和 Tendermint 等工具,让开发者以一种模块化、标准化、可插拔的方式(这种方式其实也是现代软件开发积累下来的大量成熟的开发技术经验),快速降低一条链的开发成本。让每个人都可以轻松拥有自己的链之后,Cosmos 再通过 IBC 跨链协议和 cosmos hub 与 zone 所组成的生态系统,为这些不同的链提供互相连接的能力,最终组成一个大网络。

Cosmos 认为,这套理念除了降低区块链的开发成本,让不同的链拥有互操作性之外,还有一个很重要的优点:可扩展性。

可扩展性

Cosmos 在可扩展性上的提升分为两个方面:

  • 垂直扩展:垂直方向上的性能提升,一方面体现在舍弃 pow 的共识算法,采用 pos+拜占庭共识算法,另一方面体现在「把应用区块链化」——在一个区块链的虚拟机上开发 dapp,这种 dapp 运行的效率,要比直接在一个内置了这种应用所需的交易类型、数据结构、状态转变函数的区块链上运行,效率来得慢。
  • 水平扩展:除了共识算法和区块链本身的垂直扩展,可扩展性还可以依附于 Cosmos 未来想要提供的多链系统。这个未来的构想是这样:网络中有一群公共的验证节点,负责保证一笔交易的安全,然后多条并行链分别执行这笔交易的一小部分,从而达到更快的交易处理速度。

Cosmos 认为,现在大多数开发者倾向于在以太坊上开发智能合约,而不愿意开发自己的链,主要是因为开发一条链的难度太高了。但随着 Tendermint 的普及,开发一条链的成本会变的像开发一个智能合约一样简单。

访谈对话

Cosmos 关于区块链和生态的理解非常有意思。可能会有不少人和笔者一样,对 Cosmos 坚信「每个人都应该拥有一条链」这个理念感到好奇。在此前上海万向区块链峰会上,笔者恰好有机会和 Cosmos 创始人 jae kwon 及核心技术开发团队进行访谈,我们着重围绕这一理念进行了探讨,以下是对话节选:

笔者:如果用简单的一段话来介绍 Cosmos 是什么,你认为 Cosmos 不同点主要在哪里?

Tendermint 核心开发人员 Christopher Goes:随着区块链的发展,我们看到很多公链出现。这些区块链如果想要彼此对话,交换彼此的 token、价值、资产甚至是代码的话,他们需要有相关的协议进行通信。Cosmos 提出了 ibc 跨链协议,用来解决不同链之间对话的问题。另一方面,像以太坊这样的公链让开发者可以开发自己的应用,比如虚拟猫、去中心化交易所等等,这一点非常酷,但是这些应用必须跑在一个通用的虚拟机上,这样其实会对应用的扩容造成限制。Cosmos 解决了这一问题,采用的办法是:让很多应用成为自己的链。应用跑在一条专门为自己量身定制的链上,从而增加扩容的能力,同时借助 ibc 协议,这些应用化的链又能拥有跨链的互操作性。

笔者:未来我们会拥有很多条链吗?我感觉类比互联网的话,我们可能会有不同的网站应用,但在这些网站应用下面,我们可能只会有一个 tcp/ip 协议?

创始人 jae:如果要从这个角度类比的话,ibc 协议可能会变成 tcp/ip 协议。从长远来看我同意你的观点,我们可能的确不会拥有很多条链。互联网最早出现也是有很多不同的网站应用,后面出现了大一统,搜索最终出现 google、博客服务只剩下 wordpress、社交网络大家都用 facebook。可能会有类似的循环出现。但是短期来看,比如最近 10 年,因为共识算法、编程语言、社区这些方面,每个项目都会有所不同。什么才是最好的共识算法、最好的开发语言、实现区块链最好的方法,这些都很难有定论。所以我们可能初期还是需要很多不同的链,到了后面很成熟的时期才会出现一条大公链,上面承接不同的应用。尽管如此,我还是相信,即使有这些大公链的存在,每个人还是会想要拥有自己的链。

笔者:我很好奇为什么你会相信人们会有自己的链?因为你要自己维护一条链的话,其实是非常困难的?

jae:的确很难。但我觉得这里面有一种类似于人类本能的东西存在,所谓人的「自举」能力,倾向于通过自己的努力获得成功。

任何时候人们感觉主流的链不能满足自己的需求,这背后就会有一些潜在的价值,一旦你有一个社区,有一条自我激励(self-incentive)的链,这些价值就会长大。我觉得自始自终会存在两种力量,这两股力不停地互相 push:一种是朝着中心化的、集群的方向,另一种是人们想要某种可替代性,或者第二选择。

Cosmos CSO Jim:如果你把 facebook 拆开的话,这里面就已经需要很多条链了。一个区块链版的 facebook,它可能需要一条广告链、一条关系链、一条 xx 链等等。这些链每个只负责做一件事情,上面有特定的应用程序,而 Facebook 则需要对这些链统一做优化和适配,控制它们分别运行得多快,控制它们怎么升级。这就是 Cosmos 一个很具象的应用案例。

Jae:用另一个例子来回答为什么人们会需要很多条链的话,可以去看看金融领域。如果你去看一些金融系统的话,里面有很多的案例,银行出于监管的要求,他们需要掌握很多敏感的数据,对相应的工具也需要有控制权。因此除了通用的公链之外,这些领域都需要拥有很多能够自己掌控的链。

Cosmos 研究员 Sunny Aggarwal:我们之前遇到过一个团队,他们非常信仰一个叫 Local Currency 的理念。这个理念认为,每个社区都应该拥有一套自己的本地货币,用这套货币就可以很完美的满足本地居民的需求,构建本地的金融系统,协调整个社区的组织工作,达到本地社区的「自治」。在这种场景里,可能每个本地社区就都需要一条属于自己的链了。

笔者:未来 Cosmos 会遇到哪些挑战?

jae:我们对整个生态系统的安全必须想得非常的深。在模块化的设计里怎么保证一个系统的安全是一个挑战。所以我们设计了一套多样化的独立的存储,还有一个逻辑控制的组件叫做 keeper,因为它负责把逻辑藏在数据后面。这些隔离对系统的安全性都是有好处的,因为这样你去架构一个应用的时候,你可以很清楚这个应用都是由哪些部分组成的,他们彼此之间如何连接,如果出了问题也可以很容易定位。未来我们可能需要对很多不同的模块做更多语言的适配,会遇到的挑战可能会是,如何把这些模块再优化得更好,比如支持直接在实时的网络上进行不同模块的热插拨,等等。

参考来源:

  • https://blog.cosmos.network/understanding-the-value-proposition-of-cosmos-ecaef63350d | Understanding the value proposition of Cosmos – Cosmos Blog
  • https://zhuanlan.zhihu.com/p/31131214 | Cosmos 互联链通信技术规范【上】
  • https://zhuanlan.zhihu.com/p/43898294 | Cosmos 项目以及 SDK 介绍
  • https://tendermint.com/docs/introduction/introduction.html#abci-overview | What is Tendermint? | Tendermint Core
  • https://blockgeeks.com/guides/what-is-cosmos-blockchain/ | What is Cosmos Blockchain ? Most Comprehensive Guide
  • https://www.itcodemonkey.com/article/4688.html | 深度剖析区块链跨链技术 Cosmos(上篇 ) - IT 程序猿
  • https://www.itcodemonkey.com/article/8420.html | 深度剖析区块链跨链技术 Cosmos(下篇 ) - IT 程序猿
  • https://cosmos.network/docs/sdk/core/intro.html