diff --git a/docs/architecture/adr-040-storage-and-smt-state-commitments.md b/docs/architecture/adr-040-storage-and-smt-state-commitments.md index 9fc57e8c60c6..3d5f40087229 100644 --- a/docs/architecture/adr-040-storage-and-smt-state-commitments.md +++ b/docs/architecture/adr-040-storage-and-smt-state-commitments.md @@ -258,8 +258,6 @@ We change the storage layout of the state machine, a storage hard fork and netwo ## Alternative designs -Most of the alternative designs were evaluated in [state commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h). - Ethereum research published [Verkle Trie](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) - an idea of combining polynomial commitments with merkle tree in order to reduce the tree height. This concept has a very good potential, but we think it's too early to implement it. The current, SMT based design could be easily updated to the Verkle Trie once other research implement all necessary libraries. The main advantage of the design described in this ADR is the separation of state commitments from the data storage and designing a more powerful interface. ## Further Discussions @@ -280,7 +278,6 @@ We were discussing use case where modules can use a support database, which is n * [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100) * [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of its state v0.15 -* [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h) * [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt) * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf) * [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf). diff --git a/docs/build/build.md b/docs/build/build.md index 3ae4eea94db0..487ea5be53d0 100644 --- a/docs/build/build.md +++ b/docs/build/build.md @@ -4,7 +4,7 @@ sidebar_position: 0 # Build -* [Building Apps](./building-apps/00-app-go.md) - The documentation in this section will guide you through the process of developing your dApp using the Cosmos SDK framework. +* [Building Apps](./building-apps/00-runtime.md) - The documentation in this section will guide you through the process of developing your dApp using the Cosmos SDK framework. * [Modules](./modules/README.md) - Information about the various modules available in the Cosmos SDK: Accounts, Auth, Authz, Bank, Circuit, Consensus, Distribution, Epochs, Evidence, Feegrant, Genutil, Governance, Group, Mint, NFT, Protocolpool, Slashing, Staking, Tx, Upgrade, Validate. * [Migrations](./migrations/01-intro.md) - See what has been updated in each release the process of the transition between versions. * [Packages](./packages/README.md) - Explore a curated collection of pre-built modules and functionalities, streamlining the development process. diff --git a/docs/build/building-apps/00-runtime.md b/docs/build/building-apps/00-runtime.md index 5da91a65396e..838905750574 100644 --- a/docs/build/building-apps/00-runtime.md +++ b/docs/build/building-apps/00-runtime.md @@ -134,7 +134,7 @@ An application only needs to call `AppBuilder.Build` to create a fully configure https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.2/runtime/builder.go#L36-L80 ``` -More information on building applications can be found in the [next section](./02-app-building.md). +More information on building applications can be found in the [next section](./02-app-go-di.md). ## Best Practices diff --git a/docs/build/building-modules/16-testing.md b/docs/build/building-modules/16-testing.md index 6b9441bbee06..828a1f72b23f 100644 --- a/docs/build/building-modules/16-testing.md +++ b/docs/build/building-modules/16-testing.md @@ -61,7 +61,7 @@ The goal of these integration tests is to test how a component interacts with ot Integration tests interact with the tested module via the defined `Msg` and `Query` services. The result of the test can be verified by checking the state of the application, by checking the emitted events or the response. It is advised to combine two of these methods to verify the result of the test. -The SDK provides small helpers for quickly setting up an integration tests. These helpers can be found at . +The SDK provides small helpers for quickly setting up an integration tests. These helpers can be found at . ### Example diff --git a/docs/learn/advanced/00-baseapp.md b/docs/learn/advanced/00-baseapp.md index 8fea13d4fd39..0017d3accd1f 100644 --- a/docs/learn/advanced/00-baseapp.md +++ b/docs/learn/advanced/00-baseapp.md @@ -309,7 +309,7 @@ Unconfirmed transactions are relayed to peers only if they pass `CheckTx`. `CheckTx()` can perform both _stateful_ and _stateless_ checks, but developers should strive to make the checks **lightweight** because gas fees are not charged for the resources (CPU, data load...) used during the `CheckTx`. -The [`Context`](../advanced/02-context.md), which includes a `GasMeter` that tracks how much gas is used during the execution of `Tx`, is initialized at the beginning of `CheckTx`. The user-provided amount of gas for `Tx` is referred to as `GasWanted`. If `GasConsumed`, the amount of gas used during execution, exceeds `GasWanted`, the execution is halted and the changes made to the cached copy of the state are not committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes ensure that the user-specified `gas-prices` exceed their locally defined `min-gas-prices`. +The [`Core pkg`](../advanced/02-core.md), which includes a `GasService` that tracks how much gas is used during the execution of `Tx`, is initialized at the beginning of `CheckTx`. The user-provided amount of gas for `Tx` is referred to as `GasWanted`. If `GasConsumed`, the amount of gas used during execution, exceeds `GasWanted`, the execution is halted and the changes made to the cached copy of the state are not committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes ensure that the user-specified `gas-prices` exceed their locally defined `min-gas-prices`. In the Cosmos SDK, after [decoding transactions](./05-encoding.md), `CheckTx()` is implemented to do the following checks: diff --git a/docs/learn/advanced/04-store.md b/docs/learn/advanced/04-store.md index d1b20d20ef66..40a2eaada985 100644 --- a/docs/learn/advanced/04-store.md +++ b/docs/learn/advanced/04-store.md @@ -189,12 +189,6 @@ When methods of the parent `KVStore` are called, `GasKv.Store` automatically con https://github.com/cosmos/cosmos-sdk/blob/store/v1.1.1/store/types/gas.go#L220-L229 ``` -By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./02-context.md): - -```go reference -https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.2/types/context.go#L339-L342 -``` - `KVStores` can be accessed in their corresponding modules by using the [`kvStoreService` and `memStoreService`](./02-core.md#kvstore-service). ### `TraceKv` Store diff --git a/docs/user/run-node/06-run-production.md b/docs/user/run-node/06-run-production.md index 9f3f31677bf2..e650f7103c5e 100644 --- a/docs/user/run-node/06-run-production.md +++ b/docs/user/run-node/06-run-production.md @@ -48,7 +48,7 @@ In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/i ### Firewall -Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. +Nodes should not have all ports open to the public, this is a simple way to get DDOS'd. Secondly it is recommended by [CometBFT](https://github.com/cometbft/cometbft) to never expose ports that are not required to operate a node. When setting up a firewall there are a few ports that can be open when operating a Cosmos SDK node. There is the CometBFT json-RPC, prometheus, p2p, remote signer and Cosmos SDK GRPC and REST. If the node is being operated as a node that does not offer endpoints to be used for submission or querying then a max of three endpoints are needed.