动手写条自己的链(2):Cosmos SDK 入门

动手写条自己的链 系列文章:

  1. Hello Cosmos
  2. Cosmos 技术架构解析
  3. Cosmos SDK 入门

本文主要是对官方文档进行翻译,如后续内容发生变化,请以英文原文为准。

目录

Cosmos SDK 介绍

英文原文:SDK Intro

Cosmos SDK 是一个用于构建多资产权益证明(Proof-of-Stake,PoS)共识区块链的框架,例如 Cosmos Hub,以及权威证明(Proof-of-Authority,PoA)共识的区块链。

Cosmos SDK 的目标是允许开发人员可以轻松的创建自定义区块链,并且这些链天生就可以和其他区块链交互。我们将 SDK 设想为类似于 npm 的框架,能够在 Tendermint 之上构建安全的区块链应用程序。

它基于两个主要原则:

  • 可组合性:任何人都可以为 Cosmos SDK 创建模块,并且集成已经构建的模块就像将它们导入区块链应用程序一样简单
  • 功能:Cosmos SDK 受到基于功能的安全性的启发,以及多年来研究区块链状态机得到的经验。大多数开发人员在构建自己的模块时需要访问其他第三方模块。鉴于 Cosmos SDK 是一个开放框架,一些模块可能是恶意的,这意味着需要安全原则来推动模块间的交互。这些原则基于对象能力。实际上,这意味着不是让每个模块保留其他模块的访问控制列表,而是每个模块都实现称为守护者(keepers)的特殊对象,这些对象可以传递给其他模块以授予预定义的一组功能。例如,如果模块A的守护者(keepers)的实例被传递给模块B,则后者将能够调用一组受限制的模块A的功能。每个管理器(keeper)的功能由模块的开发人员定义,开发人员的工作是根据它们传递到每个第三方模块的功能来理解和审计来自第三方模块的外部代码的安全性。要深入了解功能,请跳转到本节

Cosmos SDK 程序架构

英文原文:SDK Application Architecture

状态机

区块链应用程序的核心是可复制的确定性状态机(State machine replication)

状态机是计算机科学概念,一台机器可以具有多个状态,但在任何给定时间只有一个状态。它描述了系统当前的状态和触发状态转换的事务。

给定一个状态S交易T,状态机会返回一个新的状态S'

1
2
3
4
5
+--------+                 +--------+
| | | |
| S +---------------->+ S' |
| | apply(T) | |
+--------+ +--------+

实际上,交易以区块的形式打包在一起可以提高处理效率。给定状态S和包含交易的区块B,状态机将返回新状态S'

1
2
3
4
5
+--------+                              +--------+
| | | |
| S +----------------------------> | S' |
| | For each T in B: apply(T) | |
+--------+ +--------+

在区块链上下文中,状态机是确定性的。这意味着如果从一个给定的状态开始并重放相同顺序的事务,将始终以相同的最终状态结束。

Cosmos SDK 为您提供了最大的灵活性,可以定义应用程序的状态、事务类型和状态转换功能。使用 SDK 构建状态机的过程将在接下来的内容中进行更深入的描述。但首先,让我们看看状态机是如何使用 Tendermint 进行复制的。

Tendermint

作为开发人员,你只需使用 Cosmos SDK 定义状态机,Tendermint 将为你处理网络复制。

1
2
3
4
5
6
7
8
9
10
11
12
13
                ^  +-------------------------------+  ^
| | | | Built with Cosmos SDK
| | State-machine = Application | |
| | | v
| +-------------------------------+
| | | ^
Blockchain node | | Consensus | |
| | | |
| +-------------------------------+ | Tendermint Core
| | | |
| | Networking | |
| | | |
v +-------------------------------+ v

Tendermint 是一个与应用程序无关的引擎,负责处理区块链的网络层和共识层。实际上,这意味着 Tendermint 负责传播和排序交易字节。Tendermint Core 依赖于拜占庭容错(BFT)算法来达成交易顺序的共识。有关 Tendermint 的更多信息,请单击此处

