密码极客 | 国内最权威的区块链技术创投社群

深度知识| COSMOS架构及核心模块分析

江鹏江鹏 2019-07-09 38 次 收藏0

Cosmos项目是个有着宏伟目标的区块链项目。在DPOS+BFT的共识引擎的基础上,Cosmos提出了更大的区块链未来和蓝图:区块链开发简便,互通互联。Cosmos设计了区块链的基础设施和生态,区块链开发者只需要调用Cosmos-SDK,开发Plugin,处理特有业务。Cosmos项目已经不只是提供DPOS+BFT共识机制的引擎这么简单。它在打造区块链的基础设施和开发生态。在Cosmos的基础上,设计开发区块链就是在Cosmos上写个应用程序。Cosmos的框架协助实现了一些区块链相关的基本功能:

1)区块链的数据存储以及共识机制(DPOS+BFT)

2)各个应用(区块链)之间的token的互换(IBC)

3)现有区块链的接入(Peg Zone)

在Cosmos框架的基础上开发一条区块链,开发人员唯一要做的事情,就是编写符合ABCI接口的应用程序(解释区块数据,业务处理)。

Cosmos官方网站:https://cosmos.network。

1)Cosmos生态框架

Cosmos的整体框架如下图:

Tendermint Core是所有Cosmos生态中区块链的核心(上图中的淡绿色部分),提供了DPOS+BFT的共识机制。Cosmos Hub提供了不同区块链的之间的交互和价值转移。各个区块链应用之间通过IBC接口进行通信。

2)Cosmos SDK

在Tendermint以及ABCI的基础上,为了进一步方便用户进行区块链开发,Cosmos提供了Cosmos SDK,把区块链中的一些通用模块标准化,用户只需要在SDK的基础上实现Plugin模块,处理一些链特有的业务。

3)Cosmos网络开发进展

Cosmos的开发如火如荼的进行中,各个子项目的代码更新非常密集。从这个网站可以看到各个模块的成熟程度:https://cosmos.network/roadmap。

从上图可以看出,Cosmos项目由四个子项目组成:

a)Cosmos Hub - Cosmos生态中的区块链的互转互换模块

b)Cosmos SDK - ABCI应用程序的SDK

c)Tendermint Core - 共识机制引擎以及网络交互

d)Cosmos Voyager - 客户端终端,提供钱包以及投票等功能

4)Cosmos SDK的框架

Cosmos SDK是Cosmos项目中的一个子项目,主要是抽象出Stack(Middleware),将区块链的应用的功能拆分成一个个module,进一步方便区块链开发人员开发新链。在Cosmos SDK的基础上,实现区块链只需要关注区块链特有的业务逻辑,将其实现成module即可。Cosmos SDK区块链的功能做了细致的划分:客户端,服务器端,以及APP。

客户端提供用户操作的接口:转账,查询等等。服务器端和客户端对应提供服务端的实现(REST接口),客户端和服务器端通过websocket通讯。APP是区块链业务逻辑实现。这些功能模块在“Stack”模块之上。“Stack”由Cosmos-sdk的一个个module组成。区块链相关的一个个小功能,实现成一个个的module,这些中间件串在一起,称为“Stack”。APP将区块链状态记录在State上。

4.1)源代码结构

整个SDK源代码目录如下图所示:

4.2)基本数据结构

a)Actor & Context

Actor以及Context定义在context.go代码中。

Actor定义了某个链上某个App的一个账户(地址)。

Context定义一些基本信息的函数集合:权限查询,Nonce/ChainID/BlockHeight查询等等。

b)Tx

Tx定义在txinner_wrapper.go文件中。Tx会贯穿整个SDK的处理,是整个SDK最重要的数据结构。

Tx是个数据结构,其中的TxInner是接口:Wrap以及ValidateBasic。也就是说一个Tx必须要实现TxInner接口。

c)Handler

Handler接口定义在handler.go文件中。

Handler定义module执行的接口:CheckTx(查看Tx),DeliverTx(区块中交易处理),InitState以及InitValidator(初始化状态和Validator),Name是执行模块的名称。有关module的具体解释,请看Stack和Module的介绍。

4.3)Stack

Stack的相关代码在stack目录中。Stack有关的数据类型如下图:

Stack有两部分组成:builder(middleware)以及Dispatcher。Dispatcher和middleware的区别是:middleware提供Next函数,可以访问下一个“middleware”,Dispatcher是一组Dispatchable构成。

Stack上的所有Middleware被wrap成一个sdk.Handler。

4.4)Client客户端

Client的逻辑在client的目录中。介绍一下Client端将sdk.Tx封装的逻辑(实现在client/txs/wrapper.go)。

Wrapps.Wrap函数将当前传入的sdk.Tx进行wrap,形成类似洋葱样的封装。

4.5)Server服务器端

与客户端相对应的是服务器端,服务器端主要是接收sdk.Tx,检查后调用Tendermint的RPC提交或者查询信息。逻辑实现在client/rest目录下。以txs.go为例,解释一下服务器的实现原理:

服务器端利用mux.Router机制,注册响应函数(如上图中的PostTx)。

4.6)ABCI App程序

ABCI App程序的逻辑实现在app以及server目录。App程序的逻辑相对简单,主要是实现ABCI的接口,调用Stack,具体的操作由Stack的一个个的middleware处理。

一个交易的大致处理流程如下图:

4.7)example示例

Cosmos SDK提供了示例代码,在examples目录下。感兴趣的小伙伴,可以查看basecoin的实现。

4.8)module实现

在Cosmos SDK中实现了一些通用module,在modules目录下:fee,coin,ibc, nonce, auth等等。fee module的逻辑相对简单,可以看出一个模块大致需要实现的逻辑:

实现一个module,要实现三个接口:commands/wrap.go(client端的封装),handler.go(Stack中的middleware的接口,也就是sdk.handler接口),以及tx.go(此模块的交易定义以及TxInner的实现)。

 

本文系作者个人观点,转载请注明出处!
喜欢 0
支付宝扫码打赏
微信打赏

相关文章

更多

发布评论

共0条评论