docs: Update docs for Comet BFT (#2493)

* initial pass-thru replace of tendermint for cometbft

* Updated comet links

* Updated vuepress-theme package

* Updated based on comments

* Update docs/zh/validators/security.md

Co-authored-by: yaruwangway <69694322+yaruwangway@users.noreply.github.com>

* Updated CometBFT reference

* Updated CometBFT references

---------

Co-authored-by: yaruwangway <69694322+yaruwangway@users.noreply.github.com>

CHANGELOG.md

@@ -93,6 +93,9 @@ To fix this problem, we have re-blocked the FeePoolAddress and created a new add
 
 Note: The fee of 10 Atoms was originally intended to be a parameter that could be changed by governance (10 Atoms might cost too much in the future). However, we ran into some problems creating a new parameter as part of an emergency upgrade. After consulting with the Cosmos-SDK team, we learned that creating new parameters is only supported as part of a scheduled upgrade. So in the current code, the number of Atoms is hardcoded. It will turn into a parameter in the next scheduled upgrade.
 
+### Docs
+* (docs) [#2425](https://github.com/cosmos/gaia/pull/2425) Update docs to include references to CometBFT
+
 ## [v9.0.3] - 2023-04-19
 * (deps) [#2399](https://github.com/cosmos/gaia/pull/2399) Bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.45.15-ics](https://github.com/cosmos/cosmos
 sdk/releases/tag/v0.45.15-ics) and migrate to [CometBFT](https://github.com/cometbft/cometbft).

Makefile

@@ -15,6 +15,7 @@ endif
 PACKAGES_SIMTEST=$(shell go list ./... | grep '/simulation')
 LEDGER_ENABLED ?= true
 SDK_PACK := $(shell go list -m github.com/cosmos/cosmos-sdk | sed  's/ /\@/g')
+TM_VERSION := $(shell go list -m github.com/cometbft/cometbft | sed 's:.* ::') # grab everything after the space in "github.com/cometbft/cometbft v0.34.7"
 DOCKER := $(shell which docker)
 BUILDDIR ?= $(CURDIR)/build
 TEST_DOCKER_REPO=cosmos/contrib-gaiatest
@@ -68,6 +69,7 @@ ldflags = -X github.com/cosmos/cosmos-sdk/version.Name=gaia \
 		  -X github.com/cosmos/cosmos-sdk/version.Version=$(VERSION) \
 		  -X github.com/cosmos/cosmos-sdk/version.Commit=$(COMMIT) \
 		  -X "github.com/cosmos/cosmos-sdk/version.BuildTags=$(build_tags_comma_sep)" \
+			-X github.com/cometbft/cometbft/version.TMCoreSemVer=$(TM_VERSION)
 
 ifeq (cleveldb,$(findstring cleveldb,$(GAIA_BUILD_OPTIONS)))
   ldflags += -X github.com/cosmos/cosmos-sdk/types.DBBackend=cleveldb

RELEASING.md

@@ -0,0 +1,182 @@
+# Releasing
+
+This document outlines the release process for <https://github.com/cosmos/gaia>. We use [Long-Lived Version Branch Approach](x) on a `main` branch and a `release` branch.
+
+We follow [Semver](https://semver.org/) in that any patch releases are non-breaking changes. It's important to note, that breaking changes in a Blockchain context include non-determinism. So if a code change is backwards compatible, it may still impact the amount of gas needed to execute an action, which means the change is in fact breaking as it results in a different apphash after the code is executed. It's important for non-breaking changes to be possible to be used on the live network prior to the release.
+
+Each major release will have a release branch and patch releases will be tagged on this branch. No patched release has its own branch. (This branch strategy only applies to `v7` and later releases.)
+
+## Long-Lived Version Branch Approach
+
+In the Gaia repo, there are two categories of long-lived branches:
+
+### Branch: `main`
+
+The `main` branch should be targeted for PRs that contain a bug-fix/feature/improvement that will be included for the next release.
+
+### Branch: `release`
+
+There are multiple long-lived branches with the `release/` prefix. Each release series follows the format `release/vn.0.x`, e.g. `release/v7.0.x`. The branch `release/vn.0.x` should point to the most updated `vn` release, e.g. `release/v5.0.x` should be the same as `release/v5.0.8` if that's the latest `v5.0` release.
+
+## Other Branches
+
+### branches for the next release
+
+Other feature/fix branches targeting at `main` contain commits preparing for the next release. When the `release-prepare-branch` is ready for next release, add label `A:backport/vn.0.x` to the PR of `release-prepare-branch` against `main`, then the mergifybot will create a new PR of `mergify/bp/release/vn.0.x`  against `Release/vn.0.x`.
+
+### branches for the backport release
+
+If the feature/fix branches are for a backport release, `main` branch already contains the commits for the next major release  `vn`, the feature/fix branch's PR should target at `Release/vn-1` rather than `main`.
+
+## Release Procedure
+
+### Checks and tests
+
+Before merge and release, the following tests checks need to be conducted:
+
+- check the `replace` line in `go.mod`, check all the versions in `go.mod` are correct.
+- run tests and simulations by `make run-tests`.
+- test version compatibilities for minor releases.
+
+### Major and minor Release
+
+For a new major release `n`, checkout `release/vn.0.x` from `main`. Merge or use mergify to merge the commits to `release/vn.0.x`, and tag the version.
+For minor release. Merge or use mergify to merge the commits to `release/vn.0.x`, and tag the version.
+
+Usually the first release on the `release/vn.0.x` is a release candidate.
+
+#### example of releasing `v8.0.0-rc0`
+
+1. checkout `release/v8.0.x` off `main`
+1. get the `v8-prepare-branch` ready including CHANGELOG.md, create a PR to merge `v8-prepare-branch` to `main`, label this PR `A:backport/v8.0.x`.
+1. after merge  `v8-prepare-branch` to `main`, mergifybot will create a new PR of  `mergify/bp/release/v8.0.x` to `release/v8.0.x`. Check the PR, and merge this PR.
+1. checkout  `release/v8.0.x` and tag `v8.0.0-rc0`.
+
+#### example of releasing `v8.0.0`
+
+1. get the `v800-prepare-branch` ready including CHANGELOG.md, create a PR to merge `v800-prepare-branch` to `main`, label this PR `A:backport/v8.0.x`.
+1. after merge  `v800-prepare-branch` to `main`, mergifybot will create a new PR of  `mergify/bp/release/v8.0.x` to `release/v8.0.x`. Check the PR, and merge this PR.
+1. checkout  `release/v8.0.x` and tag `v8.0.0`.
+
+#### example of releasing `v8.0.1`
+
+1. get the `v801-prepare-branch`(off `main`) ready including CHANGELOG.md, create a PR to merge `v801-prepare-branch` to `main`, label this PR `A:backport/v8.0.x`.
+1. after merge  `v801-prepare-branch` to `main`, mergifybot will create a new PR of  `mergify/bp/release/v8.0.x` to `release/v8.0.x`. Check the PR, and merge this PR.
+1. checkout  `release/v8.0.x` and tag `v8.0.1`.
+
+### backport release
+
+For a backport release, checkout a new branch from the right release branch, for example, `release/vn-1.0.x`. Commits to this new branch and merge into `release/vn-1.0.x`, tag the backport version from `release/vn-1.0.x`.
+
+#### example of backport release `v7.0.5`
+
+assume main branch is at `v8`.
+
+1. checkout `v705-prepare-branch` off `release/v7.0.x`, get the backport changes ready including CHANGELOG.md on `v705-prepare-branch`.
+1. create a PR to merge `v705-prepare-branch` to `release/v7.0.x`, and merge.
+1. checkout `release/v7.0.x`  tag `v7.0.5`.
+
+### Test building artifacts
+
+Before tagging the version, please test the building releasing artifacts by
+
+```bash
+make distclean build-reproducible
+```
+
+The above command will generate a directory
+`gaia/artifacts` with different os and architecture binaries. If the above command runs sucessfully, delete the directory `rm -r gaia/artifacts`.
+
+### Tagging
+
+The following steps are the default for tagging a specific branch commit (usually on a branch labeled `release/vX.X.X`):
+
+1. Ensure you have checked out the commit you wish to tag
+1. `git pull --tags --dry-run`
+1. `git pull --tags`
+1. `git tag -s v3.0.1 -m 'Release v3.0.1'`
+   1. optional, add the `-s` tag to create a signed commit using your PGP key (which should be added to github beforehand)
+1. `git push --tags --dry-run`
+1. `git push --tags`
+
+To re-create a tag:
+
+1. `git tag -d v4.0.0` to delete a tag locally
+1. `git push --delete origin v4.0.0`, to push the deletion to the remote
+1. Proceed with the above steps to create a tag
+
+To tag and build without a public release (e.g., as part of a timed security release):
+
+1. Follow the steps above for tagging locally, but do not push the tags to the repository.
+1. After adding the tag locally, you can build the binary, e.g., `make build-reproducible`.
+1. To finalize the release, push the local tags, create a release based off the newly pushed tag, and attach the binaries.
+
+### Release notes
+
+Ensure you run the reproducible build in order to generate sha256 hashes and platform binaries;
+these artifacts should be included in the release.
+
+```bash
+make distclean build-reproducible
+```
+
+This runs the docker image [tendermintdev/rbuilder](https://hub.docker.com/r/tendermintdev/rbuilder) with a copy of the [rbuilder](https://github.com/tendermint/images/tree/master/rbuilder) docker file.
+
+Then use the following release text template:
+
+```markdown
+# Gaia v4.0.0 Release Notes
+
+Note, that this specific release will be updated with a newer changelog, and the below hashes and binaries will also be updated.
+
+This release includes bug fixes for prop29, as well as additional support for IBC and Ledger signing.
+
+As there is a breaking change from Gaia v3, the Gaia module has been incremented to v4.
+
+See the [Cosmos SDK v0.41.0 Release](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.0) for details.
+
+```bash
+$ make distclean build-reproducible
+App: gaiad
+Version: 4.0.0
+Commit: 2bb04266266586468271c4ab322367acbf41188f
+Files:
+ 2e801c7424ef67e6d9fc092c2b75c2d3  gaiad-4.0.0-darwin-amd64
+ dc21eb861480e0f55af876f271b512fe  gaiad-4.0.0-linux-amd64
+ bda165f91bc065afb8a445e72be9a868  gaiad-4.0.0-linux-arm64
+ c7203d53bd596679b39b6a94d1dbe0dc  gaiad-4.0.0-windows-amd64.exe
+ 81299b602e1760078e03c97813edda60  gaiad-4.0.0.tar.gz
+Checksums-Sha256:
+ de764e52acc31dd98fa49d8d0eef851f3b7b53e4f1d4fbfda2c07b1a8b115b91  gaiad-4.0.0-darwin-amd64
+ e5244ccd98a05479cc35753da1bb5b6bd873f6d8ebe6f8c5d112cf4d9e2761b4  gaiad-4.0.0-linux-amd64
+ 7b7c4ea3e2de5f228436dcbb177455906239603b11eca1fb1015f33973d7b567  gaiad-4.0.0-linux-arm64
+ b418c5f296ee6f946f44da8497af594c6ad0ece2b1da09a93a45d7d1b1457f27  gaiad-4.0.0-windows-amd64.exe
+ 3895518436b74be8b042d7d0b868a60d03e1656e2556b12132be0f25bcb061ef  gaiad-4.0.0.tar.gz
+```
+
+# Major Release Maintenance
+
+Major Release series continue to receive bug fixes (released as a Patch Release) until they reach End Of Life. Major Release series are maintained in compliance with the Stable Release Policy as described in this document. Note: not every Major Release is denoted as a stable release.
+
+Only the following major release series have a stable release status:
+
+v7 Theta is supported until v9 Lambda. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
+
+v6 Vega is supported until v8 Rho. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
+
+v5 Delta is supported until v7 Theta. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release.
+
+After two releases, a supported version will be transitioned to unsupported and will be deemed EOL with no further updates.
+
+# Stable Release Policy
+
+The intention of the Stable Release Policy is to ensure that all major release series that are not EOL, are maintained with the following categories of fixes:
+
+- Tooling improvements (including code formatting, linting, static analysis and updates to testing frameworks)
+- Performance enhancements for running archival and synching nodes
+- Test and benchmarking suites, ensuring that fixes are sound and there are no performance regressions
+- Library updates including point releases for core libraries such as IBC-Go, Cosmos SDK, CometBFT and other dependencies
+- General maintenance improvements, that are deemed necessary by the stewarding team, that help align different releases and reduce the workload on the stewarding team
+- Security fixes
+
+Issues that are likely excluded, are any issues that impact operating a block producing network.

contrib/testnets/test_platform/templates/app.toml

@@ -36,15 +36,15 @@ halt-time = 0
 
 # MinRetainBlocks defines the minimum block height offset from the current
 # block being committed, such that all blocks past this offset are pruned
-# from Tendermint. It is used as part of the process of determining the
+# from CometBFT. It is used as part of the process of determining the
 # ResponseCommit.RetainHeight value during ABCI Commit. A value of 0 indicates
 # that no blocks should be pruned.
 #
-# This configuration value is only responsible for pruning Tendermint blocks.
+# This configuration value is only responsible for pruning CometBFT blocks.
 # It has no bearing on application state pruning which is determined by the
 # "pruning-*" configurations.
 #
-# Note: Tendermint block pruning is dependant on this parameter in conunction
+# Note: CometBFT block pruning is dependant on this parameter in conunction
 # with the unbonding (safety threshold) period, state pruning and state sync
 # snapshot parameters to determine the correct minimum value of
 # ResponseCommit.RetainHeight.
@@ -54,7 +54,7 @@ min-retain-blocks = 0
 inter-block-cache = true
 
 # IndexEvents defines the set of events in the form {eventType}.{attributeKey},
-# which informs Tendermint what to index. If empty, all events will be indexed.
+# which informs CometBFT what to index. If empty, all events will be indexed.
 #
 # Example:
 # ["message.sender", "message.recipient"]
@@ -113,13 +113,13 @@ address = "<API_ADDRESS>:<API_ADDRESS_PORT>"
 # MaxOpenConnections defines the number of maximum open connections.
 max-open-connections = 1000
 
-# RPCReadTimeout defines the Tendermint RPC read timeout (in seconds).
+# RPCReadTimeout defines the CometBFT RPC read timeout (in seconds).
 rpc-read-timeout = 10
 
-# RPCWriteTimeout defines the Tendermint RPC write timeout (in seconds).
+# RPCWriteTimeout defines the CometBFT RPC write timeout (in seconds).
 rpc-write-timeout = 0
 
-# RPCMaxBodyBytes defines the Tendermint maximum response body (in bytes).
+# RPCMaxBodyBytes defines the CometBFT maximum response body (in bytes).
 rpc-max-body-bytes = 1000000
 
 # EnableUnsafeCORS defines if CORS should be enabled (unsafe - use it at your own risk).

docs/.vuepress/config.js

@@ -52,9 +52,13 @@ module.exports = {
             {
               title: "REST API Spec",
               path: "https://cosmos.network/rpc/"
-            }
+            },
+            {
+              title: "REST API Spec ABC",
+              path: "https://cosmos.network/rpc/"
+            }            
           ]
-        }
+        }        
       ]
     },
     gutter: {
@@ -78,10 +82,6 @@ module.exports = {
           service: "twitter",
           url: "https://twitter.com/cosmos"
         },
-        {
-          service: "linkedin",
-          url: "https://www.linkedin.com/company/tendermint/"
-        },
         {
           service: "github",
           url: "https://github.com/cosmos/gaia"
@@ -100,23 +100,12 @@ module.exports = {
         }
       ],
       smallprint:
-        "This website is maintained by Tendermint Inc. The contents and opinions of this website are those of Tendermint Inc.",
+        "This website is maintained by Interchain Foundation/Informal Systems. The contents and opinions of this website are those of Interchain Foundation/Informal Systems.",
       links: [
         {
           title: "Documentation",
           children: [
-            {
-              title: "Cosmos SDK",
-              url: "https://docs.cosmos.network"
-            },
-            {
-              title: "Cosmos Hub",
-              url: "https://hub.cosmos.network/"
-            },
-            {
-              title: "Tendermint Core",
-              url: "https://docs.tendermint.com/"
-            }
+
           ]
         },
         {

docs/DOCS_README.md

@@ -94,11 +94,6 @@ To build documentation as a static website run `npm run build`. You will find th
 
 We are using [Algolia](https://www.algolia.com) to power full-text search. This uses a public API search-only key in the `config.js` as well as a [cosmos_network.json](https://github.com/algolia/docsearch-configs/blob/master/configs/cosmos_network.json) configuration file that we can update with PRs.
 
-## Consistency
-
-Because the build processes are identical (as is the information contained herein), this file should be kept in sync as
-much as possible with its [counterpart in the Tendermint Core repo](https://github.com/tendermint/tendermint/blob/master/docs/DOCS_README.md).
-
 ### Update and Build the RPC docs
 
 1. Execute the following command at the root directory to install the swagger-ui generate tool.

docs/es/gaia-tutorials/installation.md

@@ -83,7 +83,7 @@ Las etiquetas (_tags_) para la construcción indican opciones especiales que deb
 
 ## Workflow para el desarrollador
 
-Para probar cualquier cambio hecho en el SDK o Tendermint, se debe agregar una cláusula de `replace` en `go.mod` proporcionando la ruta de entrada correcta.
+Para probar cualquier cambio hecho en el SDK o CometBFT, se debe agregar una cláusula de `replace` en `go.mod` proporcionando la ruta de entrada correcta.
 
 - Realice los cambios apropiados
 - Añada `replace github.com/cosmos/cosmos-sdk => /ruta/a/clon/cosmos-sdk` en `go.mod`

docs/es/gaia-tutorials/join-mainnet.md

@@ -82,7 +82,8 @@ Si estas semillas no funcionan, puedes encontrar más _seeds_ y _peers_ persiste
 
 También puedes preguntar por _peers_ en el [canal de Validadores de Riot](https://riot.im/app/#/room/#cosmos-validators:matrix.org)
 
-Para más información acerca de seeds y peers, puede leer [este enlace](https://docs.tendermint.com/master/spec/p2p/peer.html)
+Para más información acerca de seeds y peers, puede leer [este enlace](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/p2p/peer.md)
+
 
 ## Nota sobre el Fee y el Gas
 

docs/hub-tutorials/gaiad.md

@@ -124,7 +124,7 @@ gaiad tendermint show-validator
 Note that this is the Tendermint signing key, _not_ the operator key you will use in delegation transactions.
 
 ::: danger Warning
-We strongly recommend _NOT_ using the same passphrase for multiple keys. The Tendermint team and the Interchain Foundation will not be responsible for the loss of funds.
+We strongly recommend _NOT_ using the same passphrase for multiple keys. The CometBFT team and the Interchain Foundation will not be responsible for the loss of funds.
 :::
 
 #### Generate Multisig Public Keys

docs/hub-tutorials/join-mainnet.md

@@ -258,7 +258,7 @@ Make sure to consult the [hardware](#Hardware) section for guidance on the best
 
 ### Blocksync
 
-Blocksync is faster than traditional consensus and syncs the chain from genesis by downloading blocks and verifying against the merkle tree of validators. For more information see [Tendermint's Fastsync Docs](https://docs.tendermint.com/v0.34/tendermint-core/fast-sync.html)
+Blocksync is faster than traditional consensus and syncs the chain from genesis by downloading blocks and verifying against the merkle tree of validators. For more information see [CometBFT's Fastsync Docs](https://docs.cometbft.com/v0.34/core/fast-sync)
 
 When syncing via Blocksync, node operators will either need to manually upgrade the chain or set up [Cosmovisor](#Cosmovisor) to upgrade automatically.
 
@@ -289,7 +289,7 @@ The node will begin rebuilding state until it hits the first upgrade height at b
 
 ### State Sync
 
-State Sync is an efficient and fast way to bootstrap a new node, and it works by replaying larger chunks of application state directly rather than replaying individual blocks or consensus rounds. For more information, see [Tendermint's State Sync docs](https://github.com/tendermint/tendermint/blob/v0.34.x/spec/p2p/messages/state-sync.md).
+State Sync is an efficient and fast way to bootstrap a new node, and it works by replaying larger chunks of application state directly rather than replaying individual blocks or consensus rounds. For more information, see [CometBFT's State Sync docs](https://docs.cometbft.com/v0.34/core/state-sync).
 
 To enable state sync, visit an explorer to get a recent block height and corresponding hash. A node operator can choose any height/hash in the current bonding period, but as the recommended snapshot period is `1000` blocks, it is advised to choose something close to `current height - 1000`.