Tendermint 一致性算法与一组称为验证人(Validators)的特殊节点一起运作。验证人负责向区块链添加交易区块。对于任何给定的区块,有一组验证人V。通过算法选择 V 中的验证人A作为下一个区块的提议人。如果 V 中超过三分之二的节点签署了 prevoteprecommit,并且区块包含的所有交易都是有效的,则该区块被认为是有效的。验证人集合可以通过状态机中编写的规则进行更改。要深入了解算法,请点击此处

Cosmos SDK 应用程序的主要部分是一个区块链守护程序,它由本地网络中的每个节点运行。如果验证器集中少于三分之一是拜占庭(即恶意),则每个节点在同时查询状态时应获得相同的结果。

ABCI

Tendermint 通过名为 ABCI 的接口将事务从网络层传递到应用程序层,应用程序必须要实现该接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
+---------------------+
| |
| Application |
| |
+--------+---+--------+
^ |
| | ABCI
| v
+--------+---+--------+
| |
| |
| Tendermint |
| |
| |
+---------------------+

注意,Tendermint 仅处理交易字节。它不知道这些字节究竟是什么意思。Tendermint 所做的只是对交易确定性地排序。赋予这些字节含义是应用程序该做的工作。Tendermint 通过 ABCI 将交易字节传递给应用程序,并期望返回结果代码以知晓消息是否传递成功。

以下是 ABCI 中最重要的信息类型:

  • CheckTx: 当 Tendermint Core 收到交易时,会将其传递给应用程序以检查其有效性。一个名为“Ante Handler”的特殊 handler 用于执行一系列验证步骤,例如检查手续费用是否足够、验证签名是否合法。如果交易有效,则将交易添加到 mempool 中并广播到对等节点。注意, CheckTx 不会处理交易(即不会对状态进行修改),因为它们尚未包含在区块中
  • DeliverTx: 当 Tendermint Core 接收到有效区块时,其中的每条交易都将通过DeliverTx传递给应用程序进行处理。正是在这一阶段发生了状态转换。“Ante Handler”将再次执行,连同对交易中每条消息进行处理的真实 handler 一起执行
  • BeginBlock/EndBlock: 无论区块是否包含交易,这两个消息都将在每个区块的开头和结尾执行。触发自动的逻辑执行是很有用的。过程中要足够小心,因为计算成本高昂的循环运算可能会减慢区块链的速度,甚至在无限循环中使区块链本身停滞

有关 ABCI 方法和类型的详细介绍请点击此处

在 Tendermint 上构建的任何应用程序都需要实现 ABCI 接口,以便与底层的本地 Tendermint 引擎进行通信。幸运的是,你不必自己实现 ABCI 接口。Cosmos SDK 以 BaseApp 的形式提供了标准实现。

Cosmos SDK 设计总览

英文原文:Cosmos SDK Design Overview

Cosmos SDK 是一个框架,可以在 Tendermint 之上优化安全状态机的开发。Cosmos SDK 的核心是基于 Golang 的 ABCI 标准实现。它带有一个用于持久化保存数据的multistore和一个用于处理事务的路由router

