cosmos · julienrbrt · Feb 3, 2023 · Feb 3, 2023 · Feb 3, 2023 · Feb 3, 2023
diff --git a/Makefile b/Makefile
@@ -368,32 +368,6 @@ format:
 	$(golangci_lint_cmd) run --fix
 .PHONY: format
 
-###############################################################################
-###                                 Devdoc                                  ###
-###############################################################################
-
-DEVDOC_SAVE = docker commit `docker ps -a -n 1 -q` devdoc:local
-
-devdoc-init:
-	$(DOCKER) run -it -v "$(CURDIR):/go/src/github.com/cosmos/cosmos-sdk" -w "/go/src/github.com/cosmos/cosmos-sdk" tendermint/devdoc echo
-	# TODO make this safer
-	$(call DEVDOC_SAVE)
-
-devdoc:
-	$(DOCKER) run -it -v "$(CURDIR):/go/src/github.com/cosmos/cosmos-sdk" -w "/go/src/github.com/cosmos/cosmos-sdk" devdoc:local bash
-
-devdoc-save:
-	# TODO make this safer
-	$(call DEVDOC_SAVE)
-
-devdoc-clean:
-	docker rmi -f $$(docker images -f "dangling=true" -q)
-
-devdoc-update:
-	docker pull tendermint/devdoc
-
-.PHONY: devdoc devdoc-clean devdoc-init devdoc-save devdoc-update
-
 ###############################################################################
 ###                                Protobuf                                 ###
 ###############################################################################

diff --git a/SECURITY.md b/SECURITY.md
@@ -56,14 +56,14 @@ the code.
 The Cosmos SDK team uses the following disclosure process:
 
 1. After a security report is received, the Cosmos SDK team works to verify the issue and confirm its severity level using Common Vulnerability Scoring System (CVSS).
