区块链技术 | Cosmos SDK 文档概述_cosmos sdk开发区块链

概述

SDK 介绍

Cosmos-SDK 是支持构建多种资产，共识机制为POS（权益证明）或者POA（权威证明）的一个区块链框架，例如Cosmos Hub。

Cosmos SDK的目标是允许开发者轻松地从0开始构建自定义区块链，同时可以与其他区块链交互。我们想象一下，SDK可以作为类似NPM框架，以Tendermint为核心，构建稳定的区块链应用。

它主要基于以下两个原则：

模块化：任何人可以为Cosmos-SDK创建模块，并且很容易的导入你自己的区块链应用，使得它与原有的模块融为一体。

功能性：SDK在设计是考虑了基础功能的安全性，参考了多年在区块链状态机设计的经验。绝大多数开发者在开发自己的模块时会需要引入第三方模块，考虑到Cosmos-SDK是一个开放的框架，一些模块可能是恶意的，这意味着需要一些安全规则来控制模块之间的交互。这些原则基于面向对象，在实践中，这意味着不是为每个模块保留一个其他模块可以访问控制的列表，而是每一个模块实现一个被叫做keeper的特殊对象，通过预先定义的功能来传递给其他模块。例如，一个实例模块A的keeper被传递给模块B，模块B可以调用模块A一些受限的函数集。每一个keeper对象的功能由模块的开发者定义，开发者的工作在于理解和审计每一个基于功能性导入的第三方模块的外部代码是否安全。对于想要深入理解功能性的话可以阅读这篇文章。

 

SDK 应用结构

状态机

它的核心在于区块链是一个被复制的确定性的状态机。

状态机是计算机科学概念，意味着一个机器可以有多种状态，但是在确定时间内只有一种状态。状态描述了系统当前状态，而交易是一种状态转换的表达形式。

给定一个状态S和交易T，这个状态机将会返回一个新的转态S`。

在实践中，交易被打包成区块，来提升系统的效率。给定一个状态S和在区块上的交易B，状态机将会返回一个新的状态S`。

在区块链的环境中，状态机是确定的，它意味着你开始一个给定的状态，并且重复同样的一系列交易，你总是以同样的最终状态结束。

Cosmos SDK给定你最大的灵活性来定义你的区块链应用的状态、交易类型、状态转移函数。如何使用SDK构建状态机将在后文更加深入的介绍。但是对于我们来说，首先要了解如何复制并使用Tendermint。

 

Tendermint

作为一个开发者，你只要使用Cosmos-SDK来定义状态机即可，Tendermint将会在你的网络上处理状态机的复制。

Tendermint是一个与应用程序无关的引擎，用来处理你区块链的网络层和共识层。在实践中，这意味着Tendermint负责去发送和排序你的交易字节。Tendermint核心依赖于一个命名为拜占庭容错机制（BFT）的共识算法来达成交易排序的共识。想要了解更多的Tendermint，点击这。

Tendermint共识算法由一组被称作验证者的特殊的节点实现的。验证者负责将包含交易的区块添加到区块链中。在任何一个确定的区块中，使用算法从验证者集合中选择出验证者A作为下一个区块的提议者。如果区块被超过2/3的验证者V在预投票和预提交阶段签名并且包含的交易是有效的，这个区块被认为是有效的。验证者集合可以通过写入状态机的规则被改变。想要深入了解算法，请点击这里。

Cosmos SDK应用程序的主要部分是运行在每一个节点本地网络的区块链守护程序，如果恶意验证者小于1/3，那么每一个节点在同样的时间查询状态会获得同样的结果。

 

ABCI

Tendermint通过被称作ABCI的接口将交易从网络层传到应用，应用必须实现该接口。

注意Tendermint只负责处理交易字节的发送和排序，它意味着Tendermint不知道这些交易字节意味着什么。所有的Tendermint只是确定这些交易字节的顺序。Tendermint通过ABCI将字节发送给应用程序，如果交易中被包含的消息被成功处理或者没有处理，则可以返回代码来通知应用程序。

这儿有ABCI最重要的消息：

CheckTx：当Tendermint核心收到一个交易，它将发送给应用去检查是否满足一些基本要求。CheckTx被用作保护全节点的交易池以防止垃圾交易。一个被称作"Ante Handler"的特殊的处理程序被用作执行一系列的验证步骤例如检查是否有足够的费用和验证签名。如果检查是有效的，交易将会被添加到交易池和发送到其他对等节点。注意没有使用CheckTx处理交易（没有修改状态），因为还没有包含在区块中。