以下是一个基于 Cosmos SDK 的应用程序在通过DeliverTx从 Tendermint 传输时如何处理事务的简化视图(CheckTx过程是相同的,没有强制执行状态更改):

  1. 解码从 Tendermint 共识引擎收到的事务(记住 Tendermint 只处理字节数据[]bytes
  2. 从事务中提取消息并执行基本的完整性检查
  3. 将每条消息路由到对应的模块,以便可以处理它
  4. 提交状态更改

该应用程序还能够生成事务,对它们进行编码并将它们传递给底层的 Tendermint 引擎以进行广播。

BaseApp

BaseApp 是 Cosmos SDK 中 ABCI 的标准实现。它带有一个路由(router),可以将事务路由到它们各自的模块。你的应用程序的主文件app.go需要自定义一个基于 BaseApp 的app类型。这样,你自定义的app将自动继承 BaseApp 的所有 ABCI 方法。

示例代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
type nameServiceApp struct {
*bam.BaseApp
cdc *codec.Codec

keyMain *sdk.KVStoreKey
keyAccount *sdk.KVStoreKey
keyNS *sdk.KVStoreKey
keyFeeCollection *sdk.KVStoreKey
keyParams *sdk.KVStoreKey
tkeyParams *sdk.TransientStoreKey

accountKeeper auth.AccountKeeper
bankKeeper bank.Keeper
feeCollectionKeeper auth.FeeCollectionKeeper
paramsKeeper params.Keeper
nsKeeper nameservice.Keeper
}

BaseApp 的目标是在存储和可扩展状态机之间提供安全的接口,同时尽可能少地定义该状态机(保持 ABCI 的原汁原味)。

有关 BaseApp 的详细介绍,请点击此处

Multistore

Cosmos SDK 为状态持久化提供了multistore,其允许开发人员声明任意数量的 KVStore。这些KVStore只接受[]byte类型的数据作为值,因此任何自定义的结构都需要在存储之前使用 go-amino 进行序列化。

multistore抽象地将状态划分为不同的分区,每个分区由其自己的模块管理。有关multistore的详细介绍,请点击此处

Modules

Cosmos SDK 的强大之处在于其模块化。 SDK 应用是通过聚合一组可互操作的模块构建的。每个模块定义一份状态的子集并包含它自己的消息/事务处理器,而 SDK 负责将每个消息路由到其各自的模块。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
                                      +
|
| Transaction relayed from Tendermint
| via DeliverTx
|
|
+---------------------v--------------------------+
| APPLICATION |
| |
| Using baseapp's methods: Decode the Tx, |
| extract and route the message(s) |
| |
+---------------------+--------------------------+
|
|
|
+---------------------------+
|
|
|
| Message routed to the correct
| module to be processed
|
|
+----------------+ +---------------+ +----------------+ +------v----------+
| | | | | | | |
| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE |
| | | | | | | |
| | | | | | | Handles message,|
| | | | | | | Updates state |
| | | | | | | |
+----------------+ +---------------+ +----------------+ +------+----------+
|
|
|
|
+--------------------------+
|
| Return result to Tendermint
| (0=Ok, 1=Err)
v

每个模块都可以看作是一个小型的状态机,开发人员需要定义各个模块处理的状态子集,以及涉及修改状态的自定义消息类型(注意:消息是通过 BaseApp 方法从事务中提取的)。通常情况下,每个模块在multistore中声明其自己的KVStore以便持久化其定义的状态子集。大多数开发人员在构建自己的模块时都需要访问其他第三方模块。鉴于 Cosmos SDK 是一个开放框架,一些模块可能是恶意的,这意味着需要安全原则来推动模块间的交互,这些原则基于对象能力。实际上,这意味着不是让每个模块保留其他模块的访问控制列表,而是每个模块都实现称为守护者(keepers)的特殊对象,这些对象可以传递给其他模块以授予预定义的一组功能。

SDK 模块在 SDK 源码中的x/文件夹中定义。一些核心模块包括:

  • x/auth:用于管理帐户和签名
  • x/bank:用于实现 Token 和 Token 转账
  • x/staking + x/slashing:用于构建权益证明(Proof-Of-Stake,PoS)共识的区块链

除了使用x/中已有的模块,SDK 还支持构建自定义的模块。你可以查看示例教程

Cosmos SDK 对象能力模型

英文原文:Object-Capability Model

介绍

在考虑安全性时,最好从特定的威胁模型开始。我们的威胁模型如下:

我们假设蓬勃发展的 Cosmos SDK 模块生态中会包含错误或恶意的模块。

Cosmos SDK 旨在通过以对象能力系统作为基础来解决此威胁。

对象能力系统的结构特性有利于代码设计中的模块化,并确保代码实现中的可靠封装。

这些结构上的特性便于分析一个对象能力程序或操作系统的某些安全属性。其中一些 - 特别是信息流属性 - 可以在对象引用和连接级别进行分析,而不依赖于对决定对象行为的代码的任何了解或分析。

因此,可以在存在包含未知或恶意代码的新对象的情况下建立和维护这些安全属性。

这些结构属性源于管理对现有对象的访问的两个规则:

  1. 只要对象A持有对象B的引用,A可以向B发送一条消息,。
  2. 只要对象A收到了一条包含对象C引用的消息,A可以获得C的引用。根据这两条规则,一个对象只有通过一条先前存在的引用链获得另一个对象的引用,简而言之,“只有连接才能产生连接”。

查看关于 object-capabilities 的文章了解更多。

严格来说,Golang 由于几个问题没有完全实现 object-capabilities:

  • 普遍有引入原始模块(比如 unsafe、os)
  • 普遍重写模块的变量
  • 存在 2 个以上 goroutine 时的数据竞态漏洞可以创建非法的接口值

第一点很容易通过审计 import 和使用适当的依赖版本控制系统(如Dep)来捕获。但第二点和第三点就不容易了,需要成本进行代码审核。

实践中的对象能力模式

想法就是只暴露完成工作所需要的部分。

比如,下面的代码片段违反了对象能力原则:

1
2
3
4
5
6
type AppAccount struct {...}
var account := &AppAccount{
Address: pub.Address(),
Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)},
}
var sumValue := externalModule.ComputeSumValue(account)