-1. The Cosmos SDK team collaborates with the Tendermint and Gaia teams to determine the vulnerability’s potential impact on the Cosmos Hub and partners.
+1. The Cosmos SDK team collaborates with the CometBFT and Gaia teams to determine the vulnerability’s potential impact on the Cosmos Hub and partners.
 1. Patches are prepared in private repositories for eligible releases of Cosmos SDK. See [Stable Release Policy](https://github.com/cosmos/cosmos-sdk/blob/main/RELEASE_PROCESS.md#stable-release-policy) for a list of eligible releases.
 1. If it is determined that a CVE-ID is required, we request a CVE through a CVE Numbering Authority.
 1. We notify the community that a security release is coming to give users time to prepare their systems for the update. Notifications can include forum posts, tweets, and emails to partners and validators.
 1. 24 hours after the notification, fixes are applied publicly and new releases are issued.
-1. The Gaia team updates their Tendermint Core and Cosmos SDK dependencies to use these releases and then issues new Gaia releases.
-1. After releases are available for Tendermint Core, Cosmos SDK, and Gaia, we notify the community again through the same channels. We also publish a Security Advisory on Github and publish the CVE, as long as the Security Advisory and the CVE do not include information on how to exploit these vulnerabilities beyond the information that is available in the patch.
-1. After the community is notified, Tendermint pays out any relevant bug bounties to submitters.
+1. The Gaia team updates their CometBFT and Cosmos SDK dependencies to use these releases and then issues new Gaia releases.
+1. After releases are available for CometBFT, Cosmos SDK, and Gaia, we notify the community again through the same channels. We also publish a Security Advisory on Github and publish the CVE, as long as the Security Advisory and the CVE do not include information on how to exploit these vulnerabilities beyond the information that is available in the patch.
+1. After the community is notified, the ICF pays out any relevant bug bounties to submitters.
 1. One week after the releases go out, we publish a post with details and our response to the vulnerability.
 
 This process can take some time. Every effort is made to handle the bug in as timely a manner as possible. However, it's important that we follow this security process to ensure that disclosures are handled consistently and to keep Cosmos SDK and its downstream dependent projects--including but not limited to Gaia and the Cosmos Hub--as secure as possible.

diff --git a/UPGRADING.md b/UPGRADING.md
@@ -4,6 +4,12 @@ This guide provides instructions for upgrading to specific versions of Cosmos SD
 
 ## [Unreleased]
 
+### Migration to CometBFT
+
+The SDK has migrated to [CometBFT](https://github.com/cometbft/cometbft), a fork of Tendermint Core.
+For migrating an app to CometBFT, all imports of Tendermint Core (`tendermint/tendermint`) must be replaced with CometBFT (`cometbft/cometbft`).
+Additionally, the app protobuf files must be re-generated.
+
 ### Configuration
 
 A new tool have been created for migrating configuration of the SDK. Use the following command to migrate your configuration:

diff --git a/client/context.go b/client/context.go
@@ -25,7 +25,7 @@ type PreprocessTxFn func(chainID string, key keyring.KeyType, tx TxBuilder) erro
 // handling and queries.
 type Context struct {
 	FromAddress       sdk.AccAddress
-	Client            TendermintRPC
+	Client            CometRPC
 	GRPCClient        *grpc.ClientConn
 	ChainID           string
 	Codec             codec.Codec
@@ -129,7 +129,7 @@ func (ctx Context) WithHeight(height int64) Context {
 
 // WithClient returns a copy of the context with an updated RPC client
 // instance.
-func (ctx Context) WithClient(client TendermintRPC) Context {
+func (ctx Context) WithClient(client CometRPC) Context {
 	ctx.Client = client
 	return ctx
 }

diff --git a/client/query.go b/client/query.go
@@ -20,7 +20,7 @@ import (
 
 // GetNode returns an RPC client. If the context's client is not defined, an
 // error is returned.
-func (ctx Context) GetNode() (TendermintRPC, error) {
+func (ctx Context) GetNode() (CometRPC, error) {
 	if ctx.Client == nil {
 		return nil, errors.New("no RPC client is defined in offline mode")
 	}

diff --git a/client/tendermint.go b/client/tendermint.go
@@ -7,9 +7,9 @@ import (
 	coretypes "github.com/cometbft/cometbft/rpc/core/types"
 )
 
-// TendermintRPC defines the interface of a Tendermint RPC client needed for
+// CometRPC defines the interface of a CometBFT RPC client needed for
 // queries and transaction handling.
-type TendermintRPC interface {
+type CometRPC interface {
 	rpcclient.ABCIClient
 
 	Validators(ctx context.Context, height *int64, page, perPage *int) (*coretypes.ResultValidators, error)

diff --git a/client/v2/go.mod b/client/v2/go.mod
@@ -8,7 +8,8 @@ require (
 	cosmossdk.io/depinject v1.0.0-alpha.3
 	github.com/cockroachdb/errors v1.9.1
 	github.com/cosmos/cosmos-proto v1.0.0-beta.1
-	github.com/cosmos/cosmos-sdk v0.47.0-rc2
+	// TODO to replace by a tagged version of the SDK (with CometBFT) when available
+	github.com/cosmos/cosmos-sdk v0.46.0-beta2.0.20230205135133-41a3dfeced29
 	github.com/spf13/cobra v1.6.1
 	github.com/spf13/pflag v1.0.5
 	google.golang.org/grpc v1.52.3
@@ -113,6 +114,3 @@ require (
 	pgregory.net/rapid v0.5.5 // indirect
 	sigs.k8s.io/yaml v1.3.0 // indirect
 )
-
-// This can be deleted after the CometBFT PR is merged
-replace github.com/cosmos/cosmos-sdk => ../..
diff --git a/client/v2/go.sum b/client/v2/go.sum
@@ -134,6 +134,8 @@ github.com/cosmos/cosmos-db v1.0.0-rc.1 h1:SjnT8B6WKMW9WEIX32qMhnEEKcI7ZP0+G1Sa9
 github.com/cosmos/cosmos-db v1.0.0-rc.1/go.mod h1:Dnmk3flSf5lkwCqvvjNpoxjpXzhxnCAFzKHlbaForso=
 github.com/cosmos/cosmos-proto v1.0.0-beta.1 h1:iDL5qh++NoXxG8hSy93FdYJut4XfgbShIocllGaXx/0=
 github.com/cosmos/cosmos-proto v1.0.0-beta.1/go.mod h1:8k2GNZghi5sDRFw/scPL8gMSowT1vDA+5ouxL8GjaUE=
+github.com/cosmos/cosmos-sdk v0.46.0-beta2.0.20230205135133-41a3dfeced29 h1:HJIOs0YfTumgmw8MU1QIiCHO+tz2IWoLpXNOXzLJqnE=
+github.com/cosmos/cosmos-sdk v0.46.0-beta2.0.20230205135133-41a3dfeced29/go.mod h1:9dul7UbanQCWIiz4b6FZ8QcKKU28EMgvXVNCTcc6Ivk=
 github.com/cosmos/go-bip39 v0.0.0-20180819234021-555e2067c45d/go.mod h1:tSxLoYXyBmiFeKpvmq4dzayMdCjCnu8uqmCysIGBT2Y=
 github.com/cosmos/go-bip39 v1.0.0 h1:pcomnQdrdH22njcAatO0yWojsUnCO3y2tNoV1cb6hHY=
 github.com/cosmos/go-bip39 v1.0.0/go.mod h1:RNJv0H/pOIVgxw6KS7QeX2a0Uo0aKUlfhZ4xuwvCdJw=

diff --git a/crypto/keys/multisig/amino.go b/crypto/keys/multisig/amino.go
@@ -10,7 +10,7 @@ import (
 // Amino JSON marshaling of LegacyAminoPubKey (see below for details).
 //
 // This struct is copy-pasted from:
-// https://github.com/tendermint/tendermint/blob/v0.33.9/crypto/multisig/threshold_pubkey.go
+// https://github.com/cometbft/cometbft/blob/v0.33.9/crypto/multisig/threshold_pubkey.go
 //
 // This struct was used in the SDK <=0.39. In 0.40 and the switch to protobuf,
 // it has been converted to LegacyAminoPubKey. However, there's one difference:

diff --git a/docs/architecture/adr-009-evidence-module.md b/docs/architecture/adr-009-evidence-module.md
@@ -164,7 +164,7 @@ type GenesisState struct {
   validators based on agreed upon slashing parameters.
 * Allows evidence types to be defined and handled by any module. This further allows
   slashing and jailing to be defined by more complex mechanisms.
-* Does not solely rely on Tendermint to submit evidence.
+* Does not solely rely on CometBFT to submit evidence.
 
 ### Negative
 

diff --git a/docs/architecture/adr-014-proportional-slashing.md b/docs/architecture/adr-014-proportional-slashing.md
@@ -28,7 +28,7 @@ slash_amount = k * (power_1 + power_2 + ... + power_n) // where power_i is the v
 
 Now, if someone splits a validator of 10% into two validators of 5% each which both fault, then they both fault in the same time frame, they both will get slashed at the sum 10% amount.
 
-However in practice, we likely don't want a linear relation between amount of stake at fault, and the percentage of stake to slash. In particular, solely 5% of stake double signing effectively did nothing to majorly threaten security, whereas 30% of stake being at fault clearly merits a large slashing factor, due to being very close to the point at which Tendermint security is threatened. A linear relation would require a factor of 6 gap between these two, whereas the difference in risk posed to the network is much larger. We propose using S-curves (formally [logistic functions](https://en.wikipedia.org/wiki/Logistic_function) to solve this). S-Curves capture the desired criterion quite well. They allow the slashing factor to be minimal for small values, and then grow very rapidly near some threshold point where the risk posed becomes notable.
+However in practice, we likely don't want a linear relation between amount of stake at fault, and the percentage of stake to slash. In particular, solely 5% of stake double signing effectively did nothing to majorly threaten security, whereas 30% of stake being at fault clearly merits a large slashing factor, due to being very close to the point at which CometBFT security is threatened. A linear relation would require a factor of 6 gap between these two, whereas the difference in risk posed to the network is much larger. We propose using S-curves (formally [logistic functions](https://en.wikipedia.org/wiki/Logistic_function) to solve this). S-Curves capture the desired criterion quite well. They allow the slashing factor to be minimal for small values, and then grow very rapidly near some threshold point where the risk posed becomes notable.
 
 #### Parameterization
 

diff --git a/docs/docs/building-modules/09-module-interfaces.md b/docs/docs/building-modules/09-module-interfaces.md
@@ -156,6 +156,6 @@ Modules that want to expose REST queries should add `google.api.http` annotation
 https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L14-L89
 ```
 
-gRPC gateway is started in-process along with the application and Tendermint. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/02-interact-node.md#configuring-the-node-using-apptoml).
+gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/02-interact-node.md#configuring-the-node-using-apptoml).
 
 The Cosmos SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../run-node/02-interact-node.md#configuring-the-node-using-apptoml) defines if swagger documentation should be automatically registered.
diff --git a/docs/docs/core/01-transactions.md b/docs/docs/core/01-transactions.md
@@ -194,6 +194,6 @@ Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gate
 
 An example can be seen [here](../run-node/03-txs.md#using-rest)
 
-#### Tendermint RPC
+#### CometBFT RPC
 
-The three methods presented above are actually higher abstractions over the Tendermint RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.tendermint.com/master/rpc/#/Tx). This means that you can use the Tendermint RPC endpoints directly to broadcast the transaction, if you wish so.
+The three methods presented above are actually higher abstractions over the CometBFT RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.tendermint.com/master/rpc/#/Tx). This means that you can use the CometBFT RPC endpoints directly to broadcast the transaction, if you wish so.
diff --git a/docs/docs/intro/01-why-app-specific.md b/docs/docs/intro/01-why-app-specific.md
@@ -21,7 +21,7 @@ Application-specific blockchains are blockchains customized to operate a single
                 |  |                               |  ^
 Blockchain node |  |           Consensus           |  |
                 |  |                               |  |
-                |  +-------------------------------+  |   Tendermint Core
+                |  +-------------------------------+  |   CometBFT
                 |  |                               |  |
                 |  |           Networking          |  |
                 |  |                               |  |
@@ -60,7 +60,7 @@ The list above contains a few examples that show how much flexibility applicatio
 
 decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance:
 
-* Developers of application-specific blockchains can choose to operate with a novel consensus engine such as Tendermint BFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throughput.
+* Developers of application-specific blockchains can choose to operate with a novel consensus engine such as CometBFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throughput.
 * An application-specific blockchain only operates a single application, so that the application does not compete with others for computation and storage. This is the opposite of most non-sharded virtual-machine blockchains today, where smart contracts all compete for computation and storage.
 * Even if a virtual-machine blockchain offered application-based sharding coupled with an efficient consensus algorithm, performance would still be limited by the virtual-machine itself. The real throughput bottleneck is the state-machine, and requiring transactions to be interpreted by a virtual-machine significantly increases the computational complexity of processing them.