cometbft · andynog · Feb 22, 2023 · Feb 13, 2023 · Feb 14, 2023 · Feb 14, 2023
@@ -5,3 +5,8 @@ parent:
 ---
 
 # Apps
+
+- [Using ABCI-CLI](./abci-cli.md)
+- [Getting Started](./getting-started.md)
+- [Indexing transactions](./indexing-transactions.md)
+- [Application Architecture Guide](./app-architecture.md)
@@ -6,6 +6,6 @@ order: 9
 
 The RPC documentation is hosted here:
 
-- [https://docs.cometbft.com/main/rpc/](https://docs.cometbft.com/main/rpc/)
+- [RPC Documentation](https://docs.cometbft.com/main/rpc)
 
 To update the documentation, edit the relevant `godoc` comments in the [rpc/core directory](https://github.com/cometbft/cometbft/blob/main/rpc/core).
@@ -119,6 +119,6 @@ cometbft node --home ./mytestnet/node3 --proxy_app=kvstore --p2p.persistent_peer
 
 Note that after the third node is started, blocks will start to stream in
 because >2/3 of validators (defined in the `genesis.json`) have come online.
-Persistent peers can also be specified in the `config.toml`. See [here](../cometbft-core/configuration.md) for more information about configuration options.
+Persistent peers can also be specified in the `config.toml`. See [here](../core/configuration.md) for more information about configuration options.
 
 Transactions can then be sent as covered in the single, local node example above.
@@ -20,5 +20,5 @@ The results obtained in each release are stored in their own directory.
 The following releases have undergone the Quality Assurance process, and the corresponding reports include detailed information on tests and comparison with the baseline.
 
 * [TM v0.34.x](./v034/TMCore.md) - Tested prior to releasing Tendermint Core v0.34.22.
-* [v0.34.x](./v034/CometBFT.md) - Tested prior to releasing v0.34.27, using TM v0.34.x results as baseline.
+* [v0.34.x](./v034/README.md) - Tested prior to releasing v0.34.27, using TM v0.34.x results as baseline.
 * [v0.37.x](./v037/) - with TM v.34.x acting as a baseline
@@ -1,7 +1,7 @@
 ---
 order: 1
 parent:
-  title: CometBFT Quality Assurance Results for v0.34.x
+  title: Tendermint Core Quality Assurance Results for v0.34.x
   description: This is a report on the results obtained when running v0.34.x on testnets
   order: 2
 ---
@@ -274,4 +274,4 @@ transactions, via RPC, from the load runner process.
 
 Date: 2022-10-10
 
-Version: a28c987f5a604ff66b515dd415270063e6fb069d
+Version: a28c987f5a604ff66b515dd415270063e6fb069d
@@ -11,7 +11,6 @@ CometBFT has some tools that are associated with it for:
 
 - [Debugging](./debugging.md)
 - [Benchmarking](#benchmarking)
-- [Testnets](#testnets)
 
 ## Benchmarking
 

@@ -1,3 +1,7 @@
+---
+order: 1
+---
+
 # Debugging
 
 ## CometBFT debug kill
@@ -62,17 +66,17 @@ CometBFT includes an `inspect` command for querying CometBFT's state store and b
 store over CometBFT RPC.
 
 When the CometBFT consensus engine detects inconsistent state, it will crash the
-entire CometBFT process. 
-While in this inconsistent state, a node running CometBFT will not start up. 
+entire CometBFT process.
+While in this inconsistent state, a node running CometBFT will not start up.
 The `inspect` command runs only a subset of CometBFT's RPC endpoints for querying the block store
-and state store. 
+and state store.
 `inspect` allows operators to query a read-only view of the stage.
 `inspect` does not run the consensus engine at all and can therefore be used to debug
-processes that have crashed due to inconsistent state. 
+processes that have crashed due to inconsistent state.
 
 ### Running inspect
 
-Start up the `inspect` tool on the machine where CometBFT crashed using: 
+Start up the `inspect` tool on the machine where CometBFT crashed using:
 ```bash
 cometbft inspect --home=</path/to/app.d>
 ```
@@ -84,7 +88,7 @@ cometbft inspect --home=</path/to/app.d>
 
 With the `inspect` server running, you can access RPC endpoints that are critically important
 for debugging.
-Calling the `/status`, `/consensus_state` and `/dump_consensus_state` RPC endpoint 
+Calling the `/status`, `/consensus_state` and `/dump_consensus_state` RPC endpoint
 will return useful information about the CometBFT consensus state.
 
 To start the `inspect` process, run
@@ -95,7 +99,7 @@ cometbft inspect
 ### RPC endpoints
 
 The list of available RPC endpoints can be found by making a request to the RPC port.
-For an `inspect` process running on `127.0.0.1:26657`, navigate your browser to 
+For an `inspect` process running on `127.0.0.1:26657`, navigate your browser to
 `http://127.0.0.1:26657/` to retrieve the list of enabled RPC endpoints.
 
 Additional information on the CometBFT RPC endpoints can be found in the [rpc documentation](https://docs.cometbft.com/master/rpc).
@@ -6,5 +6,5 @@ parent:
 
 # Guides
 
-- [Creating a built-in application in Go][./go-built-in.md]
-- [Creating an external application in Go][./go.md]
+- [Creating a built-in application in Go](./go-built-in.md)
+- [Creating an external application in Go](./go.md)
@@ -18,7 +18,7 @@ process as the application.
 
 By following along this tutorial you will create a CometBFT application called kvstore,
 a (very) simple distributed BFT key-value store.
-The application will be written in Go and  
+The application will be written in Go and
 some understanding of the Go programming language is expected.
 If you have never written Go, you may want to go through [Learn X in Y minutes
 Where X=Go](https://learnxinyminutes.com/docs/go/) first, to familiarize
@@ -796,5 +796,4 @@ echo cm9ja3M=" | base64 -d
 
 I hope everything went smoothly and your first, but hopefully not the last,
 CometBFT application is up and running. If not, please [open an issue on
-Github](https://github.com/cometbft/cometbft/issues/new/choose). To dig
-deeper, read [the docs](https://docs.cometbft.com/main/).
+Github](https://github.com/cometbft/cometbft/issues/new/choose).
@@ -18,7 +18,7 @@ process as the application.
 
 By following along this tutorial you will create a CometBFT application called kvstore,
 a (very) simple distributed BFT key-value store.
-The application will be written in Go and  
+The application will be written in Go and
 some understanding of the Go programming language is expected.
 If you have never written Go, you may want to go through [Learn X in Y minutes
 Where X=Go](https://learnxinyminutes.com/docs/go/) first, to familiarize
@@ -712,5 +712,4 @@ echo cm9ja3M=" | base64 -d
 
 I hope everything went smoothly and your first, but hopefully not the last,
 CometBFT application is up and running. If not, please [open an issue on
-Github](https://github.com/cometbft/cometbft/issues/new/choose). To dig
-deeper, read [the docs](https://docs.cometbft.com/main/).
+Github](https://github.com/cometbft/cometbft/issues/new/choose).
@@ -0,0 +1,12 @@
+---
+order: 5
+parent:
+title: RPC
+order: 5
+---
+
+# RPC
+
+The RPC documentation is hosted here:
+
+- [RPC Documentation](./rpc.html)
@@ -20,7 +20,7 @@ for handling all ABCI++ methods.
 Thus, CometBFT always sends the `Request*` messages and receives the `Response*` messages
 in return.
 
-All ABCI++ messages and methods are defined in [protocol buffers](../../proto/tendermint/abci/types.proto).
+All ABCI++ messages and methods are defined in [protocol buffers](https://github.com/cometbft/cometbft/blob/main/proto/tendermint/abci/types.proto).
 This allows CometBFT to run with applications written in many programming languages.
 
 This specification is split as follows:
@@ -35,7 +35,7 @@ This specification is split as follows:
 - [CometBFT's expected behavior](./abci++_comet_expected_behavior.md) - specification of
   how the different ABCI++ methods may be called by CometBFT. This explains what the Application
   is to expect from CometBFT.
-- [Example scenarios](./abci++_example_scenarios.md) - specific scenarios showing why the Application needs to account 
+- [Example scenarios](./abci++_example_scenarios.md) - specific scenarios showing why the Application needs to account
 for any CometBFT's behaviour prescribed by the specification.
-- [Client and Server](abci++_client_server.md) - for those looking to implement their
+- [Client and Server](./abci++_client_server.md) - for those looking to implement their
   own ABCI application servers.
@@ -26,7 +26,7 @@ title: Overview and basic concepts
 
 ## ABCI++ vs. ABCI
 
-[&uparrow; Back to Outline](#outline)
+[&#8593; Back to Outline](#outline)
 
 The Application's main role is to execute blocks decided (a.k.a. finalized) by consensus. The
 decided blocks are the consensus's main ouput to the (replicated) Application. With ABCI, the
@@ -56,7 +56,7 @@ and `VerifyVoteExtension` methods.
 ## Method overview
 
 
-[&uparrow; Back to Outline](#outline)
+[&#8593; Back to Outline](#outline)
 
 Methods can be classified into four categories: *consensus*, *mempool*, *info*, and *state-sync*.
 
@@ -68,7 +68,7 @@ state. One `DeliverTx` is called for each transaction in the block. The result i
 Cryptographic commitments to the results of `DeliverTx`, and an application-provided hash in `Commit` are included in the header of the next block. During the execution of an instance of consensus, which decides the block for a given
 height, and before method `BeginBlock` is called, methods `PrepareProposal` and `ProcessProposal`,
  may be called several times. See
-[CometBFT's expected behavior](abci++_tmint_expected_behavior.md) for details on the possible
+[CometBFT's expected behavior](./abci++_comet_expected_behavior.md) for details on the possible
 call sequences of these methods.
 
 - [**InitChain:**](./abci++_methods.md#initchain) This method initializes the blockchain.
@@ -78,7 +78,7 @@ call sequences of these methods.
   proposer to perform application-dependent work in a block before proposing it.
   This enables, for instance, batch optimizations to a block, which has been empirically
   demonstrated to be a key component for improved performance. Method `PrepareProposal` is called
-  every time CometBFT is about to broadcast a Proposal message and _validValue_ is `nil`. 
+  every time CometBFT is about to broadcast a Proposal message and _validValue_ is `nil`.
   CometBFT gathers outstanding transactions from the
   mempool, generates a block header, and uses them to create a block to propose. Then, it calls
   `RequestPrepareProposal` with the newly created proposal, called *raw proposal*. The Application
@@ -91,7 +91,7 @@ call sequences of these methods.
   perform application-dependent work in a proposed block. This enables features such as immediate
   block execution, and allows the Application to reject invalid blocks.
 
-  CometBFT calls it when it receives a proposal and _validValue_ is `nil`. 
+  CometBFT calls it when it receives a proposal and _validValue_ is `nil`.
   The Application cannot modify the proposal at this point but can reject it if it is
   invalid. If that is the case, the consensus algorithm will prevote `nil` on the proposal, which has
   strong liveness implications for CometBFT. As a general rule, the Application
@@ -114,7 +114,7 @@ call sequences of these methods.
  `DeliverTx` to inform the application that no other transactions will be delivered as part of the current
  block and to ask for changes of the validator set and consensus parameters to be used in the following block.
  As with `DeliverTx`, cryptographic commitments of the responses returned are included in the header of the next block.
-<!-- 
+<!--
 
 - [**ExtendVote:**](./abci++_methods.md#extendvote) It allows applications to force their
   validators to do more than just validate within consensus. `ExtendVote` allows applications to
@@ -138,7 +138,7 @@ call sequences of these methods.
   a process receives a precommit message with a (possibly empty) vote extension.
 -->
 
-<!--- 
+<!---
 - [**FinalizeBlock:**](./abci++_methods.md#finalizeblock) It delivers a decided block to the
   Application. The Application must execute the transactions in the block deterministically and
   update its state accordingly. Cryptographic commitments to the block and transaction results,
@@ -238,7 +238,7 @@ in order to suit the needs of the particular application being deployed.
 
 ## Deterministic State-Machine Replication
 
-[&uparrow; Back to Outline](#outline)
+[&#8593; Back to Outline](#outline)
 
 ABCI++ applications must implement deterministic finite-state machines to be
 securely replicated by the CometBFT consensus engine. This means block execution
@@ -297,7 +297,7 @@ on them. All other fields in the `Response*` must be strictly deterministic.
 
 ## Events
 
-[&uparrow; Back to Outline](#outline)
+[&#8593; Back to Outline](#outline)
 
 Methods `BeginBlock, DeliverTx` and `EndBlock` include an `events` field in their
 `Response*`.
@@ -374,7 +374,7 @@ Example:
 
 ## Evidence
 
-[&uparrow; Back to Outline](#outline)
+[&#8593; Back to Outline](#outline)
 
 CometBFT's security model relies on the use of evidences of misbehavior. An evidence is an
 irrefutable proof of malicious behavior by a network participant. It is the responsibility of
@@ -400,7 +400,7 @@ enum EvidenceType {
 
 ## Errors
 
-[&uparrow; Back to Outline](#outline)
+[&#8593; Back to Outline](#outline)
 
 The `Query`, `CheckTx` and `DeliverTx` methods include a `Code` field in their `Response*`.
 Field `Code` is meant to contain an application-specific response code.
@@ -423,7 +423,7 @@ Method `FinalizeBlock` is a special case. It contains a number of
 these codes reports errors related to the transaction it is attached to.
 However, `FinalizeBlock` does not return errors at the top level, so the
 same considerations on critical issues made for `Echo`, `Info`, and
-`InitChain` also apply here. 
+`InitChain` also apply here.
 -->
 
 The handling of non-zero response codes by CometBFT is described below.
@@ -440,11 +440,11 @@ The `DeliverTx` ABCI method delivers transactions from CometBFT to the applicati
 When CometBFT receives a `ResponseDeliverTx` with a non-zero `Code`, the response code is logged.
 The transaction was already included in a block, so the `Code` does not influence consensus.
 
-<!-- 
+<!--
 The `ExecTxResult` type delivers transaction results from the Application to CometBFT. When
 CometBFT receives a `ResponseFinalizeBlock` containing an `ExecTxResult` with a non-zero `Code`,
 the response code is logged. Past `Code` values can be queried by clients. As the transaction was
-part of a decided block, the `Code` does not influence consensus. 
+part of a decided block, the `Code` does not influence consensus.
 -->
 
 ### `Query`

@@ -12,12 +12,12 @@ You are expected to have read all previous sections of ABCI++ specification, nam
 [Basic Concepts](./abci%2B%2B_basic_concepts.md),
 [Methods](./abci%2B%2B_methods.md),
 [Application Requirements](./abci%2B%2B_app_requirements.md), and
-[Expected Behavior](./abci%2B%2B_tmint_expected_behavior.md).
+[Expected Behavior](./abci%2B%2B_comet_expected_behavior.md).
 
 ## Message Protocol and Synchrony
 
 The message protocol consists of pairs of requests and responses defined in the
-[protobuf file](../../proto/tendermint/abci/types.proto).
+[protobuf file](https://github.com/cometbft/cometbft/blob/main/proto/tendermint/abci/types.proto).
 
 Some messages have no fields, while others may include byte-arrays, strings, integers,
 or custom protobuf types.

@@ -237,7 +237,7 @@ title: Methods
         * `H+3`: `last_commit_info (BeginBlock)` is changed to include the altered validator set and `*_last_commit` fields in `PrepareProposal`, `ProcessProposal` now include the altered validator set.
     * `consensus_param_updates` returned for block `H` apply to the consensus
       params for block `H+1`. For more information on the consensus parameters,
-      see the [application spec entry on consensus parameters](abci++_app_requirements.md#consensus-parameters).
+      see the [application spec entry on consensus parameters](./abci++_app_requirements.md#consensus-parameters).
     * `validator_updates` and `consensus_param_updates` may be empty. In this case, CometBFT will keep the current values.
 
 
@@ -464,7 +464,7 @@ title: Methods
     * The implementation of `PrepareProposal` can be non-deterministic.
 
 
-#### When does CometBFT call `PrepareProposal`?
+#### When does CometBFT call "PrepareProposal" ?
 
 
 When a validator _p_ enters consensus round _r_, height _h_, in which _p_ is the proposer,
@@ -539,7 +539,7 @@ the consensus algorithm will use it as proposal and will not call `RequestPrepar
     * Moreover, application implementors SHOULD always set `ResponseProcessProposal.status` to `ACCEPT`,
       unless they _really_ know what the potential liveness implications of returning `REJECT` are.
 
-#### When does CometBFT call `ProcessProposal`?
+#### When does CometBFT call "ProcessProposal" ?
 
 When a node _p_ enters consensus round _r_, height _h_, in which _q_ is the proposer (possibly _p_ = _q_):
 
@@ -564,7 +564,9 @@ When a node _p_ enters consensus round _r_, height _h_, in which _q_ is the prop
     3. If _p_ is a validator and the returned value is
          * `ACCEPT`: _p_ prevotes on this proposal for round _r_, height _h_.
          * `REJECT`: _p_ prevotes `nil`.
+         *
 <!--
+
 ### ExtendVote
 
 #### Parameters and Types
@@ -669,9 +671,6 @@ message for round _r_, height _h_ from validator _q_ (_q_ &ne; _p_):
      structure in calls to `RequestPrepareProposal`, in rounds of height _h + 1_ where _p_ is the proposer.
    * `REJECT`, _p_ will deem the Precommit message invalid and discard it.
 
--->
-
-<!--
 ### FinalizeBlock
 
 #### Parameters and Types
@@ -763,7 +762,9 @@ then _p_ decides block _v_ and finalizes consensus for height _h_ in the followi
    against the newly persisted Application state.
 10. _p_'s CometBFT unlocks the mempool &mdash; newly received transactions can now be checked.
 11. _p_ starts consensus for height _h+1_, round 0
+
 -->
+
 ## Data Types existing in ABCI
 
 Most of the data structures used in ABCI are shared [common data structures](../core/data_structures.md). In certain cases, ABCI uses different data structures which are documented here:
@@ -919,7 +920,7 @@ Most of the data structures used in ABCI are shared [common data structures](../
     | round | int32                                          | Commit round. Reflects the round at which the block proposer decided in the previous height.                      | 1            |
     | votes | repeated [ExtendedVoteInfo](#extendedvoteinfo) | List of validators' addresses in the last validator set with their voting information, including vote extensions. | 2            |
 
-<!-- 
+<!--
 ### ExecTxResult
 
 * **Fields**:
@@ -941,7 +942,7 @@ Most of the data structures used in ABCI are shared [common data structures](../
 
 ```proto
 enum ProposalStatus {
-  UNKNOWN = 0; // Unknown status. Returning this from the application is always an error. 
+  UNKNOWN = 0; // Unknown status. Returning this from the application is always an error.
   ACCEPT  = 1; // Status that signals that the application finds the proposal valid.
   REJECT  = 2; // Status that signals that the application finds the proposal invalid.
 }
@@ -953,7 +954,7 @@ enum ProposalStatus {
         * If `Status` is `ACCEPT`, the consensus algorithm accepts the proposal and will issue a Prevote message for it.
         * If `Status` is `REJECT`, the consensus algorithm rejects the proposal and will issue a Prevote for `nil` instead.
 
-<!-- 
+<!--
 ### VerifyStatus
 
 ```proto