方法名ComputeSumValue暗示了这是一个不修改状态的纯函数,但传入指针值意味着函数可以修改其值。更好的函数定义是使用一个拷贝来替代:

1
var sumValue := externalModule.ComputeSumValue(*account)

在 Cosmos SDK 中,你可以看到 gaia app 中对该原则的实践。

1
2
3
4
5
6
7
// register message routes
app.Router().
AddRoute(bank.RouterKey, bank.NewHandler(app.bankKeeper)).
AddRoute(staking.RouterKey, staking.NewHandler(app.stakingKeeper)).
AddRoute(distr.RouterKey, distr.NewHandler(app.distrKeeper)).
AddRoute(slashing.RouterKey, slashing.NewHandler(app.slashingKeeper)).
AddRoute(gov.RouterKey, gov.NewHandler(app.govKeeper))

动手写条自己的链(1):Cosmos 技术架构解析

动手写条自己的链 系列文章:

  1. Hello Cosmos
  2. Cosmos 技术架构解析
  3. Cosmos SDK 入门

本文主要内容来自橙皮书《对话 Cosmos:未来是所有人都用一条公链,还是每个人都有自己的链?》,稍作修改,原文链接见文末。

Cosmos 在 3 月 14 日的早 7:00 成功启动了主网,它是以伯克利的 Tendermint 团队为核心团队开发的跨链项目,目标要实现两件事情:第一件,是让公链开发变得简单;第二件,是让所有的链能够连接起来。

Cosmos 的起源:Tendermint

在技术发展早期,人们对如何开发一个去中心化的公共账本并不会有太多的认识和思考。比特币和以太坊的设计就像一块单片电路板,上面所有的元件都集成在一起,其中的逻辑错综复杂,没有任何分层的技术栈可言。如果你写过代码的话就会知道,解耦是设计复杂系统的第一要义。只有把各个功能分开,把一个系统拆解成干净的层级、模块和接口,代码才能复用,以及更好的做修改,为未来留下灵活的扩展空间。

比特币和以太坊就像一台整体焊死的电脑,你很难对他进行改动,里面的零件也没法拔出来做升级。当人们对公链有各种各样完全不同的想法之后,人们发现把所有东西都做在一条链上是不对的,于是很多人开始想开发自己的链。这个时候你会发现,即使比特币和以太坊开源了,你也很难进行代码的复用。除了把比特币代码拷过来,改个参数,换个名称,弄出来一个山寨币之外,做不了太多事情。

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

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

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

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

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

