Merge branch 'main' into alex/20085_bench

* main: refactor(x/feegrant): set environment in context (#20529) refactor(x/accounts)!: accounts and auth module use the same account number tracking (#20405) chore: remove sonar from simapp (#20528) docs: add docs on permissions (#20526) refactor(x/gov): set environment in context for legacy proposals (#20521) docs: migrate diagrams to mermaidjs (#20503) refactor(tools/hubl): don't use nil panic (#20515) refactor(x/authz): set environment in context (#20502) build(deps): Bump github.com/spf13/viper from 1.18.2 to 1.19.0 (#20519) feat(x/bank): Placing SendRestriction before Deduction of Coins in SendCoins (#20517) chore: sonar ignore directories with their own go.mods (#20509) ci: run action in merge queue (#20508) refactor(server/v2/cometbft): update function comments (#20506)
cosmos · Jun 3, 2024 · 53a7f4d · 53a7f4d
2 parents b66871a + d1aab15
commit 53a7f4d
Show file tree

Hide file tree

Showing 124 changed files with 858 additions and 487 deletions.
diff --git a/.github/workflows/pr-go-mod-tidy-mocks.yml b/.github/workflows/pr-go-mod-tidy-mocks.yml
@@ -1,6 +1,8 @@
-name: 'Checks dependencies and mocks generation'
+name: "Checks dependencies and mocks generation"
 on:
+  merge_group:
   pull_request:
+  push:
     branches:
       - main
 

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -454,14 +454,6 @@ jobs:
         run: |
           cd simapp
           go test -mod=readonly -timeout 30m -tags='app_v1 norace ledger test_ledger_mock' ./...
-      - name: sonarcloud
-        if: ${{ env.GIT_DIFF && !github.event.pull_request.draft && env.SONAR_TOKEN != null }}
-        uses: SonarSource/sonarcloud-github-action@master
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
-        with:
-          projectBaseDir: simapp/
 
   test-collections:
     runs-on: ubuntu-latest

diff --git a/.golangci.yml b/.golangci.yml
@@ -1,19 +1,8 @@
 run:
   tests: true
   timeout: 15m
-  sort-results: true
   allow-parallel-runners: true
-  exclude-dir: testutil/testdata
-  skip-files:
-    - server/grpc/gogoreflection/fix_registration.go
-    - "fix_registration.go"
-    - ".*\\.pb\\.go$"
-    - ".*\\.pb\\.gw\\.go$"
-    - ".*\\.pulsar\\.go$"
-    - crypto/keys/secp256k1/internal/*
-    - types/coin_regex.go
-
-build-tags:
+  build-tags:
   - e2e
   - ledger
   - test_ledger_mock
@@ -46,6 +35,16 @@ linters:
     - unused
 
 issues:
+  exclude-dirs: 
+    - testutil/testdata
+  exclude-files:
+    - server/grpc/gogoreflection/fix_registration.go
+    - "fix_registration.go"
+    - ".*\\.pb\\.go$"
+    - ".*\\.pb\\.gw\\.go$"
+    - ".*\\.pulsar\\.go$"
+    - crypto/keys/secp256k1/internal/*
+    - types/coin_regex.go
   exclude-rules:
     - text: "Use of weak random number generator"
       linters:
@@ -141,11 +140,8 @@ linters-settings:
     extra-rules: true
   dogsled:
     max-blank-identifiers: 6
-  maligned:
-    suggest-new: true
   nolintlint:
     allow-unused: false
-    allow-leading-space: true
     require-explanation: true
     require-specific: false
   gosimple:

diff --git a/UPGRADING.md b/UPGRADING.md
@@ -682,6 +682,15 @@ To learn more see the [docs](https://docs.cosmos.network/main/learn/advanced/tra
 
 ### Modules
 
+<!-- create server/v2 changes docs and mention it here
+	* mention changes in tx validators
+	* mention changes with appmodulev2
+	* mention changes with sdk context removal
+	* mention changes with environment
+	* mention changes with environment in context in interfaces
+	* mention legacy proposal in gov when using server/v2 if using sdk context must be rewritten
+-->
+
 #### `**all**`
 
 * [RFC 001](https://docs.cosmos.network/main/rfc/rfc-001-tx-validation) has defined a simplification of the message validation process for modules.

diff --git a/client/v2/go.mod b/client/v2/go.mod
@@ -139,7 +139,7 @@ require (
 	github.com/sourcegraph/conc v0.3.0 // indirect
 	github.com/spf13/afero v1.11.0 // indirect
 	github.com/spf13/cast v1.6.0 // indirect
-	github.com/spf13/viper v1.18.2 // indirect
+	github.com/spf13/viper v1.19.0 // indirect
 	github.com/stretchr/testify v1.9.0
 	github.com/subosito/gotenv v1.6.0 // indirect
 	github.com/supranational/blst v0.3.11 // indirect
@@ -154,7 +154,7 @@ require (
 	go.opencensus.io v0.24.0 // indirect
 	go.uber.org/multierr v1.11.0 // indirect
 	golang.org/x/crypto v0.23.0 // indirect
-	golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842 // indirect
+	golang.org/x/exp v0.0.0-20240531132922-fd00a4e0eefc // indirect
 	golang.org/x/mod v0.17.0 // indirect
 	golang.org/x/net v0.25.0 // indirect
 	golang.org/x/sync v0.7.0 // indirect

diff --git a/client/v2/go.sum b/client/v2/go.sum
@@ -456,8 +456,8 @@ github.com/spf13/cobra v1.8.0 h1:7aJaZx1B85qltLMc546zn58BxxfZdR/W22ej9CFoEf0=
 github.com/spf13/cobra v1.8.0/go.mod h1:WXLWApfZ71AjXPya3WOlMsY9yMs7YeiHhFVlvLyhcho=
 github.com/spf13/pflag v1.0.5 h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA=
 github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
-github.com/spf13/viper v1.18.2 h1:LUXCnvUvSM6FXAsj6nnfc8Q2tp1dIgUfY9Kc8GsSOiQ=
-github.com/spf13/viper v1.18.2/go.mod h1:EKmWIqdnk5lOcmR72yw6hS+8OPYcwD0jteitLMVB+yk=
+github.com/spf13/viper v1.19.0 h1:RWq5SEjt8o25SROyN3z2OrDB9l7RPd3lwTWU8EcEdcI=
+github.com/spf13/viper v1.19.0/go.mod h1:GQUN9bilAbhU/jgc1bKs99f/suXKeUMct8Adx5+Ntkg=
 github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
 github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
 github.com/stretchr/objx v0.4.0/go.mod h1:YvHI0jy2hoMjB+UWwv71VJQ9isScKT/TqJzVSSt89Yw=
@@ -518,8 +518,8 @@ golang.org/x/crypto v0.0.0-20200728195943-123391ffb6de/go.mod h1:LzIPMQfyMNhhGPh
 golang.org/x/crypto v0.23.0 h1:dIJU/v2J8Mdglj/8rJ6UUOM3Zc9zLZxVZwwxMooUSAI=
 golang.org/x/crypto v0.23.0/go.mod h1:CKFgDieR+mRhux2Lsu27y0fO304Db0wZe70UKqHu0v8=
 golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
-golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842 h1:vr/HnozRka3pE4EsMEg1lgkXJkTFJCVUX+S/ZT6wYzM=
-golang.org/x/exp v0.0.0-20240506185415-9bf2ced13842/go.mod h1:XtvwrStGgqGPLc4cjQfWqZHG1YFdYs6swckp8vpsjnc=
+golang.org/x/exp v0.0.0-20240531132922-fd00a4e0eefc h1:O9NuF4s+E/PvMIy+9IUZB9znFwUIXEWSstNjek6VpVg=
+golang.org/x/exp v0.0.0-20240531132922-fd00a4e0eefc/go.mod h1:XtvwrStGgqGPLc4cjQfWqZHG1YFdYs6swckp8vpsjnc=
 golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
 golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU=
 golang.org/x/lint v0.0.0-20190313153728-d0100b6bd8b3/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=

diff --git a/core/context/context.go b/core/context/context.go
@@ -6,3 +6,8 @@ const (
 	ExecModeKey  contextKey = iota
 	CometInfoKey contextKey = iota
 )
+
+// EnvironmentContextKey is the context key for the environment.
+// A caller should not assume the environment is available in each context.
+// ref: https://github.com/cosmos/cosmos-sdk/issues/19640
+var EnvironmentContextKey = struct{}{}
diff --git a/docs/build/building-modules/00-intro.md b/docs/build/building-modules/00-intro.md
@@ -42,6 +42,15 @@ flowchart TD
 
 As a result of this architecture, building a Cosmos SDK application usually revolves around writing modules to implement the specialized logic of the application and composing them with existing modules to complete the application. Developers will generally work on modules that implement logic needed for their specific use case that do not exist yet, and will use existing modules for more generic functionalities like staking, accounts, or token management.
 
+
+### Modules as Sudo
+
+Modules have the ability to perform actions that are not available to regular users. This is because modules are given sudo permissions by the state machine. Modules can reject another modules desire to execute a function but this logic must be explicit. Examples of this can be seen when modules create functions to modify parameters:
+
+```go reference
+https://github.com/cosmos/cosmos-sdk/blob/61da5d1c29c16a1eb5bb5488719fde604ec07b10/x/bank/keeper/msg_server.go#L147-L149
+```
+
 ## How to Approach Building Modules as a Developer
 
 While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them:

diff --git a/docs/learn/beginner/00-app-anatomy.md b/docs/learn/beginner/00-app-anatomy.md
@@ -12,22 +12,31 @@ This document describes the core parts of a Cosmos SDK application, represented
 
 The Daemon, or [Full-Node Client](../advanced/03-node.md), is the core process of a Cosmos SDK-based blockchain. Participants in the network run this process to initialize their state-machine, connect with other full-nodes, and update their state-machine as new blocks come in.
 
-```text
-                ^  +-------------------------------+  ^
-                |  |                               |  |
-                |  |  State-machine = Application  |  |
-                |  |                               |  |   Built with Cosmos SDK
-                |  |            ^      +           |  |
-                |  +----------- | ABCI | ----------+  v
-                |  |            +      v           |  ^
-                |  |                               |  |
-Blockchain Node |  |           Consensus           |  |
-                |  |                               |  |
-                |  +-------------------------------+  |   CometBFT
-                |  |                               |  |
-                |  |           Networking          |  |
-                |  |                               |  |
-                v  +-------------------------------+  v
+```mermaid
+flowchart TD
+    subgraph Blockchain_Node[Blockchain Node]
+        subgraph SM[State-machine = Application]
+            direction TB
+            SM1[Cosmos SDK]
+        end
+        subgraph ABCI[ABCI]
+            direction TB
+        end
+        subgraph Consensus[Consensus]
+            direction TB
+        end
+        subgraph Networking[Networking]
+            direction TB
+        end
+    end
+
+    SM <--> ABCI
+    ABCI <--> Consensus
+    Consensus <--> Networking
+
+    Blockchain_Node -->|Includes| SM
+    Blockchain_Node -->|Includes| Consensus
+    Blockchain_Node -->|Includes| Networking
 ```
 
 The blockchain full-node presents itself as a binary, generally suffixed by `-d` for "daemon" (e.g. `appd` for `app` or `gaiad` for `gaia`). This binary is built by running a simple [`main.go`](../advanced/03-node.md#main-function) function placed in `./cmd/appd/`. This operation usually happens through the [Makefile](#dependencies-and-makefile).
@@ -112,13 +121,15 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/app.go#L626-L63
 
 There are two semantics around the new lifecycle method:
 
-- It runs before the `BeginBlocker` of all modules
-- It can modify consensus parameters in storage, and signal the caller through the return value.
+* It runs before the `BeginBlocker` of all modules
+* It can modify consensus parameters in storage, and signal the caller through the return value.
 
 When it returns `ConsensusParamsChanged=true`, the caller must refresh the consensus parameter in the finalize context:
+
 ```
 app.finalizeBlockState.ctx = app.finalizeBlockState.ctx.WithConsensusParams(app.GetConsensusParams())
 ```
+
 The new ctx must be passed to all the other lifecycle methods.
 
 ### BeginBlocker and EndBlocker

diff --git a/docs/learn/beginner/01-tx-lifecycle.md b/docs/learn/beginner/01-tx-lifecycle.md
@@ -163,46 +163,13 @@ that receive a block proposal from the correct proposer execute the transactions
 As mentioned throughout the documentation `BeginBlock`, `ExecuteTx` and `EndBlock` are called within FinalizeBlock. 
 Although every full-node operates individually and locally, the outcome is always consistent and unequivocal. This is because the state changes brought about by the messages are predictable, and the transactions are specifically sequenced in the proposed block.
 
-```text
-        --------------------------
-        | Receive Block Proposal |
-        --------------------------
-                    |
-                    v
-        -------------------------
-        |     FinalizeBlock      |
-        -------------------------
-                    |
-                    v
-            -------------------
-            |   BeginBlock     | 
-            -------------------
-                    |
-                    v
-            --------------------
-            | ExecuteTx(tx0)   |
-            | ExecuteTx(tx1)   |
-            | ExecuteTx(tx2)   |
-            | ExecuteTx(tx3)   |
-            |       .          |
-            |       .          |
-            |       .          |
-            -------------------
-                    |
-                    v
-            --------------------
-            |    EndBlock      |
-            --------------------
-                    |
-                    v
-        -------------------------
-        |       Consensus        |
-        -------------------------
-                    |
-                    v
-        -------------------------
-        |         Commit         |
-        -------------------------
+```mermaid
+ flowchart TD
+    A[Receive Block Proposal] --> B[FinalizeBlock]
+    B --> C[BeginBlock]
+    C --> D["ExecuteTx(tx0, tx1, 1x2)"]
+    D --> E[EndBlock]
+    E --> F[Commit]
 ```
 
 ### Transaction Execution

diff --git a/docs/learn/beginner/03-accounts.md b/docs/learn/beginner/03-accounts.md
@@ -21,44 +21,21 @@ In the Cosmos SDK, an _account_ designates a pair of _public key_ `PubKey` and _
 
 For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The BIP32 allows users to create an HD wallet (as specified in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) - a set of accounts derived from an initial secret seed. A seed is usually created from a 12- or 24-word mnemonic. A single seed can derive any number of `PrivKey`s using a one-way cryptographic function. Then, a `PubKey` can be derived from the `PrivKey`. Naturally, the mnemonic is the most sensitive information, as private keys can always be re-generated if the mnemonic is preserved.
 
-```text
-     Account 0                         Account 1                         Account 2
-
-+------------------+              +------------------+               +------------------+
-|                  |              |                  |               |                  |
-|    Address 0     |              |    Address 1     |               |    Address 2     |
-|        ^         |              |        ^         |               |        ^         |
-|        |         |              |        |         |               |        |         |
-|        |         |              |        |         |               |        |         |
-|        |         |              |        |         |               |        |         |
-|        +         |              |        +         |               |        +         |
-|  Public key 0    |              |  Public key 1    |               |  Public key 2    |
-|        ^         |              |        ^         |               |        ^         |
-|        |         |              |        |         |               |        |         |
-|        |         |              |        |         |               |        |         |
-|        |         |              |        |         |               |        |         |
-|        +         |              |        +         |               |        +         |
-|  Private key 0   |              |  Private key 1   |               |  Private key 2   |
-|        ^         |              |        ^         |               |        ^         |
-+------------------+              +------------------+               +------------------+
-         |                                 |                                  |
-         |                                 |                                  |
-         |                                 |                                  |
-         +--------------------------------------------------------------------+
-                                           |
-                                           |
-                                 +---------+---------+
-                                 |                   |
-                                 |  Master PrivKey   |
-                                 |                   |
-                                 +-------------------+
-                                           |
-                                           |
-                                 +---------+---------+
-                                 |                   |
-                                 |  Mnemonic (Seed)  |
-                                 |                   |
-                                 +-------------------+
+```mermaid
+graph BT
+    A0A[Address 0] --> A0[Account 0]
+    A0PK[Public key 0] --> A0A[Address 0]
+    A0SK[Private key 0] --> A0PK[Public key 0]
+    A1A[Address 1] --> A1[Account 1]
+    A1PK[Public key 1] --> A1A[Address 1]
+    A1SK[Private key 1] --> A1PK[Public key 1]
+    A2A[Address 2] --> A2[Account 2]
+    A2PK[Public key 2] --> A2A[Address 2]
+    A2SK[Private key 2] --> A2PK[Public key 2]
+    MasterPK[Master PrivKey] --> A0SK[Private key 0]
+    MasterPK[Master PrivKey] --> A1SK[Private key 1]
+    MasterPK[Master PrivKey] --> A2SK[Private key 2]
+    Mnemonic["Mnemonic (Seed)"] --> MasterPK[Master PrivKey]
 ```
 
 In the Cosmos SDK, keys are stored and managed by using an object called a [`Keyring`](#keyring).

diff --git a/docs/learn/intro/01-why-app-specific.md b/docs/learn/intro/01-why-app-specific.md
@@ -12,20 +12,28 @@ This document explains what application-specific blockchains are, and why develo
 
 Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralized application on top of an underlying blockchain like Ethereum, developers build their own blockchain from the ground up. This means building a full-node client, a light-client, and all the necessary interfaces (CLI, REST, ...) to interact with the nodes.
 
-```text
-                ^  +-------------------------------+  ^
-                |  |                               |  |   Built with Cosmos SDK
-                |  |  State-machine = Application  |  |
-                |  |                               |  v
-                |  +-------------------------------+
-                |  |                               |  ^
-Blockchain node |  |           Consensus           |  |
-                |  |                               |  |
-                |  +-------------------------------+  |   CometBFT
-                |  |                               |  |
-                |  |           Networking          |  |
-                |  |                               |  |
-                v  +-------------------------------+  v
+```mermaid
+flowchart TD
+    subgraph Blockchain_Node[Blockchain Node]
+        subgraph SM[State-machine]
+            direction TB
+            SM1[Cosmos SDK]
+        end
+        subgraph Consensus[Consensus]
+            direction TB
+        end
+        subgraph Networking[Networking]
+            direction TB
+        end
+    end
+
+    SM <--> Consensus
+    Consensus <--> Networking
+
+
+    Blockchain_Node -->|Includes| SM
+    Blockchain_Node -->|Includes| Consensus
+    Blockchain_Node -->|Includes| Networking
 ```
 
 ## What are the shortcomings of Smart Contracts