mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-03-27 12:05:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

consensus reactor

Browse Source
This commit is contained in:
Josef Widder
2022-12-05 14:03:54 +01:00
parent 0fbeaaf0a3
commit e3fd2cfd3d
1 changed files with 28 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
spec/p2p/p2p-top-level.md
View File

@@ -5,6 +5,8 @@
<!--- > Rough outline of what the component is doing and why. 2-3 paragraphs
--->
> Perhaps this should go into a separate document on Tendermint architecture.
The Tendermint consists of multiple protocols, namely,
- Consensus
- Mempool
@@ -19,10 +21,11 @@ that each plays a role in making sure that validators can produce blocks. These
- Communication. Implement the communication abstractions needed by the protocol on top of the p2p system (e.g., Gossip)
> perhaps we should clarify nomenclature: the Consensus gossip service actually is not implemented by a gossip algorithm but a peer-to-peer system
Tendermint (as many classic BFT algorithms) have an all-to-all communication pattern (e.g., every validator sends a `precommit` to every other full node). Naive implementations, e.g., maintaining a channel between each of the *N* validators is not scaling to the system sizes of typical Cosmos blockchains (e.g., N = 200 validator nodes + seed nodes + sentry nodes + other full nodes). There is the fundamental necessity to restrict the communication. There is another explicit requirement which is called "deployment flexibility", which means that we do not want to impose a completely-connected network (also for safety concerns).
The p2p system maintains an overlay network that should satisfy a list of requirements (connectivity, stability, diversity in geographical peers) that are inherited from the communication needs of the reactors.
The design decision is to use an overlay network. Instead of having *N* connections, each node only maintains a relatively small number. In principle, this allows to implement more efficient communication (e.g., gossiping), provided that with this small number of connections per node, the system as a whole stays connected. This overlay network
is established by the **peer-to-peer system (p2p)**, which is composed of the p2p layers of the participating nodes that locally decide with which peers a node keeps connections.
GOAL: what are the consequences of the choices in the config file
@@ -93,8 +96,21 @@ these tags we frequently use the following short forms:
# Part I - A Tendermint node
TODO:
- we should survey here what we think are the expectations of the reactors from p2p?
We survey the communication protocols within the reactors. These should inform the requirements of the p2p layer
## Consensus reactor
#### [TM-REQ-CR-GOSIP.0]
The consensus protocol is based on the "gossip" property: every message delivered by a correct process (after stabilization time) is received by every correct process within bounded time.
ß
#### [TM-REQ-CR-COMM.0]
Gossiping is done by surveying the peers' states within the consensus protocol. The information of peer *p* tells us what consensus messages *p* is waiting for.
#### [TM-REQ-CR-CONNECT.0]
- consensus might need
- for liveness that neighborhood is stable
- proposers are not disconnected?
@@ -297,6 +313,13 @@ a section called "Analysis"
# Old text
Tendermint (as many classic BFT algorithms) have an all-to-all communication pattern (e.g., every validator sends a `precommit` to every other full node). Naive implementations, e.g., maintaining a channel between each of the *N* validators is not scaling to the system sizes of typical Cosmos blockchains (e.g., N = 200 validator nodes + seed nodes + sentry nodes + other full nodes). There is the fundamental necessity to restrict the communication. There is another explicit requirement which is called "deployment flexibility", which means that we do not want to impose a completely-connected network (also for safety concerns).
The design decision is to use an overlay network. Instead of having *N* connections, each node only maintains a relatively small number. In principle, this allows to implement more efficient communication (e.g., gossiping), provided that with this small number of connections per node, the system as a whole stays connected. This overlay network
is established by the **peer-to-peer system (p2p)**, which is composed of the p2p layers of the participating nodes that locally decide with which peers a node keeps connections.
# References