diff --git a/dependabot.yml b/dependabot.yml new file mode 100644 index 000000000..433aaac33 --- /dev/null +++ b/dependabot.yml @@ -0,0 +1,9 @@ +# Please see the documentation for all configuration options: +# https://help.github.com/github/administering-a-repository/configuration-options-for-dependency-updates + +version: 2 +updates: + - package-ecosystem: 'yarn' + directory: '/' + schedule: + interval: 'daily' diff --git a/docs/build/building-apps/04-vote-extensions.md b/docs/build/building-apps/04-vote-extensions.md index f78f4c677..d2f33aa07 100644 --- a/docs/build/building-apps/04-vote-extensions.md +++ b/docs/build/building-apps/04-vote-extensions.md @@ -5,14 +5,14 @@ sidebar_position: 1 # Vote Extensions :::note Synopsis -This sections describes how the application can define and use vote extensions +This section describes how the application can define and use vote extensions defined in ABCI++. ::: ## Extend Vote ABCI++ allows an application to extend a pre-commit vote with arbitrary data. This -process does NOT have be deterministic and the data returned can be unique to the +process does NOT have to be deterministic, and the data returned can be unique to the validator process. The Cosmos SDK defines `baseapp.ExtendVoteHandler`: ```go @@ -62,13 +62,13 @@ these vote extensions manually in the block proposal itself. This can be done by "injecting" them into the block proposal, since the `Txs` field in `PrepareProposal` is just a slice of byte slices. -`FinalizeBlock` will ignore any byte slice that doesn't implement an `sdk.Tx` so +`FinalizeBlock` will ignore any byte slice that doesn't implement an `sdk.Tx`, so any injected vote extensions will safely be ignored in `FinalizeBlock`. For more details on propagation, see the [ABCI++ 2.0 ADR](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-064-abci-2.0.md#vote-extension-propagation--verification). ### Recovery of injected Vote Extensions -As stated before, vote extensions can be injected in a block proposal (along with +As stated before, vote extensions can be injected into a block proposal (along with other transactions in the `Txs` field). The Cosmos SDK provides a pre-FinalizeBlock hook to allow applications to recover vote extensions, perform any necessary computation on them, and then store the results in the cached store. These results @@ -102,7 +102,7 @@ app.SetPreBlocker(func(ctx sdk.Context, req *abci.RequestFinalizeBlock) error { ``` -Then in an app's module the application can retrieve the result of the computation +Then, in an app's module, the application can retrieve the result of the computation of vote extensions from the cached store: ```go @@ -118,4 +118,4 @@ func (k Keeper) BeginBlocker(ctx context.Context) error { return nil } -``` \ No newline at end of file +``` diff --git a/docs/build/migrations/02-upgrading.md b/docs/build/migrations/02-upgrading.md index 5d1b10c8f..add7694bd 100644 --- a/docs/build/migrations/02-upgrading.md +++ b/docs/build/migrations/02-upgrading.md @@ -7,7 +7,7 @@ Note, always read the **SimApp** section for more information on application wir ### Params -Params Migrations were removed. It is required to migrate to 0.50 prior to upgrading to .51. +* Params Migrations were removed. It is required to migrate to 0.50 prior to upgrading to .51. ### SimApp @@ -34,6 +34,10 @@ Refer to SimApp `root_v2.go` and `root.go` for an example with an app v2 and a l ### Modules +#### Params + +A standalone Go module was created and it is accessible at "cosmossdk.io/x/params". + #### `**all**` ##### Genesis Interface diff --git a/docs/build/modules/README.md b/docs/build/modules/README.md index d65a66f8f..1a3533e72 100644 --- a/docs/build/modules/README.md +++ b/docs/build/modules/README.md @@ -16,6 +16,7 @@ Here are some production-grade modules that can be used in Cosmos SDK applicatio * [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. +* [Protocolpool](./protocolpool/README.md) - Functionalities handling community pool funds. * [Slashing](./slashing/README.md) - Validator punishment mechanisms. * [Staking](./staking/README.md) - Proof-of-Stake layer for public blockchains. * [Upgrade](./upgrade/README.md) - Software upgrades handling and coordination. diff --git a/docs/build/modules/protocolpool/README.md b/docs/build/modules/protocolpool/README.md index 5e1993d49..31de69ee6 100644 --- a/docs/build/modules/protocolpool/README.md +++ b/docs/build/modules/protocolpool/README.md @@ -4,30 +4,79 @@ sidebar_position: 1 # `x/protocolpool` -Functionality to handle community pool funds. This provides a separate module account for community pool making it easier to track the pool assets. We no longer track community pool assets in distribution module, but instead in this protocolpool module. Funds are migrated from the distribution module's community pool to protocolpool's module account. - ## Concepts -## State +Protopool is a module that handle functionality around community pool funds. This provides a separate module account for community pool making it easier to track the pool assets. We no longer track community pool assets in distribution module, but instead in this protocolpool module. Funds are migrated from the distribution module's community pool to protocolpool's module account. ## State Transitions +### FundCommunityPool + +FundCommunityPool can be called by any valid account to send funds to the protocolpool module account. + +```protobuf + // FundCommunityPool defines a method to allow an account to directly + // fund the community pool. + rpc FundCommunityPool(MsgFundCommunityPool) returns (MsgFundCommunityPoolResponse); +``` + +### CommunityPoolSpend + +CommunityPoolSpend can be called by the module authority (default governance module account) or any account with authorization to spend funds from the protocolpool module account to a receiver address. + +```protobuf + // CommunityPoolSpend defines a governance operation for sending tokens from + // the community pool in the x/protocolpool module to another account, which + // could be the governance module itself. The authority is defined in the + // keeper. + rpc CommunityPoolSpend(MsgCommunityPoolSpend) returns (MsgCommunityPoolSpendResponse); +``` + ## Messages -## Begin Block +### MsgFundCommunityPool -## End Block +This message sends coins directly from the sender to the community pool. -## Hooks +:::tip +If you know the protocolpool module account address, you can directly use bank `send` transaction instead. +:::: -## Events +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/9dd34510e27376005e7e7ff3628eab9dbc8ad6dc/proto/cosmos/protocolpool/v1/tx.proto#L31-L41 +``` -## Client +* The msg will fail if the amount cannot be transferred from the sender to the protocolpool module account. -## Params +```go +func (k Keeper) FundCommunityPool(ctx context.Context, amount sdk.Coins, sender sdk.AccAddress) error { + return k.bankKeeper.SendCoinsFromAccountToModule(ctx, sender, types.ModuleName, amount) +} +``` -## Future Improvements +### MsgCommunityPoolSpend + +This message distributes funds from the protocolpool module account to the recipient using `DistributeFromFeePool` keeper method. + +```protobuf reference +https://github.com/cosmos/cosmos-sdk/blob/9dd34510e27376005e7e7ff3628eab9dbc8ad6dc/proto/cosmos/protocolpool/v1/tx.proto#L46-L59 +``` + +The message will fail under the following conditions: + +* The amount cannot be transferred to the recipient from the protocolpool module account. +* The `recipient` address is restricted + +```go +func (k Keeper) DistributeFromFeePool(ctx context.Context, amount sdk.Coins, receiveAddr sdk.AccAddress) error { + return k.bankKeeper.SendCoinsFromModuleToAccount(ctx, types.ModuleName, receiveAddr, amount) +} +``` + +## Client -## Tests +It takes the advantage of `AutoCLI` -## Appendix +```go reference +https://github.com/cosmos/cosmos-sdk/blob/9dd34510e27376005e7e7ff3628eab9dbc8ad6dc/x/protocolpool/autocli.go +``` diff --git a/docs/build/modules/staking/README.md b/docs/build/modules/staking/README.md index 5dd94dc69..c011a593d 100644 --- a/docs/build/modules/staking/README.md +++ b/docs/build/modules/staking/README.md @@ -75,14 +75,14 @@ Store entries prefixed with "Last" must remain unchanged until EndBlock. ### ValidatorUpdates -ValidatorUpdates contains the validator updates returned to ABCI at the end of every block. -The values are overwritten in every block. +ValidatorUpdates contains the validator updates returned to ABCI at the end of every block. +The values are overwritten in every block. * ValidatorUpdates `0x61 -> []abci.ValidatorUpdate` ### UnbondingID -UnbondingID stores the ID of the latest unbonding operation. It enables to create unique IDs for unbonding operation, i.e., UnbondingID is incremented every time a new unbonding operation (validator unbonding, unbonding delegation, redelegation) is initiated. +UnbondingID stores the ID of the latest unbonding operation. It enables creating unique IDs for unbonding operations, i.e., UnbondingID is incremented every time a new unbonding operation (validator unbonding, unbonding delegation, redelegation) is initiated. * UnbondingID: `0x37 -> uint64` @@ -115,7 +115,7 @@ Validators can have one of three statuses before their tokens are moved to their accounts from the `BondedPool`. :::warning -Tombstoning is permanent, once tombstoned a validators consensus key can not be reused within the chain where the tombstoning happened. +Tombstoning is permanent, once tombstoned a validator's consensus key can not be reused within the chain where the tombstoning happened. ::: Validators objects should be primarily stored and accessed by the @@ -137,7 +137,7 @@ associated validator, where the public key of that validator can change in the future. Delegators can refer to the immutable operator of the validator, without concern for the changing public key. -`ValidatorsByUnbondingID` is an additional index that enables lookups for +`ValidatorsByUnbondingID` is an additional index that enables lookups for validators by the unbonding IDs corresponding to their current unbonding. `ValidatorByConsAddr` is an additional index that enables lookups for slashing. @@ -182,7 +182,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/staking/v1bet #### Delegator Shares -When one Delegates tokens to a Validator they are issued a number of delegator shares based on a +When one delegates tokens to a Validator, they are issued a number of delegator shares based on a dynamic exchange rate, calculated as follows from the total number of tokens delegated to the validator and the number of shares issued so far: @@ -196,7 +196,7 @@ hold and the inverse exchange rate: These `Shares` are simply an accounting mechanism. They are not a fungible asset. The reason for this mechanism is to simplify the accounting around slashing. Rather than iteratively slashing the -tokens of every delegation entry, instead the Validators total bonded tokens can be slashed, +tokens of every delegation entry, instead the Validator's total bonded tokens can be slashed, effectively reducing the value of each issued delegator share. ### UnbondingDelegation @@ -217,8 +217,8 @@ detected. unbonding delegations associated with a given validator that need to be slashed. - `UnbondingDelegationByUnbondingId` is an additional index that enables - lookups for unbonding delegations by the unbonding IDs of the containing + `UnbondingDelegationByUnbondingId` is an additional index that enables + lookups for unbonding delegations by the unbonding IDs of the containing unbonding delegation entries. @@ -254,8 +254,8 @@ The first map here is used for queries, to lookup all redelegations for a given delegator. The second map is used for slashing based on the `ValidatorSrcAddr`, while the third map is for slashing based on the `ValidatorDstAddr`. -`RedelegationByUnbondingId` is an additional index that enables - lookups for redelegations by the unbonding IDs of the containing +`RedelegationByUnbondingId` is an additional index that enables + lookups for redelegations by the unbonding IDs of the containing redelegation entries. A redelegation object is created every time a redelegation occurs. To prevent @@ -272,13 +272,13 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/staking/v1bet ### Queues -All queues objects are sorted by timestamp. The time used within any queue is -first rounded to the nearest nanosecond then sorted. The sortable time format +All queue objects are sorted by timestamp. The time used within any queue is +firstly converted to UTC, rounded to the nearest nanosecond then sorted. The sortable time format used is a slight modification of the RFC3339Nano and uses the format string `"2006-01-02T15:04:05.000000000"`. Notably this format: * right pads all zeros -* drops the time zone info (uses UTC) +* drops the time zone info (we already use UTC) In all cases, the stored timestamp represents the maturation time of the queue element. @@ -312,7 +312,7 @@ queue is kept. * ValidatorQueueTime: `0x43 | format(time) -> []sdk.ValAddress` -The stored object as each key is an array of validator operator addresses from +The stored object by each key is an array of validator operator addresses from which the validator object can be accessed. Typically it is expected that only a single validator record will be associated with a given timestamp however it is possible that multiple validators exist in the queue at the same location. @@ -415,16 +415,16 @@ Delegation may be called. shares from the `BondedPool` to the `NotBondedPool` `ModuleAccount` * remove the validator if it is unbonded and there are no more delegation shares. * remove the validator if it is unbonded and there are no more delegation shares -* get a unique `unbondingId` and map it to the `UnbondingDelegationEntry` in `UnbondingDelegationByUnbondingId` +* get a unique `unbondingId` and map it to the `UnbondingDelegationEntry` in `UnbondingDelegationByUnbondingId` * call the `AfterUnbondingInitiated(unbondingId)` hook * add the unbonding delegation to `UnbondingDelegationQueue` with the completion time set to `UnbondingTime` -#### Cancel an `UnbondingDelegation` Entry +#### Cancel an `UnbondingDelegation` Entry When a `cancel unbond delegation` occurs both the `validator`, the `delegation` and an `UnbondingDelegationQueue` state will be updated. * if cancel unbonding delegation amount equals to the `UnbondingDelegation` entry `balance`, then the `UnbondingDelegation` entry deleted from `UnbondingDelegationQueue`. -* if the `cancel unbonding delegation amount is less than the `UnbondingDelegation` entry balance, then the `UnbondingDelegation` entry will be updated with new balance in the `UnbondingDelegationQueue`. +* if the `cancel unbonding delegation amount is less than the `UnbondingDelegation` entry balance, then the `UnbondingDelegation` entry will be updated with new balance in the `UnbondingDelegationQueue`. * cancel `amount` is [Delegated](#delegations) back to the original `validator`. #### Complete Unbonding @@ -661,7 +661,7 @@ This message is expected to fail if: When this message is processed the following actions occur: -* if the `unbondingDelegation` Entry balance is zero +* if the `unbondingDelegation` Entry balance is zero * in this condition `unbondingDelegation` entry will be removed from `unbondingDelegationQueue`. * otherwise `unbondingDelegationQueue` will be updated with new `unbondingDelegation` entry balance and initial balance * the validator's `DelegatorShares` and the delegation's `Shares` are both increased by the message `Amount`. @@ -791,11 +791,11 @@ validators that still have remaining delegations, the `validator.Status` is switched from `types.Unbonding` to `types.Unbonded`. -Unbonding operations can be put on hold by external modules via the `PutUnbondingOnHold(unbondingId)` method. - As a result, an unbonding operation (e.g., an unbonding delegation) that is on hold, cannot complete - even if it reaches maturity. For an unbonding operation with `unbondingId` to eventually complete - (after it reaches maturity), every call to `PutUnbondingOnHold(unbondingId)` must be matched - by a call to `UnbondingCanComplete(unbondingId)`. +Unbonding operations can be put on hold by external modules via the `PutUnbondingOnHold(unbondingId)` method. + As a result, an unbonding operation (e.g., an unbonding delegation) that is on hold, cannot complete + even if it reaches maturity. For an unbonding operation with `unbondingId` to eventually complete + (after it reaches maturity), every call to `PutUnbondingOnHold(unbondingId)` must be matched + by a call to `UnbondingCanComplete(unbondingId)`. #### Unbonding Delegations @@ -1666,7 +1666,7 @@ Example: simd tx staking unbond cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj 100stake --from mykey ``` -##### cancel unbond +##### cancel unbond The command `cancel-unbond` allow users to cancel the unbonding delegation entry and delegate back to the original validator. diff --git a/docs/build/tooling/02-confix.md b/docs/build/tooling/02-confix.md index a990ed98d..f6badd497 100644 --- a/docs/build/tooling/02-confix.md +++ b/docs/build/tooling/02-confix.md @@ -47,11 +47,6 @@ To use Confix standalone, without having to add it in your application, install go install cosmossdk.io/tools/confix/cmd/confix@latest ``` -:::warning -Currently, due to the replace directive in the Confix go.mod, it is not possible to use `go install`. -Building from source or importing in an application is required until that replace directive is removed. -::: - Alternatively, for building from source, simply run `make confix`. The binary will be located in `tools/confix`. ## Usage @@ -120,6 +115,18 @@ simd config diff v0.47 # gets the diff between defaultHome/config/app.toml and t confix diff v0.47 ~/.simapp/config/app.toml # gets the diff between ~/.simapp/config/app.toml and the latest v0.47 config ``` +### View + +View a configuration file, e.g: + +```shell +simd config view client # views the current app client config +``` + +```shell +confix view ~/.simapp/config/client.toml # views the current app client conf +``` + ### Maintainer At each SDK modification of the default configuration, add the default SDK config under `data/v0.XX-app.toml`. diff --git a/docs/learn/advanced/00-baseapp.md b/docs/learn/advanced/00-baseapp.md index 51d7421cf..66578c5cf 100644 --- a/docs/learn/advanced/00-baseapp.md +++ b/docs/learn/advanced/00-baseapp.md @@ -538,7 +538,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go# ### VerifyVoteExtension -`VerifyVoteExtension` allows an application to verify that the data returned by `ExtendVote` is valid. This process does NOT have to be deterministic and the data returned can be unique to the validator process. +`VerifyVoteExtension` allows an application to verify that the data returned by `ExtendVote` is valid. This process MUST be deterministic. Moreover, the value of ResponseVerifyVoteExtension.status MUST exclusively depend on the parameters passed in the call to RequestVerifyVoteExtension, and the last committed Application state. In the Cosmos-SDK this is implemented as a NoOp: diff --git a/docs/learn/advanced/17-autocli.md b/docs/learn/advanced/17-autocli.md index 516c7f495..e5458ea9a 100644 --- a/docs/learn/advanced/17-autocli.md +++ b/docs/learn/advanced/17-autocli.md @@ -75,7 +75,7 @@ if err := rootCmd.Execute(); err != nil { ### Keyring -`autocli` supports a keyring for key name resolving and signing transactions. Providing a keyring is optional, but if you want to use the `autocli` generated commands to sign transactions, you must provide a keyring. +`autocli` uses a keyring for key name resolving and signing transactions. Providing a keyring is optional, but if you want to use the `autocli` generated commands to sign transactions, you must provide a keyring. :::tip This provides a better UX as it allows to resolve key names directly from the keyring in all transactions and commands. @@ -87,16 +87,23 @@ This provides a better UX as it allows to resolve key names directly from the ke ::: -The keyring to be provided to `client/v2` must match the `client/v2` keyring interface. The Cosmos SDK keyring and Hubl keyring both implement this interface. +The keyring to be provided to `client/v2` must match the `client/v2` keyring interface. The keyring should be provided in the `appOptions` struct as follows, and can be gotten from the client context: +:::tip +The Cosmos SDK keyring and Hubl keyring both implement the `client/v2/autocli/keyring` interface, thanks to the following wrapper: + +```go +keyring.NewAutoCLIKeyring(kb) +``` + +::: + :::warning When using AutoCLI the keyring will only be created once and before any command flag parsing. ::: ```go -// Get the keyring from the client context -keyring := ctx.Keyring // Set the keyring in the appOptions appOptions.Keyring = keyring @@ -104,6 +111,16 @@ err := autoCliOpts.EnhanceRootCommand(rootCmd) ... ``` +## Signing + +`autocli` supports signing transactions with the keyring. +The [`cosmos.msg.v1.signer` protobuf annotation](https://github.com/cosmos/cosmos-sdk/blob/9dd34510e27376005e7e7ff3628eab9dbc8ad6dc/docs/build/building-modules/05-protobuf-annotations.md#L9) defines the signer field of the message. +This field is automatically filled when using the `--from` flag or defining the signer as a positional argument. + +:::warning +AutoCLI currently supports only one signer per transaction. +::: + ## Module Wiring & Customization The `AutoCLIOptions()` method on your module allows to specify custom commands, sub-commands or flags for each service, as it was a `cobra.Command` instance, within the `RpcCommandOptions` struct. Defining such options will customize the behavior of the `autocli` command generation, which by default generates a command for each method in your gRPC service. diff --git a/docs/learn/intro/01-why-app-specific.md b/docs/learn/intro/01-why-app-specific.md index 5830530ae..0f0c1c64e 100644 --- a/docs/learn/intro/01-why-app-specific.md +++ b/docs/learn/intro/01-why-app-specific.md @@ -58,7 +58,7 @@ The list above contains a few examples that show how much flexibility applicatio ### Performance -decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: +Decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: * Developers of application-specific blockchains can choose to operate with a novel consensus engine such as CometBFT BFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throughput. * An application-specific blockchain only operates a single application, so that the application does not compete with others for computation and storage. This is the opposite of most non-sharded virtual-machine blockchains today, where smart contracts all compete for computation and storage. diff --git a/versioned_docs/version-0.50/build/building-apps/04-vote-extensions.md b/versioned_docs/version-0.50/build/building-apps/04-vote-extensions.md index f78f4c677..d2f33aa07 100644 --- a/versioned_docs/version-0.50/build/building-apps/04-vote-extensions.md +++ b/versioned_docs/version-0.50/build/building-apps/04-vote-extensions.md @@ -5,14 +5,14 @@ sidebar_position: 1 # Vote Extensions :::note Synopsis -This sections describes how the application can define and use vote extensions +This section describes how the application can define and use vote extensions defined in ABCI++. ::: ## Extend Vote ABCI++ allows an application to extend a pre-commit vote with arbitrary data. This -process does NOT have be deterministic and the data returned can be unique to the +process does NOT have to be deterministic, and the data returned can be unique to the validator process. The Cosmos SDK defines `baseapp.ExtendVoteHandler`: ```go @@ -62,13 +62,13 @@ these vote extensions manually in the block proposal itself. This can be done by "injecting" them into the block proposal, since the `Txs` field in `PrepareProposal` is just a slice of byte slices. -`FinalizeBlock` will ignore any byte slice that doesn't implement an `sdk.Tx` so +`FinalizeBlock` will ignore any byte slice that doesn't implement an `sdk.Tx`, so any injected vote extensions will safely be ignored in `FinalizeBlock`. For more details on propagation, see the [ABCI++ 2.0 ADR](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-064-abci-2.0.md#vote-extension-propagation--verification). ### Recovery of injected Vote Extensions -As stated before, vote extensions can be injected in a block proposal (along with +As stated before, vote extensions can be injected into a block proposal (along with other transactions in the `Txs` field). The Cosmos SDK provides a pre-FinalizeBlock hook to allow applications to recover vote extensions, perform any necessary computation on them, and then store the results in the cached store. These results @@ -102,7 +102,7 @@ app.SetPreBlocker(func(ctx sdk.Context, req *abci.RequestFinalizeBlock) error { ``` -Then in an app's module the application can retrieve the result of the computation +Then, in an app's module, the application can retrieve the result of the computation of vote extensions from the cached store: ```go @@ -118,4 +118,4 @@ func (k Keeper) BeginBlocker(ctx context.Context) error { return nil } -``` \ No newline at end of file +``` diff --git a/versioned_docs/version-0.50/build/modules/staking/README.md b/versioned_docs/version-0.50/build/modules/staking/README.md index 5dd94dc69..c011a593d 100644 --- a/versioned_docs/version-0.50/build/modules/staking/README.md +++ b/versioned_docs/version-0.50/build/modules/staking/README.md @@ -75,14 +75,14 @@ Store entries prefixed with "Last" must remain unchanged until EndBlock. ### ValidatorUpdates -ValidatorUpdates contains the validator updates returned to ABCI at the end of every block. -The values are overwritten in every block. +ValidatorUpdates contains the validator updates returned to ABCI at the end of every block. +The values are overwritten in every block. * ValidatorUpdates `0x61 -> []abci.ValidatorUpdate` ### UnbondingID -UnbondingID stores the ID of the latest unbonding operation. It enables to create unique IDs for unbonding operation, i.e., UnbondingID is incremented every time a new unbonding operation (validator unbonding, unbonding delegation, redelegation) is initiated. +UnbondingID stores the ID of the latest unbonding operation. It enables creating unique IDs for unbonding operations, i.e., UnbondingID is incremented every time a new unbonding operation (validator unbonding, unbonding delegation, redelegation) is initiated. * UnbondingID: `0x37 -> uint64` @@ -115,7 +115,7 @@ Validators can have one of three statuses before their tokens are moved to their accounts from the `BondedPool`. :::warning -Tombstoning is permanent, once tombstoned a validators consensus key can not be reused within the chain where the tombstoning happened. +Tombstoning is permanent, once tombstoned a validator's consensus key can not be reused within the chain where the tombstoning happened. ::: Validators objects should be primarily stored and accessed by the @@ -137,7 +137,7 @@ associated validator, where the public key of that validator can change in the future. Delegators can refer to the immutable operator of the validator, without concern for the changing public key. -`ValidatorsByUnbondingID` is an additional index that enables lookups for +`ValidatorsByUnbondingID` is an additional index that enables lookups for validators by the unbonding IDs corresponding to their current unbonding. `ValidatorByConsAddr` is an additional index that enables lookups for slashing. @@ -182,7 +182,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/staking/v1bet #### Delegator Shares -When one Delegates tokens to a Validator they are issued a number of delegator shares based on a +When one delegates tokens to a Validator, they are issued a number of delegator shares based on a dynamic exchange rate, calculated as follows from the total number of tokens delegated to the validator and the number of shares issued so far: @@ -196,7 +196,7 @@ hold and the inverse exchange rate: These `Shares` are simply an accounting mechanism. They are not a fungible asset. The reason for this mechanism is to simplify the accounting around slashing. Rather than iteratively slashing the -tokens of every delegation entry, instead the Validators total bonded tokens can be slashed, +tokens of every delegation entry, instead the Validator's total bonded tokens can be slashed, effectively reducing the value of each issued delegator share. ### UnbondingDelegation @@ -217,8 +217,8 @@ detected. unbonding delegations associated with a given validator that need to be slashed. - `UnbondingDelegationByUnbondingId` is an additional index that enables - lookups for unbonding delegations by the unbonding IDs of the containing + `UnbondingDelegationByUnbondingId` is an additional index that enables + lookups for unbonding delegations by the unbonding IDs of the containing unbonding delegation entries. @@ -254,8 +254,8 @@ The first map here is used for queries, to lookup all redelegations for a given delegator. The second map is used for slashing based on the `ValidatorSrcAddr`, while the third map is for slashing based on the `ValidatorDstAddr`. -`RedelegationByUnbondingId` is an additional index that enables - lookups for redelegations by the unbonding IDs of the containing +`RedelegationByUnbondingId` is an additional index that enables + lookups for redelegations by the unbonding IDs of the containing redelegation entries. A redelegation object is created every time a redelegation occurs. To prevent @@ -272,13 +272,13 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/staking/v1bet ### Queues -All queues objects are sorted by timestamp. The time used within any queue is -first rounded to the nearest nanosecond then sorted. The sortable time format +All queue objects are sorted by timestamp. The time used within any queue is +firstly converted to UTC, rounded to the nearest nanosecond then sorted. The sortable time format used is a slight modification of the RFC3339Nano and uses the format string `"2006-01-02T15:04:05.000000000"`. Notably this format: * right pads all zeros -* drops the time zone info (uses UTC) +* drops the time zone info (we already use UTC) In all cases, the stored timestamp represents the maturation time of the queue element. @@ -312,7 +312,7 @@ queue is kept. * ValidatorQueueTime: `0x43 | format(time) -> []sdk.ValAddress` -The stored object as each key is an array of validator operator addresses from +The stored object by each key is an array of validator operator addresses from which the validator object can be accessed. Typically it is expected that only a single validator record will be associated with a given timestamp however it is possible that multiple validators exist in the queue at the same location. @@ -415,16 +415,16 @@ Delegation may be called. shares from the `BondedPool` to the `NotBondedPool` `ModuleAccount` * remove the validator if it is unbonded and there are no more delegation shares. * remove the validator if it is unbonded and there are no more delegation shares -* get a unique `unbondingId` and map it to the `UnbondingDelegationEntry` in `UnbondingDelegationByUnbondingId` +* get a unique `unbondingId` and map it to the `UnbondingDelegationEntry` in `UnbondingDelegationByUnbondingId` * call the `AfterUnbondingInitiated(unbondingId)` hook * add the unbonding delegation to `UnbondingDelegationQueue` with the completion time set to `UnbondingTime` -#### Cancel an `UnbondingDelegation` Entry +#### Cancel an `UnbondingDelegation` Entry When a `cancel unbond delegation` occurs both the `validator`, the `delegation` and an `UnbondingDelegationQueue` state will be updated. * if cancel unbonding delegation amount equals to the `UnbondingDelegation` entry `balance`, then the `UnbondingDelegation` entry deleted from `UnbondingDelegationQueue`. -* if the `cancel unbonding delegation amount is less than the `UnbondingDelegation` entry balance, then the `UnbondingDelegation` entry will be updated with new balance in the `UnbondingDelegationQueue`. +* if the `cancel unbonding delegation amount is less than the `UnbondingDelegation` entry balance, then the `UnbondingDelegation` entry will be updated with new balance in the `UnbondingDelegationQueue`. * cancel `amount` is [Delegated](#delegations) back to the original `validator`. #### Complete Unbonding @@ -661,7 +661,7 @@ This message is expected to fail if: When this message is processed the following actions occur: -* if the `unbondingDelegation` Entry balance is zero +* if the `unbondingDelegation` Entry balance is zero * in this condition `unbondingDelegation` entry will be removed from `unbondingDelegationQueue`. * otherwise `unbondingDelegationQueue` will be updated with new `unbondingDelegation` entry balance and initial balance * the validator's `DelegatorShares` and the delegation's `Shares` are both increased by the message `Amount`. @@ -791,11 +791,11 @@ validators that still have remaining delegations, the `validator.Status` is switched from `types.Unbonding` to `types.Unbonded`. -Unbonding operations can be put on hold by external modules via the `PutUnbondingOnHold(unbondingId)` method. - As a result, an unbonding operation (e.g., an unbonding delegation) that is on hold, cannot complete - even if it reaches maturity. For an unbonding operation with `unbondingId` to eventually complete - (after it reaches maturity), every call to `PutUnbondingOnHold(unbondingId)` must be matched - by a call to `UnbondingCanComplete(unbondingId)`. +Unbonding operations can be put on hold by external modules via the `PutUnbondingOnHold(unbondingId)` method. + As a result, an unbonding operation (e.g., an unbonding delegation) that is on hold, cannot complete + even if it reaches maturity. For an unbonding operation with `unbondingId` to eventually complete + (after it reaches maturity), every call to `PutUnbondingOnHold(unbondingId)` must be matched + by a call to `UnbondingCanComplete(unbondingId)`. #### Unbonding Delegations @@ -1666,7 +1666,7 @@ Example: simd tx staking unbond cosmosvaloper1gghjut3ccd8ay0zduzj64hwre2fxs9ldmqhffj 100stake --from mykey ``` -##### cancel unbond +##### cancel unbond The command `cancel-unbond` allow users to cancel the unbonding delegation entry and delegate back to the original validator. diff --git a/versioned_docs/version-0.50/build/tooling/02-confix.md b/versioned_docs/version-0.50/build/tooling/02-confix.md index a990ed98d..f6badd497 100644 --- a/versioned_docs/version-0.50/build/tooling/02-confix.md +++ b/versioned_docs/version-0.50/build/tooling/02-confix.md @@ -47,11 +47,6 @@ To use Confix standalone, without having to add it in your application, install go install cosmossdk.io/tools/confix/cmd/confix@latest ``` -:::warning -Currently, due to the replace directive in the Confix go.mod, it is not possible to use `go install`. -Building from source or importing in an application is required until that replace directive is removed. -::: - Alternatively, for building from source, simply run `make confix`. The binary will be located in `tools/confix`. ## Usage @@ -120,6 +115,18 @@ simd config diff v0.47 # gets the diff between defaultHome/config/app.toml and t confix diff v0.47 ~/.simapp/config/app.toml # gets the diff between ~/.simapp/config/app.toml and the latest v0.47 config ``` +### View + +View a configuration file, e.g: + +```shell +simd config view client # views the current app client config +``` + +```shell +confix view ~/.simapp/config/client.toml # views the current app client conf +``` + ### Maintainer At each SDK modification of the default configuration, add the default SDK config under `data/v0.XX-app.toml`. diff --git a/versioned_docs/version-0.50/learn/advanced/00-baseapp.md b/versioned_docs/version-0.50/learn/advanced/00-baseapp.md index 90183a155..161a1d1a2 100644 --- a/versioned_docs/version-0.50/learn/advanced/00-baseapp.md +++ b/versioned_docs/version-0.50/learn/advanced/00-baseapp.md @@ -538,7 +538,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go# ### VerifyVoteExtension -`VerifyVoteExtension` allows an application to verify that the data returned by `ExtendVote` is valid. This process does NOT have to be deterministic and the data returned can be unique to the validator process. +`VerifyVoteExtension` allows an application to verify that the data returned by `ExtendVote` is valid. This process MUST be deterministic. Moreover, the value of ResponseVerifyVoteExtension.status MUST exclusively depend on the parameters passed in the call to RequestVerifyVoteExtension, and the last committed Application state. In the Cosmos-SDK this is implemented as a NoOp: diff --git a/versioned_docs/version-0.50/learn/advanced/17-autocli.md b/versioned_docs/version-0.50/learn/advanced/17-autocli.md index 516c7f495..e5458ea9a 100644 --- a/versioned_docs/version-0.50/learn/advanced/17-autocli.md +++ b/versioned_docs/version-0.50/learn/advanced/17-autocli.md @@ -75,7 +75,7 @@ if err := rootCmd.Execute(); err != nil { ### Keyring -`autocli` supports a keyring for key name resolving and signing transactions. Providing a keyring is optional, but if you want to use the `autocli` generated commands to sign transactions, you must provide a keyring. +`autocli` uses a keyring for key name resolving and signing transactions. Providing a keyring is optional, but if you want to use the `autocli` generated commands to sign transactions, you must provide a keyring. :::tip This provides a better UX as it allows to resolve key names directly from the keyring in all transactions and commands. @@ -87,16 +87,23 @@ This provides a better UX as it allows to resolve key names directly from the ke ::: -The keyring to be provided to `client/v2` must match the `client/v2` keyring interface. The Cosmos SDK keyring and Hubl keyring both implement this interface. +The keyring to be provided to `client/v2` must match the `client/v2` keyring interface. The keyring should be provided in the `appOptions` struct as follows, and can be gotten from the client context: +:::tip +The Cosmos SDK keyring and Hubl keyring both implement the `client/v2/autocli/keyring` interface, thanks to the following wrapper: + +```go +keyring.NewAutoCLIKeyring(kb) +``` + +::: + :::warning When using AutoCLI the keyring will only be created once and before any command flag parsing. ::: ```go -// Get the keyring from the client context -keyring := ctx.Keyring // Set the keyring in the appOptions appOptions.Keyring = keyring @@ -104,6 +111,16 @@ err := autoCliOpts.EnhanceRootCommand(rootCmd) ... ``` +## Signing + +`autocli` supports signing transactions with the keyring. +The [`cosmos.msg.v1.signer` protobuf annotation](https://github.com/cosmos/cosmos-sdk/blob/9dd34510e27376005e7e7ff3628eab9dbc8ad6dc/docs/build/building-modules/05-protobuf-annotations.md#L9) defines the signer field of the message. +This field is automatically filled when using the `--from` flag or defining the signer as a positional argument. + +:::warning +AutoCLI currently supports only one signer per transaction. +::: + ## Module Wiring & Customization The `AutoCLIOptions()` method on your module allows to specify custom commands, sub-commands or flags for each service, as it was a `cobra.Command` instance, within the `RpcCommandOptions` struct. Defining such options will customize the behavior of the `autocli` command generation, which by default generates a command for each method in your gRPC service. diff --git a/versioned_docs/version-0.50/learn/intro/01-why-app-specific.md b/versioned_docs/version-0.50/learn/intro/01-why-app-specific.md index 5830530ae..0f0c1c64e 100644 --- a/versioned_docs/version-0.50/learn/intro/01-why-app-specific.md +++ b/versioned_docs/version-0.50/learn/intro/01-why-app-specific.md @@ -58,7 +58,7 @@ The list above contains a few examples that show how much flexibility applicatio ### Performance -decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: +Decentralized applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralized application to optimise performance, it needs to be built as an application-specific blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: * Developers of application-specific blockchains can choose to operate with a novel consensus engine such as CometBFT BFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throughput. * An application-specific blockchain only operates a single application, so that the application does not compete with others for computation and storage. This is the opposite of most non-sharded virtual-machine blockchains today, where smart contracts all compete for computation and storage.