DeliverTx：当Tendermint核心收到一个可用的区块，给定区块中的每一个交易经由DeliverTx处理发送到应用。在这个阶段，当前的交易状态发生了改变。"Ante Handler"和实际中每一个交易中的消息被再次执行。

BeginBlock/EndBlock：这个消息被执行在每一个区块的开始和结束，无论该区块是否包含交易。触发自动执行的逻辑上是非常有用的，但要谨慎行事，计算昂贵的循环可能会降低区块链的性能，甚至死循环会破坏区块链。

任何构建在Tendermint上的应用程序都需要实现ABCI接口，以便与底层的本地Tendermint引擎进行通信。幸运的是，您不必直接实现ABCI接口。Cosmos SDK以Base app的形式提供了它的demo实现。

接下来，让我们介绍一下SDK的高级设计原则。

 

Cosmos SDK设计概况

Cosmos SDK是一个在Tendermint基础上来安全开发状态机的区块链框架。SDK在核心使用Go语言开发的ABCI接口的模块。它包括了一个持久化数据存储multistore数据存储模块和处理交易的router路由模块。

 

下面是一个简化的流程，当交易通过DeliverTx从Tendermint发送时基于Cosmos SDK构建的顶层应用如何处理交易。

1.解码从Tendermint共识引擎收到的交易（记住在Tendermint上仅仅处理的是字节）。

2.从交易中提取消息，并进行基本的正常检查。

3.将每条消息通过路由传递到适当的模块，以便对其进行处理。

4.提交状态更改。

应用程序还允许创建交易，对它们进行编码，并将它们传递给底层Tendermint引擎来广播它们。

Baseapp

baseApp是Cosmos SDK ABCI接口的案例实现，它还包含一个router去将交易路由到它们各自的模块处理。你的应用程序的主程序文件app.go将会自定义你的app类型来嵌入baseapp。通过这种方法，你的自定义app 类型将会自动继承baseapp的ABCI方法。了解这个例子请看SDK 应用教程。

 

base app的目标是在存储和可扩展的状态机之间提供一个安全的接口，同时尽可能少地定义状态机(保持对ABCI的原生性)。

想要了解更多baseapp，请点击这。

Multistore

Cosmos SDK提供多种方式存储来实现持久化存储。多种存储方式意味着允许开发者声明任意数量的KVStores。KVStores存储只接受字节类型数组（[]BYTE）的值。也就是说，任何自定义的数据结构在被存储前都需要使用go-amino进行序列化。

 

Multistore抽象上来说被用来将状态划分为不同的分区，每一个分区有自己的模块来管理。想要了解更多Multistore，请点击这儿。

Modules

Cosmos SDK的强大之处在于它的模块化，SDK应用被一堆可互操作的模块构建。每个模块定义了状态的子集和包含了与自己有关的消息/交易处理程序，而SDK负责将每一个消息路由到与它们有关的模块。

 

这是一个简单的流程图，当接受到一个可用的区块时，每一个全节点的应用如何处理交易过程。

（译者注：交易由Tendermint engine通过DeliverTx发送到应用程序，应用程序通过baseapp的方法解码字节数组，提取消息，分发到不同路由模块，模块处理消息更新状态，返回成功结果到Tendermint）

每一个模块都可以被视为最小的状态机。开发者需要定义每一个模块可以处理的状态的子集，同样需要自定义修改状态的消息类型（注意：消息使用baseapp的方法从交易中提取）。在实践中，每一个模块通常都声明它们自己的键值存储KVStore在multistore中实现状态子集的持久存储。绝大多数开发者在开发自己的模块时会需要引入第三方模块，考虑到Cosmos-SDK是一个开放的框架，一些模块可能是恶意的，这意味着需要一些安全规则来控制模块之间的交互。这些原则基于面向对象，在实践中，这意味着不是为每个模块保留一个其他模块可以访问控制的列表，而是每一个模块实现一个被叫做keeper的特殊对象，通过预先定义的功能来传递给其他模块。

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

x/auth：用于管理帐户和签名。

x/bank：用于启用代币和实现代币转移。

x/staking + x/slashing：用于构建POS区块链

除了x/中已经存在的模块(任何人都可以在其应用程序中使用)之外，SDK还允许您构建自己的自定义模块。您可以在本教程中查看该示例。

接下来，了解有关Cosmos SDK的OCAP的安全模型的更多信息

原文地址：https://cosmos.network/docs/intro/sdk-design.html