区块链系统可以归结为如下图所示的六层架构模型，自下而上分别是数据层、网络层、共识层、激励层、合约层和应用层。部分区块链应用并不完整地包含这六层结构，但是数据层、网络层和共识层可以说是构建所有区块链应用的必要因素。
目前，大部分的区块链应用都是采用整体的设计方法，就是说，这些区块链应用实现成单一的程序，一个程序实现了区块链各层的所有功能，包括P2P连接，交易数据的处理和广播，共识达成，具体的应用功能实现等等。
例如比特币，一整套代码就实现了所有比特币的功能。从软件工程的角度来看，这种非模块化的设计是不合理的，这会使代码复用变得困难，代码的分支管理也变得复杂，同时还限制的区块链应用开发使用的语言。
针对这个问题，Tendermint对区块链的功能模块进行解耦，将共识和P2P部分从具体的区块链应用状态细节中分离出来，以适用各种分布式应用。
Tendermint由两部分组成：区块链共识引擎和通用的应用程序接口。
1. 共识引擎被称为Tendermint Core，用于确保同一个交易在不同机器上记录的顺序相同。
2. 通用的应用程序接口也被称为应用区块链接口（Application Blockchain Interface，ABCI），其作用是使交易可以用任何编程语言进行处理。
Tendermint Core通过ABCI接口与应用层进行交互，应用程序可以用任何语言编写，开发者可以很方便地开发自己的区块链应用。
Tendermint Core
Tendermint Core实现区块链大部分功能，包括：共识算法，RPC，数据库，同步，P2P等等。本节主要介绍Tendermint共识算法。
Tendermint共识算法
Tendermint使用一种基于拜占庭容错（BFT）的共识算法，其工作模式类似于循环投票机制。参与Tendermint共识过程的角色主要有两个：
· Validator（验证者）：网络中的节点，可参与共识过程中的投票，不同的验证者在投票过程可能具备不同的投票权重（vote power）。
· Proposer（提议人）：Tendermint使用一种确定的非阻塞轮询选择算法从validators中选出proposer，该算法根据validators的投票权重所占比例来选择proposer，投票权重越大的validator被选为proposer的频率越高。
Tendermint区块链是通过基于round（回合）的机制来确定下一个区块。每个round由三个过程组成：propose（提议），prevote（预投票）和precommit（预提交）。
理想情况下，链上的区块生成状态如下：
NewHeight -> (Propose -> Prevote -> Precommit) -> Commit -> NewHeight ->…
其中，NewHeight为区块被全网接受后，区块高度+1。Propose -> Prevote -> Precommit为一个round，这里加括号表示在某一区块高度成功提交一个区块可能需要多个round，也就是说，一个round可能无法成功地提交区块。
区块链处于某一区块高度时，为决定出下一区块，系统会进入如上图所示的共识过程。
第一阶段为propose阶段，在该阶段由系统选出的proposer提议将某一交易区块作为链上的下一区块，并将该提议广播出去。接下来需要进入两个投票阶段：prevote和precommit。在prevote阶段，对于proposer提议的区块，若validator验证为有效区块，那么validator会对其进行prevote；相反，若为无效区块或者validator没有及时收到提议的区块，那么validators的prevote为空（Nil）。
在precommit阶段，若validator收到该区块超过2/3的prevote，那么validator会对区块进行precommit；反之，则precommit为Nil。
上图中有一对夫妇在跳polka（波卡）舞，validator做的事情就像在跳polka舞。当超过2/3的validators对提议的区块进行了prevote，可以称为一个Polka。每次precommit必须由同一round的Polka证明。
在precommit阶段的最后，每个节点需要作出决定。若节点收到了超过2/3的precommit，那么节点进入commit阶段；否则，节点继续进入下一round的propose阶段。
因此，系统处于propose阶段是由两种条件驱动，一种是区块被提交到链上后重新提交新的区块，新的区块高度+1；另一种是区块提交失败后重启round，此时区块高度不变。
此时，我们可以分析在共识过程中为什么成功提交一个区块可能需要多个round，原因有以下几点：
· 选出的proposer不在线；
· proposer提议的区块无效；
· proposer提议的区块没有及时传播出去；
· 提议的区块有效，但在到达Precommit阶段前，validator节点没有及时收到超过2/3的prevote。或者是，prevote超过2/3可以进入下一状态，却出现至少有一个validator投了Nil票或恶意投票；
· 提议的区块有效，并且prevote超过了2/3，但是validator节点没有收到超过2/3的precommit。
每个round开始期间，若validators在一个timeout时间内没有收到提议，validators将通过投票来决定是否跳过当前的proposer。这种对超时的依赖使得Tendermint是一种弱同步协议，而不是一种异步协议。但是，每个round在收到提议之后，就进入完全异步模式，validators只能在取得超过2/3的共识后才能继续往前。
Tendermint共识算法可以容忍1/3以内的节点错误，这个错误包括节点离线和节点作恶。
在拜占庭节点数少于节点总数的1/3时，为了避免出现在同一区块高度不同round分别提交两个不同区块的情况，Tendermint引入了锁机制。Validators会被锁定在其最近precommit的区块上。当收到区块超过2/3的prevote后，validators为该区块进行precommit，validator即锁定在该区块上了。Validators节点每次最多只能锁定一个区块，且只能prevote他们被锁定的区块，这样可以阻止validators在上一round中precommit一个区块，在下一round中又prevote另一个区块，从而避免出现在同一区块高度提交两个不同区块的情况。Validators只有看到更高round（相对于其当前被锁定区块的round数）的polka才能解锁，该polka包括收到超过2/3的prevote或Nil prevote两种类型的polka。
因此，如果拜占庭节点数少于1/3，基于Tendermint的区块链永远不会分叉。
上面说到，大部分的区块链应用都是采用整体的设计方法，就是说，这些区块链应用实现成单一的程序，一个程序实现了区块链各层的所有功能，包括P2P连接，交易数据的处理和广播，共识达成，具体的应用功能实现等等。
例如比特币，一整套代码就实现了所有比特币的功能。从软件工程的角度来看，这种非模块化的设计是不合理的，这会使代码复用变得困难，代码的分支管理也变得复杂，同时还限制的区块链应用开发使用的语言。
针对这个问题，Tendermint对区块链的功能模块进行解耦，将共识和P2P部分从具体的区块链应用状态细节中分离出来，以适用各种分布式应用。
Tendermint由两部分组成：区块链共识引擎和通用的应用程序接口。
1. 共识引擎被称为Tendermint Core，用于确保同一个交易在不同机器上记录的顺序相同。
2. 通用的应用程序接口也被称为应用区块链接口（Application Blockchain Interface，ABCI），其作用是使交易可以用任何编程语言进行处理。
Tendermint Core通过ABCI接口与应用层进行交互，应用程序可以用任何语言编写，开发者可以很方便地开发自己的区块链应用。
ABCI（Application Blockchain Interface）
Tendermint Core通过一个满足ABCI标准的socket协议与应用程序进行交互。
ABCI 包含3 种消息类型：DeliverTx消息，CheckTx消息和commit消息。Tendermint Core将消息发送给应用，应用根据消息进行相应的回复。
DeliverTx 消息是应用的主要工作流程。链上的每笔交易都通过这个消息进行传送。应用基于当前状态、应用协议和交易的加密证书，验证接收到 DeliverTx 消息的每笔交易。然后，验证后的交易会更新应用状态。
CheckTx 消息类似于 DeliverTx，但它仅用于验证交易。Tendermint Core 的内存池首先使用 CheckTx 检验交易的有效性，并且只将有效交易广播给其他节点。
Commit 消息用于通知应用程序计算当前应用状态的加密保证（cryptographic commitment），该加密保证会被放入下一个区块头部。
一个应用可能与多个ABCI socket 连接。Tendermint Core 给应用程序创建了三个 ABCI 连接：一个用于内存池广播时的交易验证，一个用于区块提议时的共识引擎，还有一个用于查询应用状态。
总结
本文主要介绍了Tendermint共识算法和ABCI接口。Tendermint是基于BFT的共识算法，在错误节点不超过1/3的情况下，Tendermint保证安全永远不会被破坏，系统不会在同一区块高度提交冲突的区块。
因此，区块链永远不会分叉。但是每个投票环节都需要得到超过2/3的validators的投票，在现实世界中有很大可能性系统真的会停止运行，这个问题还需要对应的解决方法。