LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

docs: Update Cosmos SDK references from v0.50.0-alpha.0 to v0.53.0 (#24654)

Browse Source
This commit is contained in:
FT 2025-05-02 16:40:17 +02:00 committed by GitHub
parent bd2742bbf7
commit d1bb429886
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/docs/learn/advanced/03-node.md
View File

@ -24,7 +24,7 @@ In general, developers will implement the `main.go` function with the following
* Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](../beginner/03-accounts.md#addresses).
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/config.go#L14-L29
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/types/config.go#L14-L29
```
* Using [cobra](https://github.com/spf13/cobra), the root command of the full-node client is created. After that, all the custom commands of the application are added using the `AddCommand()` method of `rootCmd`.
@ -38,7 +38,7 @@ https://github.com/cometbft/cometbft/blob/v0.37.0/libs/cli/setup.go#L74-L78
See an example of `main` function from the `simapp` application, the Cosmos SDK's application for demo purposes:
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/simd/main.go
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/main.go
```
## `start` command
@ -60,25 +60,25 @@ The flow of the `start` command is pretty straightforward. First, it retrieves t
With the `db`, the `start` command creates a new instance of the application using an `appCreator` function:
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/server/start.go#L220
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server/start.go#L1007
```
Note that an `appCreator` is a function that fulfills the `AppCreator` signature:
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/server/types/app.go#L68
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server/types/app.go#L69
```
In practice, the [constructor of the application](../beginner/00-app-anatomy.md#constructor-function) is passed as the `appCreator`.
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/simapp/simd/cmd/root_v2.go#L294-L308
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/simd/cmd/root_v2.go#L294-L308
```
Then, the instance of `app` is used to instantiate a new CometBFT node:
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/server/start.go#L341-L378
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server/start.go#L361-L400
```
The CometBFT node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/cometbft/cometbft/blob/v0.37.0/abci/types/application.go#L9-L35) (given that `app` extends [`baseapp`](./00-baseapp.md)). As part of the `node.New` method, CometBFT makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the CometBFT node. The difference between these two heights should always be negative or null. If it is strictly negative, `node.New` will replay blocks until the height of the application reaches the height of the CometBFT node. Finally, if the height of the application is `0`, the CometBFT node will call [`InitChain`](./00-baseapp.md#initchain) on the application to initialize the state from the genesis file.
@ -86,7 +86,7 @@ The CometBFT node can be created with `app` because the latter satisfies the [`a
Once the CometBFT node is instantiated and in sync with the application, the node can be started:
```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/server/start.go#L350-L352
https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server/start.go#L373-L374
```
Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress.