You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

328 lines
16 KiB

  1. # What is Tendermint?
  2. Tendermint is software for securely and consistently replicating an
  3. application on many machines. By securely, we mean that Tendermint works
  4. even if up to 1/3 of machines fail in arbitrary ways. By consistently,
  5. we mean that every non-faulty machine sees the same transaction log and
  6. computes the same state. Secure and consistent replication is a
  7. fundamental problem in distributed systems; it plays a critical role in
  8. the fault tolerance of a broad range of applications, from currencies,
  9. to elections, to infrastructure orchestration, and beyond.
  10. The ability to tolerate machines failing in arbitrary ways, including
  11. becoming malicious, is known as Byzantine fault tolerance (BFT). The
  12. theory of BFT is decades old, but software implementations have only
  13. became popular recently, due largely to the success of "blockchain
  14. technology" like Bitcoin and Ethereum. Blockchain technology is just a
  15. reformalization of BFT in a more modern setting, with emphasis on
  16. peer-to-peer networking and cryptographic authentication. The name
  17. derives from the way transactions are batched in blocks, where each
  18. block contains a cryptographic hash of the previous one, forming a
  19. chain. In practice, the blockchain data structure actually optimizes BFT
  20. design.
  21. Tendermint consists of two chief technical components: a blockchain
  22. consensus engine and a generic application interface. The consensus
  23. engine, called Tendermint Core, ensures that the same transactions are
  24. recorded on every machine in the same order. The application interface,
  25. called the Application BlockChain Interface (ABCI), enables the
  26. transactions to be processed in any programming language. Unlike other
  27. blockchain and consensus solutions, which come pre-packaged with built
  28. in state machines (like a fancy key-value store, or a quirky scripting
  29. language), developers can use Tendermint for BFT state machine
  30. replication of applications written in whatever programming language and
  31. development environment is right for them.
  32. Tendermint is designed to be easy-to-use, simple-to-understand, highly
  33. performant, and useful for a wide variety of distributed applications.
  34. ## Tendermint vs. X
  35. Tendermint is broadly similar to two classes of software. The first
  36. class consists of distributed key-value stores, like Zookeeper, etcd,
  37. and consul, which use non-BFT consensus. The second class is known as
  38. "blockchain technology", and consists of both cryptocurrencies like
  39. Bitcoin and Ethereum, and alternative distributed ledger designs like
  40. Hyperledger's Burrow.
  41. ### Zookeeper, etcd, consul
  42. Zookeeper, etcd, and consul are all implementations of a key-value store
  43. atop a classical, non-BFT consensus algorithm. Zookeeper uses a version
  44. of Paxos called Zookeeper Atomic Broadcast, while etcd and consul use
  45. the Raft consensus algorithm, which is much younger and simpler. A
  46. typical cluster contains 3-5 machines, and can tolerate crash failures
  47. in up to 1/2 of the machines, but even a single Byzantine fault can
  48. destroy the system.
  49. Each offering provides a slightly different implementation of a
  50. featureful key-value store, but all are generally focused around
  51. providing basic services to distributed systems, such as dynamic
  52. configuration, service discovery, locking, leader-election, and so on.
  53. Tendermint is in essence similar software, but with two key differences:
  54. - It is Byzantine Fault Tolerant, meaning it can only tolerate up to a
  55. 1/3 of failures, but those failures can include arbitrary behaviour -
  56. including hacking and malicious attacks. - It does not specify a
  57. particular application, like a fancy key-value store. Instead, it
  58. focuses on arbitrary state machine replication, so developers can build
  59. the application logic that's right for them, from key-value store to
  60. cryptocurrency to e-voting platform and beyond.
  61. ### Bitcoin, Ethereum, etc.
  62. Tendermint emerged in the tradition of cryptocurrencies like Bitcoin,
  63. Ethereum, etc. with the goal of providing a more efficient and secure
  64. consensus algorithm than Bitcoin's Proof of Work. In the early days,
  65. Tendermint had a simple currency built in, and to participate in
  66. consensus, users had to "bond" units of the currency into a security
  67. deposit which could be revoked if they misbehaved -this is what made
  68. Tendermint a Proof-of-Stake algorithm.
  69. Since then, Tendermint has evolved to be a general purpose blockchain
  70. consensus engine that can host arbitrary application states. That means
  71. it can be used as a plug-and-play replacement for the consensus engines
  72. of other blockchain software. So one can take the current Ethereum code
  73. base, whether in Rust, or Go, or Haskell, and run it as a ABCI
  74. application using Tendermint consensus. Indeed, [we did that with
  75. Ethereum](https://github.com/cosmos/ethermint). And we plan to do
  76. the same for Bitcoin, ZCash, and various other deterministic
  77. applications as well.
  78. Another example of a cryptocurrency application built on Tendermint is
  79. [the Cosmos network](http://cosmos.network).
  80. ### Other Blockchain Projects
  81. [Fabric](https://github.com/hyperledger/fabric) takes a similar approach
  82. to Tendermint, but is more opinionated about how the state is managed,
  83. and requires that all application behaviour runs in potentially many
  84. docker containers, modules it calls "chaincode". It uses an
  85. implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf).
  86. from a team at IBM that is [augmented to handle potentially
  87. non-deterministic
  88. chaincode](https://www.zurich.ibm.com/~cca/papers/sieve.pdf) It is
  89. possible to implement this docker-based behaviour as a ABCI app in
  90. Tendermint, though extending Tendermint to handle non-determinism
  91. remains for future work.
  92. [Burrow](https://github.com/hyperledger/burrow) is an implementation of
  93. the Ethereum Virtual Machine and Ethereum transaction mechanics, with
  94. additional features for a name-registry, permissions, and native
  95. contracts, and an alternative blockchain API. It uses Tendermint as its
  96. consensus engine, and provides a particular application state.
  97. ## ABCI Overview
  98. The [Application BlockChain Interface
  99. (ABCI)](https://github.com/tendermint/tendermint/tree/master/abci)
  100. allows for Byzantine Fault Tolerant replication of applications
  101. written in any programming language.
  102. ### Motivation
  103. Thus far, all blockchains "stacks" (such as
  104. [Bitcoin](https://github.com/bitcoin/bitcoin)) have had a monolithic
  105. design. That is, each blockchain stack is a single program that handles
  106. all the concerns of a decentralized ledger; this includes P2P
  107. connectivity, the "mempool" broadcasting of transactions, consensus on
  108. the most recent block, account balances, Turing-complete contracts,
  109. user-level permissions, etc.
  110. Using a monolithic architecture is typically bad practice in computer
  111. science. It makes it difficult to reuse components of the code, and
  112. attempts to do so result in complex maintenance procedures for forks of
  113. the codebase. This is especially true when the codebase is not modular
  114. in design and suffers from "spaghetti code".
  115. Another problem with monolithic design is that it limits you to the
  116. language of the blockchain stack (or vice versa). In the case of
  117. Ethereum which supports a Turing-complete bytecode virtual-machine, it
  118. limits you to languages that compile down to that bytecode; today, those
  119. are Serpent and Solidity.
  120. In contrast, our approach is to decouple the consensus engine and P2P
  121. layers from the details of the application state of the particular
  122. blockchain application. We do this by abstracting away the details of
  123. the application to an interface, which is implemented as a socket
  124. protocol.
  125. Thus we have an interface, the Application BlockChain Interface (ABCI),
  126. and its primary implementation, the Tendermint Socket Protocol (TSP, or
  127. Teaspoon).
  128. ### Intro to ABCI
  129. [Tendermint Core](https://github.com/tendermint/tendermint) (the
  130. "consensus engine") communicates with the application via a socket
  131. protocol that satisfies the ABCI.
  132. To draw an analogy, lets talk about a well-known cryptocurrency,
  133. Bitcoin. Bitcoin is a cryptocurrency blockchain where each node
  134. maintains a fully audited Unspent Transaction Output (UTXO) database. If
  135. one wanted to create a Bitcoin-like system on top of ABCI, Tendermint
  136. Core would be responsible for
  137. - Sharing blocks and transactions between nodes
  138. - Establishing a canonical/immutable order of transactions
  139. (the blockchain)
  140. The application will be responsible for
  141. - Maintaining the UTXO database
  142. - Validating cryptographic signatures of transactions
  143. - Preventing transactions from spending non-existent transactions
  144. - Allowing clients to query the UTXO database.
  145. Tendermint is able to decompose the blockchain design by offering a very
  146. simple API (ie. the ABCI) between the application process and consensus
  147. process.
  148. The ABCI consists of 3 primary message types that get delivered from the
  149. core to the application. The application replies with corresponding
  150. response messages.
  151. The messages are specified here: [ABCI Message
  152. Types](https://github.com/tendermint/tendermint/blob/master/abci/README.md#message-types).
  153. The **DeliverTx** message is the work horse of the application. Each
  154. transaction in the blockchain is delivered with this message. The
  155. application needs to validate each transaction received with the
  156. **DeliverTx** message against the current state, application protocol,
  157. and the cryptographic credentials of the transaction. A validated
  158. transaction then needs to update the application state — by binding a
  159. value into a key values store, or by updating the UTXO database, for
  160. instance.
  161. The **CheckTx** message is similar to **DeliverTx**, but it's only for
  162. validating transactions. Tendermint Core's mempool first checks the
  163. validity of a transaction with **CheckTx**, and only relays valid
  164. transactions to its peers. For instance, an application may check an
  165. incrementing sequence number in the transaction and return an error upon
  166. **CheckTx** if the sequence number is old. Alternatively, they might use
  167. a capabilities based system that requires capabilities to be renewed
  168. with every transaction.
  169. The **Commit** message is used to compute a cryptographic commitment to
  170. the current application state, to be placed into the next block header.
  171. This has some handy properties. Inconsistencies in updating that state
  172. will now appear as blockchain forks which catches a whole class of
  173. programming errors. This also simplifies the development of secure
  174. lightweight clients, as Merkle-hash proofs can be verified by checking
  175. against the block hash, and that the block hash is signed by a quorum.
  176. There can be multiple ABCI socket connections to an application.
  177. Tendermint Core creates three ABCI connections to the application; one
  178. for the validation of transactions when broadcasting in the mempool, one
  179. for the consensus engine to run block proposals, and one more for
  180. querying the application state.
  181. It's probably evident that applications designers need to very carefully
  182. design their message handlers to create a blockchain that does anything
  183. useful but this architecture provides a place to start. The diagram
  184. below illustrates the flow of messages via ABCI.
  185. ![](../imgs/abci.png)
  186. ## A Note on Determinism
  187. The logic for blockchain transaction processing must be deterministic.
  188. If the application logic weren't deterministic, consensus would not be
  189. reached among the Tendermint Core replica nodes.
  190. Solidity on Ethereum is a great language of choice for blockchain
  191. applications because, among other reasons, it is a completely
  192. deterministic programming language. However, it's also possible to
  193. create deterministic applications using existing popular languages like
  194. Java, C++, Python, or Go. Game programmers and blockchain developers are
  195. already familiar with creating deterministic programs by avoiding
  196. sources of non-determinism such as:
  197. - random number generators (without deterministic seeding)
  198. - race conditions on threads (or avoiding threads altogether)
  199. - the system clock
  200. - uninitialized memory (in unsafe programming languages like C
  201. or C++)
  202. - [floating point
  203. arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/)
  204. - language features that are random (e.g. map iteration in Go)
  205. While programmers can avoid non-determinism by being careful, it is also
  206. possible to create a special linter or static analyzer for each language
  207. to check for determinism. In the future we may work with partners to
  208. create such tools.
  209. ## Consensus Overview
  210. Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus
  211. protocol. The protocol follows a simple state machine that looks like
  212. this:
  213. ![](../imgs/consensus_logic.png)
  214. Participants in the protocol are called **validators**; they take turns
  215. proposing blocks of transactions and voting on them. Blocks are
  216. committed in a chain, with one block at each **height**. A block may
  217. fail to be committed, in which case the protocol moves to the next
  218. **round**, and a new validator gets to propose a block for that height.
  219. Two stages of voting are required to successfully commit a block; we
  220. call them **pre-vote** and **pre-commit**. A block is committed when
  221. more than 2/3 of validators pre-commit for the same block in the same
  222. round.
  223. There is a picture of a couple doing the polka because validators are
  224. doing something like a polka dance. When more than two-thirds of the
  225. validators pre-vote for the same block, we call that a **polka**. Every
  226. pre-commit must be justified by a polka in the same round.
  227. Validators may fail to commit a block for a number of reasons; the
  228. current proposer may be offline, or the network may be slow. Tendermint
  229. allows them to establish that a validator should be skipped. Validators
  230. wait a small amount of time to receive a complete proposal block from
  231. the proposer before voting to move to the next round. This reliance on a
  232. timeout is what makes Tendermint a weakly synchronous protocol, rather
  233. than an asynchronous one. However, the rest of the protocol is
  234. asynchronous, and validators only make progress after hearing from more
  235. than two-thirds of the validator set. A simplifying element of
  236. Tendermint is that it uses the same mechanism to commit a block as it
  237. does to skip to the next round.
  238. Assuming less than one-third of the validators are Byzantine, Tendermint
  239. guarantees that safety will never be violated - that is, validators will
  240. never commit conflicting blocks at the same height. To do this it
  241. introduces a few **locking** rules which modulate which paths can be
  242. followed in the flow diagram. Once a validator precommits a block, it is
  243. locked on that block. Then,
  244. 1. it must prevote for the block it is locked on
  245. 2. it can only unlock, and precommit for a new block, if there is a
  246. polka for that block in a later round
  247. ## Stake
  248. In many systems, not all validators will have the same "weight" in the
  249. consensus protocol. Thus, we are not so much interested in one-third or
  250. two-thirds of the validators, but in those proportions of the total
  251. voting power, which may not be uniformly distributed across individual
  252. validators.
  253. Since Tendermint can replicate arbitrary applications, it is possible to
  254. define a currency, and denominate the voting power in that currency.
  255. When voting power is denominated in a native currency, the system is
  256. often referred to as Proof-of-Stake. Validators can be forced, by logic
  257. in the application, to "bond" their currency holdings in a security
  258. deposit that can be destroyed if they're found to misbehave in the
  259. consensus protocol. This adds an economic element to the security of the
  260. protocol, allowing one to quantify the cost of violating the assumption
  261. that less than one-third of voting power is Byzantine.
  262. The [Cosmos Network](https://cosmos.network) is designed to use this
  263. Proof-of-Stake mechanism across an array of cryptocurrencies implemented
  264. as ABCI applications.
  265. The following diagram is Tendermint in a (technical) nutshell. [See here
  266. for high resolution
  267. version](https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf).
  268. ![](../imgs/tm-transaction-flow.png)