Rename Tendermint to CometBFT in /spec (backport #143) (#185)

* Rename Tendermint to CometBFT in /spec (#143) * spec: renaming Tendermint to CometBFT * CometBFT's consensus protocol is called Tendermint, so this use has been preserved. * spec: initial renaming Tendermint to CometBFT * spec: renaming Tendermint to CometBFT in /spec/p2p * spec/rename: links to CometBFT repo in /spec/ * spec/rename: repository links in /spec/light-client * spec/rename: Tendermint to CometBFT in /spec/abci * spec/rename: further renaming of links * spec/rename: Tendermint consensus protocol of CometBFT * spec/rename: Tendermint -> CometBFT Socket Protocol * spec/rename: Tendermint as a consensus algorithm * spec/rename: replacing some Go documentation links * spec/rename: TMHOME -> CMTHOME, go-amino removed * spec/rename: Tendermint -> Cosmos blockchain * Also applies for full node, light node, security and failure model * spec/rename: tags renamed TMBC -> CMBC * spec: renaming Tendermint to CometBFT * CometBFT's consensus protocol is called Tendermint, so this use has been preserved. * spec: initial renaming Tendermint to CometBFT * spec: renaming Tendermint to CometBFT in /spec/p2p * spec/rename: links to CometBFT repo in /spec/ * spec/rename: repository links in /spec/light-client * spec/rename: Tendermint to CometBFT in /spec/abci * spec/rename: further renaming of links * spec/rename: Tendermint consensus protocol of CometBFT * spec/rename: Tendermint -> CometBFT Socket Protocol * spec/rename: Tendermint as a consensus algorithm * spec/rename: replacing some Go documentation links * spec/rename: TMHOME -> CMTHOME, go-amino removed * spec/rename: Tendermint -> Cosmos blockchain * Also applies for full node, light node, security and failure model * spec/rename: tags renamed TMBC -> CMBC * spec/rename: Tendermint -> Cosmos security model * spec/rename: fixing mismatch CometBFT/Tendermint/consensus * spec/rename: Apply suggestions from code review Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Sergio Mena <sergio@informal.systems> (cherry picked from commit a36697d) * spec/p2p/v0.34: synchronizing main and v0.34.x branches * spec/rename: aligning branches main and v0.34.x * spec/rename: update branch links main -> v0.34.x * Apply suggestions from code review Co-authored-by: Sergio Mena <sergio@informal.systems> Co-authored-by: Daniel <daniel.cason@informal.systems> Co-authored-by: Sergio Mena <sergio@informal.systems>
celestiaorg · Jan 25, 2023 · ff4360b · ff4360b
1 parent 6b02109
commit ff4360b
Show file tree

Hide file tree

Showing 76 changed files with 2,279 additions and 614 deletions.
diff --git a/spec/README.md b/spec/README.md
@@ -6,15 +6,15 @@ parent:
   order: 7
 ---
 
-# Tendermint Spec
+# CometBFT Spec
 
-This is a markdown specification of the Tendermint blockchain.
+This is a markdown specification of CometBFT.
 It defines the base data structures, how they are validated,
 and how they are communicated over the network.
 
 If you find discrepancies between the spec and the code that
 do not have an associated issue or pull request on github,
-please submit them to our [bug bounty](https://tendermint.com/security)!
+please submit them to our [bug bounty](https://cometbft.com/security)!
 
 ## Contents
 
@@ -44,7 +44,7 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
 
 ### RPC
 
-- [RPC SPEC](./rpc/README.md): Specification of the Tendermint remote procedure call interface.
+- [RPC SPEC](./rpc/README.md): Specification of the CometBFT remote procedure call interface.
 
 ### Software
 
@@ -55,19 +55,19 @@ please submit them to our [bug bounty](https://tendermint.com/security)!
 
 ## Overview
 
-Tendermint provides Byzantine Fault Tolerant State Machine Replication using
+CometBFT provides Byzantine Fault Tolerant State Machine Replication using
 hash-linked batches of transactions. Such transaction batches are called "blocks".
-Hence, Tendermint defines a "blockchain".
+Hence, CometBFT defines a "blockchain".
 
-Each block in Tendermint has a unique index - its Height.
+Each block in CometBFT has a unique index - its Height.
 Height's in the blockchain are monotonic.
 Each block is committed by a known set of weighted Validators.
 Membership and weighting within this validator set may change over time.
-Tendermint guarantees the safety and liveness of the blockchain
+CometBFT guarantees the safety and liveness of the blockchain
 so long as less than 1/3 of the total weight of the Validator set
 is malicious or faulty.
 
-A commit in Tendermint is a set of signed messages from more than 2/3 of
+A commit in CometBFT is a set of signed messages from more than 2/3 of
 the total weight of the current Validator set. Validators take turns proposing
 blocks and voting on them. Once enough votes are received, the block is considered
 committed. These votes are included in the _next_ block as proof that the previous block
@@ -79,7 +79,7 @@ The application returns results for each of the transactions in the block.
 The application can also return changes to be made to the validator set,
 as well as a cryptographic digest of its latest state.
 
-Tendermint is designed to enable efficient verification and authentication
+CometBFT is designed to enable efficient verification and authentication
 of the latest state of the blockchain. To achieve this, it embeds
 cryptographic commitments to certain information in the block "header".
 This information includes the contents of the block (eg. the transactions),

diff --git a/spec/abci/README.md b/spec/abci/README.md
@@ -14,7 +14,7 @@ _methods_, each with a corresponding `Request` and `Response`message type.
 To perform state-machine replication, Tendermint calls the ABCI methods on the 
 ABCI application by sending the `Request*` messages and receiving the `Response*` messages in return.
 
-All ABCI messages and methods are defined in [protocol buffers](https://github.com/tendermint/tendermint/blob/v0.34.x/proto/abci/types.proto). 
+All ABCI messages and methods are defined in [protocol buffers](https://github.com/cometbft/cometbft/blob/v0.34.x/proto/abci/types.proto). 
 This allows Tendermint to run with applications written in many programming languages.
 
 This specification is split as follows:

diff --git a/spec/blockchain/readme.md b/spec/blockchain/readme.md
@@ -7,7 +7,7 @@ parent:
 
 # Blockchain
 
-This section describes the core types and functionality of the Tendermint protocol implementation.
+This section describes the core types and functionality of the CometBFT protocol implementation.
 
 [Core Data Structures](../core/data_structures.md)
 [Encoding](../core/encoding.md)

diff --git a/spec/consensus/bft-time.md b/spec/consensus/bft-time.md
@@ -3,8 +3,8 @@ order: 2
 ---
 # BFT Time
 
-Tendermint provides a deterministic, Byzantine fault-tolerant, source of time.
-Time in Tendermint is defined with the Time field of the block header.
+CometBFT provides a deterministic, Byzantine fault-tolerant, source of time.
+Time in CometBFT is defined with the Time field of the block header.
 
 It satisfies the following properties:
 
@@ -15,12 +15,13 @@ valid values for the Time field of the block header is defined only by
 Precommit messages (from the LastCommit field) sent by correct processes, i.e.,
 a faulty process cannot arbitrarily increase the Time value.  
 
-In the context of Tendermint, time is of type int64 and denotes UNIX time in milliseconds, i.e.,
-corresponds to the number of milliseconds since January 1, 1970. Before defining rules that need to be enforced by the
-Tendermint consensus protocol, so the properties above holds, we introduce the following definition:
+In the context of CometBFT, time is of type int64 and denotes UNIX time in milliseconds, i.e.,
+corresponds to the number of milliseconds since January 1, 1970.
+Before defining rules that need to be enforced by Tendermint, the consensus algorithm adopted in CometBFT,
+so the properties above holds, we introduce the following definition:
 
 - median of a Commit is equal to the median of `Vote.Time` fields of the `Vote` messages,
-where the value of `Vote.Time` is counted number of times proportional to the process voting power. As in Tendermint
+where the value of `Vote.Time` is counted number of times proportional to the process voting power. As
 the voting power is not uniform (one process one vote), a vote message is actually an aggregator of the same votes whose
 number is equal to the voting power of the process that has casted the corresponding votes message.
 

diff --git a/spec/consensus/consensus-paper/README.md b/spec/consensus/consensus-paper/README.md
@@ -1,7 +1,7 @@
-# Tendermint-spec
+# Consensus Paper
 
 The repository contains the specification (and the proofs) of the Tendermint
-consensus protocol.
+consensus protocol, adopted in CometBFT.
 
 ## How to install Latex on Mac OS
 

diff --git a/spec/consensus/consensus.md b/spec/consensus/consensus.md
@@ -14,10 +14,8 @@ order: 1
   just "step").
 - A node is said to be _at_ a given height, round, and step, or at
   `(H,R,S)`, or at `(H,R)` in short to omit the step.
-- To _prevote_ or _precommit_ something means to broadcast a [prevote
-  vote](https://godoc.org/github.com/tendermint/tendermint/types#Vote)
-  or [first precommit
-  vote](https://godoc.org/github.com/tendermint/tendermint/types#FirstPrecommit)
+- To _prevote_ or _precommit_ something means to broadcast a prevote
+  or precommit [vote](https://github.com/cometbft/cometbft/blob/af3bc47df982e271d4d340a3c5e0d773e440466d/types/vote.go#L50)
   for something.
 - A vote _at_ `(H,R)` is a vote signed with the bytes for `H` and `R`
   included in its [sign-bytes](../core/data_structures.md#vote).
@@ -108,7 +106,7 @@ example,
 - Nodes gossip prevotes for the proposed PoLC (proof-of-lock-change)
   round if one is proposed.
 - Nodes gossip to nodes lagging in blockchain height with block
-  [commits](https://godoc.org/github.com/tendermint/tendermint/types#Commit)
+  [commits](https://github.com/cometbft/cometbft/blob/af3bc47df982e271d4d340a3c5e0d773e440466d/types/block.go#L738)
   for older blocks.
 - Nodes opportunistically gossip `ReceivedVote` messages to hint peers what
   votes it already has.
@@ -123,7 +121,7 @@ A proposal is signed and published by the designated proposer at each
 round. The proposer is chosen by a deterministic and non-choking round
 robin selection algorithm that selects proposers in proportion to their
 voting power (see
-[implementation](https://github.com/tendermint/tendermint/blob/v0.34.x/types/validator_set.go)).
+[implementation](https://github.com/cometbft/cometbft/blob/v0.34.x/types/validator_set.go#L51)).
 
 A proposal at `(H,R)` is composed of a block and an optional latest
 `PoLC-Round < R` which is included iff the proposer knows of one. This
@@ -285,7 +283,7 @@ tells peers that this node has (or does not have) a +2/3 majority for B
 majority. Peers can react by responding with appropriate votes.
 
 We will implement such an algorithm for the next iteration of the
-Tendermint consensus protocol.
+consensus protocol.
 
 Other potential improvements include adding more data in votes such as
 the last known PoLC round that caused a lock change, and the last voted
@@ -295,7 +293,7 @@ may make JSet verification/gossip logic easier to implement.
 ### Censorship Attacks
 
 Due to the definition of a block
-[commit](https://github.com/tendermint/tendermint/blob/v0.34.x/docs/tendermint-core/validators.md), any 1/3+ coalition of
+[commit](https://github.com/cometbft/cometbft/blob/v0.34.x/docs/tendermint-core/validators.md), any 1/3+ coalition of
 validators can halt the blockchain by not broadcasting their votes. Such
 a coalition can also censor particular transactions by rejecting blocks
 that include these transactions, though this would result in a

diff --git a/spec/consensus/evidence.md b/spec/consensus/evidence.md
@@ -1,11 +1,11 @@
 # Evidence
 
-Evidence is an important component of Tendermint's security model. Whilst the core
+Evidence is an important component of CometBFT's security model. Whilst the core
 consensus protocol provides correctness gaurantees for state machine replication
 that can tolerate less than 1/3 failures, the evidence system looks to detect and
 gossip byzantine faults whose combined power is greater than  or equal to 1/3. It is worth noting that
 the evidence system is designed purely to detect possible attacks, gossip them,
-commit them on chain and inform the application running on top of Tendermint.
+commit them on chain and inform the application running on top of CometBFT.
 Evidence in itself does not punish "bad actors", this is left to the discretion
 of the application. A common form of punishment is slashing where the validators
 that were caught violating the protocol have all or a portion of their voting
@@ -16,7 +16,7 @@ security on a "best effort" basis.
 This document walks through the various forms of evidence, how they are detected,
 gossiped, verified and committed.
 
-> NOTE: Evidence here is internal to tendermint and should not be confused with
+> NOTE: Evidence here is internal to CometBFT and should not be confused with
 > application evidence
 
 ## Detection

diff --git a/spec/consensus/light-client/README.md b/spec/consensus/light-client/README.md
@@ -4,6 +4,6 @@ parent:
   title: Light Client
   order: false
 ---
-# Tendermint Light Client Protocol
+# Light Client Protocol
 
 Deprecated, please see [light-client](../../light-client/README.md).
diff --git a/spec/consensus/light-client/accountability.md b/spec/consensus/light-client/accountability.md
@@ -1,3 +1,3 @@
 # Fork accountability
 
-Deprecated, please see [light-client/accountability](../../light-client/accountability.md).
+Deprecated, please see [light-client/accountability](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/light-client/accountability).
diff --git a/spec/consensus/light-client/detection.md b/spec/consensus/light-client/detection.md
@@ -1,3 +1,3 @@
 # Detection
 
-Deprecated, please see [light-client/detection](../../light-client/detection.md).
+Deprecated, please see [light-client/detection](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/light-client/detection).
diff --git a/spec/consensus/light-client/verification.md b/spec/consensus/light-client/verification.md
@@ -1,3 +1,3 @@
 # Core Verification
 
-Deprecated, please see [light-client/accountability](../../light-client/verification.md).
+Deprecated, please see [light-client/verification](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/light-client/verification).
diff --git a/spec/consensus/proposer-based-timestamp/README.md b/spec/consensus/proposer-based-timestamp/README.md
@@ -1,6 +1,6 @@
 # Proposer-Based Timestamps
 
-This section describes a version of the Tendermint consensus protocol,
+This section describes a version of the Tendermint consensus algorithm, adopted in CometBFT,
 which uses proposer-based timestamps.
 
 ## Contents

diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md
@@ -156,8 +156,5 @@ Back to [main document][main].
 
 [arXiv]: https://arxiv.org/abs/1807.04938
 
-[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md
 
-[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md
 
-[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md
diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md
@@ -18,7 +18,8 @@ There exists a system parameter `PRECISION` such that for any two correct valida
 
 ### Message Delays
 
-We do not want to interfere with the Tendermint timing assumptions. We will postulate a timing restriction, which, if satisfied, ensures that liveness is preserved.
+We do not want to interfere with the timing assumptions of Tendermint consensus algorithm.
+We will postulate a timing restriction, which, if satisfied, ensures that liveness is preserved.
 
 In general the local clock may drift from the global time. (It may progress faster, e.g., one second of clock time might take 1.005 seconds of real-time). As a result the local clock and the global clock may be measured in different time units. Usually, the message delay is measured in global clock time units. To estimate the correct local timeout precisely, we would need to estimate the clock time duration of a message delay taking into account the clock drift. For simplicity we ignore this, and directly postulate the message delay assumption in terms of local time.
 
@@ -36,7 +37,7 @@ The message end-to-end delay between a correct proposer and a correct validator
 
 ## Problem Statement
 
-In this section we define the properties of Tendermint consensus (cf. the [arXiv paper][arXiv]) in this new system model.
+In this section we define the properties of Tendermint consensus algorithm (cf. the [arXiv paper][arXiv]) in this new system model.
 
 #### **[PBTS-PROPOSE.0]**
 
@@ -52,7 +53,7 @@ A proposer proposes a pair `(v,t)` of consensus value `v` and time `t`.
 
 [Time-Validity] If a correct validator decides on `t` then `t` is "OK" (we will formalize this below), even if up to `2f` validators are faulty.
 
-However, the properties of Tendermint consensus are of more interest with respect to the blocks, that is, what is written into a block and when. We therefore, in the following, will give the safety and liveness properties from this block-centric viewpoint.  
+However, the properties of Tendermint consensus algorithm are of more interest with respect to the blocks, that is, what is written into a block and when. We therefore, in the following, will give the safety and liveness properties from this block-centric viewpoint.  
 For this, observe that the time `t` decided at consensus height `k` will be written in the block of height `k+1`, and will be supported by `2f + 1` `PRECOMMIT` messages of the same consensus round `r`. The time written in the block, we will denote by `b.time` (to distinguish it from the term `bfttime` used for median-based time). For this, it is important to have the following consensus algorithm property:
 
 #### **[PBTS-INV-TIME-AGR.0]**
@@ -69,11 +70,11 @@ However, as most consensus instances terminate within one round on the Cosmos hu
 
 
 
-Finally, observe that the agreement ([Agreement] and [Time-Agreement]) properties are based on the Tendermint security model [TMBC-FM-2THIRDS.0] of more than 2/3 correct validators, while [Time-Validity] is based on more than 1/3 correct validators.
+Finally, observe that the agreement ([Agreement] and [Time-Agreement]) properties are based on the Cosmos security model [CMBC-FM-2THIRDS.0][CMBC-FM-2THIRDS-link] of more than 2/3 correct validators, while [Time-Validity] is based on more than 1/3 correct validators.
 
 ### SAFETY
 
-Here we will provide specifications that relate local time to block time. However, since we do not assume (by now) that local time is linked to real-time, these specifications also do not provide a relation between block time and real-time. Such properties are given [later](#REAL-TIME-SAFETY).
+Here we will provide specifications that relate local time to block time. However, since we do not assume (by now) that local time is linked to real-time, these specifications also do not provide a relation between block time and real-time. Such properties are given [later](#real-time-safety).
 
 For a correct validator `V`, let `beginConsensus(V,k)` be the local time when it sets its height to `k`, and let `endConsensus(V,k)` be the time when it sets its height to `k + 1`.
 
@@ -110,7 +111,7 @@ then the time `b.time` in the block `b` that is signed by `c` satisfies
 
 If the proposer of round 1 is correct, and
 
-- [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
+- [CMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
 - [PBTS-MSG-FAIR.0], and
 - [PBTS-CLOCK-PRECISION.0], and
 - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
@@ -121,7 +122,7 @@ then eventually (within bounded time) every correct validator decides in round 1
 
 If the proposer of round 1 is correct, and
 
-- [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
+- [CMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
 - [PBTS-MSG-FAIR.0], and
 - [PBTS-CLOCK-PRECISION.0], and
 - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
@@ -135,7 +136,7 @@ then `beginConsensus_k <= b.time <= last-beginConsensus_k`.
 
 If
 
-- [TMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
+- [CMBC-FM-2THIRDS.0] holds for a block of height `k - 1`, and
 - [PBTS-MSG-FAIR.0],
 - [PBTS-CLOCK.0], and
 - [PBTS-CLOCK-GROW.0] (**TODO:** is that enough?)
@@ -187,12 +188,4 @@ Back to [main document][main].
 
 [arXiv]: https://arxiv.org/abs/1807.04938
 
-[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md
-
-[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md
-
-[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md
-
-[algorithm]: ./pbts-algorithm_001_draft.md
-
-[sysmodel]: ./pbts-sysmodel_001_draft.md
+[CMBC-FM-2THIRDS-link]: https://github.com/cometbft/cometbft/blob/v0.34.x/spec/light-client/verification/verification_002_draft.md#cmbc-fm-2thirds1
diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md
@@ -4,7 +4,7 @@
 
 ### Description
 
-In Tendermint consensus, the first version of how time is computed and stored in a block works as follows:
+In CometBFT, the first version of how time is computed and stored in a block works as follows:
 
 - validators send their current local time as part of `precommit` messages
 - upon collecting the `precommit` messages that the proposer uses to build a commit to be put in the next block, the proposer computes the `time` of the next block as the median (weighted over voting power) of the times in the `precommit` messages.
@@ -255,16 +255,15 @@ This specification describes the changes needed to be done to the Tendermint con
 
 [arXiv]: https://arxiv.org/abs/1807.04938
 
-[tlatender]: https://github.com/tendermint/spec/blob/master/rust-spec/tendermint-accountability/README.md
+[tlatender]: ../../light-client/accountability/README.md
 
-[bfttime]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/spec/consensus/bft-time.md
+[bfttime]: ../bft-time.md
 
-[lcspec]: https://github.com/tendermint/spec/blob/439a5bcacb5ef6ef1118566d7b0cd68fff3553d4/rust-spec/lightclient/README.md
+[lcspec]: ../../light-client/README.md
 
 [algorithm]: ./pbts-algorithm_001_draft.md
 
 [sysmodel]: ./pbts-sysmodel_001_draft.md
 
-[main]: ./pbts_001_draft.md
 
 [proposertla]: ./tla/TendermintPBT_001_draft.tla
diff --git a/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla b/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla
@@ -1,9 +1,9 @@
 -------------------- MODULE TendermintPBT_001_draft ---------------------------
 (*
- A TLA+ specification of a simplified Tendermint consensus, with added clocks 
+ A TLA+ specification of a simplified Tendermint consensus algorithm, with added clocks 
  and proposer-based timestamps. This TLA+ specification extends and modifies 
  the Tendermint TLA+ specification for fork accountability: 
-    https://github.com/tendermint/tendermint/blob/v0.34.x/spec/light-client/accountability/TendermintAcc_004_draft.tla
+    https://github.com/cometbft/cometbft/blob/v0.34.x/spec/light-client/accountability/TendermintAcc_004_draft.tla
  
  * Version 1. A preliminary specification.