概述
cosmos+tenderminter是一个基于PoS的开源区块链底层库，可以用于快速搭建
序言、前言
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
| 涉及到的东西
对等网络通讯
密码学
共识协议
证明机制
经济激励设计
PoS替换PoW降低资源消耗
BFT共识替换比特币的中本聪共识，提高了交易的速度
cosmos hub交易速度比比特币速度块，无法满足
为了每个特定的应用开发专属的区块链系统
使用跨链方式来让其互联互通
框架介绍
tendermint
共识协议层
对等网路通讯层
提供IBC协议，用于制作跨链相关解决方案
cosmos sdk
应用层
两个项目之间通过ABCI接口来通讯
利用cosmos-sdk的模块化快速实现定制化的逻辑
本书特色
理解Tendermint core、cosmos-sdk两个项目的理论原理、架构设计和内部实现，对于构建稳定的区块链系统很有帮助。根据自己的需求找到解决方案也会更加快速。不会让自己在迭代过程中迷失方向。
代码版本信息
Tendermint core 0.33.3
Cosmos-SDK 0.38.4
IAVL+ 0.13.3
Gaia 2.0.11
区块链架构师视角出发，给专属区块链系统开发师讲解需要了解的相关信息
密码算法
理论阐述，知道离散函数、数字签名
离散函数
merkle树
数字签名算法
共识协议
实用拜占庭容错
Tendermint共识协议
对比两种差异
提案者轮换选择算法
深入剖析PoS机制
完整讲解PoS机制的原理和具体实现。
讲解模块化的设计理念
系统阐述IBC协议的原理和设计
链间标准 interchain standard ICS
从 Tendermint Core 轻客户端的构建出发。
内容简介
第一章 介绍区块链的技术挑战，概述Tendermint团队通过Tendermint Core的分层设计、Cosmos-SDK的模块化设计以及IBC协议给出的解决方案
第二章 Tendermit core 用到的密码学算法。
第三章 分布式系统开始，介绍PBFT共识协议以及Tendermint 共识的差异，内部的算法。
第四章 描述Tendermint Core的架构设计。抽象反应器、转换器等概念。结合UML类图讲解
第五章 描述Tenndermint 分层抽象出ABCI。让应用层和底层解耦。
第六章 Cosmos-SDK的架构设计，认证数据结构IAVL+s树，存储设计。理解后续应用模块的前提
第七章 Cosmos基本模块介绍，账户与交易、链上资产转移、创世交易、链上参数管理、链上资产总量追踪、链上状态一致性检查、链上智力、节点升级等等模块。
第八章 PoS原理开始，逐步引入 Cosmos中的PoS机制，链上抵押、被动作恶惩罚、主动作恶惩罚、链上资产铸造以及链上奖励分发机制等等
第九章 Tendermint Core 轻客户端构建原理入手，介绍IBC协议的原理和设计。ICS完成一笔跨链转账的操作
第十章 Cosmos 客户端 Gaia 的实现和启动流程方面，介绍专属区块链系统的基本流程。
|
第一章
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
| 概述
2008年中本聪发布论文
2009年发布比特币
包含的学科
密码学
共识协议等
1.1 技术挑战
1.1.1 开发周期与技术门槛
大量的“社区纷争”。例如比特币区块大小争论造成了“分叉”事件，导致了比特币现金（bitcoin cash）的诞生
安全问题
构建P2P的困难成都
密码学
共识算法
1.1.2 资源消耗与交易体验
PoW方式的消耗很大
中本聪共识需要10分钟左右的消耗
PoS无厉害攻击 长程攻击可能会有伤害
实用拜占庭容错，需要O(n^2)通讯复杂度
1.1.3 链上扩容与跨链通讯
以太坊是公用一条链，不同应用各自编写智能合约通过去中心化应用（DApper）来做链应用 。以太坊繁荣，说明可行。但是会面临严重的底层区块资源问题，生态的发展受限于底层区块链的性能表现。
改善性能，比特币现金项目扩大区块容积提高链上交易处理速度，提升速度也有限。
eos通过牺牲部分分布式特性提高链上交易速度，现实中网络也遭遇过拥堵。
以太坊2.0计划通过分片（sharding）的方式实现链上交易的并行处理，分片方案在工程上遇到巨大的挑战。
多种定位不同、功能迥异的区块链并行是今后的常态。使用IBC将全部的应用专属区块链（zone）联通的模式是非常合适的。
Vitalik Buterin在 Chain Interoperability 中总结跨链通讯的三种实现机制
离散锁
公证人
中继
1.2. cosmos 网络
1.2.1 cosmos的解决方案
Tendermint Core
提供区块链底层实现，共识机制，PoS机制，通过ABCI提供接口交互
Cosmos-SDK
应用程序开发框架，cosmos寓意宇宙，每个独立的区块链都是一个星系，称为zone，zone可以通过cosmos-hub这样的中继实现互联
IBC
提供跨链支持
1.2.2 cosmos hub
2019-03-14 07 am CTS，cosmos hub上线。使用的通证为ATOM。使用链上投票方式来实现去跨链的治理。
确保稳定性一般分为3个步骤启动链
第一阶段 网络趋于稳定
第二阶段 链上交易开启
第三阶段 启动IBC协议
cosmos hub网络完成了“星际之门”stargate升级计划。任意两个区块链如果想通过IBC协议进行交互操作，只需要和cosmos hub 建立连接，无需通过IBC直接连接。cosmos hub 扮演了链通讯中心枢纽，降低链之间操作的复杂度。任意团队也能自己构建架设hub。hub之间也通过IBC协议进行跨链通讯。
催生去中心化预言机项目 Band
1.2.3 Tendermint Core
cosmos hub网络的客户端Gaia也是用这构建的
分为3层：
1. 上层应用层
2. 共识协议层
3. 对等网络通讯层
Jae Kwon 2014开始 Tendermint 共识协议研发，2015年 Ethan Buchman参与。
大概的步骤：
1. 选择新区块提案者（proposer）
2. 预投票（prevote）
3. 预提交（precommit）
具体过程在后续章节里面将会详细论述
为了支持上层的应用的深度定制，提供了ABCI抽象。
1.2.4 cosmos-SDK
准备了通用模块
基础功能
auth 管理所有账号
bank 管理链上资产转移
辅助功能
genutil 管理创世块
supply 管理链上资产总量
crisis 不变量检查的管理
params 所有模块的参数管理
链上治理
gov 链上智力机制
upgrade 链升级
PoS 链上资产抵押、链上惩罚和奖励
staking 资产抵押
slashing对验证者的被动作恶行为进行惩罚
evidence 对验证者主动作恶进行惩罚
mint 链上资产的铸造
distribution 区块奖励的分发
IBC协议，基于中继机制的跨链协议
ibc/core 跨链通讯功能
采用模块化来设计这些功能。遵循对象能力模型（object-capability model），每个模块之对外暴漏必要的功能接口。
Tendermint提供多样化的存储体系，给每个子模块独立的存储空间。
cosmos-SDK为每一个模块设计了守护者（keeper）的角色，模块之间的调用都只能通过keeper来走，防止内部的状态被恶意修改。
每个专属区块链系统都能独享自己单独一份的链上资源，所以不会出现以太坊拥堵
1.2.5 IBC协议
短期已经有的应用专属区块链
Kave
Band
Peg Zone
Aragon
通过relayer中继来完成跨链。也预防了中继恶意修改的情况。
|
第二章
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
42
43
44
45
| 第二章 密码学算法
使用到的密码学的东西
散列函数
SHA-256
RIPEMD-16
SHA-512
数字签名
ECDSA
ed25519
2.1 散列函数与Merkle树
2.1.1 散列函数简介
用于制作一个数字指纹，防止伪造
2.1.2 生日悖论原理
单向性：给定散列值h，无法获得输入的原始信息m
弱抗碰撞性：给定消息m1，无法获得第二个消息m2使得两个的散列值相等。
强抗碰撞性：无法找到两个消息m1,m2使得他们的hash值相等
2.1.3 Merkle 树构建
目的是为了保证区块中全部的交易都没有被篡改。通过使用了二叉树方式来将多条tx数据计算出唯一的散列数
cosmos-SDK设计了Immutable AVL+树。
当插入、删除节点时自动调整左右树的高度差，以确保结构不变化。
2010年提出来的自平衡二叉搜索树。
不可变数值的自平衡二叉搜索树。
Merkle树的生成方式，是通过递归算法来实现的
具体阅读代码可以在这里找到
/tendermint/crypto/merkle/
2.2 数字签名算法
基本概念
私钥能将一些信息做授权签名
验证签名需要公开可验证
涉及到3个子算法
密钥生成算法
消息签名算法
签名验证算法
公钥与地址
cosmos-sdk采用secp256k1 曲线的ECDSA签名机制授权交易。
Tendermint Core采用Edwards25519曲线的Ed25519数字签名算法来进行共识投票计算。
一共有3种类型地址和公钥
Acc
账户
Val
验证者运营方
Cons
验证者共识
2.3 网络流量加密
每个节点生成对等网络进行加密的公私钥
|
第三章
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
| 第三章 共识协议与区块链设计
cosmos hub无须消耗海量的计算资源，Tendermint共识协议秒级初亏哎特征，提升了链上交易速度
3.1 共识协议基础
达成共识，一般遵循少数服从多数。
3.1.1 半同步网络模型与BFT
多节点，且节点有可能存在故障，或者有节点存在作恶的情况，
网络本身就有不稳定和通讯延时的问题
同步网络模型
假设不会出现任何延时
异步网络模型
承认会存在延时，并且无限制等待
半同步网络模型
假设全网稳定时间（global stabilization time,GST）
FLP（Fischer-Lynch-Paterson）定理
只要有一个节点发生故障，就不存在任何共识协议能使节点在有限时间内达成共识。
共识协议必须满足下面3点
正确性：诚实节点最终达成共识必须是诚实节点提议的值
一致性：所有诚实节点都不必须就相同值大臣公式。
可结束性：诚实节点必须最终就某个值达成共识
3.1.2 拜占庭将军问题和CAP定律
Lamport 1982年提出来的拜占庭将军问题，在出现1/3及以上的叛徒，将军们就无法达成统一的决策。
f叛徒的数量
n将军总数
n<=3f
无法达成
Brewer 2000年提出了分布式系统中CAP定律
下面3个属性永远只能得到一个（典型的摁下葫芦起来瓢）
一致性 consistency
可靠性 availability
网络分区容忍 partition tolerance
3.2 PBFT共识协议
Castro和Liskov 在1999年设计的PBFT协议。包含有n=3f+1个节点，最多容忍f个节点出现故障。开始时确定所有参与的节点，节点加入与退出油管理员负责管理。节点分为主节点，从节点。任意时刻只有一个主节点，当选主节点是通过算法轮询。每个节点有自己的数字签名密钥对。
论文：
Miguel Castro, Barbara Liskov, "Practical Byzantine Fault Tolerance"
3.2.1 协议概述
客户端发起0节点请求
0节点给1-3节点转发
1-3节点给0-3除开自己的节点预准备阶段
0-3 节点提交
0-3节点反馈给客户端
3.2.2 视图转换
为了保证可用性，引入了超时机制，当某个节点掉线了，剩余的节点能通过
中间使用的全连接方式拓扑结构修改成常用的基于对等网络的拓扑结构
3.3 Tendermint共识协议
PBFT是唯一能部署的工业级BFT共识协议，然而受限于O(n^2)的通讯复杂度，不能有很多节点参与。
3.3.1 协议概述
validator node 验证者节点
PoS机制来管理节点加入退出逻辑。
参与的节点拥有权重数，被选择当提案者。投票和共识密钥。每轮投票都需要超过2f+1个节点数才算成功，否则就需要发起多轮投票，新轮次投票会选择不同的提案者。
筛选出提案者
广播开始预投票
收集了预投票结果开始广播2/3结果发起提交投票
收集投票信息并且决定是否提交
3.3.2 锁定机制
为了防止在预投票过程中有人网络中断，提交之后节点掉线未能收到提交确认信息，造成后续重复提交的问题：
当预投票的时候，每个节点就会记录下来自己的投票的高度。这样错估的节点成为提议者重复发起B2区块的投票的时候，其他节点都不会投票，这样就会让错误修复。
3.3.3 解锁机制
为了防止死锁，还需要增加解锁机制
每个新的区块高度刚开始时，所有验证者已经锁定在空值
当验证者节点锁定的区块与后续轮中其他验证者都赞成的区块不一致的情况，解锁机制允许验证节点将本地区块释放，并且重新参与新轮次的投票
3.4 识协议比较
Tendermint和PBFT
工程上不是使用全节点直连，通过了对等网络进行连接
协议的简化
Tendermint 能做到100个节点每7秒出一个块
从新区块高度到提案新区快这一步需要等待CommitTime+timeoutCommit超时。
可以通过修改ConsensusConfig结构体中SkipTimeoutCommit字段来跳过固定的等待时间。
3.5 提案者轮换选择算法
每个节点都有选举权重，初始权值
每轮将会加上自己的权重
然后全局比大小
数字最大的数字，将会得到提议权力，并且将自己当前的值减去全部参与人的权值的总和
实验推导结果，基本符合权重，和当选次数。
3.6 区块结构
区块链的数据结构
tendermint/types/vote.go
evidence.go
part_set.go
block.go
互斥量
区块头
版本信息
高度
生成时间
前一个区块的区块标识
大量的散列值
当前区块的提案者
区块体
作恶举证
上一个区块的投票信息
cosmos hub中抵押链上资产数量排名前100位有资格成为活跃验证者
|
第四章
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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
| 第四章 Tendermint Core 的架构设计
tendermint core实现了对等网络通讯，以及tendermint 共识协议，定义实现了ABCI。核心都围绕这Node结构体来管理所有的模块功能
4.1 整体架构概述
抽象了一些概念：Service、Reactor、Switch以及MultiplexTransport等
4.1.1 基本概念
服务Service接口
Start() Stop() Reset()
反应器Reactor接口
AddPeer()
RemovePeer()
Receive()
BaseService管理反应器的启动和停止，Switch让反应器之间互相配合
转换器Switch
内部结构的枢纽
全局的switch保存着全部的反应器，每个反应器都存储了一份转换器。这样反应器就能通过转换器找到需要通讯的另外的反应器。
switch利用pex模块进行节点发现并且记录到AddressBook中
利用MultiplexTransaport建立并且管理对等网络节点之间的全部网络连接
多路复用传输MultiplexTransport
负责建立并且维护对等网络节点之间的通讯
抽象了MConnection封装了普通的TCP连接以实现多路复用
两个对等网络节点之间需要不时的同步各种信息：区块广播、交易广播或者投标信息广播
实现了Channel结构体，每个真实的连接对应一个MConnection，一个MConnection被多个Channel公用
通讯过程都是使用了加密通讯，每个节点都有自己的密钥。
节点信息交换pex模块
应该是包含了网络张狂，安全性相关的信息
4.1.2 反应器简介
MultiplexTransaport负责将节点网络建立起来，当创建了连接之后，需要同步节点的区块状态信息
BlockchainReactor实现区块链请求、接受和处理相关的逻辑。同步的区块通过BlockPool存储
mempool.Reactor负责处理交易。接收到交易利用结构体CListMempool管理。使用了Go里面的并发双链表（concurrent liked-list）
evidence.Reactor举证惩罚机制反应器
处理接受举证信息
consensus.Reactor共识协议反应器
抵押链上资产竞争参与共识投票权利。
pex.Reactor 节点发现与管理
4.2 核心数据结构Node结构体
tendermint/node/node.go
这个数据结构是最核心的数据结构
4.2.1 作为服务的Node结构体
防止反复启停
OnReset将会直接崩溃
4.2.2 可配置的Node结构体
提供了可配置相关的数据结构
GenesisDoc
共识相关的配置信息
PrivValidator
4.2.3 作为对等网络节点的Node结构体
启动BaseService之后，将会出发启动multiplexTransaport
自己打开Listener
transportLiecycle
自己连接别人的结构
Transport
addOutboundPeerWithConfig()
发起对其他的节点的连接
连接之前需要去重，防止别人已经连接过来了
filterPeer()
交换密码完成加密信道建立
createMConnection() secretConn
通过调用Reactor.InitPeer()函数通知Reactor存在
启动接手、发送携程。
为啥要构建多路复用的MConnection
减少套接字的消耗，多个反应器能共用同一个TCP的连接。使用数据包在逻辑层来做分流。
TCP有两个特性：滑动窗口大小，慢启动。在生命周期内，窗口大小会不停的调整。针对TCP连接本身特性还引入了各种辅助机制。
节点发现管理，还通过了pex模块进行的。
4.3 反应器
概述
InitPeer()将会分配Peer对象
AddPeer() 启动内部的消息处理的协程
设置Switch
获取关联的Channels
AddPeer
InitPeer
RemovePeer
Receive(chID,peer,msgBytes)
各种readctor
mempool.Reactor,CListMempool
evidence.Reactor.Pool 举证信息
BlockchainReactor.BlockPool,bpRequester
consensus.Reactor consensus.State记录共识协议的状态
4.3.1 mempool.Reactor
负责处理交易相关的信息，TxMessage
tendermint/memepool/reactor.go
调用InitPeer()分配peer一个编号
调用AddPeer函数，启动broadcastTxRoutine里面的goroutine。以确保交易的广播。
反应器反馈了自己关心的Channel，当MConnection接收到Channel的信息之后，将会调用关联的反应器的OnReceiver函数。
反应器和MConnection绑定是通过createMConnection函数来实现的
tendermint/p2p/peer.go 365-400lines
后续反应器的工作流程都大致擦不多，只是处理逻辑的差别
4.3.2 evidence.Reactor
处理验证节点作恶的情况
4.3.3 Blockchain.Reactor
tendermit/blockchain/v0/reactor.go
4.3.4 consensus.Reactor
tendermint/consensus/reactor.go
通过4个Channel处理9种消息
StateChannel
NewRoundStepMessage、NewValidBlockMessage、
HasVoteMessage、
VoteSetMaj23Message
DataChannel
VoteChannel
VoteSetBitsChannel
能订阅其中处理的过程
|
第五章
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 第5章 ABCI
概述
三层结构：通信层、共识协议层、上层应用层
ABCI结构：应用层为服务器、tendermint为客户端
交互方式
进程内交互
gRPC
套接字交互
三种功能分别独立的连接
交易池连接
共识连接
查询链接
5.1 交易池连接
CheckTx
收到自己成为提议者之后需要抓取一些区块开始构建。tendermint没有验证区块是否合法的逻辑，需要通过ABCI检查区块是否合法
5.2 共识连接
5.3 查询连接
|
第六章