Merge branch 'master' into add-rosetta-master

CHANGELOG.md

@@ -36,6 +36,10 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 ## [Unreleased]
 
+### Improvements
+
+* (tendermint) [\#8316](https://github.com/cosmos/cosmos-sdk/pull/8316) Bump Tendermint version to [v0.34.2](https://github.com/tendermint/tendermint/releases/tag/v0.34.2)
+
 ### Bug Fixes
 
   * (x/auth) [\#8287](https://github.com/cosmos/cosmos-sdk/pull/8287) Fix `tx sign --signature-only` to return correct sequence value in signature.

docs/migrations/chain-upgrade-guide-040.md

@@ -87,7 +87,7 @@ software and restore to their latest snapshot before restarting their nodes.
 1) If your chain is using IBC, make sure to add IBC initial genesis state to the genesis file. You can use the following command to add IBC initial genesis state to the genesis file.
 
    ```shell
-   cat new_040_genesis.json | jq '.app_state |= . + {"ibc":{"client_genesis":{"clients":[],"clients_consensus":[],"create_localhost":false},"connection_genesis":{"connections":[],"client_connection_paths":[]},"channel_genesis":{"channels":[],"acknowledgements":[],"commitments":[],"receipts":[],"send_sequences":[],"recv_sequences":[],"ack_sequences":[]}},"transfer":{"port_id":"transfer","denom_traces":[],"params":{"send_enabled":false,"receive_enabled":false}},"capability":{"index":"1","owners":[]}}' > new_040_genesis.json
+   cat new_v040_genesis.json | jq '.app_state |= . + {"ibc":{"client_genesis":{"clients":[],"clients_consensus":[],"create_localhost":false},"connection_genesis":{"connections":[],"client_connection_paths":[]},"channel_genesis":{"channels":[],"acknowledgements":[],"commitments":[],"receipts":[],"send_sequences":[],"recv_sequences":[],"ack_sequences":[]}},"transfer":{"port_id":"transfer","denom_traces":[],"params":{"send_enabled":false,"receive_enabled":false}},"capability":{"index":"1","owners":[]}}' > new_v040_genesis.json
    ```
 
    **Note:** This would add IBC state with IBC's `send_enabled: false` and `receive_enabled: false`. Make sure to update them to `true` in the above command if are planning to enable IBC transactions with chain upgrade. Otherwise you can do it via a governance proposal.

docs/run-node/README.md

@@ -12,3 +12,4 @@ This folder contains documentation on how to run a node and interact with it.
 1. [Running a Node](./run-node.md)
 1. [Interacting with a Node](./interact-node.md)
 1. [Generating, Signing and Broadcasting Transactions](./txs.md)
+1. [Cosmos Upgrade Manager](./cosmovisor.md)

docs/using-the-sdk/README.md

@@ -7,4 +7,3 @@ parent:
 
 - [Modules](../../x/README.md)
 - [Simulation](./simulation.md)
-- [Cosmos Upgrade Manager](./cosmovisor.md)

go.mod

@@ -46,7 +46,7 @@ require (
 	github.com/tendermint/cosmos-rosetta-gateway v0.3.0-rc1
 	github.com/tendermint/crypto v0.0.0-20191022145703-50d29ede1e15
 	github.com/tendermint/go-amino v0.16.0
-	github.com/tendermint/tendermint v0.34.1
+	github.com/tendermint/tendermint v0.34.2
 	github.com/tendermint/tm-db v0.6.3
 	golang.org/x/crypto v0.0.0-20201221181555-eec23a3978ad
 	golang.org/x/net v0.0.0-20200930145003-4acb6c075d10 // indirect

go.sum

@@ -647,8 +647,8 @@ github.com/tendermint/tendermint v0.34.0-rc4/go.mod h1:yotsojf2C1QBOw4dZrTcxbyxm
 github.com/tendermint/tendermint v0.34.0-rc6/go.mod h1:ugzyZO5foutZImv0Iyx/gOFCX6mjJTgbLHTwi17VDVg=
 github.com/tendermint/tendermint v0.34.0 h1:eXCfMgoqVSzrjzOj6clI9GAejcHH0LvOlRjpCmMJksU=
 github.com/tendermint/tendermint v0.34.0/go.mod h1:Aj3PIipBFSNO21r+Lq3TtzQ+uKESxkbA3yo/INM4QwQ=
-github.com/tendermint/tendermint v0.34.1 h1:TsJXY8+1NThc/XIENMv1ENzazriHBJJjeP6hN3kpC8g=
-github.com/tendermint/tendermint v0.34.1/go.mod h1:Aj3PIipBFSNO21r+Lq3TtzQ+uKESxkbA3yo/INM4QwQ=
+github.com/tendermint/tendermint v0.34.2 h1:bB4xReGw4jalTDeNg0npYoONuZrD55F90LrWPF4m/PQ=
+github.com/tendermint/tendermint v0.34.2/go.mod h1:Aj3PIipBFSNO21r+Lq3TtzQ+uKESxkbA3yo/INM4QwQ=
 github.com/tendermint/tm-db v0.6.2/go.mod h1:GYtQ67SUvATOcoY8/+x6ylk8Qo02BQyLrAs+yAcLvGI=
 github.com/tendermint/tm-db v0.6.3 h1:ZkhQcKnB8/2jr5EaZwGndN4owkPsGezW2fSisS9zGbg=
 github.com/tendermint/tm-db v0.6.3/go.mod h1:lfA1dL9/Y/Y8wwyPp2NMLyn5P5Ptr/gvDFNWtrCWSf8=

x/gov/spec/01_concepts.md

@@ -29,18 +29,24 @@ its unique `proposalID`.
 
 ### Proposal types
 
-In the initial version of the governance module, there are two types of
-proposal:
+In the initial version of the governance module, there are five types of
+proposals:
 
-- `PlainTextProposal` All the proposals that do not involve a modification of
+- `TextProposal` All the proposals that do not involve a modification of
   the source code go under this type. For example, an opinion poll would use a
-  proposal of type `PlainTextProposal`.
+  proposal of type `TextProposal`.
 - `SoftwareUpgradeProposal`. If accepted, validators are expected to update
   their software in accordance with the proposal. They must do so by following
   a 2-steps process described in the [Software Upgrade](#software-upgrade)
   section below. Software upgrade roadmap may be discussed and agreed on via
-  `PlainTextProposals`, but actual software upgrades must be performed via
+  `TextProposals`, but actual software upgrades must be performed via
   `SoftwareUpgradeProposals`.
+- `CommunityPoolSpendProposal` details a proposal for use of community funds,
+  together with how many coins are proposed to be spent, and to which recipient account.
+- `ParameterChangeProposal` defines a proposal to change one or 
+  more parameters. If accepted, the requested parameter change is updated 
+  automatically by the proposal handler upon conclusion of the voting period.
+- `CancelSoftwareUpgradeProposal` is a gov Content type for cancelling a software upgrade.
 
 Other modules may expand upon the governance module by implementing their own
 proposal types and handlers. These types are registered and processed through the

x/gov/spec/02_state.md

@@ -11,26 +11,14 @@ be one active parameter set at any given time. If governance wants to change a
 parameter set, either to modify a value or add/remove a parameter field, a new
 parameter set has to be created and the previous one rendered inactive.
 
-```go
-type DepositParams struct {
-  MinDeposit        sdk.Coins  //  Minimum deposit for a proposal to enter voting period.
-  MaxDepositPeriod  time.Time  //  Maximum period for Atom holders to deposit on a proposal. Initial value: 2 months
-}
-```
+### DepositParams
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L127-L145
 
-```go
-type VotingParams struct {
-  VotingPeriod      time.Time  //  Length of the voting period. Initial value: 2 weeks
-}
-```
+### VotingParams
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L147-L156
 
-```go
-type TallyParams struct {
-  Quorum            sdk.Dec  //  Minimum percentage of stake that needs to vote for a proposal to be considered valid
-  Threshold         sdk.Dec  //  Minimum proportion of Yes votes for proposal to pass. Initial value: 0.5
-  Veto              sdk.Dec  //  Minimum proportion of Veto votes to Total votes ratio for proposal to be vetoed. Initial value: 1/3
-}
-```
+### TallyParams
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L158-L183
 
 Parameters are stored in a global `GlobalParams` KVStore.
 
@@ -68,12 +56,7 @@ const (
 
 ## Deposit
 
-```go
-  type Deposit struct {
-    Amount      sdk.Coins       //  Amount of coins deposited by depositor
-    Depositor   crypto.address  //  Address of depositor
-  }
-```
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L43-L53
 
 ## ValidatorGovInfo
 
@@ -92,22 +75,7 @@ This type is used in a temp map when tallying
 what this proposal is about, and other fields, which are the mutable state of
 the governance process.
 
-```go
-type Proposal struct {
-	Content  // Proposal content interface
-
-	ProposalID       uint64
-	Status           ProposalStatus  // Status of the Proposal {Pending, Active, Passed, Rejected}
-	FinalTallyResult TallyResult     // Result of Tallies
-
-	SubmitTime     time.Time  // Time of the block where TxGovSubmitProposal was included
-	DepositEndTime time.Time  // Time that the Proposal would expire if deposit amount isn't met
-	TotalDeposit   sdk.Coins  // Current deposit on this proposal. Initial value is set at InitialDeposit
-
-	VotingStartTime time.Time  //  Time of the block where MinDeposit was reached. -1 if MinDeposit is not reached
-	VotingEndTime   time.Time  // Time that the VotingPeriod for this proposal will end and votes will be tallied
-}
-```
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L55-L77
 
 ```go
 type Content interface {

x/gov/spec/03_messages.md

@@ -6,18 +6,12 @@ order: 3
 
 ## Proposal Submission
 
-Proposals can be submitted by any Atom holder via a `TxGovSubmitProposal`
+Proposals can be submitted by any account via a `MsgSubmitProposal`
 transaction.
 
-```go
-type TxGovSubmitProposal struct {
-	Content        Content
-	InitialDeposit sdk.Coins
-	Proposer       sdk.AccAddress
-}
-```
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/tx.proto#L24-L39
 
-The `Content` of a `TxGovSubmitProposal` message must have an appropriate router
+The `Content` of a `MsgSubmitProposal` message must have an appropriate router
 set in the governance module.
 
 **State modifications:**
@@ -30,12 +24,12 @@ set in the governance module.
   - Push `proposalID` in `ProposalProcessingQueue`
 - Transfer `InitialDeposit` from the `Proposer` to the governance `ModuleAccount`
 
-A `TxGovSubmitProposal` transaction can be handled according to the following
+A `MsgSubmitProposal` transaction can be handled according to the following
 pseudocode.
 
 ```go
 // PSEUDOCODE //
-// Check if TxGovSubmitProposal is valid. If it is, create proposal //
+// Check if MsgSubmitProposal is valid. If it is, create proposal //
 
 upon receiving txGovSubmitProposal from sender do
 
@@ -79,14 +73,9 @@ upon receiving txGovSubmitProposal from sender do
 
 Once a proposal is submitted, if
 `Proposal.TotalDeposit < ActiveParam.MinDeposit`, Atom holders can send
-`TxGovDeposit` transactions to increase the proposal's deposit.
+`MsgDeposit` transactions to increase the proposal's deposit.
 
-```go
-type TxGovDeposit struct {
-  ProposalID    int64       // ID of the proposal
-  Deposit       sdk.Coins   // Number of Atoms to add to the proposal's deposit
-}
-```
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/tx.proto#L61-L72
 
 **State modifications:**
 
@@ -97,12 +86,12 @@ type TxGovDeposit struct {
   - Push `proposalID` in `ProposalProcessingQueueEnd`
 - Transfer `Deposit` from the `proposer` to the governance `ModuleAccount`
 
-A `TxGovDeposit` transaction has to go through a number of checks to be valid.
+A `MsgDeposit` transaction has to go through a number of checks to be valid.
 These checks are outlined in the following pseudocode.
 
 ```go
 // PSEUDOCODE //
-// Check if TxGovDeposit is valid. If it is, increase deposit and check if MinDeposit is reached
+// Check if MsgDeposit is valid. If it is, increase deposit and check if MinDeposit is reached
 
 upon receiving txGovDeposit from sender do
   // check if proposal is correctly formatted. Includes fee payment.
@@ -149,28 +138,23 @@ upon receiving txGovDeposit from sender do
 ## Vote
 
 Once `ActiveParam.MinDeposit` is reached, voting period starts. From there,
-bonded Atom holders are able to send `TxGovVote` transactions to cast their
+bonded Atom holders are able to send `MsgVote` transactions to cast their
 vote on the proposal.
 
-```go
-  type TxGovVote struct {
-    ProposalID           int64         //  proposalID of the proposal
-    Vote                 byte          //  option from OptionSet chosen by the voter
-  }
-```
++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/tx.proto#L46-L56
 
 **State modifications:**
 
 - Record `Vote` of sender
 
 _Note: Gas cost for this message has to take into account the future tallying of the vote in EndBlocker_
 
-Next is a pseudocode proposal of the way `TxGovVote` transactions are
+Next is a pseudocode outline of the way `MsgVote` transactions are
 handled:
 
 ```go
   // PSEUDOCODE //
-  // Check if TxGovVote is valid. If it is, count vote//
+  // Check if MsgVote is valid. If it is, count vote//
 
   upon receiving txGovVote from sender do
     // check if proposal is correctly formatted. Includes fee payment.