-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
2d1f472
commit c7d8c0d
Showing
12 changed files
with
276 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
{ | ||
"label": "Develop", | ||
"position": 0, | ||
"link": null | ||
"label": "Develop", | ||
"position": 0, | ||
"link": null | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
--- | ||
sidebar_position: 0 | ||
slug : /modules | ||
--- | ||
|
||
# Module Summary | ||
|
||
Here are some production-grade modules that can be used in Cosmos SDK applications, along with their respective documentation: | ||
|
||
* [Auth](auth/README.md) - Authentication of accounts and transactions for Cosmos SDK applications. | ||
* [Authz](authz/README.md) - Authorization for accounts to perform actions on behalf of other accounts. | ||
* [Bank](bank/README.md) - Token transfer functionalities. | ||
* [Crisis](crisis/README.md) - Halting the blockchain under certain circumstances (e.g. if an invariant is broken). | ||
* [Distribution](distribution/README.md) - Fee distribution, and staking token provision distribution. | ||
* [Evidence](evidence/README.md) - Evidence handling for double signing, misbehaviour, etc. | ||
* [Feegrant](feegrant/README.md) - Grant fee allowances for executing transactions. | ||
* [Governance](gov/README.md) - On-chain proposals and voting. | ||
* [Mint](mint/README.md) - Creation of new units of staking token. | ||
* [Params](params/README.md) - Globally available parameter store. | ||
* [Staking](staking/README.md) - Proof-of-Stake layer for public blockchains. | ||
* [Upgrade](upgrade/README.md) - Software upgrades handling and coordination. | ||
|
||
To learn more about the process of building modules, visit the [building modules reference documentation](https://docs.cosmos.network/main/building-modules/intro). | ||
|
||
## IBC | ||
|
||
The IBC module for the SDK is maintained by the IBC Go team in its [own repository](https://github.com/cosmos/ibc-go). | ||
|
||
Additionally, the [capability module](https://github.com/cosmos/ibc-go/tree/fdd664698d79864f1e00e147f9879e58497b5ef1/modules/capability) is from v0.48+ maintained by the IBC Go team in its [own repository](https://github.com/cosmos/ibc-go/tree/fdd664698d79864f1e00e147f9879e58497b5ef1/modules/capability). | ||
|
||
## CosmWasm | ||
|
||
The CosmWasm module enables smart contracts, learn more by going to their [documentation site](https://book.cosmwasm.com/), or visit [the repository](https://github.com/CosmWasm/cosmwasm). | ||
|
||
## EVM | ||
|
||
Read more about writing smart contracts with solidity at the official [`evm` documentation page](https://docs.evmos.org/modules/evm/). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
--- | ||
sidebar_position: 1 | ||
--- | ||
|
||
# Requests for Comments | ||
|
||
A Request for Comments (RFC) is a record of discussion on an open-ended topic | ||
related to the design and implementation of the Cosmos SDK, for which no | ||
immediate decision is required. | ||
|
||
The purpose of an RFC is to serve as a historical record of a high-level | ||
discussion that might otherwise only be recorded in an ad-hoc way (for example, | ||
via gists or Google docs) that are difficult to discover for someone after the | ||
fact. An RFC _may_ give rise to more specific architectural _decisions_ for | ||
the Cosmos SDK, but those decisions must be recorded separately in | ||
[Architecture Decision Records (ADR)](../architecture). | ||
|
||
As a rule of thumb, if you can articulate a specific question that needs to be | ||
answered, write an ADR. If you need to explore the topic and get input from | ||
others to know what questions need to be answered, an RFC may be appropriate. | ||
|
||
## RFC Content | ||
|
||
An RFC should provide: | ||
|
||
* A **changelog**, documenting when and how the RFC has changed. | ||
* An **abstract**, briefly summarizing the topic so the reader can quickly tell | ||
whether it is relevant to their interest. | ||
* Any **background** a reader will need to understand and participate in the | ||
substance of the discussion (links to other documents are fine here). | ||
* The **discussion**, the primary content of the document. | ||
|
||
The [rfc-template.md](rfc-template.md) file includes placeholders for these | ||
sections. |
93 changes: 93 additions & 0 deletions
93
versioned_docs/version-0.46/integrate/building-modules/11-structure.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,93 @@ | ||
--- | ||
sidebar_position: 1 | ||
--- | ||
|
||
# Recommended Folder Structure | ||
|
||
:::note Synopsis | ||
This document outlines the recommended structure of Cosmos SDK modules. These ideas are meant to be applied as suggestions. Application developers are encouraged to improve upon and contribute to module structure and development design. | ||
::: | ||
|
||
## Structure | ||
|
||
A typical Cosmos SDK module can be structured as follows: | ||
|
||
```shell | ||
proto | ||
└── {project_name} | ||
└── {module_name} | ||
└── {proto_version} | ||
├── {module_name}.proto | ||
├── event.proto | ||
├── genesis.proto | ||
├── query.proto | ||
└── tx.proto | ||
``` | ||
|
||
* `{module_name}.proto`: The module's common message type definitions. | ||
* `event.proto`: The module's message type definitions related to events. | ||
* `genesis.proto`: The module's message type definitions related to genesis state. | ||
* `query.proto`: The module's Query service and related message type definitions. | ||
* `tx.proto`: The module's Msg service and related message type definitions. | ||
|
||
```shell | ||
x/{module_name} | ||
├── client | ||
│ ├── cli | ||
│ │ ├── query.go | ||
│ │ └── tx.go | ||
│ └── testutil | ||
│ ├── cli_test.go | ||
│ └── suite.go | ||
├── exported | ||
│ └── exported.go | ||
├── keeper | ||
│ ├── genesis.go | ||
│ ├── grpc_query.go | ||
│ ├── hooks.go | ||
│ ├── invariants.go | ||
│ ├── keeper.go | ||
│ ├── keys.go | ||
│ ├── msg_server.go | ||
│ └── querier.go | ||
├── module | ||
│ └── module.go | ||
│ └── abci.go | ||
├── simulation | ||
│ ├── decoder.go | ||
│ ├── genesis.go | ||
│ ├── operations.go | ||
│ └── params.go | ||
├── {module_name}.pb.go | ||
├── codec.go | ||
├── errors.go | ||
├── events.go | ||
├── events.pb.go | ||
├── expected_keepers.go | ||
├── genesis.go | ||
├── genesis.pb.go | ||
├── keys.go | ||
├── msgs.go | ||
├── params.go | ||
├── query.pb.go | ||
├── tx.pb.go | ||
└── 05-depinject.md | ||
``` | ||
|
||
* `client/`: The module's CLI client functionality implementation and the module's CLI testing suite. | ||
* `exported/`: The module's exported types - typically interface types. If a module relies on keepers from another module, it is expected to receive the keepers as interface contracts through the `expected_keepers.go` file (see below) in order to avoid a direct dependency on the module implementing the keepers. However, these interface contracts can define methods that operate on and/or return types that are specific to the module that is implementing the keepers and this is where `exported/` comes into play. The interface types that are defined in `exported/` use canonical types, allowing for the module to receive the keepers as interface contracts through the `expected_keepers.go` file. This pattern allows for code to remain DRY and also alleviates import cycle chaos. | ||
* `keeper/`: The module's `Keeper` and `MsgServer` implementation. | ||
* `module/`: The module's `AppModule` and `AppModuleBasic` implementation. | ||
* `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). | ||
* `simulation/`: The module's [simulation](14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`). | ||
* `REAMDE.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../spec/SPEC_MODULE.md). | ||
* The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. | ||
* `codec.go`: The module's registry methods for interface types. | ||
* `errors.go`: The module's sentinel errors. | ||
* `events.go`: The module's event types and constructors. | ||
* `expected_keepers.go`: The module's [expected keeper](06-keeper.md#type-definition) interfaces. | ||
* `genesis.go`: The module's genesis state methods and helper functions. | ||
* `keys.go`: The module's store keys and associated helper functions. | ||
* `msgs.go`: The module's message type definitions and associated methods. | ||
* `params.go`: The module's parameter type definitions and associated methods. | ||
* `*.pb.go`: The module's type definitions generated by Protocol Buffers (as defined in the respective `*.proto` files above). |
Oops, something went wrong.