* docs theme * vuepress-theme-cosmos * version bump * changes to docs * more code changes * sidebar order fix * moar changes * fixed dev sessions title * fixed dev sessions title, again * specs should show up in sidebar * contents cards * version bump * sidebar, rpc * version bump * custom footer and super naive search * version * minor change to vuepress * move swagger file * pre and post scripts * build * changed docs build process * added deployment config * updated versions file and added deployment filterspull/4055/head
@ -1,141 +1,140 @@ | |||
module.exports = { | |||
title: "Tendermint Documentation", | |||
description: "Documentation for Tendermint Core.", | |||
ga: "UA-51029217-1", | |||
dest: "./dist/docs", | |||
base: "/docs/", | |||
markdown: { | |||
lineNumbers: true | |||
}, | |||
theme: "cosmos", | |||
// locales: { | |||
// "/": { | |||
// lang: "en-US" | |||
// }, | |||
// "/ru/": { | |||
// lang: "ru" | |||
// } | |||
// }, | |||
themeConfig: { | |||
repo: "tendermint/tendermint", | |||
editLinks: true, | |||
docsRepo: "tendermint/tendermint", | |||
editLink: true, | |||
docsDir: "docs", | |||
docsBranch: "develop", | |||
editLinkText: 'Edit this page on Github', | |||
lastUpdated: true, | |||
algolia: { | |||
apiKey: '59f0e2deb984aa9cdf2b3a5fd24ac501', | |||
indexName: 'tendermint', | |||
debug: false | |||
logo: "/logo.svg", | |||
label: "core", | |||
gutter: { | |||
title: "Help & Support", | |||
editLink: true, | |||
children: [ | |||
{ | |||
title: "Riot Chat", | |||
text: "Chat with Tendermint developers on Riot Chat.", | |||
highlighted: "500+ people chatting now" | |||
}, | |||
{ | |||
title: "Tendermint Forum", | |||
text: "Found an Issue?", | |||
highlighted: | |||
"Help us improve this page by suggesting edits on GitHub." | |||
} | |||
] | |||
}, | |||
nav: [ | |||
{ text: "Back to Tendermint", link: "https://tendermint.com" }, | |||
{ text: "RPC", link: "https://tendermint.com/rpc/" } | |||
], | |||
sidebar: [ | |||
{ | |||
title: "Introduction", | |||
collapsable: false, | |||
children: [ | |||
"/introduction/", | |||
"/introduction/quick-start", | |||
"/introduction/install", | |||
"/introduction/what-is-tendermint" | |||
] | |||
}, | |||
{ | |||
title: "Guides", | |||
collapsable: false, | |||
children: [ | |||
"/guides/go-built-in", | |||
"/guides/go" | |||
] | |||
}, | |||
{ | |||
title: "Apps", | |||
collapsable: false, | |||
children: [ | |||
"/app-dev/getting-started", | |||
"/app-dev/abci-cli", | |||
"/app-dev/app-architecture", | |||
"/app-dev/app-development", | |||
"/app-dev/subscribing-to-events-via-websocket", | |||
"/app-dev/indexing-transactions", | |||
"/spec/abci/abci", | |||
"/app-dev/ecosystem" | |||
] | |||
}, | |||
{ | |||
title: "Tendermint Core", | |||
collapsable: false, | |||
children: [ | |||
"/tendermint-core/", | |||
"/tendermint-core/using-tendermint", | |||
"/tendermint-core/configuration", | |||
"/tendermint-core/rpc", | |||
"/tendermint-core/running-in-production", | |||
"/tendermint-core/fast-sync", | |||
"/tendermint-core/how-to-read-logs", | |||
"/tendermint-core/block-structure", | |||
"/tendermint-core/light-client-protocol", | |||
"/tendermint-core/metrics", | |||
"/tendermint-core/secure-p2p", | |||
"/tendermint-core/validators", | |||
"/tendermint-core/mempool" | |||
] | |||
}, | |||
{ | |||
title: "Networks", | |||
collapsable: false, | |||
children: [ | |||
"/networks/", | |||
"/networks/docker-compose", | |||
"/networks/terraform-and-ansible", | |||
] | |||
}, | |||
{ | |||
title: "Tools", | |||
collapsable: false, | |||
children: [ | |||
"/tools/", | |||
"/tools/benchmarking", | |||
"/tools/monitoring", | |||
"/tools/remote-signer-validation" | |||
] | |||
}, | |||
{ | |||
title: "Tendermint Spec", | |||
collapsable: true, | |||
children: [ | |||
"/spec/", | |||
"/spec/blockchain/blockchain", | |||
"/spec/blockchain/encoding", | |||
"/spec/blockchain/state", | |||
"/spec/software/abci", | |||
"/spec/consensus/bft-time", | |||
"/spec/consensus/consensus", | |||
"/spec/consensus/light-client", | |||
"/spec/software/wal", | |||
"/spec/p2p/config", | |||
"/spec/p2p/connection", | |||
"/spec/p2p/node", | |||
"/spec/p2p/peer", | |||
"/spec/reactors/block_sync/reactor", | |||
"/spec/reactors/block_sync/impl", | |||
"/spec/reactors/consensus/consensus", | |||
"/spec/reactors/consensus/consensus-reactor", | |||
"/spec/reactors/consensus/proposer-selection", | |||
"/spec/reactors/evidence/reactor", | |||
"/spec/reactors/mempool/concurrency", | |||
"/spec/reactors/mempool/config", | |||
"/spec/reactors/mempool/functionality", | |||
"/spec/reactors/mempool/messages", | |||
"/spec/reactors/mempool/reactor", | |||
"/spec/reactors/pex/pex", | |||
"/spec/reactors/pex/reactor", | |||
] | |||
footer: { | |||
logo: "/logo-bw.svg", | |||
textLink: { | |||
text: "tendermint.com", | |||
url: "https://tendermint.com" | |||
}, | |||
services: [ | |||
{ | |||
service: "medium", | |||
url: "https://medium.com/@tendermint" | |||
}, | |||
{ | |||
service: "twitter", | |||
url: "https://twitter.com/tendermint_team" | |||
}, | |||
{ | |||
service: "linkedin", | |||
url: "https://www.linkedin.com/company/tendermint/" | |||
}, | |||
{ | |||
service: "reddit", | |||
url: "https://reddit.com/r/cosmosnetwork" | |||
}, | |||
{ | |||
service: "telegram", | |||
url: "https://t.me/cosmosproject" | |||
}, | |||
{ | |||
service: "youtube", | |||
url: "https://www.youtube.com/c/CosmosProject" | |||
} | |||
], | |||
smallprint: | |||
"The development of the Tendermint project is led primarily by Tendermint Inc., the for-profit entity which also maintains this website. Funding for this development comes primarily from the Interchain Foundation, a Swiss non-profit.", | |||
links: [ | |||
{ | |||
title: "Documentation", | |||
children: [ | |||
{ | |||
title: "Cosmos SDK", | |||
url: "https://cosmos.network/docs" | |||
}, | |||
{ | |||
title: "Cosmos Hub", | |||
url: "https://hub.cosmos.network/" | |||
} | |||
] | |||
}, | |||
{ | |||
title: "Community", | |||
children: [ | |||
{ | |||
title: "Tendermint blog", | |||
url: "https://medium.com/@tendermint" | |||
}, | |||
{ | |||
title: "Forum", | |||
url: "https://forum.cosmos.network/c/tendermint" | |||
}, | |||
{ | |||
title: "Chat", | |||
url: "https://riot.im/app/#/room/#tendermint:matrix.org" | |||
} | |||
] | |||
}, | |||
{ | |||
title: "Contributing", | |||
children: [ | |||
{ | |||
title: "Contributing to the docs", | |||
url: "https://github.com/tendermint/tendermint" | |||
}, | |||
{ | |||
title: "Source code on GitHub", | |||
url: "https://github.com/tendermint/tendermint" | |||
}, | |||
{ | |||
title: "Careers at Tendermint", | |||
url: "https://tendermint.com/careers" | |||
} | |||
] | |||
} | |||
] | |||
}, | |||
sidebar: [ | |||
{ | |||
title: "ABCI Spec", | |||
collapsable: false, | |||
title: "Resources", | |||
children: [ | |||
"/spec/abci/", | |||
"/spec/abci/abci", | |||
"/spec/abci/apps", | |||
"/spec/abci/client-server" | |||
{ | |||
title: "Developer Sessions", | |||
path: "/DEV_SESSIONS" | |||
}, | |||
{ | |||
title: "RPC", | |||
static: true, | |||
path: "/rpc/" | |||
} | |||
] | |||
} | |||
] | |||
}, | |||
markdown: { | |||
anchor: { | |||
permalinkSymbol: "" | |||
} | |||
} | |||
}; |
@ -1,17 +0,0 @@ | |||
<!DOCTYPE html> | |||
<html lang="en-US"> | |||
<head> | |||
<meta charset="utf-8"> | |||
<meta name="viewport" content="width=device-width,initial-scale=1"> | |||
<title>VuePress</title> | |||
<meta name="description" content=""> | |||
<link rel="preload" href="/assets/css/1.styles.c01b7ee3.css" as="style"><link rel="preload" href="/assets/js/app.48f1ff5f.js" as="script"><link rel="prefetch" href="/assets/js/0.7c2695bf.js"> | |||
<link rel="stylesheet" href="/assets/css/1.styles.c01b7ee3.css"> | |||
</head> | |||
<body> | |||
<div id="app" data-server-rendered="true"><div class="theme-container"><div class="content"><h1>404</h1><blockquote>Looks like we've got some broken links.</blockquote><a href="/" class="router-link-active">Take me home.</a></div></div></div> | |||
<script src="/assets/js/app.48f1ff5f.js" defer></script> | |||
</body> | |||
</html> |
@ -1 +0,0 @@ | |||
<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg" width="12" height="13"><g stroke-width="2" stroke="#aaa" fill="none"><path d="M11.29 11.71l-4-4"/><circle cx="5" cy="5" r="4"/></g></svg> |
@ -1 +0,0 @@ | |||
(window.webpackJsonp=window.webpackJsonp||[]).push([[0],{136:function(e,t,s){"use strict";s.r(t);var n=s(0),r=Object(n.a)({},function(){this.$createElement;this._self._c;return this._m(0)},[function(){var e=this.$createElement,t=this._self._c||e;return t("div",{staticClass:"content"},[t("h1",{attrs:{id:"hello-vuepress"}},[t("a",{staticClass:"header-anchor",attrs:{href:"#hello-vuepress","aria-hidden":"true"}},[this._v("#")]),this._v(" Hello VuePress")])])}],!1,null,null,null);t.default=r.exports}}]); |
@ -1,17 +0,0 @@ | |||
<!DOCTYPE html> | |||
<html lang="en-US"> | |||
<head> | |||
<meta charset="utf-8"> | |||
<meta name="viewport" content="width=device-width,initial-scale=1"> | |||
<title>Hello VuePress</title> | |||
<meta name="description" content=""> | |||
<link rel="preload" href="/assets/css/1.styles.c01b7ee3.css" as="style"><link rel="preload" href="/assets/js/app.48f1ff5f.js" as="script"><link rel="preload" href="/assets/js/0.7c2695bf.js" as="script"> | |||
<link rel="stylesheet" href="/assets/css/1.styles.c01b7ee3.css"> | |||
</head> | |||
<body> | |||
<div id="app" data-server-rendered="true"><div class="theme-container no-sidebar"><header class="navbar"><div class="sidebar-button"><svg xmlns="http://www.w3.org/2000/svg" aria-hidden="true" role="img" viewBox="0 0 448 512" class="icon"><path fill="currentColor" d="M436 124H12c-6.627 0-12-5.373-12-12V80c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12zm0 160H12c-6.627 0-12-5.373-12-12v-32c0-6.627 5.373-12 12-12h424c6.627 0 12 5.373 12 12v32c0 6.627-5.373 12-12 12z"></path></svg></div><a href="/" class="home-link router-link-exact-active router-link-active"></a><div class="links"><div class="search-box"><input aria-label="Search" autocomplete="off" spellcheck="false" value=""><!----></div><!----></div></header><div class="sidebar-mask"></div><div class="sidebar"><!----><!----></div><div class="page"><div class="content"><h1 id="hello-vuepress"><a href="#hello-vuepress" aria-hidden="true" class="header-anchor">#</a> Hello VuePress</h1></div><div class="page-edit"><!----><!----></div><!----></div></div></div> | |||
<script src="/assets/js/0.7c2695bf.js" defer></script><script src="/assets/js/app.48f1ff5f.js" defer></script> | |||
</body> | |||
</html> |
@ -0,0 +1,7 @@ | |||
<svg width="142" height="20" viewBox="0 0 142 20" fill="none" xmlns="http://www.w3.org/2000/svg"> | |||
<path d="M33.5369 19.2904H35.9969V7.57038H40.4569V5.29038H29.0769V7.57038H33.5369V19.2904ZM45.3214 19.5304C47.2614 19.5304 48.6414 18.7504 49.6414 17.5504L48.2214 16.2904C47.3814 17.1104 46.5414 17.5504 45.3614 17.5504C43.8014 17.5504 42.5814 16.5904 42.3214 14.8704H50.0814C50.1014 14.6304 50.1214 14.4104 50.1214 14.1904C50.1214 11.1504 48.4214 8.51038 45.0614 8.51038C42.0414 8.51038 39.9014 10.9904 39.9014 14.0104V14.0504C39.9014 17.3104 42.2614 19.5304 45.3214 19.5304ZM42.3014 13.2704C42.5214 11.6304 43.5614 10.4904 45.0414 10.4904C46.6414 10.4904 47.5614 11.7104 47.7214 13.2704H42.3014ZM52.5317 19.2904H54.9717V13.3304C54.9717 11.6904 55.9517 10.7104 57.3517 10.7104C58.7917 10.7104 59.6117 11.6504 59.6117 13.2904V19.2904H62.0317V12.5504C62.0317 10.1104 60.6517 8.51038 58.2717 8.51038C56.6317 8.51038 55.6517 9.37038 54.9717 10.3504V8.73038H52.5317V19.2904ZM69.3141 19.5104C71.0341 19.5104 72.1341 18.6304 72.9141 17.5304V19.2904H75.3341V4.69038H72.9141V10.3704C72.1541 9.37038 71.0541 8.51038 69.3141 8.51038C66.7941 8.51038 64.4141 10.4904 64.4141 13.9904V14.0304C64.4141 17.5304 66.8341 19.5104 69.3141 19.5104ZM69.8941 17.4104C68.2541 17.4104 66.8541 16.0704 66.8541 14.0304V13.9904C66.8541 11.9104 68.2341 10.6104 69.8941 10.6104C71.5141 10.6104 72.9541 11.9504 72.9541 13.9904V14.0304C72.9541 16.0504 71.5141 17.4104 69.8941 17.4104ZM83.212 19.5304C85.152 19.5304 86.532 18.7504 87.532 17.5504L86.112 16.2904C85.272 17.1104 84.432 17.5504 83.252 17.5504C81.692 17.5504 80.472 16.5904 80.212 14.8704H87.972C87.992 14.6304 88.012 14.4104 88.012 14.1904C88.012 11.1504 86.312 8.51038 82.952 8.51038C79.932 8.51038 77.792 10.9904 77.792 14.0104V14.0504C77.792 17.3104 80.152 19.5304 83.212 19.5304ZM80.192 13.2704C80.412 11.6304 81.452 10.4904 82.932 10.4904C84.532 10.4904 85.452 11.7104 85.612 13.2704H80.192ZM90.4223 19.2904H92.8623V15.2704C92.8623 12.4704 94.3423 11.0904 96.4623 11.0904H96.6023V8.53038C94.7423 8.45038 93.5223 9.53038 92.8623 11.1104V8.73038H90.4223V19.2904ZM98.6841 19.2904H101.124V13.3304C101.124 11.7104 102.044 10.7104 103.384 10.7104C104.724 10.7104 105.524 11.6304 105.524 13.2704V19.2904H107.944V13.3304C107.944 11.6304 108.884 10.7104 110.204 10.7104C111.564 10.7104 112.344 11.6104 112.344 13.2904V19.2904H114.764V12.5504C114.764 9.97038 113.364 8.51038 111.064 8.51038C109.464 8.51038 108.344 9.25038 107.504 10.3704C106.944 9.25038 105.864 8.51038 104.344 8.51038C102.724 8.51038 101.804 9.39038 101.124 10.3304V8.73038H98.6841V19.2904ZM117.728 7.11038H120.328V4.81038H117.728V7.11038ZM117.808 19.2904H120.248V8.73038H117.808V19.2904ZM123.391 19.2904H125.831V13.3304C125.831 11.6904 126.811 10.7104 128.211 10.7104C129.651 10.7104 130.471 11.6504 130.471 13.2904V19.2904H132.891V12.5504C132.891 10.1104 131.511 8.51038 129.131 8.51038C127.491 8.51038 126.511 9.37038 125.831 10.3504V8.73038H123.391V19.2904ZM139.353 19.4704C140.273 19.4704 140.933 19.2704 141.533 18.9304V16.9504C141.053 17.1904 140.573 17.3104 140.033 17.3104C139.213 17.3104 138.733 16.9304 138.733 15.9904V10.8104H141.573V8.73038H138.733V5.83038H136.313V8.73038H134.973V10.8104H136.313V16.3704C136.313 18.6904 137.573 19.4704 139.353 19.4704Z" fill="white" /> | |||
<path fill-rule="evenodd" clip-rule="evenodd" d="M14.8359 8.62449C13.6297 8.17373 12.3308 7.93828 11.0189 7.93828C8.26156 7.93828 5.66799 8.96445 3.71603 10.8277C1.77253 12.6827 0.692757 15.1469 0.675382 17.7662L0.67308 18.1179L0.995493 18.2917C2.54939 19.1298 4.30666 19.5708 6.08735 19.5708C6.13631 19.5708 6.18567 19.5704 6.23475 19.5697C7.78697 19.5486 9.32263 19.1947 10.7148 18.5417C10.2758 18.3089 9.85515 18.0468 9.45524 17.7578C7.02864 18.664 4.27847 18.5523 1.95105 17.4173C2.17744 12.8209 6.16956 9.13899 11.0189 9.13899C12.3676 9.13899 13.6998 9.42181 14.903 9.95924C14.9185 9.51427 14.8962 9.06826 14.8359 8.62449" fill="white" /> | |||
<path fill-rule="evenodd" clip-rule="evenodd" d="M21.3623 17.6846C21.3253 14.4281 19.6525 11.4569 16.864 9.64708C16.8661 10.1236 16.8325 10.5998 16.7635 11.0733C18.7449 12.6069 19.9528 14.8652 20.085 17.3394C15.8109 19.4271 10.4806 17.965 8.05257 13.9755C7.39676 12.8979 6.99466 11.693 6.87649 10.4619C6.46399 10.6752 6.07001 10.9205 5.69806 11.1956C5.89419 12.3803 6.32039 13.5309 6.95641 14.5759C8.33758 16.8453 10.5581 18.4723 13.2087 19.1571C14.108 19.3895 15.0224 19.5045 15.9317 19.5045C17.7034 19.5045 19.4562 19.068 21.0421 18.213L21.3662 18.0382L21.3623 17.6846Z" fill="white" /> | |||
<path fill-rule="evenodd" clip-rule="evenodd" d="M11.3845 1.1535L11.0648 0.975742L10.745 1.15323C9.16521 2.02964 7.85272 3.28619 6.94934 4.78692C6.16925 6.08298 5.70784 7.5348 5.59962 9.01676C6.0321 8.77307 6.48263 8.55879 6.94848 8.37569C7.34977 5.93272 8.84843 3.72483 11.0642 2.37561C15.1338 4.85607 16.4721 9.999 14.0276 14.0154C13.3657 15.1031 12.4605 16.0436 11.3882 16.7656C11.7887 16.9971 12.2093 17.1981 12.6463 17.3662C13.6376 16.6043 14.4816 15.671 15.1238 14.6157C17.9778 9.92641 16.3003 3.88731 11.3845 1.1535" fill="white" /> | |||
<path fill-rule="evenodd" clip-rule="evenodd" d="M11.0584 11.4001C10.4754 11.4001 10.0012 11.85 10.0012 12.4031C10.0012 12.9561 10.4754 13.4061 11.0584 13.4061C11.6415 13.4061 12.1158 12.9561 12.1158 12.4031C12.1158 11.85 11.6415 11.4001 11.0584 11.4001M11.0584 14.6068C9.77747 14.6068 8.73544 13.6183 8.73544 12.4031C8.73544 11.188 9.77747 10.1994 11.0584 10.1994C12.3394 10.1994 13.3815 11.188 13.3815 12.4031C13.3815 13.6183 12.3394 14.6068 11.0584 14.6068" fill="white" /> | |||
</svg> |
@ -0,0 +1,3 @@ | |||
:root | |||
--accent-color #00BB00 | |||
--background #222222 |
@ -0,0 +1,7 @@ | |||
--- | |||
order: false | |||
parent: | |||
order: 3 | |||
--- | |||
# Apps |
@ -0,0 +1,7 @@ | |||
--- | |||
order: false | |||
parent: | |||
order: 2 | |||
--- | |||
# Guides |
@ -0,0 +1,4 @@ | |||
--- | |||
parent: | |||
order: false | |||
--- |
@ -1,334 +0,0 @@ | |||
# What is Tendermint? | |||
DEPRECATED! See [What is Tendermint?](what-is-tendermint.md). | |||
Tendermint is software for securely and consistently replicating an | |||
application on many machines. By securely, we mean that Tendermint works | |||
even if up to 1/3 of machines fail in arbitrary ways. By consistently, | |||
we mean that every non-faulty machine sees the same transaction log and | |||
computes the same state. Secure and consistent replication is a | |||
fundamental problem in distributed systems; it plays a critical role in | |||
the fault tolerance of a broad range of applications, from currencies, | |||
to elections, to infrastructure orchestration, and beyond. | |||
The ability to tolerate machines failing in arbitrary ways, including | |||
becoming malicious, is known as Byzantine fault tolerance (BFT). The | |||
theory of BFT is decades old, but software implementations have only | |||
became popular recently, due largely to the success of "blockchain | |||
technology" like Bitcoin and Ethereum. Blockchain technology is just a | |||
reformalization of BFT in a more modern setting, with emphasis on | |||
peer-to-peer networking and cryptographic authentication. The name | |||
derives from the way transactions are batched in blocks, where each | |||
block contains a cryptographic hash of the previous one, forming a | |||
chain. In practice, the blockchain data structure actually optimizes BFT | |||
design. | |||
Tendermint consists of two chief technical components: a blockchain | |||
consensus engine and a generic application interface. The consensus | |||
engine, called Tendermint Core, ensures that the same transactions are | |||
recorded on every machine in the same order. The application interface, | |||
called the Application BlockChain Interface (ABCI), enables the | |||
transactions to be processed in any programming language. Unlike other | |||
blockchain and consensus solutions, which come pre-packaged with built | |||
in state machines (like a fancy key-value store, or a quirky scripting | |||
language), developers can use Tendermint for BFT state machine | |||
replication of applications written in whatever programming language and | |||
development environment is right for them. | |||
Tendermint is designed to be easy-to-use, simple-to-understand, highly | |||
performant, and useful for a wide variety of distributed applications. | |||
## Tendermint vs. X | |||
Tendermint is broadly similar to two classes of software. The first | |||
class consists of distributed key-value stores, like Zookeeper, etcd, | |||
and consul, which use non-BFT consensus. The second class is known as | |||
"blockchain technology", and consists of both cryptocurrencies like | |||
Bitcoin and Ethereum, and alternative distributed ledger designs like | |||
Hyperledger's Burrow. | |||
### Zookeeper, etcd, consul | |||
Zookeeper, etcd, and consul are all implementations of a key-value store | |||
atop a classical, non-BFT consensus algorithm. Zookeeper uses a version | |||
of Paxos called Zookeeper Atomic Broadcast, while etcd and consul use | |||
the Raft consensus algorithm, which is much younger and simpler. A | |||
typical cluster contains 3-5 machines, and can tolerate crash failures | |||
in up to 1/2 of the machines, but even a single Byzantine fault can | |||
destroy the system. | |||
Each offering provides a slightly different implementation of a | |||
featureful key-value store, but all are generally focused around | |||
providing basic services to distributed systems, such as dynamic | |||
configuration, service discovery, locking, leader-election, and so on. | |||
Tendermint is in essence similar software, but with two key differences: | |||
- It is Byzantine Fault Tolerant, meaning it can only tolerate up to a | |||
1/3 of failures, but those failures can include arbitrary behaviour - | |||
including hacking and malicious attacks. - It does not specify a | |||
particular application, like a fancy key-value store. Instead, it | |||
focuses on arbitrary state machine replication, so developers can build | |||
the application logic that's right for them, from key-value store to | |||
cryptocurrency to e-voting platform and beyond. | |||
The layout of this Tendermint website content is also ripped directly | |||
and without shame from [consul.io](https://www.consul.io/) and the other | |||
[Hashicorp sites](https://www.hashicorp.com/#tools). | |||
### Bitcoin, Ethereum, etc. | |||
Tendermint emerged in the tradition of cryptocurrencies like Bitcoin, | |||
Ethereum, etc. with the goal of providing a more efficient and secure | |||
consensus algorithm than Bitcoin's Proof of Work. In the early days, | |||
Tendermint had a simple currency built in, and to participate in | |||
consensus, users had to "bond" units of the currency into a security | |||
deposit which could be revoked if they misbehaved -this is what made | |||
Tendermint a Proof-of-Stake algorithm. | |||
Since then, Tendermint has evolved to be a general purpose blockchain | |||
consensus engine that can host arbitrary application states. That means | |||
it can be used as a plug-and-play replacement for the consensus engines | |||
of other blockchain software. So one can take the current Ethereum code | |||
base, whether in Rust, or Go, or Haskell, and run it as a ABCI | |||
application using Tendermint consensus. Indeed, [we did that with | |||
Ethereum](https://github.com/cosmos/ethermint). And we plan to do | |||
the same for Bitcoin, ZCash, and various other deterministic | |||
applications as well. | |||
Another example of a cryptocurrency application built on Tendermint is | |||
[the Cosmos network](http://cosmos.network). | |||
### Other Blockchain Projects | |||
[Fabric](https://github.com/hyperledger/fabric) takes a similar approach | |||
to Tendermint, but is more opinionated about how the state is managed, | |||
and requires that all application behaviour runs in potentially many | |||
docker containers, modules it calls "chaincode". It uses an | |||
implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). | |||
from a team at IBM that is [augmented to handle potentially | |||
non-deterministic | |||
chaincode](https://www.zurich.ibm.com/~cca/papers/sieve.pdf) It is | |||
possible to implement this docker-based behaviour as a ABCI app in | |||
Tendermint, though extending Tendermint to handle non-determinism | |||
remains for future work. | |||
[Burrow](https://github.com/hyperledger/burrow) is an implementation of | |||
the Ethereum Virtual Machine and Ethereum transaction mechanics, with | |||
additional features for a name-registry, permissions, and native | |||
contracts, and an alternative blockchain API. It uses Tendermint as its | |||
consensus engine, and provides a particular application state. | |||
## ABCI Overview | |||
The [Application BlockChain Interface | |||
(ABCI)](https://github.com/tendermint/tendermint/tree/master/abci) | |||
allows for Byzantine Fault Tolerant replication of applications | |||
written in any programming language. | |||
### Motivation | |||
Thus far, all blockchains "stacks" (such as | |||
[Bitcoin](https://github.com/bitcoin/bitcoin)) have had a monolithic | |||
design. That is, each blockchain stack is a single program that handles | |||
all the concerns of a decentralized ledger; this includes P2P | |||
connectivity, the "mempool" broadcasting of transactions, consensus on | |||
the most recent block, account balances, Turing-complete contracts, | |||
user-level permissions, etc. | |||
Using a monolithic architecture is typically bad practice in computer | |||
science. It makes it difficult to reuse components of the code, and | |||
attempts to do so result in complex maintenance procedures for forks of | |||
the codebase. This is especially true when the codebase is not modular | |||
in design and suffers from "spaghetti code". | |||
Another problem with monolithic design is that it limits you to the | |||
language of the blockchain stack (or vice versa). In the case of | |||
Ethereum which supports a Turing-complete bytecode virtual-machine, it | |||
limits you to languages that compile down to that bytecode; today, those | |||
are Serpent and Solidity. | |||
In contrast, our approach is to decouple the consensus engine and P2P | |||
layers from the details of the application state of the particular | |||
blockchain application. We do this by abstracting away the details of | |||
the application to an interface, which is implemented as a socket | |||
protocol. | |||
Thus we have an interface, the Application BlockChain Interface (ABCI), | |||
and its primary implementation, the Tendermint Socket Protocol (TSP, or | |||
Teaspoon). | |||
### Intro to ABCI | |||
[Tendermint Core](https://github.com/tendermint/tendermint) (the | |||
"consensus engine") communicates with the application via a socket | |||
protocol that satisfies the ABCI. | |||
To draw an analogy, lets talk about a well-known cryptocurrency, | |||
Bitcoin. Bitcoin is a cryptocurrency blockchain where each node | |||
maintains a fully audited Unspent Transaction Output (UTXO) database. If | |||
one wanted to create a Bitcoin-like system on top of ABCI, Tendermint | |||
Core would be responsible for | |||
- Sharing blocks and transactions between nodes | |||
- Establishing a canonical/immutable order of transactions | |||
(the blockchain) | |||
The application will be responsible for | |||
- Maintaining the UTXO database | |||
- Validating cryptographic signatures of transactions | |||
- Preventing transactions from spending non-existent transactions | |||
- Allowing clients to query the UTXO database. | |||
Tendermint is able to decompose the blockchain design by offering a very | |||
simple API (ie. the ABCI) between the application process and consensus | |||
process. | |||
The ABCI consists of 3 primary message types that get delivered from the | |||
core to the application. The application replies with corresponding | |||
response messages. | |||
The messages are specified here: [ABCI Message | |||
Types](https://github.com/tendermint/tendermint/blob/master/abci/README.md#message-types). | |||
The **DeliverTx** message is the work horse of the application. Each | |||
transaction in the blockchain is delivered with this message. The | |||
application needs to validate each transaction received with the | |||
**DeliverTx** message against the current state, application protocol, | |||
and the cryptographic credentials of the transaction. A validated | |||
transaction then needs to update the application state — by binding a | |||
value into a key values store, or by updating the UTXO database, for | |||
instance. | |||
The **CheckTx** message is similar to **DeliverTx**, but it's only for | |||
validating transactions. Tendermint Core's mempool first checks the | |||
validity of a transaction with **CheckTx**, and only relays valid | |||
transactions to its peers. For instance, an application may check an | |||
incrementing sequence number in the transaction and return an error upon | |||
**CheckTx** if the sequence number is old. Alternatively, they might use | |||
a capabilities based system that requires capabilities to be renewed | |||
with every transaction. | |||
The **Commit** message is used to compute a cryptographic commitment to | |||
the current application state, to be placed into the next block header. | |||
This has some handy properties. Inconsistencies in updating that state | |||
will now appear as blockchain forks which catches a whole class of | |||
programming errors. This also simplifies the development of secure | |||
lightweight clients, as Merkle-hash proofs can be verified by checking | |||
against the block hash, and that the block hash is signed by a quorum. | |||
There can be multiple ABCI socket connections to an application. | |||
Tendermint Core creates three ABCI connections to the application; one | |||
for the validation of transactions when broadcasting in the mempool, one | |||
for the consensus engine to run block proposals, and one more for | |||
querying the application state. | |||
It's probably evident that applications designers need to very carefully | |||
design their message handlers to create a blockchain that does anything | |||
useful but this architecture provides a place to start. The diagram | |||
below illustrates the flow of messages via ABCI. | |||
![](../imgs/abci.png) | |||
## A Note on Determinism | |||
The logic for blockchain transaction processing must be deterministic. | |||
If the application logic weren't deterministic, consensus would not be | |||
reached among the Tendermint Core replica nodes. | |||
Solidity on Ethereum is a great language of choice for blockchain | |||
applications because, among other reasons, it is a completely | |||
deterministic programming language. However, it's also possible to | |||
create deterministic applications using existing popular languages like | |||
Java, C++, Python, or Go. Game programmers and blockchain developers are | |||
already familiar with creating deterministic programs by avoiding | |||
sources of non-determinism such as: | |||
- random number generators (without deterministic seeding) | |||
- race conditions on threads (or avoiding threads altogether) | |||
- the system clock | |||
- uninitialized memory (in unsafe programming languages like C | |||
or C++) | |||
- [floating point | |||
arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/) | |||
- language features that are random (e.g. map iteration in Go) | |||
While programmers can avoid non-determinism by being careful, it is also | |||
possible to create a special linter or static analyzer for each language | |||
to check for determinism. In the future we may work with partners to | |||
create such tools. | |||
## Consensus Overview | |||
Tendermint is an easy-to-understand, mostly asynchronous, BFT consensus | |||
protocol. The protocol follows a simple state machine that looks like | |||
this: | |||
![](../imgs/consensus_logic.png) | |||
Participants in the protocol are called **validators**; they take turns | |||
proposing blocks of transactions and voting on them. Blocks are | |||
committed in a chain, with one block at each **height**. A block may | |||
fail to be committed, in which case the protocol moves to the next | |||
**round**, and a new validator gets to propose a block for that height. | |||
Two stages of voting are required to successfully commit a block; we | |||
call them **pre-vote** and **pre-commit**. A block is committed when | |||
more than 2/3 of validators pre-commit for the same block in the same | |||
round. | |||
There is a picture of a couple doing the polka because validators are | |||
doing something like a polka dance. When more than two-thirds of the | |||
validators pre-vote for the same block, we call that a **polka**. Every | |||
pre-commit must be justified by a polka in the same round. | |||
Validators may fail to commit a block for a number of reasons; the | |||
current proposer may be offline, or the network may be slow. Tendermint | |||
allows them to establish that a validator should be skipped. Validators | |||
wait a small amount of time to receive a complete proposal block from | |||
the proposer before voting to move to the next round. This reliance on a | |||
timeout is what makes Tendermint a weakly synchronous protocol, rather | |||
than an asynchronous one. However, the rest of the protocol is | |||
asynchronous, and validators only make progress after hearing from more | |||
than two-thirds of the validator set. A simplifying element of | |||
Tendermint is that it uses the same mechanism to commit a block as it | |||
does to skip to the next round. | |||
Assuming less than one-third of the validators are Byzantine, Tendermint | |||
guarantees that safety will never be violated - that is, validators will | |||
never commit conflicting blocks at the same height. To do this it | |||
introduces a few **locking** rules which modulate which paths can be | |||
followed in the flow diagram. Once a validator precommits a block, it is | |||
locked on that block. Then, | |||
1. it must prevote for the block it is locked on | |||
2. it can only unlock, and precommit for a new block, if there is a | |||
polka for that block in a later round | |||
## Stake | |||
In many systems, not all validators will have the same "weight" in the | |||
consensus protocol. Thus, we are not so much interested in one-third or | |||
two-thirds of the validators, but in those proportions of the total | |||
voting power, which may not be uniformly distributed across individual | |||
validators. | |||
Since Tendermint can replicate arbitrary applications, it is possible to | |||
define a currency, and denominate the voting power in that currency. | |||
When voting power is denominated in a native currency, the system is | |||
often referred to as Proof-of-Stake. Validators can be forced, by logic | |||
in the application, to "bond" their currency holdings in a security | |||
deposit that can be destroyed if they're found to misbehave in the | |||
consensus protocol. This adds an economic element to the security of the | |||
protocol, allowing one to quantify the cost of violating the assumption | |||
that less than one-third of voting power is Byzantine. | |||
The [Cosmos Network](https://cosmos.network) is designed to use this | |||
Proof-of-Stake mechanism across an array of cryptocurrencies implemented | |||
as ABCI applications. | |||
The following diagram is Tendermint in a (technical) nutshell. [See here | |||
for high resolution | |||
version](https://github.com/mobfoundry/hackatom/blob/master/tminfo.pdf). | |||
![](../imgs/tm-transaction-flow.png) |
@ -1,83 +0,0 @@ | |||
# Deploy a Testnet | |||
DEPRECATED DOCS! | |||
See [Networks](../networks). | |||
## Manual Deployments | |||
It's relatively easy to setup a Tendermint cluster manually. The only | |||
requirements for a particular Tendermint node are a private key for the | |||
validator, stored as `priv_validator.json`, a node key, stored as | |||
`node_key.json` and a list of the public keys of all validators, stored | |||
as `genesis.json`. These files should be stored in | |||
`~/.tendermint/config`, or wherever the `$TMHOME` variable might be set | |||
to. | |||
Here are the steps to setting up a testnet manually: | |||
1. Provision nodes on your cloud provider of choice | |||
2. Install Tendermint and the application of interest on all nodes | |||
3. Generate a private key and a node key for each validator using | |||
`tendermint init` | |||
4. Compile a list of public keys for each validator into a | |||
new `genesis.json` file and replace the existing file with it. | |||
5. Get the node IDs of any peers you want other peers to connect to by | |||
running `tendermint show_node_id` on the relevant machine | |||
6. Set the `p2p.persistent_peers` in the config for all nodes to the comma | |||
separated list of `ID@IP:PORT` for all nodes. Default port is 26656. | |||
Then start the node | |||
``` | |||
tendermint node --proxy_app=kvstore | |||
``` | |||
After a few seconds, all the nodes should connect to each other and | |||
start making blocks! For more information, see the Tendermint Networks | |||
section of [the guide to using Tendermint](../tendermint-core/using-tendermint.md). | |||
But wait! Steps 3, 4 and 5 are quite manual. Instead, use the `tendermint testnet` command. By default, running `tendermint testnet` will create all the | |||
required files, but it won't populate the list of persistent peers. It will do | |||
it however if you provide the `--populate-persistent-peers` flag and optional | |||
`--starting-ip-address` flag. Run `tendermint testnet --help` for more details | |||
on the available flags. | |||
``` | |||
tendermint testnet --populate-persistent-peers --starting-ip-address 192.168.0.1 | |||
``` | |||
This command will generate four folders, prefixed with "node" and put them into | |||
the "./mytestnet" directory by default. | |||
As you might imagine, this command is useful for manual or automated | |||
deployments. | |||
## Automated Deployments | |||
The easiest and fastest way to get a testnet up in less than 5 minutes. | |||
### Local | |||
With `docker` and `docker-compose` installed, run the command: | |||
``` | |||
make localnet-start | |||
``` | |||
from the root of the tendermint repository. This will spin up a 4-node | |||
local testnet. Note that this command expects a linux binary in the build directory. | |||
If you built the binary using a non-linux OS, you may see | |||
the error `Binary needs to be OS linux, ARCH amd64`, in which case you can | |||
run: | |||
``` | |||
make build-linux | |||
make localnet-start | |||
``` | |||
Review the target in the Makefile to debug any problems. | |||
### Cloud | |||
See the [next section](./terraform-and-ansible.md) for details. |
@ -0,0 +1,20 @@ | |||
{ | |||
"name": "docs", | |||
"version": "1.0.0", | |||
"description": "Welcome to the Tendermint Core documentation!", | |||
"main": "index.js", | |||
"dependencies": { | |||
"vuepress-theme-cosmos": "^1.0.24" | |||
}, | |||
"devDependencies": {}, | |||
"scripts": { | |||
"preserve": "./pre.sh", | |||
"serve": "trap 'exit 0' SIGINT; vuepress dev", | |||
"postserve": "./post.sh", | |||
"prebuild": "./pre.sh", | |||
"build": "trap 'exit 0' SIGINT; vuepress build", | |||
"postbuild": "./post.sh" | |||
}, | |||
"author": "", | |||
"license": "ISC" | |||
} |
@ -0,0 +1,3 @@ | |||
#!/bin/bash | |||
rm -rf ./.vuepress/public/rpc |
@ -0,0 +1,3 @@ | |||
#!/bin/bash | |||
cp -a ../rpc/swagger/ .vuepress/public/rpc/ |
@ -0,0 +1 @@ | |||
# README in russian |
@ -0,0 +1,5 @@ | |||
--- | |||
cards: true | |||
--- | |||
# Blockchain |
@ -1 +1,3 @@ | |||
# ABCI | |||
[Moved](../software/abci.md) |
@ -0,0 +1,5 @@ | |||
--- | |||
cards: true | |||
--- | |||
# Consensus |
@ -0,0 +1,5 @@ | |||
--- | |||
cards: true | |||
--- | |||
# P2P |
@ -0,0 +1,5 @@ | |||
--- | |||
cards: true | |||
--- | |||
# Reactors |
@ -1,4 +1,10 @@ | |||
--- | |||
order: 1 | |||
parent: | |||
title: Tendermint Core | |||
order: 4 | |||
--- | |||
# Overview | |||
See the side-bar for details on the various features of Tendermint Core. | |||
@ -1,7 +1,14 @@ | |||
--- | |||
order: 1 | |||
parent: | |||
title: Tools | |||
order: 6 | |||
--- | |||
# Overview | |||
Tendermint comes with some tools for: | |||
* [Benchmarking](./benchmarking.md) | |||
* [Monitoring](./monitoring.md) | |||
* [Validation of remote signers](./remote-signer-validation.md) | |||
- [Benchmarking](./benchmarking.md) | |||
- [Monitoring](./monitoring.md) | |||
- [Validation of remote signers](./remote-signer-validation.md) |
@ -0,0 +1 @@ | |||
master |