那么问题来了,一条链的必要组成部分都包括哪些呢?

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

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

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

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

Tendermint 包含两部分的东西:

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

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

Tendermint Core

GitHub

Tendermint Ecosystem

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

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

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

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

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

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

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

ABCI 协议

GitHub

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

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

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)共识算法都是即时确定的。

Cosmos SDK

GitHub

Cosmos Ecosystem

到这一步,Cosmos 把开发一条公链的工作减少为设计一个应用层的工作。但 Cosmos 并没有就此打住,它继续「切分」应用层。

应用层需要实现一系列的功能来完成最终的业务逻辑,不过这些功能中有很多是可以通用的,比如账户管理的功能,Cosmos 把这些功能分解出来,再以模块化的方式加以实现。

这样一来,开发者在进行应用层开发时,只需要实现自身业务逻辑中特殊的功能,其他的功能都可以直接调用 Cosmos 的功能模块。

如上图所示,Accounts(账户系统)、Governance(治理机制)、Staking(抵押机制)、Slashing(惩罚机制)、IBC(跨链功能)、Rewards&Fees(奖励&手续费)等均是功能模块,能够以「插拔」的方式被组合到一起使用。

Cosmos 把自己提供的这一模块化开发工具叫做「Cosmos SDK」,它覆盖了应用层需要实现的大部分的功能,到这一步,Cosmos 把设计一个应用层的工作减少为实现少数具体的功能模块的工作。Cosmos 团队自己也利用这套 SDK 实现了一个例子叫 Cosmos Hub。

最终,如上图所示,通过对公链的分层设计以及对应用层的分模块设计,开发者能够以 Tendermint 共识引擎和 Cosmos SDK 开发工具为基础,快速地完成公链的开发。他们不再需要设计整条公链,而只需要实现核心的业务功能。

正因为这样,币安可以在较短的时间内迅速基于 Cosmos 的开发工具和共识引擎,开发完成应用方向非常聚焦的 Binance Chain

小结

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

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

最后,Cosmos 关于区块链和生态的理解非常有意思,Cosmos 团队坚信「每个人都应该拥有一条链」,想知道为什么吗?推荐阅读下面橙皮书的文章,在末尾有橙皮书和 Cosmos 创始人 Jae Kwon 及核心技术开发团队进行的访谈。

参考资料

Hello Cosmos

动手写条自己的链 系列文章:

  1. Hello Cosmos
  2. Cosmos 技术架构解析
  3. Cosmos SDK 入门

据链闻消息,北京时间 3 月 14 日早间,跨链项目 Cosmos 正式启动主网。Cosmos 主网是指由 Cosmos 团队自己开发的第一个官方版 Hub,也就是不同链进行跨链操作时的第一个中央枢纽。随着该主网的上线,Cosmos 的跨链生态将从理论阶段进入到实现阶段。在 3 月 1 日,中国的边界智能团队开发的 Cosmos 网络中另一个 Hub 「IRISnet」已经正式启动了主网。目前,随着 Cosmos 主网正式启动,Cosmos Hub 和 IRISnet Hub 将完成 Cosmos 跨链生态中的双 Hub 链接。

0x00 What is Cosmos

官方介绍 调皮一下:「cosmos」这个单词的本意是「宇宙」的意思 :)

Cosmos Whitepaper

Cosmos 中文版白皮书

0x01 科普

0x02 Coding

0x03 应用

  • IRISnet:其对 Cosmos SDK 和 IBC 进行了扩展,用以支持公链、联盟链以及传统商业系统之间的集成,使得数据和复杂计算能够跨异构网络互联互通,实现服务的跨链调用
  • Binance Chain:币安链,是 Cosmos 上的第一个去中心化交易所平台
  • IOV:基于 Cosmos 的第一个分布式区块链 DNS
  • Kava:基于 Cosmos 的第一个跨链钱包协议提供者
  • 其他更多请查看 Cosmos EcosystemTendermint Ecosystem