diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 0aa18f40cf..b3ab5cbf59 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -164,17 +164,22 @@ jobs: - uses: actions/download-artifact@v2 with: name: "${{ github.sha }}-00-coverage" + if: env.GIT_DIFF - uses: actions/download-artifact@v2 with: name: "${{ github.sha }}-01-coverage" + if: env.GIT_DIFF - uses: actions/download-artifact@v2 with: name: "${{ github.sha }}-02-coverage" + if: env.GIT_DIFF - uses: actions/download-artifact@v2 with: name: "${{ github.sha }}-03-coverage" + if: env.GIT_DIFF - run: | cat ./*profile.out | grep -v "mode: atomic" >> coverage.txt + if: env.GIT_DIFF - name: filter out DONTCOVER run: | excludelist="$(find ./ -type f -name '*.go' | xargs grep -l 'DONTCOVER')" @@ -184,10 +189,12 @@ jobs: echo "Excluding ${filename} from coverage report..." sed -i.bak "/$(echo $filename | sed 's/\//\\\//g')/d" coverage.txt done + if: env.GIT_DIFF - uses: codecov/codecov-action@v1.5.0 with: token: ${{ secrets.CODECOV_TOKEN }} file: ./coverage.txt + if: env.GIT_DIFF test-race: runs-on: ubuntu-latest diff --git a/CHANGELOG.md b/CHANGELOG.md index fc8d26655a..8f54950f82 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3530 +1,56 @@ - - # Changelog -## [v0.42.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.42.1) - 2021-03-10 - -This release fixes security vulnerability identified in the simapp. - - -## [v0.42.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.42.0) - 2021-03-08 - -**IMPORTANT**: This release contains an important security fix for all non Cosmos Hub chains running Stargate version of the Cosmos SDK (>0.40). Non-hub chains should not be using any version of the SDK in the v0.40.x or v0.41.x release series. See [#8461](https://github.com/cosmos/cosmos-sdk/pull/8461) for more details. - -### Improvements - -* (x/ibc) [\#8624](https://github.com/cosmos/cosmos-sdk/pull/8624) Emit full header in IBC UpdateClient message. -* (x/crisis) [\#8621](https://github.com/cosmos/cosmos-sdk/issues/8621) crisis invariants names now print to loggers. - -### Bug fixes - -* (x/evidence) [\#8461](https://github.com/cosmos/cosmos-sdk/pull/8461) Fix bech32 prefix in evidence validator address conversion -* (x/gov) [\#8806](https://github.com/cosmos/cosmos-sdk/issues/8806) Fix q gov proposals command's mishandling of the --status parameter's values. - -## [v0.41.4](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.3) - 2021-03-02 - -### Features - -* [\#7787](https://github.com/cosmos/cosmos-sdk/pull/7787) Add multisign-batch command. - -### Bug fixes - -* [\#8730](https://github.com/cosmos/cosmos-sdk/pull/8730) Allow REST endpoint to query txs with multisig addresses. -* [\#8680](https://github.com/cosmos/cosmos-sdk/issues/8680) Fix missing timestamp in GetTxsEvent response [\#8732](https://github.com/cosmos/cosmos-sdk/pull/8732). -* [\#8681](https://github.com/cosmos/cosmos-sdk/issues/8681) Fix missing error message when calling GetTxsEvent [\#8732](https://github.com/cosmos/cosmos-sdk/pull/8732) -* (server) [\#8641](https://github.com/cosmos/cosmos-sdk/pull/8641) Fix Tendermint and application configuration reading from file -* (client/keys) [\#8639] (https://github.com/cosmos/cosmos-sdk/pull/8639) Fix keys migrate for mulitisig, offline, and ledger keys. The migrate command now takes a positional old_home_dir argument. - -### Improvements - -* (store/cachekv), (x/bank/types) [\#8719](https://github.com/cosmos/cosmos-sdk/pull/8719) algorithmically fix pathologically slow code -* [\#8701](https://github.com/cosmos/cosmos-sdk/pull/8701) Upgrade tendermint v0.34.8. -* [\#8714](https://github.com/cosmos/cosmos-sdk/pull/8714) Allow accounts to have a balance of 0 at genesis. - -## [v0.41.3](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.3) - 2021-02-18 - -### Bug Fixes - -* [\#8617](https://github.com/cosmos/cosmos-sdk/pull/8617) Fix build failures caused by a small API breakage introduced in tendermint v0.34.7. - -## [v0.41.2](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.2) - 2021-02-18 - -### Improvements - -* Bump tendermint dependency to v0.34.7. - -## [v0.41.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.1) - 2021-02-17 - -### Bug Fixes - -* (grpc) [\#8549](https://github.com/cosmos/cosmos-sdk/pull/8549) Make gRPC requests go through ABCI and disallow concurrency. -* (x/staking) [\#8546](https://github.com/cosmos/cosmos-sdk/pull/8546) Fix caching bug where concurrent calls to GetValidator could cause a node to crash -* (server) [\#8481](https://github.com/cosmos/cosmos-sdk/pull/8481) Don't create files when running `{appd} tendermint show-*` subcommands. -* (client/keys) [\#8436](https://github.com/cosmos/cosmos-sdk/pull/8436) Fix keybase->keyring keys migration. -* (crypto/hd) [\#8607](https://github.com/cosmos/cosmos-sdk/pull/8607) Make DerivePrivateKeyForPath error and not panic on trailing slashes. - -### Improvements - -* (x/ibc) [\#8458](https://github.com/cosmos/cosmos-sdk/pull/8458) Add `packet_connection` attribute to ibc events to enable relayer filtering -* [\#8396](https://github.com/cosmos/cosmos-sdk/pull/8396) Add support for ARM platform -* (x/bank) [\#8479](https://github.com/cosmos/cosmos-sdk/pull/8479) Aditional client denom metadata validation for `base` and `display` denoms. -* (codec/types) [\#8605](https://github.com/cosmos/cosmos-sdk/pull/8605) Avoid unnecessary allocations for NewAnyWithCustomTypeURL on error. - -## [v0.41.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.0) - 2021-01-26 - -### State Machine Breaking - -* (x/ibc) [\#8266](https://github.com/cosmos/cosmos-sdk/issues/8266) Add amino JSON for IBC messages in order to support Ledger text signing. -* (x/ibc) [\#8404](https://github.com/cosmos/cosmos-sdk/pull/8404) Reorder IBC `ChanOpenAck` and `ChanOpenConfirm` handler execution to perform core handler first, followed by application callbacks. - -### Bug Fixes - -* (simapp) [\#8418](https://github.com/cosmos/cosmos-sdk/pull/8418) Add balance coin to supply when adding a new genesis account -* (x/bank) [\#8417](https://github.com/cosmos/cosmos-sdk/pull/8417) Validate balances and coin denom metadata on genesis -* (x/staking) [\#8546](https://github.com/cosmos/cosmos-sdk/pull/8546) Fix caching bug where concurrent calls to GetValidator could cause a node to crash - -## [v0.40.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.40.1) - 2021-01-19 - -### Improvements - -* (x/bank) [\#8302](https://github.com/cosmos/cosmos-sdk/issues/8302) Add gRPC and CLI queries for client denomination metadata. -* (tendermint) Bump Tendermint version to [v0.34.3](https://github.com/tendermint/tendermint/releases/tag/v0.34.3). - -### Bug Fixes - -* [\#8085](https://github.com/cosmos/cosmos-sdk/pull/8058) fix zero time checks -* [\#8280](https://github.com/cosmos/cosmos-sdk/pull/8280) fix GET /upgrade/current query -* (x/auth) [\#8287](https://github.com/cosmos/cosmos-sdk/pull/8287) Fix `tx sign --signature-only` to return correct sequence value in signature. -* (build) [\8300](https://github.com/cosmos/cosmos-sdk/pull/8300), [\8301](https://github.com/cosmos/cosmos-sdk/pull/8301) Fix reproducible builds -* (types/errors) [\#8355][https://github.com/cosmos/cosmos-sdk/pull/8355] Fix errorWrap `Is` method. -* (x/ibc) [\#8341](https://github.com/cosmos/cosmos-sdk/pull/8341) Fix query latest consensus state. -* (proto) [\#8350][https://github.com/cosmos/cosmos-sdk/pull/8350], [\#8361](https://github.com/cosmos/cosmos-sdk/pull/8361) Update gogo proto deps with v1.3.2 security fixes -* (x/ibc) [\#8359](https://github.com/cosmos/cosmos-sdk/pull/8359) Add missing UnpackInterfaces functions to IBC Query Responses. Fixes 'cannot unpack Any' error for IBC types. -* (x/bank) [\#8317](https://github.com/cosmos/cosmos-sdk/pull/8317) Fix panic when querying for a not found client denomination metadata. - - -## [v0.40.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.40.0) - 2021-01-08 - -v0.40.0, known as the Stargate release of the Cosmos SDK, is one of the largest releases -of the Cosmos SDK since launch. Please read through this changelog and [release notes](./RELEASE_NOTES.md) to make -sure you are aware of any relevant breaking changes. - -### Client Breaking Changes - -* __Modules__ - -* __CLI__ - * (client/keys) [\#5889](https://github.com/cosmos/cosmos-sdk/pull/5889) remove `keys update` command. - * (x/auth) [\#5844](https://github.com/cosmos/cosmos-sdk/pull/5844) `tx sign` command now returns an error when signing is attempted with offline/multisig keys. - * (x/auth) [\#6108](https://github.com/cosmos/cosmos-sdk/pull/6108) `tx sign` command's `--validate-signatures` flag is migrated into a `tx validate-signatures` standalone command. - * (x/auth) [#7788](https://github.com/cosmos/cosmos-sdk/pull/7788) Remove `tx auth` subcommands, all auth subcommands exist as `tx ` - * (x/genutil) [\#6651](https://github.com/cosmos/cosmos-sdk/pull/6651) The `gentx` command has been improved. No longer are `--from` and `--name` flags required. Instead, a single argument, `name`, is required which refers to the key pair in the Keyring. In addition, an optional - `--moniker` flag can be provided to override the moniker found in `config.toml`. - * (x/upgrade) [#7697](https://github.com/cosmos/cosmos-sdk/pull/7697) Rename flag name "--time" to "--upgrade-time", "--info" to "--upgrade-info", to keep it consistent with help message. -* __REST / Queriers__ - * (api) [\#6426](https://github.com/cosmos/cosmos-sdk/pull/6426) The ability to start an out-of-process API REST server has now been removed. Instead, the API server is now started in-process along with the application and Tendermint. Configuration options have been added to `app.toml` to enable/disable the API server along with additional HTTP server options. - * (client) [\#7246](https://github.com/cosmos/cosmos-sdk/pull/7246) The rest server endpoint `/swagger-ui/` is replaced by `/swagger/`, and contains swagger documentation for gRPC Gateway routes in addition to legacy REST routes. Swagger API is exposed only if set in `app.toml`. - * (x/auth) [\#5702](https://github.com/cosmos/cosmos-sdk/pull/5702) The `x/auth` querier route has changed from `"acc"` to `"auth"`. - * (x/bank) [\#5572](https://github.com/cosmos/cosmos-sdk/pull/5572) The `/bank/balances/{address}` endpoint now returns all account balances or a single balance by denom when the `denom` query parameter is present. - * (x/evidence) [\#5952](https://github.com/cosmos/cosmos-sdk/pull/5952) Remove CLI and REST handlers for querying `x/evidence` parameters. - * (x/gov) [#6295](https://github.com/cosmos/cosmos-sdk/pull/6295) Fix typo in querying governance params. -* __General__ - * (baseapp) [\#6384](https://github.com/cosmos/cosmos-sdk/pull/6384) The `Result.Data` is now a Protocol Buffer encoded binary blob of type `TxData`. The `TxData` contains `Data` which contains a list of Protocol Buffer encoded message data and the corresponding message type. - * (client) [\#5783](https://github.com/cosmos/cosmos-sdk/issues/5783) Unify all coins representations on JSON client requests for governance proposals. - * (crypto) [\#7419](https://github.com/cosmos/cosmos-sdk/pull/7419) The SDK doesn't use Tendermint's `crypto.PubKey` - interface anymore, and uses instead it's own `PubKey` interface, defined in `crypto/types`. Replace all instances of - `crypto.PubKey` by `cryptotypes.Pubkey`. - * (store/rootmulti) [\#6390](https://github.com/cosmos/cosmos-sdk/pull/6390) Proofs of empty stores are no longer supported. - * (store/types) [\#5730](https://github.com/cosmos/cosmos-sdk/pull/5730) store.types.Cp() is removed in favour of types.CopyBytes(). - * (x/auth) [\#6054](https://github.com/cosmos/cosmos-sdk/pull/6054) Remove custom JSON marshaling for base accounts as multsigs cannot be bech32 decoded. - * (x/auth/vesting) [\#6859](https://github.com/cosmos/cosmos-sdk/pull/6859) Custom JSON marshaling of vesting accounts was removed. Vesting accounts are now marshaled using their default proto or amino JSON representation. - * (x/bank) [\#5785](https://github.com/cosmos/cosmos-sdk/issues/5785) In x/bank errors, JSON strings coerced to valid UTF-8 bytes at JSON marshalling time - are now replaced by human-readable expressions. This change can potentially break compatibility with all those client side tools - that parse log messages. - * (x/evidence) [\#7538](https://github.com/cosmos/cosmos-sdk/pull/7538) The ABCI's `Result.Data` field for - `MsgSubmitEvidence` responses does not contain the raw evidence's hash, but the protobuf encoded - `MsgSubmitEvidenceResponse` struct. - * (x/gov) [\#7533](https://github.com/cosmos/cosmos-sdk/pull/7533) The ABCI's `Result.Data` field for - `MsgSubmitProposal` responses does not contain a raw binary encoding of the `proposalID`, but the protobuf encoded - `MsgSubmitSubmitProposalResponse` struct. - * (x/gov) [\#6859](https://github.com/cosmos/cosmos-sdk/pull/6859) `ProposalStatus` and `VoteOption` are now JSON serialized using its protobuf name, so expect names like `PROPOSAL_STATUS_DEPOSIT_PERIOD` as opposed to `DepositPeriod`. - * (x/staking) [\#7499](https://github.com/cosmos/cosmos-sdk/pull/7499) `BondStatus` is now a protobuf `enum` instead - of an `int32`, and JSON serialized using its protobuf name, so expect names like `BOND_STATUS_UNBONDING` as opposed - to `Unbonding`. - * (x/staking) [\#7556](https://github.com/cosmos/cosmos-sdk/pull/7556) The ABCI's `Result.Data` field for - `MsgBeginRedelegate` and `MsgUndelegate` responses does not contain custom binary marshaled `completionTime`, but the - protobuf encoded `MsgBeginRedelegateResponse` and `MsgUndelegateResponse` structs respectively - -### API Breaking Changes - -* __Baseapp / Client__ - * (AppModule) [\#7518](https://github.com/cosmos/cosmos-sdk/pull/7518) [\#7584](https://github.com/cosmos/cosmos-sdk/pull/7584) Rename `AppModule.RegisterQueryServices` to `AppModule.RegisterServices`, as this method now registers multiple services (the gRPC query service and the protobuf Msg service). A `Configurator` struct is used to hold the different services. - * (baseapp) [\#5865](https://github.com/cosmos/cosmos-sdk/pull/5865) The `SimulationResponse` returned from tx simulation is now JSON encoded instead of Amino binary. - * (client) [\#6290](https://github.com/cosmos/cosmos-sdk/pull/6290) `CLIContext` is renamed to `Context`. `Context` and all related methods have been moved from package context to client. - * (client) [\#6525](https://github.com/cosmos/cosmos-sdk/pull/6525) Removed support for `indent` in JSON responses. Clients should consider piping to an external tool such as `jq`. - * (client) [\#8107](https://github.com/cosmos/cosmos-sdk/pull/8107) Renamed `PrintOutput` and `PrintOutputLegacy` - methods of the `context.Client` object to `PrintProto` and `PrintObjectLegacy`. - * (client/flags) [\#6632](https://github.com/cosmos/cosmos-sdk/pull/6632) Remove NewCompletionCmd(), the function is now available in tendermint. - * (client/input) [\#5904](https://github.com/cosmos/cosmos-sdk/pull/5904) Removal of unnecessary `GetCheckPassword`, `PrintPrefixed` functions. - * (client/keys) [\#5889](https://github.com/cosmos/cosmos-sdk/pull/5889) Rename `NewKeyBaseFromDir()` -> `NewLegacyKeyBaseFromDir()`. - * (client/keys) [\#5820](https://github.com/cosmos/cosmos-sdk/pull/5820/) Removed method CloseDB from Keybase interface. - * (client/rpc) [\#6290](https://github.com/cosmos/cosmos-sdk/pull/6290) `client` package and subdirs reorganization. - * (client/lcd) [\#6290](https://github.com/cosmos/cosmos-sdk/pull/6290) `CliCtx` of struct `RestServer` in package client/lcd has been renamed to `ClientCtx`. - * (codec) [\#6330](https://github.com/cosmos/cosmos-sdk/pull/6330) `codec.RegisterCrypto` has been moved to the `crypto/codec` package and the global `codec.Cdc` Amino instance has been deprecated and moved to the `codec/legacy_global` package. - * (codec) [\#8080](https://github.com/cosmos/cosmos-sdk/pull/8080) Updated the `codec.Marshaler` interface - * Moved `MarshalAny` and `UnmarshalAny` helper functions to `codec.Marshaler` and renamed to `MarshalInterface` and - `UnmarshalInterface` respectively. These functions must take interface as a parameter (not a concrete type nor `Any` - object). Underneath they use `Any` wrapping for correct protobuf serialization. - * (crypto) [\#6780](https://github.com/cosmos/cosmos-sdk/issues/6780) Move ledger code to its own package. - * (crypto/types/multisig) [\#6373](https://github.com/cosmos/cosmos-sdk/pull/6373) `multisig.Multisignature` has been renamed to `AminoMultisignature` - * (codec) `*codec.LegacyAmino` is now a wrapper around Amino which provides backwards compatibility with protobuf `Any`. ALL legacy code should use `*codec.LegacyAmino` instead of `*amino.Codec` directly - * (crypto) [\#5880](https://github.com/cosmos/cosmos-sdk/pull/5880) Merge `crypto/keys/mintkey` into `crypto`. - * (crypto/hd) [\#5904](https://github.com/cosmos/cosmos-sdk/pull/5904) `crypto/keys/hd` moved to `crypto/hd`. - * (crypto/keyring): - * [\#5866](https://github.com/cosmos/cosmos-sdk/pull/5866) Rename `crypto/keys/` to `crypto/keyring/`. - * [\#5904](https://github.com/cosmos/cosmos-sdk/pull/5904) `Keybase` -> `Keyring` interfaces migration. `LegacyKeybase` interface is added in order - to guarantee limited backward compatibility with the old Keybase interface for the sole purpose of migrating keys across the new keyring backends. `NewLegacy` - constructor is provided [\#5889](https://github.com/cosmos/cosmos-sdk/pull/5889) to allow for smooth migration of keys from the legacy LevelDB based implementation - to new keyring backends. Plus, the package and the new keyring no longer depends on the sdk.Config singleton. Please consult the [package documentation](https://github.com/cosmos/cosmos-sdk/tree/master/crypto/keyring/doc.go) for more - information on how to implement the new `Keyring` interface. - * [\#5858](https://github.com/cosmos/cosmos-sdk/pull/5858) Make Keyring store keys by name and address's hexbytes representation. - * (export) [\#5952](https://github.com/cosmos/cosmos-sdk/pull/5952) `AppExporter` now returns ABCI consensus parameters to be included in marshaled exported state. These parameters must be returned from the application via the `BaseApp`. - * (simapp) Deprecating and renaming `MakeEncodingConfig` to `MakeTestEncodingConfig` (both in `simapp` and `simapp/params` packages). - * (store) [\#5803](https://github.com/cosmos/cosmos-sdk/pull/5803) The `store.CommitMultiStore` interface now includes the new `snapshots.Snapshotter` interface as well. - * (types) [\#5579](https://github.com/cosmos/cosmos-sdk/pull/5579) The `keepRecent` field has been removed from the `PruningOptions` type. - The `PruningOptions` type now only includes fields `KeepEvery` and `SnapshotEvery`, where `KeepEvery` - determines which committed heights are flushed to disk and `SnapshotEvery` determines which of these - heights are kept after pruning. The `IsValid` method should be called whenever using these options. Methods - `SnapshotVersion` and `FlushVersion` accept a version arugment and determine if the version should be - flushed to disk or kept as a snapshot. Note, `KeepRecent` is automatically inferred from the options - and provided directly the IAVL store. - * (types) [\#5533](https://github.com/cosmos/cosmos-sdk/pull/5533) Refactored `AppModuleBasic` and `AppModuleGenesis` - to now accept a `codec.JSONMarshaler` for modular serialization of genesis state. - * (types/rest) [\#5779](https://github.com/cosmos/cosmos-sdk/pull/5779) Drop unused Parse{Int64OrReturnBadRequest,QueryParamBool}() functions. -* __Modules__ - * (modules) [\#7243](https://github.com/cosmos/cosmos-sdk/pull/7243) Rename `RegisterCodec` to `RegisterLegacyAminoCodec` and `codec.New()` is now renamed to `codec.NewLegacyAmino()` - * (modules) [\#6564](https://github.com/cosmos/cosmos-sdk/pull/6564) Constant `DefaultParamspace` is removed from all modules, use ModuleName instead. - * (modules) [\#5989](https://github.com/cosmos/cosmos-sdk/pull/5989) `AppModuleBasic.GetTxCmd` now takes a single `CLIContext` parameter. - * (modules) [\#5664](https://github.com/cosmos/cosmos-sdk/pull/5664) Remove amino `Codec` from simulation `StoreDecoder`, which now returns a function closure in order to unmarshal the key-value pairs. - * (modules) [\#5555](https://github.com/cosmos/cosmos-sdk/pull/5555) Move `x/auth/client/utils/` types and functions to `x/auth/client/`. - * (modules) [\#5572](https://github.com/cosmos/cosmos-sdk/pull/5572) Move account balance logic and APIs from `x/auth` to `x/bank`. - * (modules) [\#6326](https://github.com/cosmos/cosmos-sdk/pull/6326) `AppModuleBasic.GetQueryCmd` now takes a single `client.Context` parameter. - * (modules) [\#6336](https://github.com/cosmos/cosmos-sdk/pull/6336) `AppModuleBasic.RegisterQueryService` method was added to support gRPC queries, and `QuerierRoute` and `NewQuerierHandler` were deprecated. - * (modules) [\#6311](https://github.com/cosmos/cosmos-sdk/issues/6311) Remove `alias.go` usage - * (modules) [\#6447](https://github.com/cosmos/cosmos-sdk/issues/6447) Rename `blacklistedAddrs` to `blockedAddrs`. - * (modules) [\#6834](https://github.com/cosmos/cosmos-sdk/issues/6834) Add `RegisterInterfaces` method to `AppModuleBasic` to support registration of protobuf interface types. - * (modules) [\#6734](https://github.com/cosmos/cosmos-sdk/issues/6834) Add `TxEncodingConfig` parameter to `AppModuleBasic.ValidateGenesis` command to support JSON tx decoding in `genutil`. - * (modules) [#7764](https://github.com/cosmos/cosmos-sdk/pull/7764) Added module initialization options: - * `server/types.AppExporter` requires extra argument: `AppOptions`. - * `server.AddCommands` requires extra argument: `addStartFlags types.ModuleInitFlags` - * `x/crisis.NewAppModule` has a new attribute: `skipGenesisInvariants`. [PR](https://github.com/cosmos/cosmos-sdk/pull/7764) - * (types) [\#6327](https://github.com/cosmos/cosmos-sdk/pull/6327) `sdk.Msg` now inherits `proto.Message`, as a result all `sdk.Msg` types now use pointer semantics. - * (types) [\#7032](https://github.com/cosmos/cosmos-sdk/pull/7032) All types ending with `ID` (e.g. `ProposalID`) now end with `Id` (e.g. `ProposalId`), to match default Protobuf generated format. Also see [\#7033](https://github.com/cosmos/cosmos-sdk/pull/7033) for more details. - * (x/auth) [\#6029](https://github.com/cosmos/cosmos-sdk/pull/6029) Module accounts have been moved from `x/supply` to `x/auth`. - * (x/auth) [\#6443](https://github.com/cosmos/cosmos-sdk/issues/6443) Move `FeeTx` and `TxWithMemo` interfaces from `x/auth/ante` to `types`. - * (x/auth) [\#7006](https://github.com/cosmos/cosmos-sdk/pull/7006) All `AccountRetriever` methods now take `client.Context` as a parameter instead of as a struct member. - * (x/auth) [\#6270](https://github.com/cosmos/cosmos-sdk/pull/6270) The passphrase argument has been removed from the signature of the following functions and methods: `BuildAndSign`, ` MakeSignature`, ` SignStdTx`, `TxBuilder.BuildAndSign`, `TxBuilder.Sign`, `TxBuilder.SignStdTx` - * (x/auth) [\#6428](https://github.com/cosmos/cosmos-sdk/issues/6428): - * `NewAnteHandler` and `NewSigVerificationDecorator` both now take a `SignModeHandler` parameter. - * `SignatureVerificationGasConsumer` now has the signature: `func(meter sdk.GasMeter, sig signing.SignatureV2, params types.Params) error`. - * The `SigVerifiableTx` interface now has a `GetSignaturesV2() ([]signing.SignatureV2, error)` method and no longer has the `GetSignBytes` method. - * (x/auth/tx) [\#8106](https://github.com/cosmos/cosmos-sdk/pull/8106) change related to missing append functionality in - client transaction signing - + added `overwriteSig` argument to `x/auth/client.SignTx` and `client/tx.Sign` functions. - + removed `x/auth/tx.go:wrapper.GetSignatures`. The `wrapper` provides `TxBuilder` functionality, and it's a private - structure. That function was not used at all and it's not exposed through the `TxBuilder` interface. - * (x/bank) [\#7327](https://github.com/cosmos/cosmos-sdk/pull/7327) AddCoins and SubtractCoins no longer return a resultingValue and will only return an error. - * (x/capability) [#7918](https://github.com/cosmos/cosmos-sdk/pull/7918) Add x/capability safety checks: - * All outward facing APIs will now check that capability is not nil and name is not empty before performing any state-machine changes - * `SetIndex` has been renamed to `InitializeIndex` - * (x/evidence) [\#7251](https://github.com/cosmos/cosmos-sdk/pull/7251) New evidence types and light client evidence handling. The module function names changed. - * (x/evidence) [\#5952](https://github.com/cosmos/cosmos-sdk/pull/5952) Remove APIs for getting and setting `x/evidence` parameters. `BaseApp` now uses a `ParamStore` to manage Tendermint consensus parameters which is managed via the `x/params` `Substore` type. - * (x/gov) [\#6147](https://github.com/cosmos/cosmos-sdk/pull/6147) The `Content` field on `Proposal` and `MsgSubmitProposal` - is now `Any` in concordance with [ADR 019](docs/architecture/adr-019-protobuf-state-encoding.md) and `GetContent` should now - be used to retrieve the actual proposal `Content`. Also the `NewMsgSubmitProposal` constructor now may return an `error` - * (x/ibc) [\#6374](https://github.com/cosmos/cosmos-sdk/pull/6374) `VerifyMembership` and `VerifyNonMembership` now take a `specs []string` argument to specify the proof format used for verification. Most SDK chains can simply use `commitmenttypes.GetSDKSpecs()` for this argument. - * (x/params) [\#5619](https://github.com/cosmos/cosmos-sdk/pull/5619) The `x/params` keeper now accepts a `codec.Marshaller` instead of - a reference to an amino codec. Amino is still used for JSON serialization. - * (x/staking) [\#6451](https://github.com/cosmos/cosmos-sdk/pull/6451) `DefaultParamspace` and `ParamKeyTable` in staking module are moved from keeper to types to enforce consistency. - * (x/staking) [\#7419](https://github.com/cosmos/cosmos-sdk/pull/7419) The `TmConsPubKey` method on ValidatorI has been - removed and replaced instead by `ConsPubKey` (which returns a SDK `cryptotypes.PubKey`) and `TmConsPublicKey` (which - returns a Tendermint proto PublicKey). - * (x/staking/types) [\#7447](https://github.com/cosmos/cosmos-sdk/issues/7447) Remove bech32 PubKey support: - * `ValidatorI` interface update. `GetConsPubKey` renamed to `TmConsPubKey` (consensus public key must be a tendermint key). `TmConsPubKey`, `GetConsAddr` methods return error. - * `Validator` update. Methods changed in `ValidatorI` (as described above) and `ToTmValidator` return error. - * `Validator.ConsensusPubkey` type changed from `string` to `codectypes.Any`. - * `MsgCreateValidator.Pubkey` type changed from `string` to `codectypes.Any`. - * (x/supply) [\#6010](https://github.com/cosmos/cosmos-sdk/pull/6010) All `x/supply` types and APIs have been moved to `x/bank`. - * [\#6409](https://github.com/cosmos/cosmos-sdk/pull/6409) Rename all IsEmpty methods to Empty across the codebase and enforce consistency. - * [\#6231](https://github.com/cosmos/cosmos-sdk/pull/6231) Simplify `AppModule` interface, `Route` and `NewHandler` methods become only `Route` - and returns a new `Route` type. - * (x/slashing) [\#6212](https://github.com/cosmos/cosmos-sdk/pull/6212) Remove `Get*` prefixes from key construction functions - * (server) [\#6079](https://github.com/cosmos/cosmos-sdk/pull/6079) Remove `UpgradeOldPrivValFile` (deprecated in Tendermint Core v0.28). - * [\#5719](https://github.com/cosmos/cosmos-sdk/pull/5719) Bump Go requirement to 1.14+ - - -### State Machine Breaking - -* __General__ - * (client) [\#7268](https://github.com/cosmos/cosmos-sdk/pull/7268) / [\#7147](https://github.com/cosmos/cosmos-sdk/pull/7147) Introduce new protobuf based PubKeys, and migrate PubKey in BaseAccount to use this new protobuf based PubKey format - -* __Modules__ - * (modules) [\#5572](https://github.com/cosmos/cosmos-sdk/pull/5572) Separate balance from accounts per ADR 004. - * Account balances are now persisted and retrieved via the `x/bank` module. - * Vesting account interface has been modified to account for changes. - * Callers to `NewBaseVestingAccount` are responsible for verifying account balance in relation to - the original vesting amount. - * The `SendKeeper` and `ViewKeeper` interfaces in `x/bank` have been modified to account for changes. - * (x/auth) [\#5533](https://github.com/cosmos/cosmos-sdk/pull/5533) Migrate the `x/auth` module to use Protocol Buffers for state - serialization instead of Amino. - * The `BaseAccount.PubKey` field is now represented as a Bech32 string instead of a `crypto.Pubkey`. - * `NewBaseAccountWithAddress` now returns a reference to a `BaseAccount`. - * The `x/auth` module now accepts a `Codec` interface which extends the `codec.Marshaler` interface by - requiring a concrete codec to know how to serialize accounts. - * The `AccountRetriever` type now accepts a `Codec` in its constructor in order to know how to - serialize accounts. - * (x/bank) [\#6518](https://github.com/cosmos/cosmos-sdk/pull/6518) Support for global and per-denomination send enabled flags. - * Existing send_enabled global flag has been moved into a Params structure as `default_send_enabled`. - * An array of: `{denom: string, enabled: bool}` is added to bank Params to support per-denomination override of global default value. - * (x/distribution) [\#5610](https://github.com/cosmos/cosmos-sdk/pull/5610) Migrate the `x/distribution` module to use Protocol Buffers for state - serialization instead of Amino. The exact codec used is `codec.HybridCodec` which utilizes Protobuf for binary encoding and Amino - for JSON encoding. - * `ValidatorHistoricalRewards.ReferenceCount` is now of types `uint32` instead of `uint16`. - * `ValidatorSlashEvents` is now a struct with `slashevents`. - * `ValidatorOutstandingRewards` is now a struct with `rewards`. - * `ValidatorAccumulatedCommission` is now a struct with `commission`. - * The `Keeper` constructor now takes a `codec.Marshaler` instead of a concrete Amino codec. This exact type - provided is specified by `ModuleCdc`. - * (x/evidence) [\#5634](https://github.com/cosmos/cosmos-sdk/pull/5634) Migrate the `x/evidence` module to use Protocol Buffers for state - serialization instead of Amino. - * The `internal` sub-package has been removed in order to expose the types proto file. - * The module now accepts a `Codec` interface which extends the `codec.Marshaler` interface by - requiring a concrete codec to know how to serialize `Evidence` types. - * The `MsgSubmitEvidence` message has been removed in favor of `MsgSubmitEvidenceBase`. The application-level - codec must now define the concrete `MsgSubmitEvidence` type which must implement the module's `MsgSubmitEvidence` - interface. - * (x/evidence) [\#5952](https://github.com/cosmos/cosmos-sdk/pull/5952) Remove parameters from `x/evidence` genesis and module state. The `x/evidence` module now solely uses Tendermint consensus parameters to determine of evidence is valid or not. - * (x/gov) [\#5737](https://github.com/cosmos/cosmos-sdk/pull/5737) Migrate the `x/gov` module to use Protocol - Buffers for state serialization instead of Amino. - * `MsgSubmitProposal` will be removed in favor of the application-level proto-defined `MsgSubmitProposal` which - implements the `MsgSubmitProposalI` interface. Applications should extend the `NewMsgSubmitProposalBase` type - to define their own concrete `MsgSubmitProposal` types. - * The module now accepts a `Codec` interface which extends the `codec.Marshaler` interface by - requiring a concrete codec to know how to serialize `Proposal` types. - * (x/mint) [\#5634](https://github.com/cosmos/cosmos-sdk/pull/5634) Migrate the `x/mint` module to use Protocol Buffers for state - serialization instead of Amino. - * The `internal` sub-package has been removed in order to expose the types proto file. - * (x/slashing) [\#5627](https://github.com/cosmos/cosmos-sdk/pull/5627) Migrate the `x/slashing` module to use Protocol Buffers for state - serialization instead of Amino. The exact codec used is `codec.HybridCodec` which utilizes Protobuf for binary encoding and Amino - for JSON encoding. - * The `Keeper` constructor now takes a `codec.Marshaler` instead of a concrete Amino codec. This exact type - provided is specified by `ModuleCdc`. - * (x/staking) [\#6844](https://github.com/cosmos/cosmos-sdk/pull/6844) Validators are now inserted into the unbonding queue based on their unbonding time and height. The relevant keeper APIs are modified to reflect these changes by now also requiring a height. - * (x/staking) [\#6061](https://github.com/cosmos/cosmos-sdk/pull/6061) Allow a validator to immediately unjail when no signing info is present due to - falling below their minimum self-delegation and never having been bonded. The validator may immediately unjail once they've met their minimum self-delegation. - * (x/staking) [\#5600](https://github.com/cosmos/cosmos-sdk/pull/5600) Migrate the `x/staking` module to use Protocol Buffers for state - serialization instead of Amino. The exact codec used is `codec.HybridCodec` which utilizes Protobuf for binary encoding and Amino - for JSON encoding. - * `BondStatus` is now of type `int32` instead of `byte`. - * Types of `int16` in the `Params` type are now of type `int32`. - * Every reference of `crypto.Pubkey` in context of a `Validator` is now of type string. `GetPubKeyFromBech32` must be used to get the `crypto.Pubkey`. - * The `Keeper` constructor now takes a `codec.Marshaler` instead of a concrete Amino codec. This exact type - provided is specified by `ModuleCdc`. - * (x/staking) [\#7979](https://github.com/cosmos/cosmos-sdk/pull/7979) keeper pubkey storage serialization migration - from bech32 to protobuf. - * (x/supply) [\#6010](https://github.com/cosmos/cosmos-sdk/pull/6010) Removed the `x/supply` module by merging the existing types and APIs into the `x/bank` module. - * (x/supply) [\#5533](https://github.com/cosmos/cosmos-sdk/pull/5533) Migrate the `x/supply` module to use Protocol Buffers for state - serialization instead of Amino. - * The `internal` sub-package has been removed in order to expose the types proto file. - * The `x/supply` module now accepts a `Codec` interface which extends the `codec.Marshaler` interface by - requiring a concrete codec to know how to serialize `SupplyI` types. - * The `SupplyI` interface has been modified to no longer return `SupplyI` on methods. Instead the - concrete type's receiver should modify the type. - * (x/upgrade) [\#5659](https://github.com/cosmos/cosmos-sdk/pull/5659) Migrate the `x/upgrade` module to use Protocol - Buffers for state serialization instead of Amino. - * The `internal` sub-package has been removed in order to expose the types proto file. - * The `x/upgrade` module now accepts a `codec.Marshaler` interface. - -### Features - -* __Baseapp / Client / REST__ - * (x/auth) [\#6213](https://github.com/cosmos/cosmos-sdk/issues/6213) Introduce new protobuf based path for transaction signing, see [ADR020](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-020-protobuf-transaction-encoding.md) for more details - * (x/auth) [\#6350](https://github.com/cosmos/cosmos-sdk/pull/6350) New sign-batch command to sign StdTx batch files. - * (baseapp) [\#5803](https://github.com/cosmos/cosmos-sdk/pull/5803) Added support for taking state snapshots at regular height intervals, via options `snapshot-interval` and `snapshot-keep-recent`. - * (baseapp) [\#7519](https://github.com/cosmos/cosmos-sdk/pull/7519) Add `ServiceMsgRouter` to BaseApp to handle routing of protobuf service `Msg`s. The two new types defined in ADR 031, `sdk.ServiceMsg` and `sdk.MsgRequest` are introduced with this router. - * (client) [\#5921](https://github.com/cosmos/cosmos-sdk/issues/5921) Introduce new gRPC and gRPC Gateway based APIs for querying app & module data. See [ADR021](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-021-protobuf-query-encoding.md) for more details - * (cli) [\#7485](https://github.com/cosmos/cosmos-sdk/pull/7485) Introduce a new optional `--keyring-dir` flag that allows clients to specify a Keyring directory if it does not reside in the directory specified by `--home`. - * (cli) [\#7221](https://github.com/cosmos/cosmos-sdk/pull/7221) Add the option of emitting amino encoded json from the CLI - * (codec) [\#7519](https://github.com/cosmos/cosmos-sdk/pull/7519) `InterfaceRegistry` now inherits `jsonpb.AnyResolver`, and has a `RegisterCustomTypeURL` method to support ADR 031 packing of `Any`s. `AnyResolver` is now a required parameter to `RejectUnknownFields`. - * (coin) [\#6755](https://github.com/cosmos/cosmos-sdk/pull/6755) Add custom regex validation for `Coin` denom by overwriting `CoinDenomRegex` when using `/types/coin.go`. - * (config) [\#7265](https://github.com/cosmos/cosmos-sdk/pull/7265) Support Tendermint block pruning through a new `min-retain-blocks` configuration that can be set in either `app.toml` or via the CLI. This parameter is used in conjunction with other criteria to determine the height at which Tendermint should prune blocks. - * (events) [\#7121](https://github.com/cosmos/cosmos-sdk/pull/7121) The application now derives what events are indexed by Tendermint via the `index-events` configuration in `app.toml`, which is a list of events taking the form `{eventType}.{attributeKey}`. - * (tx) [\#6089](https://github.com/cosmos/cosmos-sdk/pull/6089) Transactions can now have a `TimeoutHeight` set which allows the transaction to be rejected if it's committed at a height greater than the timeout. - * (rest) [\#6167](https://github.com/cosmos/cosmos-sdk/pull/6167) Support `max-body-bytes` CLI flag for the REST service. - * (genesis) [\#7089](https://github.com/cosmos/cosmos-sdk/pull/7089) The `export` command now adds a `initial_height` field in the exported JSON. Baseapp's `CommitMultiStore` now also has a `SetInitialVersion` setter, so it can set the initial store version inside `InitChain` and start a new chain from a given height. -* __General__ - * (crypto/multisig) [\#6241](https://github.com/cosmos/cosmos-sdk/pull/6241) Add Multisig type directly to the repo. Previously this was in tendermint. - * (codec/types) [\#8106](https://github.com/cosmos/cosmos-sdk/pull/8106) Adding `NewAnyWithCustomTypeURL` to correctly - marshal Messages in TxBuilder. - * (tests) [\#6489](https://github.com/cosmos/cosmos-sdk/pull/6489) Introduce package `testutil`, new in-process testing network framework for use in integration and unit tests. - * (tx) Add new auth/tx gRPC & gRPC-Gateway endpoints for basic querying & broadcasting support - * [\#7842](https://github.com/cosmos/cosmos-sdk/pull/7842) Add TxsByEvent gRPC endpoint - * [\#7852](https://github.com/cosmos/cosmos-sdk/pull/7852) Add tx broadcast gRPC endpoint - * (tx) [\#7688](https://github.com/cosmos/cosmos-sdk/pull/7688) Add a new Tx gRPC service with methods `Simulate` and `GetTx` (by hash). - * (store) [\#5803](https://github.com/cosmos/cosmos-sdk/pull/5803) Added `rootmulti.Store` methods for taking and restoring snapshots, based on `iavl.Store` export/import. - * (store) [\#6324](https://github.com/cosmos/cosmos-sdk/pull/6324) IAVL store query proofs now return CommitmentOp which wraps an ics23 CommitmentProof - * (store) [\#6390](https://github.com/cosmos/cosmos-sdk/pull/6390) `RootMulti` store query proofs now return `CommitmentOp` which wraps `CommitmentProofs` - * `store.Query` now only returns chained `ics23.CommitmentProof` wrapped in `merkle.Proof` - * `ProofRuntime` only decodes and verifies `ics23.CommitmentProof` -* __Modules__ - * (modules) [\#5921](https://github.com/cosmos/cosmos-sdk/issues/5921) Introduction of Query gRPC service definitions along with REST annotations for gRPC Gateway for each module - * (modules) [\#7540](https://github.com/cosmos/cosmos-sdk/issues/7540) Protobuf service definitions can now be used for - packing `Msg`s in transactions as defined in [ADR 031](./docs/architecture/adr-031-msg-service.md). All modules now - define a `Msg` protobuf service. - * (x/auth/vesting) [\#7209](https://github.com/cosmos/cosmos-sdk/pull/7209) Create new `MsgCreateVestingAccount` message type along with CLI handler that allows for the creation of delayed and continuous vesting types. - * (x/capability) [\#5828](https://github.com/cosmos/cosmos-sdk/pull/5828) Capability module integration as outlined in [ADR 3 - Dynamic Capability Store](https://github.com/cosmos/tree/master/docs/architecture/adr-003-dynamic-capability-store.md). - * (x/crisis) `x/crisis` has a new function: `AddModuleInitFlags`, which will register optional crisis module flags for the start command. - * (x/ibc) [\#5277](https://github.com/cosmos/cosmos-sdk/pull/5277) `x/ibc` changes from IBC alpha. For more details check the the [`x/ibc/core/spec`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/spec) directory, or the ICS specs below: - * [ICS 002 - Client Semantics](https://github.com/cosmos/ics/tree/master/spec/ics-002-client-semantics) subpackage - * [ICS 003 - Connection Semantics](https://github.com/cosmos/ics/blob/master/spec/ics-003-connection-semantics) subpackage - * [ICS 004 - Channel and Packet Semantics](https://github.com/cosmos/ics/blob/master/spec/ics-004-channel-and-packet-semantics) subpackage - * [ICS 005 - Port Allocation](https://github.com/cosmos/ics/blob/master/spec/ics-005-port-allocation) subpackage - * [ICS 006 - Solo Machine Client](https://github.com/cosmos/ics/tree/master/spec/ics-006-solo-machine-client) subpackage - * [ICS 007 - Tendermint Client](https://github.com/cosmos/ics/blob/master/spec/ics-007-tendermint-client) subpackage - * [ICS 009 - Loopback Client](https://github.com/cosmos/ics/tree/master/spec/ics-009-loopback-client) subpackage - * [ICS 020 - Fungible Token Transfer](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer) subpackage - * [ICS 023 - Vector Commitments](https://github.com/cosmos/ics/tree/master/spec/ics-023-vector-commitments) subpackage - * [ICS 024 - Host State Machine Requirements](https://github.com/cosmos/ics/tree/master/spec/ics-024-host-requirements) subpackage - * (x/ibc) [\#6374](https://github.com/cosmos/cosmos-sdk/pull/6374) ICS-23 Verify functions will now accept and verify ics23 CommitmentProofs exclusively - * (x/params) [\#6005](https://github.com/cosmos/cosmos-sdk/pull/6005) Add new CLI command for querying raw x/params parameters by subspace and key. - -### Bug Fixes - -* __Baseapp / Client / REST__ - * (client) [\#5964](https://github.com/cosmos/cosmos-sdk/issues/5964) `--trust-node` is now false by default - for real. Users must ensure it is set to true if they don't want to enable the verifier. - * (client) [\#6402](https://github.com/cosmos/cosmos-sdk/issues/6402) Fix `keys add` `--algo` flag which only worked for Tendermint's `secp256k1` default key signing algorithm. - * (client) [\#7699](https://github.com/cosmos/cosmos-sdk/pull/7699) Fix panic in context when setting invalid nodeURI. `WithNodeURI` does not set the `Client` in the context. - * (export) [\#6510](https://github.com/cosmos/cosmos-sdk/pull/6510/) Field TimeIotaMs now is included in genesis file while exporting. - * (rest) [\#5906](https://github.com/cosmos/cosmos-sdk/pull/5906) Fix an issue that make some REST calls panic when sending invalid or incomplete requests. - * (crypto) [\#7966](https://github.com/cosmos/cosmos-sdk/issues/7966) `Bip44Params` `String()` function now correctly - returns the absolute HD path by adding the `m/` prefix. - * (crypto/keyring) [\#5844](https://github.com/cosmos/cosmos-sdk/pull/5844) `Keyring.Sign()` methods no longer decode amino signatures when method receivers - are offline/multisig keys. - * (store) [\#7415](https://github.com/cosmos/cosmos-sdk/pull/7415) Allow new stores to be registered during on-chain upgrades. -* __Modules__ - * (modules) [\#5569](https://github.com/cosmos/cosmos-sdk/issues/5569) `InitGenesis`, for the relevant modules, now ensures module accounts exist. - * (x/auth) [\#5892](https://github.com/cosmos/cosmos-sdk/pull/5892) Add `RegisterKeyTypeCodec` to register new - types (eg. keys) to the `auth` module internal amino codec. - * (x/bank) [\#6536](https://github.com/cosmos/cosmos-sdk/pull/6536) Fix bug in `WriteGeneratedTxResponse` function used by multiple - REST endpoints. Now it writes a Tx in StdTx format. - * (x/genutil) [\#5938](https://github.com/cosmos/cosmos-sdk/pull/5938) Fix `InitializeNodeValidatorFiles` error handling. - * (x/gentx) [\#8183](https://github.com/cosmos/cosmos-sdk/pull/8183) change gentx cmd amount to arg from flag - * (x/gov) [#7641](https://github.com/cosmos/cosmos-sdk/pull/7641) Fix tally calculation precision error. - * (x/staking) [\#6529](https://github.com/cosmos/cosmos-sdk/pull/6529) Export validator addresses (previously was empty). - * (x/staking) [\#5949](https://github.com/cosmos/cosmos-sdk/pull/5949) Skip staking `HistoricalInfoKey` in simulations as headers are not exported. - * (x/staking) [\#6061](https://github.com/cosmos/cosmos-sdk/pull/6061) Allow a validator to immediately unjail when no signing info is present due to -falling below their minimum self-delegation and never having been bonded. The validator may immediately unjail once they've met their minimum self-delegation. -* __General__ - * (types) [\#7038](https://github.com/cosmos/cosmos-sdk/issues/7038) Fix infinite looping of `ApproxRoot` by including a hard-coded maximum iterations limit of 100. - * (types) [\#7084](https://github.com/cosmos/cosmos-sdk/pull/7084) Fix panic when calling `BigInt()` on an uninitialized `Int`. - * (simulation) [\#7129](https://github.com/cosmos/cosmos-sdk/issues/7129) Fix support for custom `Account` and key types on auth's simulation. - - -### Improvements -* __Baseapp / Client / REST__ - * (baseapp) [\#6186](https://github.com/cosmos/cosmos-sdk/issues/6186) Support emitting events during `AnteHandler` execution. - * (baseapp) [\#6053](https://github.com/cosmos/cosmos-sdk/pull/6053) Customizable panic recovery handling added for `app.runTx()` method (as proposed in the [ADR 22](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-022-custom-panic-handling.md)). Adds ability for developers to register custom panic handlers extending standard ones. - * (client) [\#5810](https://github.com/cosmos/cosmos-sdk/pull/5810) Added a new `--offline` flag that allows commands to be executed without an - internet connection. Previously, `--generate-only` served this purpose in addition to only allowing txs to be generated. Now, `--generate-only` solely - allows txs to be generated without being broadcasted and disallows Keybase use and `--offline` allows the use of Keybase but does not allow any - functionality that requires an online connection. - * (cli) [#7764](https://github.com/cosmos/cosmos-sdk/pull/7764) Update x/banking and x/crisis InitChain to improve node startup time - * (client) [\#5856](https://github.com/cosmos/cosmos-sdk/pull/5856) Added the possibility to set `--offline` flag with config command. - * (client) [\#5895](https://github.com/cosmos/cosmos-sdk/issues/5895) show config options in the config command's help screen. - * (client/keys) [\#8043](https://github.com/cosmos/cosmos-sdk/pull/8043) Add support for export of unarmored private key - * (client/tx) [\#7801](https://github.com/cosmos/cosmos-sdk/pull/7801) Update sign-batch multisig to work online - * (x/genutil) [\#8099](https://github.com/cosmos/cosmos-sdk/pull/8099) `init` now supports a `--recover` flag to recover - the private validator key from a given mnemonic -* __Modules__ - * (x/auth) [\#5702](https://github.com/cosmos/cosmos-sdk/pull/5702) Add parameter querying support for `x/auth`. - * (x/auth/ante) [\#6040](https://github.com/cosmos/cosmos-sdk/pull/6040) `AccountKeeper` interface used for `NewAnteHandler` and handler's decorators to add support of using custom `AccountKeeper` implementations. - * (x/evidence) [\#5952](https://github.com/cosmos/cosmos-sdk/pull/5952) Tendermint Consensus parameters can now be changed via parameter change proposals through `x/gov`. - * (x/evidence) [\#5961](https://github.com/cosmos/cosmos-sdk/issues/5961) Add `StoreDecoder` simulation for evidence module. - * (x/ibc) [\#5948](https://github.com/cosmos/cosmos-sdk/issues/5948) Add `InitGenesis` and `ExportGenesis` functions for `ibc` module. - * (x/ibc-transfer) [\#6871](https://github.com/cosmos/cosmos-sdk/pull/6871) Implement [ADR 001 - Coin Source Tracing](./docs/architecture/adr-001-coin-source-tracing.md). - * (x/staking) [\#6059](https://github.com/cosmos/cosmos-sdk/pull/6059) Updated `HistoricalEntries` parameter default to 100. - * (x/staking) [\#5584](https://github.com/cosmos/cosmos-sdk/pull/5584) Add util function `ToTmValidator` that converts a `staking.Validator` type to `*tmtypes.Validator`. - * (x/staking) [\#6163](https://github.com/cosmos/cosmos-sdk/pull/6163) CLI and REST call to unbonding delegations and delegations now accept - pagination. - * (x/staking) [\#8178](https://github.com/cosmos/cosmos-sdk/pull/8178) Update default historical header number for stargate -* __General__ - * (crypto) [\#7987](https://github.com/cosmos/cosmos-sdk/pull/7987) Fix the inconsistency of CryptoCdc, only use - `codec/legacy.Cdc`. - * (logging) [\#8072](https://github.com/cosmos/cosmos-sdk/pull/8072) Refactor logging: - * Use [zerolog](https://github.com/rs/zerolog) over Tendermint's go-kit logging wrapper. - * Introduce Tendermint's `--log_format=plain|json` flag. Using format `json` allows for emitting structured JSON - logs which can be consumed by an external logging facility (e.g. Loggly). Both formats log to STDERR. - * The existing `--log_level` flag and it's default value now solely relates to the global logging - level (e.g. `info`, `debug`, etc...) instead of `:`. - * (rest) [#7649](https://github.com/cosmos/cosmos-sdk/pull/7649) Return an unsigned tx in legacy GET /tx endpoint when signature conversion fails - * (simulation) [\#6002](https://github.com/cosmos/cosmos-sdk/pull/6002) Add randomized consensus params into simulation. - * (store) [\#6481](https://github.com/cosmos/cosmos-sdk/pull/6481) Move `SimpleProofsFromMap` from Tendermint into the SDK. - * (store) [\#6719](https://github.com/cosmos/cosmos-sdk/6754) Add validity checks to stores for nil and empty keys. - * (SDK) Updated dependencies - * Updated iavl dependency to v0.15.3 - * Update tendermint to v0.34.1 - * (types) [\#7027](https://github.com/cosmos/cosmos-sdk/pull/7027) `Coin(s)` and `DecCoin(s)` updates: - * Bump denomination max length to 128 - * Allow uppercase letters and numbers in denominations to support [ADR 001](./docs/architecture/adr-001-coin-source-tracing.md) - * Added `Validate` function that returns a descriptive error - * (types) [\#5581](https://github.com/cosmos/cosmos-sdk/pull/5581) Add convenience functions {,Must}Bech32ifyAddressBytes. - * (types/module) [\#5724](https://github.com/cosmos/cosmos-sdk/issues/5724) The `types/module` package does no longer depend on `x/simulation`. - * (types) [\#5585](https://github.com/cosmos/cosmos-sdk/pull/5585) IBC additions: - * `Coin` denomination max lenght has been increased to 32. - * Added `CapabilityKey` alias for `StoreKey` to match IBC spec. - * (types/rest) [\#5900](https://github.com/cosmos/cosmos-sdk/pull/5900) Add Check*Error function family to spare developers from replicating tons of boilerplate code. - * (types) [\#6128](https://github.com/cosmos/cosmos-sdk/pull/6137) Add `String()` method to `GasMeter`. - * (types) [\#6195](https://github.com/cosmos/cosmos-sdk/pull/6195) Add codespace to broadcast(sync/async) response. - * (types) \#6897 Add KV type from tendermint to `types` directory. - * (version) [\#7848](https://github.com/cosmos/cosmos-sdk/pull/7848) [\#7941](https://github.com/cosmos/cosmos-sdk/pull/7941) - `version --long` output now shows the list of build dependencies and replaced build dependencies. - -## [v0.39.1](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.39.1) - 2020-08-11 - -### Client Breaking - -* (x/auth) [\#6861](https://github.com/cosmos/cosmos-sdk/pull/6861) Remove public key Bech32 encoding for all account types for JSON serialization, instead relying on direct Amino encoding. In addition, JSON serialization utilizes Amino instead of the Go stdlib, so integers are treated as strings. - -### Improvements - -* (client) [\#6853](https://github.com/cosmos/cosmos-sdk/pull/6853) Add --unsafe-cors flag. - -## [v0.39.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.39.0) - 2020-07-20 - -### Improvements - -* (deps) Bump IAVL version to [v0.14.0](https://github.com/cosmos/iavl/releases/tag/v0.14.0) -* (client) [\#5585](https://github.com/cosmos/cosmos-sdk/pull/5585) `CLIContext` additions: - * Introduce `QueryABCI` that returns the full `abci.ResponseQuery` with inclusion Merkle proofs. - * Added `prove` flag for Merkle proof verification. -* (x/staking) [\#6791)](https://github.com/cosmos/cosmos-sdk/pull/6791) Close {UBDQueue,RedelegationQueu}Iterator once used. - -### API Breaking Changes - -* (baseapp) [\#5837](https://github.com/cosmos/cosmos-sdk/issues/5837) Transaction simulation now returns a `SimulationResponse` which contains the `GasInfo` and `Result` from the execution. - -### Client Breaking Changes - -* (x/auth) [\#6745](https://github.com/cosmos/cosmos-sdk/issues/6745) Remove BaseAccount's custom JSON {,un}marshalling. - -### Bug Fixes - -* (store) [\#6475](https://github.com/cosmos/cosmos-sdk/pull/6475) Revert IAVL pruning functionality introduced in -[v0.13.0](https://github.com/cosmos/iavl/releases/tag/v0.13.0), -where the IAVL no longer keeps states in-memory in which it flushes periodically. IAVL now commits and -flushes every state to disk as it did pre-v0.13.0. The SDK's multi-store will track and ensure the proper -heights are pruned. The operator can set the pruning options via a `pruning` config via the CLI or -through `app.toml`. The `pruning` flag exposes `default|everything|nothing|custom` as options -- -see docs for further details. If the operator chooses `custom`, they may provide granular pruning -options `pruning-keep-recent`, `pruning-keep-every`, and `pruning-interval`. The former two options -dictate how many recent versions are kept on disk and the offset of what versions are kept after that -respectively, and the latter defines the height interval in which versions are deleted in a batch. -**Note, there are some client-facing API breaking changes with regard to IAVL, stores, and pruning settings.** -* (x/distribution) [\#6210](https://github.com/cosmos/cosmos-sdk/pull/6210) Register `MsgFundCommunityPool` in distribution amino codec. -* (types) [\#5741](https://github.com/cosmos/cosmos-sdk/issues/5741) Prevent `ChainAnteDecorators()` from panicking when empty `AnteDecorator` slice is supplied. -* (baseapp) [\#6306](https://github.com/cosmos/cosmos-sdk/issues/6306) Prevent events emitted by the antehandler from being persisted between transactions. -* (client/keys) [\#5091](https://github.com/cosmos/cosmos-sdk/issues/5091) `keys parse` does not honor client app's configuration. -* (x/bank) [\#6674](https://github.com/cosmos/cosmos-sdk/pull/6674) Create account if recipient does not exist on handing `MsgMultiSend`. -* (x/auth) [\#6287](https://github.com/cosmos/cosmos-sdk/pull/6287) Fix nonce stuck when sending multiple transactions from an account in a same block. - -## [v0.38.5] - 2020-07-02 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.33.6](https://github.com/tendermint/tendermint/releases/tag/v0.33.6). - -## [v0.38.4] - 2020-05-21 - -### Bug Fixes - -* (x/auth) [\#5950](https://github.com/cosmos/cosmos-sdk/pull/5950) Fix `IncrementSequenceDecorator` to use is `IsReCheckTx` instead of `IsCheckTx` to allow account sequence incrementing. - -## [v0.38.3] - 2020-04-09 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.33.3](https://github.com/tendermint/tendermint/releases/tag/v0.33.3). - -## [v0.38.2] - 2020-03-25 - -### Bug Fixes - -* (baseapp) [\#5718](https://github.com/cosmos/cosmos-sdk/pull/5718) Remove call to `ctx.BlockGasMeter` during failed message validation which resulted in a panic when the tx execution mode was `CheckTx`. -* (x/genutil) [\#5775](https://github.com/cosmos/cosmos-sdk/pull/5775) Fix `ExportGenesis` in `x/genutil` to export default genesis state (`[]`) instead of `null`. -* (client) [\#5618](https://github.com/cosmos/cosmos-sdk/pull/5618) Fix crash on the client when the verifier is not set. -* (crypto/keys/mintkey) [\#5823](https://github.com/cosmos/cosmos-sdk/pull/5823) fix errors handling in `UnarmorPubKeyBytes` (underlying armoring function's return error was not being checked). -* (x/distribution) [\#5620](https://github.com/cosmos/cosmos-sdk/pull/5620) Fix nil pointer deref in distribution tax/reward validation helpers. - -### Improvements - -* (rest) [\#5648](https://github.com/cosmos/cosmos-sdk/pull/5648) Enhance /txs usability: - * Add `tx.minheight` key to filter transaction with an inclusive minimum block height - * Add `tx.maxheight` key to filter transaction with an inclusive maximum block height -* (crypto/keys) [\#5739](https://github.com/cosmos/cosmos-sdk/pull/5739) Print an error message if the password input failed. - -## [v0.38.1] - 2020-02-11 - -### Improvements - -* (modules) [\#5597](https://github.com/cosmos/cosmos-sdk/pull/5597) Add `amount` event attribute to the `complete_unbonding` -and `complete_redelegation` events that reflect the total balances of the completed unbondings and redelegations -respectively. - -### Bug Fixes - -* (types) [\#5579](https://github.com/cosmos/cosmos-sdk/pull/5579) The IAVL `Store#Commit` method has been refactored to -delete a flushed version if it is not a snapshot version. The root multi-store now keeps track of `commitInfo` instead -of `types.CommitID`. During `Commit` of the root multi-store, `lastCommitInfo` is updated from the saved state -and is only flushed to disk if it is a snapshot version. During `Query` of the root multi-store, if the request height -is the latest height, we'll use the store's `lastCommitInfo`. Otherwise, we fetch `commitInfo` from disk. -* (x/bank) [\#5531](https://github.com/cosmos/cosmos-sdk/issues/5531) Added missing amount event to MsgMultiSend, emitted for each output. -* (x/gov) [\#5622](https://github.com/cosmos/cosmos-sdk/pull/5622) Track any events emitted from a proposal's handler upon successful execution. - -## [v0.38.0] - 2020-01-23 - -### State Machine Breaking - -* (genesis) [\#5506](https://github.com/cosmos/cosmos-sdk/pull/5506) The `x/distribution` genesis state - now includes `params` instead of individual parameters. -* (genesis) [\#5017](https://github.com/cosmos/cosmos-sdk/pull/5017) The `x/genaccounts` module has been -deprecated and all components removed except the `legacy/` package. This requires changes to the -genesis state. Namely, `accounts` now exist under `app_state.auth.accounts`. The corresponding migration -logic has been implemented for v0.38 target version. Applications can migrate via: -`$ {appd} migrate v0.38 genesis.json`. -* (modules) [\#5299](https://github.com/cosmos/cosmos-sdk/pull/5299) Handling of `ABCIEvidenceTypeDuplicateVote` - during `BeginBlock` along with the corresponding parameters (`MaxEvidenceAge`) have moved from the - `x/slashing` module to the `x/evidence` module. - -### API Breaking Changes - -* (modules) [\#5506](https://github.com/cosmos/cosmos-sdk/pull/5506) Remove individual setters of `x/distribution` parameters. Instead, follow the module spec in getting parameters, setting new value(s) and finally calling `SetParams`. -* (types) [\#5495](https://github.com/cosmos/cosmos-sdk/pull/5495) Remove redundant `(Must)Bech32ify*` and `(Must)Get*KeyBech32` functions in favor of `(Must)Bech32ifyPubKey` and `(Must)GetPubKeyFromBech32` respectively, both of which take a `Bech32PubKeyType` (string). -* (types) [\#5430](https://github.com/cosmos/cosmos-sdk/pull/5430) `DecCoins#Add` parameter changed from `DecCoins` -to `...DecCoin`, `Coins#Add` parameter changed from `Coins` to `...Coin`. -* (baseapp/types) [\#5421](https://github.com/cosmos/cosmos-sdk/pull/5421) The `Error` interface (`types/errors.go`) -has been removed in favor of the concrete type defined in `types/errors/` which implements the standard `error` interface. - * As a result, the `Handler` and `Querier` implementations now return a standard `error`. - Within `BaseApp`, `runTx` now returns a `(GasInfo, *Result, error)` tuple and `runMsgs` returns a - `(*Result, error)` tuple. A reference to a `Result` is now used to indicate success whereas an error - signals an invalid message or failed message execution. As a result, the fields `Code`, `Codespace`, - `GasWanted`, and `GasUsed` have been removed the `Result` type. The latter two fields are now found - in the `GasInfo` type which is always returned regardless of execution outcome. - * Note to developers: Since all handlers and queriers must now return a standard `error`, the `types/errors/` - package contains all the relevant and pre-registered errors that you typically work with. A typical - error returned will look like `sdkerrors.Wrap(sdkerrors.ErrUnknownRequest, "...")`. You can retrieve - relevant ABCI information from the error via `ABCIInfo`. -* (client) [\#5442](https://github.com/cosmos/cosmos-sdk/pull/5442) Remove client/alias.go as it's not necessary and -components can be imported directly from the packages. -* (store) [\#4748](https://github.com/cosmos/cosmos-sdk/pull/4748) The `CommitMultiStore` interface -now requires a `SetInterBlockCache` method. Applications that do not wish to support this can simply -have this method perform a no-op. -* (modules) [\#4665](https://github.com/cosmos/cosmos-sdk/issues/4665) Refactored `x/gov` module structure and dev-UX: - * Prepare for module spec integration - * Update gov keys to use big endian encoding instead of little endian -* (modules) [\#5017](https://github.com/cosmos/cosmos-sdk/pull/5017) The `x/genaccounts` module has been deprecated and all components removed except the `legacy/` package. -* [\#4486](https://github.com/cosmos/cosmos-sdk/issues/4486) Vesting account types decoupled from the `x/auth` module and now live under `x/auth/vesting`. Applications wishing to use vesting account types must be sure to register types via `RegisterCodec` under the new vesting package. -* [\#4486](https://github.com/cosmos/cosmos-sdk/issues/4486) The `NewBaseVestingAccount` constructor returns an error -if the provided arguments are invalid. -* (x/auth) [\#5006](https://github.com/cosmos/cosmos-sdk/pull/5006) Modular `AnteHandler` via composable decorators: - * The `AnteHandler` interface now returns `(newCtx Context, err error)` instead of `(newCtx Context, result sdk.Result, abort bool)` - * The `NewAnteHandler` function returns an `AnteHandler` function that returns the new `AnteHandler` - interface and has been moved into the `auth/ante` directory. - * `ValidateSigCount`, `ValidateMemo`, `ProcessPubKey`, `EnsureSufficientMempoolFee`, and `GetSignBytes` - have all been removed as public functions. - * Invalid Signatures may return `InvalidPubKey` instead of `Unauthorized` error, since the transaction - will first hit `SetPubKeyDecorator` before the `SigVerificationDecorator` runs. - * `StdTx#GetSignatures` will return an array of just signature byte slices `[][]byte` instead of - returning an array of `StdSignature` structs. To replicate the old behavior, use the public field - `StdTx.Signatures` to get back the array of StdSignatures `[]StdSignature`. -* (modules) [\#5299](https://github.com/cosmos/cosmos-sdk/pull/5299) `HandleDoubleSign` along with params `MaxEvidenceAge` and `DoubleSignJailEndTime` have moved from the `x/slashing` module to the `x/evidence` module. -* (keys) [\#4941](https://github.com/cosmos/cosmos-sdk/issues/4941) Keybase concrete types constructors such as `NewKeyBaseFromDir` and `NewInMemory` now accept optional parameters of type `KeybaseOption`. These -optional parameters are also added on the keys sub-commands functions, which are now public, and allows -these options to be set on the commands or ignored to default to previous behavior. -* [\#5547](https://github.com/cosmos/cosmos-sdk/pull/5547) `NewKeyBaseFromHomeFlag` constructor has been removed. -* [\#5439](https://github.com/cosmos/cosmos-sdk/pull/5439) Further modularization was done to the `keybase` -package to make it more suitable for use with different key formats and algorithms: - * The `WithKeygenFunc` function added as a `KeybaseOption` which allows a custom bytes to key - implementation to be defined when keys are created. - * The `WithDeriveFunc` function added as a `KeybaseOption` allows custom logic for deriving a key - from a mnemonic, bip39 password, and HD Path. - * BIP44 is no longer build into `keybase.CreateAccount()`. It is however the default when using - the `client/keys` add command. - * `SupportedAlgos` and `SupportedAlgosLedger` functions return a slice of `SigningAlgo`s that are - supported by the keybase and the ledger integration respectively. -* (simapp) [\#5419](https://github.com/cosmos/cosmos-sdk/pull/5419) The `helpers.GenTx()` now accepts a gas argument. -* (baseapp) [\#5455](https://github.com/cosmos/cosmos-sdk/issues/5455) A `sdk.Context` is now passed into the `router.Route()` function. - -### Client Breaking Changes - -* (rest) [\#5270](https://github.com/cosmos/cosmos-sdk/issues/5270) All account types now implement custom JSON serialization. -* (rest) [\#4783](https://github.com/cosmos/cosmos-sdk/issues/4783) The balance field in the DelegationResponse type is now sdk.Coin instead of sdk.Int -* (x/auth) [\#5006](https://github.com/cosmos/cosmos-sdk/pull/5006) The gas required to pass the `AnteHandler` has -increased significantly due to modular `AnteHandler` support. Increase GasLimit accordingly. -* (rest) [\#5336](https://github.com/cosmos/cosmos-sdk/issues/5336) `MsgEditValidator` uses `description` instead of `Description` as a JSON key. -* (keys) [\#5097](https://github.com/cosmos/cosmos-sdk/pull/5097) Due to the keybase -> keyring transition, keys need to be migrated. See `keys migrate` command for more info. -* (x/auth) [\#5424](https://github.com/cosmos/cosmos-sdk/issues/5424) Drop `decode-tx` command from x/auth/client/cli, duplicate of the `decode` command. - -### Features - -* (store) [\#5435](https://github.com/cosmos/cosmos-sdk/pull/5435) New iterator for paginated requests. Iterator limits DB reads to the range of the requested page. -* (x/evidence) [\#5240](https://github.com/cosmos/cosmos-sdk/pull/5240) Initial implementation of the `x/evidence` module. -* (cli) [\#5212](https://github.com/cosmos/cosmos-sdk/issues/5212) The `q gov proposals` command now supports pagination. -* (store) [\#4724](https://github.com/cosmos/cosmos-sdk/issues/4724) Multistore supports substore migrations upon load. New `rootmulti.Store.LoadLatestVersionAndUpgrade` method in -`Baseapp` supports `StoreLoader` to enable various upgrade strategies. It no -longer panics if the store to load contains substores that we didn't explicitly mount. -* [\#4972](https://github.com/cosmos/cosmos-sdk/issues/4972) A `TxResponse` with a corresponding code -and tx hash will be returned for specific Tendermint errors: - * `CodeTxInMempoolCache` - * `CodeMempoolIsFull` - * `CodeTxTooLarge` -* [\#3872](https://github.com/cosmos/cosmos-sdk/issues/3872) Implement a RESTful endpoint and cli command to decode transactions. -* (keys) [\#4754](https://github.com/cosmos/cosmos-sdk/pull/4754) Introduce new Keybase implementation that can -leverage operating systems' built-in functionalities to securely store secrets. MacOS users may encounter -the following [issue](https://github.com/keybase/go-keychain/issues/47) with the `go-keychain` library. If -you encounter this issue, you must upgrade your xcode command line tools to version >= `10.2`. You can -upgrade via: `sudo rm -rf /Library/Developer/CommandLineTools; xcode-select --install`. Verify the -correct version via: `pkgutil --pkg-info=com.apple.pkg.CLTools_Executables`. -* [\#5355](https://github.com/cosmos/cosmos-sdk/pull/5355) Client commands accept a new `--keyring-backend` option through which users can specify which backend should be used -by the new key store: - * `os`: use OS default credentials storage (default). - * `file`: use encrypted file-based store. - * `kwallet`: use [KDE Wallet](https://utils.kde.org/projects/kwalletmanager/) service. - * `pass`: use the [pass](https://www.passwordstore.org/) command line password manager. - * `test`: use password-less key store. *For testing purposes only. Use it at your own risk.* -* (keys) [\#5097](https://github.com/cosmos/cosmos-sdk/pull/5097) New `keys migrate` command to assist users migrate their keys -to the new keyring. -* (keys) [\#5366](https://github.com/cosmos/cosmos-sdk/pull/5366) `keys list` now accepts a `--list-names` option to list key names only, whilst the `keys delete` -command can delete multiple keys by passing their names as arguments. The aforementioned commands can then be piped together, e.g. -`appcli keys list -n | xargs appcli keys delete` -* (modules) [\#4233](https://github.com/cosmos/cosmos-sdk/pull/4233) Add upgrade module that coordinates software upgrades of live chains. -* [\#4486](https://github.com/cosmos/cosmos-sdk/issues/4486) Introduce new `PeriodicVestingAccount` vesting account type -that allows for arbitrary vesting periods. -* (baseapp) [\#5196](https://github.com/cosmos/cosmos-sdk/pull/5196) Baseapp has a new `runTxModeReCheck` to allow applications to skip expensive and unnecessary re-checking of transactions. -* (types) [\#5196](https://github.com/cosmos/cosmos-sdk/pull/5196) Context has new `IsRecheckTx() bool` and `WithIsReCheckTx(bool) Context` methods to to be used in the `AnteHandler`. -* (x/auth/ante) [\#5196](https://github.com/cosmos/cosmos-sdk/pull/5196) AnteDecorators have been updated to avoid unnecessary checks when `ctx.IsReCheckTx() == true` -* (x/auth) [\#5006](https://github.com/cosmos/cosmos-sdk/pull/5006) Modular `AnteHandler` via composable decorators: - * The `AnteDecorator` interface has been introduced to allow users to implement modular `AnteHandler` - functionality that can be composed together to create a single `AnteHandler` rather than implementing - a custom `AnteHandler` completely from scratch, where each `AnteDecorator` allows for custom behavior in - tightly defined and logically isolated manner. These custom `AnteDecorator` can then be chained together - with default `AnteDecorator` or third-party `AnteDecorator` to create a modularized `AnteHandler` - which will run each `AnteDecorator` in the order specified in `ChainAnteDecorators`. For details - on the new architecture, refer to the [ADR](docs/architecture/adr-010-modular-antehandler.md). - * `ChainAnteDecorators` function has been introduced to take in a list of `AnteDecorators` and chain - them in sequence and return a single `AnteHandler`: - * `SetUpContextDecorator`: Sets `GasMeter` in context and creates defer clause to recover from any - `OutOfGas` panics in future AnteDecorators and return `OutOfGas` error to `BaseApp`. It MUST be the - first `AnteDecorator` in the chain for any application that uses gas (or another one that sets the gas meter). - * `ValidateBasicDecorator`: Calls tx.ValidateBasic and returns any non-nil error. - * `ValidateMemoDecorator`: Validates tx memo with application parameters and returns any non-nil error. - * `ConsumeGasTxSizeDecorator`: Consumes gas proportional to the tx size based on application parameters. - * `MempoolFeeDecorator`: Checks if fee is above local mempool `minFee` parameter during `CheckTx`. - * `DeductFeeDecorator`: Deducts the `FeeAmount` from first signer of the transaction. - * `SetPubKeyDecorator`: Sets pubkey of account in any account that does not already have pubkey saved in state machine. - * `SigGasConsumeDecorator`: Consume parameter-defined amount of gas for each signature. - * `SigVerificationDecorator`: Verify each signature is valid, return if there is an error. - * `ValidateSigCountDecorator`: Validate the number of signatures in tx based on app-parameters. - * `IncrementSequenceDecorator`: Increments the account sequence for each signer to prevent replay attacks. -* (cli) [\#5223](https://github.com/cosmos/cosmos-sdk/issues/5223) Cosmos Ledger App v2.0.0 is now supported. The changes are backwards compatible and App v1.5.x is still supported. -* (x/staking) [\#5380](https://github.com/cosmos/cosmos-sdk/pull/5380) Introduced ability to store historical info entries in staking keeper, allows applications to introspect specified number of past headers and validator sets - * Introduces new parameter `HistoricalEntries` which allows applications to determine how many recent historical info entries they want to persist in store. Default value is 0. - * Introduces cli commands and rest routes to query historical information at a given height -* (modules) [\#5249](https://github.com/cosmos/cosmos-sdk/pull/5249) Funds are now allowed to be directly sent to the community pool (via the distribution module account). -* (keys) [\#4941](https://github.com/cosmos/cosmos-sdk/issues/4941) Introduce keybase option to allow overriding the default private key implementation of a key generated through the `keys add` cli command. -* (keys) [\#5439](https://github.com/cosmos/cosmos-sdk/pull/5439) Flags `--algo` and `--hd-path` are added to - `keys add` command in order to make use of keybase modularized. By default, it uses (0, 0) bip44 - HD path and secp256k1 keys, so is non-breaking. -* (types) [\#5447](https://github.com/cosmos/cosmos-sdk/pull/5447) Added `ApproxRoot` function to sdk.Decimal type in order to get the nth root for a decimal number, where n is a positive integer. - * An `ApproxSqrt` function was also added for convenience around the common case of n=2. - -### Improvements - -* (iavl) [\#5538](https://github.com/cosmos/cosmos-sdk/pull/5538) Remove manual IAVL pruning in favor of IAVL's internal pruning strategy. -* (server) [\#4215](https://github.com/cosmos/cosmos-sdk/issues/4215) The `--pruning` flag -has been moved to the configuration file, to allow easier node configuration. -* (cli) [\#5116](https://github.com/cosmos/cosmos-sdk/issues/5116) The `CLIContext` now supports multiple verifiers -when connecting to multiple chains. The connecting chain's `CLIContext` will have to have the correct -chain ID and node URI or client set. To use a `CLIContext` with a verifier for another chain: - ```go - // main or parent chain (chain as if you're running without IBC) - mainCtx := context.NewCLIContext() - - // connecting IBC chain - sideCtx := context.NewCLIContext(). - WithChainID(sideChainID). - WithNodeURI(sideChainNodeURI) // or .WithClient(...) - - sideCtx = sideCtx.WithVerifier( - context.CreateVerifier(sideCtx, context.DefaultVerifierCacheSize), - ) - ``` -* (modules) [\#5017](https://github.com/cosmos/cosmos-sdk/pull/5017) The `x/auth` package now supports -generalized genesis accounts through the `GenesisAccount` interface. -* (modules) [\#4762](https://github.com/cosmos/cosmos-sdk/issues/4762) Deprecate remove and add permissions in ModuleAccount. -* (modules) [\#4760](https://github.com/cosmos/cosmos-sdk/issues/4760) update `x/auth` to match module spec. -* (modules) [\#4814](https://github.com/cosmos/cosmos-sdk/issues/4814) Add security contact to Validator description. -* (modules) [\#4875](https://github.com/cosmos/cosmos-sdk/issues/4875) refactor integration tests to use SimApp and separate test package -* (sdk) [\#4566](https://github.com/cosmos/cosmos-sdk/issues/4566) Export simulation's parameters and app state to JSON in order to reproduce bugs and invariants. -* (sdk) [\#4640](https://github.com/cosmos/cosmos-sdk/issues/4640) improve import/export simulation errors by extending `DiffKVStores` to return an array of `KVPairs` that are then compared to check for inconsistencies. -* (sdk) [\#4717](https://github.com/cosmos/cosmos-sdk/issues/4717) refactor `x/slashing` to match the new module spec -* (sdk) [\#4758](https://github.com/cosmos/cosmos-sdk/issues/4758) update `x/genaccounts` to match module spec -* (simulation) [\#4824](https://github.com/cosmos/cosmos-sdk/issues/4824) `PrintAllInvariants` flag will print all failed invariants -* (simulation) [\#4490](https://github.com/cosmos/cosmos-sdk/issues/4490) add `InitialBlockHeight` flag to resume a simulation from a given block - - * Support exporting the simulation stats to a given JSON file -* (simulation) [\#4847](https://github.com/cosmos/cosmos-sdk/issues/4847), [\#4838](https://github.com/cosmos/cosmos-sdk/pull/4838) and [\#4869](https://github.com/cosmos/cosmos-sdk/pull/4869) `SimApp` and simulation refactors: - * Implement `SimulationManager` for executing modules' simulation functionalities in a modularized way - * Add `RegisterStoreDecoders` to the `SimulationManager` for decoding each module's types - * Add `GenerateGenesisStates` to the `SimulationManager` to generate a randomized `GenState` for each module - * Add `RandomizedParams` to the `SimulationManager` that registers each modules' parameters in order to - simulate `ParamChangeProposal`s' `Content`s - * Add `WeightedOperations` to the `SimulationManager` that define simulation operations (modules' `Msg`s) with their - respective weights (i.e chance of being simulated). - * Add `ProposalContents` to the `SimulationManager` to register each module's governance proposal `Content`s. -* (simulation) [\#4893](https://github.com/cosmos/cosmos-sdk/issues/4893) Change `SimApp` keepers to be public and add getter functions for keys and codec -* (simulation) [\#4906](https://github.com/cosmos/cosmos-sdk/issues/4906) Add simulation `Config` struct that wraps simulation flags -* (simulation) [\#4935](https://github.com/cosmos/cosmos-sdk/issues/4935) Update simulation to reflect a proper `ABCI` application without bypassing `BaseApp` semantics -* (simulation) [\#5378](https://github.com/cosmos/cosmos-sdk/pull/5378) Simulation tests refactor: - * Add `App` interface for general SDK-based app's methods. - * Refactor and cleanup simulation tests into util functions to simplify their implementation for other SDK apps. -* (store) [\#4792](https://github.com/cosmos/cosmos-sdk/issues/4792) panic on non-registered store -* (types) [\#4821](https://github.com/cosmos/cosmos-sdk/issues/4821) types/errors package added with support for stacktraces. It is meant as a more feature-rich replacement for sdk.Errors in the mid-term. -* (store) [\#1947](https://github.com/cosmos/cosmos-sdk/issues/1947) Implement inter-block (persistent) -caching through `CommitKVStoreCacheManager`. Any application wishing to utilize an inter-block cache -must set it in their app via a `BaseApp` option. The `BaseApp` docs have been drastically improved -to detail this new feature and how state transitions occur. -* (docs/spec) All module specs moved into their respective module dir in x/ (i.e. docs/spec/staking -->> x/staking/spec) -* (docs/) [\#5379](https://github.com/cosmos/cosmos-sdk/pull/5379) Major documentation refactor, including: - * (docs/intro/) Add and improve introduction material for newcomers. - * (docs/basics/) Add documentation about basic concepts of the cosmos sdk such as the anatomy of an SDK application, the transaction lifecycle or accounts. - * (docs/core/) Add documentation about core conepts of the cosmos sdk such as `baseapp`, `server`, `store`s, `context` and more. - * (docs/building-modules/) Add reference documentation on concepts relevant for module developers (`keeper`, `handler`, `messages`, `queries`,...). - * (docs/interfaces/) Add documentation on building interfaces for the Cosmos SDK. - * Redesigned user interface that features new dynamically generated sidebar, build-time code embedding from GitHub, new homepage as well as many other improvements. -* (types) [\#5428](https://github.com/cosmos/cosmos-sdk/pull/5428) Add `Mod` (modulo) method and `RelativePow` (exponentation) function for `Uint`. -* (modules) [\#5506](https://github.com/cosmos/cosmos-sdk/pull/5506) Remove redundancy in `x/distribution`s use of parameters. There - now exists a single `Params` type with a getter and setter along with a getter for each individual parameter. - -### Bug Fixes - -* (client) [\#5303](https://github.com/cosmos/cosmos-sdk/issues/5303) Fix ignored error in tx generate only mode. -* (cli) [\#4763](https://github.com/cosmos/cosmos-sdk/issues/4763) Fix flag `--min-self-delegation` for staking `EditValidator` -* (keys) Fix ledger custom coin type support bug. -* (x/gov) [\#5107](https://github.com/cosmos/cosmos-sdk/pull/5107) Sum validator operator's all voting power when tally votes -* (rest) [\#5212](https://github.com/cosmos/cosmos-sdk/issues/5212) Fix pagination in the `/gov/proposals` handler. - -## [v0.37.14] - 2020-08-12 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.13](https://github.com/tendermint/tendermint/releases/tag/v0.32.13). - - -## [v0.37.13] - 2020-06-03 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.12](https://github.com/tendermint/tendermint/releases/tag/v0.32.12). -* (cosmos-ledger-go) Bump Cosmos Ledger Wallet library version to [v0.11.1](https://github.com/cosmos/ledger-cosmos-go/releases/tag/v0.11.1). - -## [v0.37.12] - 2020-05-05 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.11](https://github.com/tendermint/tendermint/releases/tag/v0.32.11). - -## [v0.37.11] - 2020-04-22 - -### Bug Fixes - -* (x/staking) [\#6021](https://github.com/cosmos/cosmos-sdk/pull/6021) --trust-node's false default value prevents creation of the genesis transaction. - -## [v0.37.10] - 2020-04-22 - -### Bug Fixes - -* (client/context) [\#5964](https://github.com/cosmos/cosmos-sdk/issues/5964) Fix incorrect instantiation of tmlite verifier when --trust-node is off. - -## [v0.37.9] - 2020-04-09 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.10](https://github.com/tendermint/tendermint/releases/tag/v0.32.10). - -## [v0.37.8] - 2020-03-11 - -### Bug Fixes - -* (rest) [\#5508](https://github.com/cosmos/cosmos-sdk/pull/5508) Fix `x/distribution` endpoints to properly return height in the response. -* (x/genutil) [\#5499](https://github.com/cosmos/cosmos-sdk/pull/) Ensure `DefaultGenesis` returns valid and non-nil default genesis state. -* (x/genutil) [\#5775](https://github.com/cosmos/cosmos-sdk/pull/5775) Fix `ExportGenesis` in `x/genutil` to export default genesis state (`[]`) instead of `null`. -* (genesis) [\#5086](https://github.com/cosmos/cosmos-sdk/issues/5086) Ensure `gentxs` are always an empty array instead of `nil`. - -### Improvements - -* (rest) [\#5648](https://github.com/cosmos/cosmos-sdk/pull/5648) Enhance /txs usability: - * Add `tx.minheight` key to filter transaction with an inclusive minimum block height - * Add `tx.maxheight` key to filter transaction with an inclusive maximum block height - -## [v0.37.7] - 2020-02-10 - -### Improvements - -* (modules) [\#5597](https://github.com/cosmos/cosmos-sdk/pull/5597) Add `amount` event attribute to the `complete_unbonding` -and `complete_redelegation` events that reflect the total balances of the completed unbondings and redelegations -respectively. - -### Bug Fixes - -* (x/gov) [\#5622](https://github.com/cosmos/cosmos-sdk/pull/5622) Track any events emitted from a proposal's handler upon successful execution. -* (x/bank) [\#5531](https://github.com/cosmos/cosmos-sdk/issues/5531) Added missing amount event to MsgMultiSend, emitted for each output. - -## [v0.37.6] - 2020-01-21 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.9](https://github.com/tendermint/tendermint/releases/tag/v0.32.9) - -## [v0.37.5] - 2020-01-07 - -### Features - -* (types) [\#5360](https://github.com/cosmos/cosmos-sdk/pull/5360) Implement `SortableDecBytes` which - allows the `Dec` type be sortable. - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.8](https://github.com/tendermint/tendermint/releases/tag/v0.32.8) -* (cli) [\#5482](https://github.com/cosmos/cosmos-sdk/pull/5482) Remove old "tags" nomenclature from the `q txs` command in - favor of the new events system. Functionality remains unchanged except that `=` is used instead of `:` to be - consistent with the API's use of event queries. - -### Bug Fixes - -* (iavl) [\#5276](https://github.com/cosmos/cosmos-sdk/issues/5276) Fix potential race condition in `iavlIterator#Close`. -* (baseapp) [\#5350](https://github.com/cosmos/cosmos-sdk/issues/5350) Allow a node to restart successfully - after a `halt-height` or `halt-time` has been triggered. -* (types) [\#5395](https://github.com/cosmos/cosmos-sdk/issues/5395) Fix `Uint#LTE`. -* (types) [\#5408](https://github.com/cosmos/cosmos-sdk/issues/5408) `NewDecCoins` constructor now sorts the coins. - -## [v0.37.4] - 2019-11-04 - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.7](https://github.com/tendermint/tendermint/releases/tag/v0.32.7) -* (ledger) [\#4716](https://github.com/cosmos/cosmos-sdk/pull/4716) Fix ledger custom coin type support bug. - -### Bug Fixes - -* (baseapp) [\#5200](https://github.com/cosmos/cosmos-sdk/issues/5200) Remove duplicate events from previous messages. - -## [v0.37.3] - 2019-10-10 - -### Bug Fixes - -* (genesis) [\#5095](https://github.com/cosmos/cosmos-sdk/issues/5095) Fix genesis file migration from v0.34 to -v0.36/v0.37 not converting validator consensus pubkey to bech32 format. - -### Improvements - -* (tendermint) Bump Tendermint version to [v0.32.6](https://github.com/tendermint/tendermint/releases/tag/v0.32.6) - -## [v0.37.1] - 2019-09-19 +## [Unreleased] ### Features - -* (cli) [\#4973](https://github.com/cosmos/cosmos-sdk/pull/4973) Enable application CPU profiling -via the `--cpu-profile` flag. -* [\#4979](https://github.com/cosmos/cosmos-sdk/issues/4979) Introduce a new `halt-time` config and -CLI option to the `start` command. When provided, an application will halt during `Commit` when the -block time is >= the `halt-time`. - -### Improvements - -* [\#4990](https://github.com/cosmos/cosmos-sdk/issues/4990) Add `Events` to the `ABCIMessageLog` to -provide context and grouping of events based on the messages they correspond to. The `Events` field -in `TxResponse` is deprecated and will be removed in the next major release. - -### Bug Fixes - -* [\#4979](https://github.com/cosmos/cosmos-sdk/issues/4979) Use `Signal(os.Interrupt)` over -`os.Exit(0)` during configured halting to allow any `defer` calls to be executed. -* [\#5034](https://github.com/cosmos/cosmos-sdk/issues/5034) Binary search in NFT Module wasn't working on larger sets. - -## [v0.37.0] - 2019-08-21 - -### Bug Fixes - -* (baseapp) [\#4903](https://github.com/cosmos/cosmos-sdk/issues/4903) Various height query fixes: - * Move height with proof check from `CLIContext` to `BaseApp` as the height - can automatically be injected there. - * Update `handleQueryStore` to resemble `handleQueryCustom` -* (simulation) [\#4912](https://github.com/cosmos/cosmos-sdk/issues/4912) Fix SimApp ModuleAccountAddrs -to properly return black listed addresses for bank keeper initialization. -* (cli) [\#4919](https://github.com/cosmos/cosmos-sdk/pull/4919) Don't crash CLI -if user doesn't answer y/n confirmation request. -* (cli) [\#4927](https://github.com/cosmos/cosmos-sdk/issues/4927) Fix the `q gov vote` -command to handle empty (pruned) votes correctly. - -### Improvements - -* (rest) [\#4924](https://github.com/cosmos/cosmos-sdk/pull/4924) Return response -height even upon error as it may be useful for the downstream caller and have -`/auth/accounts/{address}` return a 200 with an empty account upon error when -that error is that the account doesn't exist. - -## [v0.36.0] - 2019-08-13 +* (global) [\#97](https://github.com/line/lbm-sdk/pull/97) Add codespace to query error +* (config) [\#114](https://github.com/line/lbm-sdk/pull/114) Add idle-timeout to rest server and rpc server config +* (x/wasm) [\#127](https://github.com/line/lbm-sdk/pull/127) Add wasm with Staragate migration completed. +* (x/wasm) [\#151](https://github.com/line/lbm-sdk/pull/151) Add contract access control. +* (x/wasm) [\#194](https://github.com/line/lbm-sdk/pull/194) Replace importing CosmWasm/wasmvm with line/wasmvm. +* (x/auth) [\#176](https://github.com/line/lbm-sdk/pull/176) Add MsgEmpty to auth module +* (metric) [\#184](https://github.com/line/lbm-sdk/pull/184) Add prometheus metrics for caches reverting telemetry metrics + +### Improvements +* (bump-up) [\#93](https://github.com/line/lbm-sdk/pull/93) Adopt ostracon, line/tm-db and line/iavl +* (bump-up) [\#107](https://github.com/line/lbm-sdk/pull/107) Bump up tm-db, iavl and ostracon +* (script) [\#110](https://github.com/line/lbm-sdk/pull/110) Add script initializing simd +* (bump-up) [\#118](https://github.com/line/lbm-sdk/pull/118) Bump up tm-db and remove Domain() call +* (test) [\#128](https://github.com/line/lbm-sdk/pull/128) Allow creating new test network without init +* (db) [\#136](https://github.com/line/lbm-sdk/pull/136) Fix DB_BACKEND configuration +* (global) [\#140](https://github.com/line/lbm-sdk/pull/140) Modify default coin type, default address prefix +* (perf) [\#141](https://github.com/line/lbm-sdk/pull/141) Concurrent `checkTx` +* (perf) [\#142](https://github.com/line/lbm-sdk/pull/142) Implement `validateGasWanted()` +* (perf) [\#143](https://github.com/line/lbm-sdk/pull/143) Signature verification cache +* (global) [\#145](https://github.com/line/lbm-sdk/pull/145) Modify key type name +* (perf) [\#155](https://github.com/line/lbm-sdk/pull/155) Concurrent recheckTx +* (global) [\#158](https://github.com/line/lbm-sdk/pull/158) Remove tm-db dependency +* (x/wasm) [\#162](https://github.com/line/lbm-sdk/pull/162) Add missed UpdateContractStatusProposal types +* (perf) [\#164](https://github.com/line/lbm-sdk/pull/164) Sse fastcache +* (build) [\#181](https://github.com/line/lbm-sdk/pull/181) Raise codecov-action version to 1.5.0 +* (build) [\#195](https://github.com/line/lbm-sdk/pull/195) Build properly when using libsecp256k1 +* (perf) [\#198](https://github.com/line/lbm-sdk/pull/198) Caching paramset +* (global) [\#200](https://github.com/line/lbm-sdk/pull/200) Add a env prefix +* (store) [\#202](https://github.com/line/lbm-sdk/pull/202) param store doesn't use gas kv + +### Bug Fixes +* (test) [\#92](https://github.com/line/lbm-sdk/pull/92) Fix SendToModuleAccountTest +* (store) [\#105](https://github.com/line/lbm-sdk/pull/105) Check `store == nil` +* (test) [\#133](https://github.com/line/lbm-sdk/pull/133) Fix `Test_runImportCmd()` +* (config) [\#138](https://github.com/line/lbm-sdk/pull/138) Fix getting coin type at running cmd +* (race) [\#159](https://github.com/line/lbm-sdk/pull/159) Fix test-race failure +* (test) [\#193](https://github.com/line/lbm-sdk/pull/193) Allow to add new validator in test network ### Breaking Changes +* (global) [\#90](https://github.com/line/lbm-sdk/pull/90) Revise module path to `github.com/line/lbm-sdk/v2` +* (rpc) [\#97](https://github.com/line/lbm-sdk/pull/97) Send response with 404 status when quering non-exist account +* (proto) [\#106](https://github.com/line/lbm-sdk/pull/106) Rename package of proto files +* (api) [\#130](https://github.com/line/lbm-sdk/pull/130) Rename rest apis -* (rest) [\#4837](https://github.com/cosmos/cosmos-sdk/pull/4837) Remove /version and /node_version - endpoints in favor of refactoring /node_info to also include application version info. -* All REST responses now wrap the original resource/result. The response - will contain two fields: height and result. -* [\#3565](https://github.com/cosmos/cosmos-sdk/issues/3565) Updates to the governance module: - * Rename JSON field from `proposal_content` to `content` - * Rename JSON field from `proposal_id` to `id` - * Disable `ProposalTypeSoftwareUpgrade` temporarily -* [\#3775](https://github.com/cosmos/cosmos-sdk/issues/3775) unify sender transaction tag for ease of querying -* [\#4255](https://github.com/cosmos/cosmos-sdk/issues/4255) Add supply module that passively tracks the supplies of a chain - - Renamed `x/distribution` `ModuleName` - - Genesis JSON and CLI now use `distribution` instead of `distr` - - Introduce `ModuleAccount` type, which tracks the flow of coins held within a module - - Replaced `FeeCollectorKeeper` for a `ModuleAccount` - - Replaced the staking `Pool`, which coins are now held by the `BondedPool` and `NotBonded` module accounts - - The `NotBonded` module account now only keeps track of the not bonded tokens within staking, instead of the whole chain - - [\#3628](https://github.com/cosmos/cosmos-sdk/issues/3628) Replaced governance's burn and deposit accounts for a `ModuleAccount` - - Added a `ModuleAccount` for the distribution module - - Added a `ModuleAccount` for the mint module - [\#4472](https://github.com/cosmos/cosmos-sdk/issues/4472) validation for crisis genesis -* [\#3985](https://github.com/cosmos/cosmos-sdk/issues/3985) `ValidatorPowerRank` uses potential consensus power instead of tendermint power -* [\#4104](https://github.com/cosmos/cosmos-sdk/issues/4104) Gaia has been moved to its own repository: https://github.com/cosmos/gaia -* [\#4104](https://github.com/cosmos/cosmos-sdk/issues/4104) Rename gaiad.toml to app.toml. The internal contents of the application - config remain unchanged. -* [\#4159](https://github.com/cosmos/cosmos-sdk/issues/4159) create the default module patterns and module manager -* [\#4230](https://github.com/cosmos/cosmos-sdk/issues/4230) Change the type of ABCIMessageLog#MsgIndex to uint16 for proper serialization. -* [\#4250](https://github.com/cosmos/cosmos-sdk/issues/4250) BaseApp.Query() returns app's version string set via BaseApp.SetAppVersion() - when handling /app/version queries instead of the version string passed as build - flag at compile time. -* [\#4262](https://github.com/cosmos/cosmos-sdk/issues/4262) GoSumHash is no longer returned by the version command. -* [\#4263](https://github.com/cosmos/cosmos-sdk/issues/4263) RestServer#Start now takes read and write timeout arguments. -* [\#4305](https://github.com/cosmos/cosmos-sdk/issues/4305) `GenerateOrBroadcastMsgs` no longer takes an `offline` parameter. -* [\#4342](https://github.com/cosmos/cosmos-sdk/pull/4342) Upgrade go-amino to v0.15.0 -* [\#4351](https://github.com/cosmos/cosmos-sdk/issues/4351) InitCmd, AddGenesisAccountCmd, and CollectGenTxsCmd take node's and client's default home directories as arguments. -* [\#4387](https://github.com/cosmos/cosmos-sdk/issues/4387) Refactor the usage of tags (now called events) to reflect the - new ABCI events semantics: - - Move `x/{module}/tags/tags.go` => `x/{module}/types/events.go` - - Update `docs/specs` - - Refactor tags in favor of new `Event(s)` type(s) - - Update `Context` to use new `EventManager` - - (Begin|End)Blocker no longer return tags, but rather uses new `EventManager` - - Message handlers no longer return tags, but rather uses new `EventManager` - Any component (e.g. BeginBlocker, message handler, etc...) wishing to emit an event must do so - through `ctx.EventManger().EmitEvent(s)`. - To reset or wipe emitted events: `ctx = ctx.WithEventManager(sdk.NewEventManager())` - To get all emitted events: `events := ctx.EventManager().Events()` -* [\#4437](https://github.com/cosmos/cosmos-sdk/issues/4437) Replace governance module store keys to use `[]byte` instead of `string`. -* [\#4451](https://github.com/cosmos/cosmos-sdk/issues/4451) Improve modularization of clients and modules: - * Module directory structure improved and standardized - * Aliases autogenerated - * Auth and bank related commands are now mounted under the respective moduels - * Client initialization and mounting standardized -* [\#4479](https://github.com/cosmos/cosmos-sdk/issues/4479) Remove codec argument redundency in client usage where - the CLIContext's codec should be used instead. -* [\#4488](https://github.com/cosmos/cosmos-sdk/issues/4488) Decouple client tx, REST, and ultil packages from auth. These packages have - been restructured and retrofitted into the `x/auth` module. -* [\#4521](https://github.com/cosmos/cosmos-sdk/issues/4521) Flatten x/bank structure by hiding module internals. -* [\#4525](https://github.com/cosmos/cosmos-sdk/issues/4525) Remove --cors flag, the feature is long gone. -* [\#4536](https://github.com/cosmos/cosmos-sdk/issues/4536) The `/auth/accounts/{address}` now returns a `height` in the response. - The account is now nested under `account`. -* [\#4543](https://github.com/cosmos/cosmos-sdk/issues/4543) Account getters are no longer part of client.CLIContext() and have now moved - to reside in the auth-specific AccountRetriever. -* [\#4588](https://github.com/cosmos/cosmos-sdk/issues/4588) Context does not depend on x/auth anymore. client/context is stripped out of the following features: - - GetAccountDecoder() - - CLIContext.WithAccountDecoder() - - CLIContext.WithAccountStore() - x/auth.AccountDecoder is unnecessary and consequently removed. -* [\#4602](https://github.com/cosmos/cosmos-sdk/issues/4602) client/input.{Buffer,Override}Stdin() functions are removed. Thanks to cobra's new release they are now redundant. -* [\#4633](https://github.com/cosmos/cosmos-sdk/issues/4633) Update old Tx search by tags APIs to use new Events - nomenclature. -* [\#4649](https://github.com/cosmos/cosmos-sdk/issues/4649) Refactor x/crisis as per modules new specs. -* [\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685) The default signature verification gas logic (`DefaultSigVerificationGasConsumer`) now specifies explicit key types rather than string pattern matching. This means that zones that depended on string matching to allow other keys will need to write a custom `SignatureVerificationGasConsumer` function. -* [\#4663](https://github.com/cosmos/cosmos-sdk/issues/4663) Refactor bank keeper by removing private functions - - `InputOutputCoins`, `SetCoins`, `SubtractCoins` and `AddCoins` are now part of the `SendKeeper` instead of the `Keeper` interface -* (tendermint) [\#4721](https://github.com/cosmos/cosmos-sdk/pull/4721) Upgrade Tendermint to v0.32.1 - -### Features - -* [\#4843](https://github.com/cosmos/cosmos-sdk/issues/4843) Add RegisterEvidences function in the codec package to register - Tendermint evidence types with a given codec. -* (rest) [\#3867](https://github.com/cosmos/cosmos-sdk/issues/3867) Allow querying for genesis transaction when height query param is set to zero. -* [\#2020](https://github.com/cosmos/cosmos-sdk/issues/2020) New keys export/import command line utilities to export/import private keys in ASCII format - that rely on Keybase's new underlying ExportPrivKey()/ImportPrivKey() API calls. -* [\#3565](https://github.com/cosmos/cosmos-sdk/issues/3565) Implement parameter change proposal support. - Parameter change proposals can be submitted through the CLI - or a REST endpoint. See docs for further usage. -* [\#3850](https://github.com/cosmos/cosmos-sdk/issues/3850) Add `rewards` and `commission` to distribution tx tags. -* [\#3981](https://github.com/cosmos/cosmos-sdk/issues/3981) Add support to gracefully halt a node at a given height - via the node's `halt-height` config or CLI value. -* [\#4144](https://github.com/cosmos/cosmos-sdk/issues/4144) Allow for configurable BIP44 HD path and coin type. -* [\#4250](https://github.com/cosmos/cosmos-sdk/issues/4250) New BaseApp.{,Set}AppVersion() methods to get/set app's version string. -* [\#4263](https://github.com/cosmos/cosmos-sdk/issues/4263) Add `--read-timeout` and `--write-timeout` args to the `rest-server` command - to support custom RPC R/W timeouts. -* [\#4271](https://github.com/cosmos/cosmos-sdk/issues/4271) Implement Coins#IsAnyGT -* [\#4318](https://github.com/cosmos/cosmos-sdk/issues/4318) Support height queries. Queries against nodes that have the queried - height pruned will return an error. -* [\#4409](https://github.com/cosmos/cosmos-sdk/issues/4409) Implement a command that migrates exported state from one version to the next. - The `migrate` command currently supports migrating from v0.34 to v0.36 by implementing - necessary types for both versions. -* [\#4570](https://github.com/cosmos/cosmos-sdk/issues/4570) Move /bank/balances/{address} REST handler to x/bank/client/rest. The exposed interface is unchanged. -* Community pool spend proposal per Cosmos Hub governance proposal [\#7](https://github.com/cosmos/cosmos-sdk/issues/7) "Activate the Community Pool" - -### Improvements - -* (simulation) PrintAllInvariants flag will print all failed invariants -* (simulation) Add `InitialBlockHeight` flag to resume a simulation from a given block -* (simulation) [\#4670](https://github.com/cosmos/cosmos-sdk/issues/4670) Update simulation statistics to JSON format - - - Support exporting the simulation stats to a given JSON file -* [\#4775](https://github.com/cosmos/cosmos-sdk/issues/4775) Refactor CI config -* Upgrade IAVL to v0.12.4 -* (tendermint) Upgrade Tendermint to v0.32.2 -* (modules) [\#4751](https://github.com/cosmos/cosmos-sdk/issues/4751) update `x/genutils` to match module spec -* (keys) [\#4611](https://github.com/cosmos/cosmos-sdk/issues/4611) store keys in simapp now use a map instead of using individual literal keys -* [\#2286](https://github.com/cosmos/cosmos-sdk/issues/2286) Improve performance of CacheKVStore iterator. -* [\#3512](https://github.com/cosmos/cosmos-sdk/issues/3512) Implement Logger method on each module's keeper. -* [\#3655](https://github.com/cosmos/cosmos-sdk/issues/3655) Improve signature verification failure error message. -* [\#3774](https://github.com/cosmos/cosmos-sdk/issues/3774) add category tag to transactions for ease of filtering -* [\#3914](https://github.com/cosmos/cosmos-sdk/issues/3914) Implement invariant benchmarks and add target to makefile. -* [\#3928](https://github.com/cosmos/cosmos-sdk/issues/3928) remove staking references from types package -* [\#3978](https://github.com/cosmos/cosmos-sdk/issues/3978) Return ErrUnknownRequest in message handlers for unknown - or invalid routed messages. -* [\#4190](https://github.com/cosmos/cosmos-sdk/issues/4190) Client responses that return (re)delegation(s) now return balances - instead of shares. -* [\#4194](https://github.com/cosmos/cosmos-sdk/issues/4194) ValidatorSigningInfo now includes the validator's consensus address. -* [\#4235](https://github.com/cosmos/cosmos-sdk/issues/4235) Add parameter change proposal messages to simulation. -* [\#4235](https://github.com/cosmos/cosmos-sdk/issues/4235) Update the minting module params to implement params.ParamSet so - individual keys can be set via proposals instead of passing a struct. -* [\#4259](https://github.com/cosmos/cosmos-sdk/issues/4259) `Coins` that are `nil` are now JSON encoded as an empty array `[]`. - Decoding remains unchanged and behavior is left intact. -* [\#4305](https://github.com/cosmos/cosmos-sdk/issues/4305) The `--generate-only` CLI flag fully respects offline tx processing. -* [\#4379](https://github.com/cosmos/cosmos-sdk/issues/4379) close db write batch. -* [\#4384](https://github.com/cosmos/cosmos-sdk/issues/4384)- Allow splitting withdrawal transaction in several chunks -* [\#4403](https://github.com/cosmos/cosmos-sdk/issues/4403) Allow for parameter change proposals to supply only desired fields to be updated - in objects instead of the entire object (only applies to values that are objects). -* [\#4415](https://github.com/cosmos/cosmos-sdk/issues/4415) /client refactor, reduce genutil dependancy on staking -* [\#4439](https://github.com/cosmos/cosmos-sdk/issues/4439) Implement governance module iterators. -* [\#4465](https://github.com/cosmos/cosmos-sdk/issues/4465) Unknown subcommands print relevant error message -* [\#4466](https://github.com/cosmos/cosmos-sdk/issues/4466) Commission validation added to validate basic of MsgCreateValidator by changing CommissionMsg to CommissionRates -* [\#4501](https://github.com/cosmos/cosmos-sdk/issues/4501) Support height queriers in rest client -* [\#4535](https://github.com/cosmos/cosmos-sdk/issues/4535) Improve import-export simulation errors by decoding the `KVPair.Value` into its - respective type -* [\#4536](https://github.com/cosmos/cosmos-sdk/issues/4536) cli context queries return query height and accounts are returned with query height -* [\#4553](https://github.com/cosmos/cosmos-sdk/issues/4553) undelegate max entries check first -* [\#4556](https://github.com/cosmos/cosmos-sdk/issues/4556) Added IsValid function to Coin -* [\#4564](https://github.com/cosmos/cosmos-sdk/issues/4564) client/input.GetConfirmation()'s default is changed to No. -* [\#4573](https://github.com/cosmos/cosmos-sdk/issues/4573) Returns height in response for query endpoints. -* [\#4580](https://github.com/cosmos/cosmos-sdk/issues/4580) Update `Context#BlockHeight` to properly set the block height via `WithBlockHeader`. -* [\#4584](https://github.com/cosmos/cosmos-sdk/issues/4584) Update bank Keeper to use expected keeper interface of the AccountKeeper. -* [\#4584](https://github.com/cosmos/cosmos-sdk/issues/4584) Move `Account` and `VestingAccount` interface types to `x/auth/exported`. -* [\#4082](https://github.com/cosmos/cosmos-sdk/issues/4082) supply module queriers for CLI and REST endpoints -* [\#4601](https://github.com/cosmos/cosmos-sdk/issues/4601) Implement generic pangination helper function to be used in - REST handlers and queriers. -* [\#4629](https://github.com/cosmos/cosmos-sdk/issues/4629) Added warning event that gets emitted if validator misses a block. -* [\#4674](https://github.com/cosmos/cosmos-sdk/issues/4674) Export `Simapp` genState generators and util functions by making them public -* [\#4706](https://github.com/cosmos/cosmos-sdk/issues/4706) Simplify context - Replace complex Context construct with a simpler immutible struct. - Only breaking change is not to support `Value` and `GetValue` as first class calls. - We do embed ctx.Context() as a raw context.Context instead to be used as you see fit. - - Migration guide: - - ```go - ctx = ctx.WithValue(contextKeyBadProposal, false) - ``` - - Now becomes: - - ```go - ctx = ctx.WithContext(context.WithValue(ctx.Context(), contextKeyBadProposal, false)) - ``` - - A bit more verbose, but also allows `context.WithTimeout()`, etc and only used - in one function in this repo, in test code. -* [\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685) Add `SetAddressVerifier` and `GetAddressVerifier` to `sdk.Config` to allow SDK users to configure custom address format verification logic (to override the default limitation of 20-byte addresses). -* [\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685) Add an additional parameter to NewAnteHandler for a custom `SignatureVerificationGasConsumer` (the default logic is now in `DefaultSigVerificationGasConsumer). This allows SDK users to configure their own logic for which key types are accepted and how those key types consume gas. -* Remove `--print-response` flag as it is no longer used. -* Revert [\#2284](https://github.com/cosmos/cosmos-sdk/pull/2284) to allow create_empty_blocks in the config -* (tendermint) [\#4718](https://github.com/cosmos/cosmos-sdk/issues/4718) Upgrade tendermint/iavl to v0.12.3 - -### Bug Fixes - -* [\#4891](https://github.com/cosmos/cosmos-sdk/issues/4891) Disable querying with proofs enabled when the query height <= 1. -* (rest) [\#4858](https://github.com/cosmos/cosmos-sdk/issues/4858) Do not return an error in BroadcastTxCommit when the tx broadcasting - was successful. This allows the proper REST response to be returned for a - failed tx during `block` broadcasting mode. -* (store) [\#4880](https://github.com/cosmos/cosmos-sdk/pull/4880) Fix error check in - IAVL `Store#DeleteVersion`. -* (tendermint) [\#4879](https://github.com/cosmos/cosmos-sdk/issues/4879) Don't terminate the process immediately after startup when run in standalone mode. -* (simulation) [\#4861](https://github.com/cosmos/cosmos-sdk/pull/4861) Fix non-determinism simulation - by using CLI flags as input and updating Makefile target. -* [\#4868](https://github.com/cosmos/cosmos-sdk/issues/4868) Context#CacheContext now sets a new EventManager. This prevents unwanted events - from being emitted. -* (cli) [\#4870](https://github.com/cosmos/cosmos-sdk/issues/4870) Disable the `withdraw-all-rewards` command when `--generate-only` is supplied -* (modules) [\#4831](https://github.com/cosmos/cosmos-sdk/issues/4831) Prevent community spend proposal from transferring funds to a module account -* (keys) [\#4338](https://github.com/cosmos/cosmos-sdk/issues/4338) fix multisig key output for CLI -* (modules) [\#4795](https://github.com/cosmos/cosmos-sdk/issues/4795) restrict module accounts from receiving transactions. - Allowing this would cause an invariant on the module account coins. -* (modules) [\#4823](https://github.com/cosmos/cosmos-sdk/issues/4823) Update the `DefaultUnbondingTime` from 3 days to 3 weeks to be inline with documentation. -* (abci) [\#4639](https://github.com/cosmos/cosmos-sdk/issues/4639) Fix `CheckTx` by verifying the message route -* Return height in responses when querying against BaseApp -* [\#1351](https://github.com/cosmos/cosmos-sdk/issues/1351) Stable AppHash allows no_empty_blocks -* [\#3705](https://github.com/cosmos/cosmos-sdk/issues/3705) Return `[]` instead of `null` when querying delegator rewards. -* [\#3966](https://github.com/cosmos/cosmos-sdk/issues/3966) fixed multiple assigns to action tags - [\#3793](https://github.com/cosmos/cosmos-sdk/issues/3793) add delegator tag for MsgCreateValidator and deleted unused moniker and identity tags -* [\#4194](https://github.com/cosmos/cosmos-sdk/issues/4194) Fix pagination and results returned from /slashing/signing_infos -* [\#4230](https://github.com/cosmos/cosmos-sdk/issues/4230) Properly set and display the message index through the TxResponse. -* [\#4234](https://github.com/cosmos/cosmos-sdk/pull/4234) Allow `tx send --generate-only` to - actually work offline. -* [\#4271](https://github.com/cosmos/cosmos-sdk/issues/4271) Fix addGenesisAccount by using Coins#IsAnyGT for vesting amount validation. -* [\#4273](https://github.com/cosmos/cosmos-sdk/issues/4273) Fix usage of AppendTags in x/staking/handler.go -* [\#4303](https://github.com/cosmos/cosmos-sdk/issues/4303) Fix NewCoins() underlying function for duplicate coins detection. -* [\#4307](https://github.com/cosmos/cosmos-sdk/pull/4307) Don't pass height to RPC calls as - Tendermint will automatically use the latest height. -* [\#4362](https://github.com/cosmos/cosmos-sdk/issues/4362) simulation setup bugfix for multisim 7601778 -* [\#4383](https://github.com/cosmos/cosmos-sdk/issues/4383) - currentStakeRoundUp is now always atleast currentStake + smallest-decimal-precision -* [\#4394](https://github.com/cosmos/cosmos-sdk/issues/4394) Fix signature count check to use the TxSigLimit param instead of - a default. -* [\#4455](https://github.com/cosmos/cosmos-sdk/issues/4455) Use `QueryWithData()` to query unbonding delegations. -* [\#4493](https://github.com/cosmos/cosmos-sdk/issues/4493) Fix validator-outstanding-rewards command. It now takes as an argument - a validator address. -* [\#4598](https://github.com/cosmos/cosmos-sdk/issues/4598) Fix redelegation and undelegation txs that were not checking for the correct bond denomination. -* [\#4619](https://github.com/cosmos/cosmos-sdk/issues/4619) Close iterators in `GetAllMatureValidatorQueue` and `UnbondAllMatureValidatorQueue` - methods. -* [\#4654](https://github.com/cosmos/cosmos-sdk/issues/4654) validator slash event stored by period and height -* [\#4681](https://github.com/cosmos/cosmos-sdk/issues/4681) panic on invalid amount on `MintCoins` and `BurnCoins` - * skip minting if inflation is set to zero -* Sort state JSON during export and initialization - -## 0.35.0 - -### Bug Fixes - -* Fix gas consumption bug in `Undelegate` preventing the ability to sync from -genesis. - -## 0.34.10 - -### Bug Fixes - -* Bump Tendermint version to [v0.31.11](https://github.com/tendermint/tendermint/releases/tag/v0.31.11) to address the vulnerability found in the `consensus` package. - -## 0.34.9 - -### Bug Fixes - -* Bump Tendermint version to [v0.31.10](https://github.com/tendermint/tendermint/releases/tag/v0.31.10) to address p2p panic errors. - -## 0.34.8 - -### Bug Fixes - -* Bump Tendermint version to v0.31.9 to fix the p2p panic error. -* Update gaiareplay's use of an internal Tendermint API - -## 0.34.7 - -### Bug Fixes - -#### SDK - -* Fix gas consumption bug in `Undelegate` preventing the ability to sync from -genesis. +## [cosmos-sdk v0.42.1] - 2021-03-15 +Initial lbm-sdk is based on the cosmos-sdk v0.42.1 -## 0.34.6 - -### Bug Fixes - -#### SDK - -* Unbonding from a validator is now only considered "complete" after the full -unbonding period has elapsed regardless of the validator's status. - -## 0.34.5 - -### Bug Fixes - -#### SDK - -* [\#4273](https://github.com/cosmos/cosmos-sdk/issues/4273) Fix usage of `AppendTags` in x/staking/handler.go - -### Improvements - -### SDK - -* [\#2286](https://github.com/cosmos/cosmos-sdk/issues/2286) Improve performance of `CacheKVStore` iterator. -* [\#3655](https://github.com/cosmos/cosmos-sdk/issues/3655) Improve signature verification failure error message. -* [\#4384](https://github.com/cosmos/cosmos-sdk/issues/4384) Allow splitting withdrawal transaction in several chunks. - -#### Gaia CLI - -* [\#4227](https://github.com/cosmos/cosmos-sdk/issues/4227) Support for Ledger App v1.5. -* [#4345](https://github.com/cosmos/cosmos-sdk/pull/4345) Update `ledger-cosmos-go` -to v0.10.3. - -## 0.34.4 - -### Bug Fixes - -#### SDK - -* [#4234](https://github.com/cosmos/cosmos-sdk/pull/4234) Allow `tx send --generate-only` to -actually work offline. - -#### Gaia - -* [\#4219](https://github.com/cosmos/cosmos-sdk/issues/4219) Return an error when an empty mnemonic is provided during key recovery. - -### Improvements - -#### Gaia - -* [\#2007](https://github.com/cosmos/cosmos-sdk/issues/2007) Return 200 status code on empty results - -### New features - -#### SDK - -* [\#3850](https://github.com/cosmos/cosmos-sdk/issues/3850) Add `rewards` and `commission` to distribution tx tags. - -## 0.34.3 - -### Bug Fixes - -#### Gaia - -* [\#4196](https://github.com/cosmos/cosmos-sdk/pull/4196) Set default invariant -check period to zero. - -## 0.34.2 - -### Improvements - -#### SDK - -* [\#4135](https://github.com/cosmos/cosmos-sdk/pull/4135) Add further clarification -to generate only usage. - -### Bug Fixes - -#### SDK - -* [\#4135](https://github.com/cosmos/cosmos-sdk/pull/4135) Fix `NewResponseFormatBroadcastTxCommit` -* [\#4053](https://github.com/cosmos/cosmos-sdk/issues/4053) Add `--inv-check-period` -flag to gaiad to set period at which invariants checks will run. -* [\#4099](https://github.com/cosmos/cosmos-sdk/issues/4099) Update the /staking/validators endpoint to support -status and pagination query flags. - -## 0.34.1 - -### Bug Fixes - -#### Gaia - -* [#4163](https://github.com/cosmos/cosmos-sdk/pull/4163) Fix v0.33.x export script to port gov data correctly. - -## 0.34.0 - -### Breaking Changes - -#### Gaia - -* [\#3463](https://github.com/cosmos/cosmos-sdk/issues/3463) Revert bank module handler fork (re-enables transfers) -* [\#3875](https://github.com/cosmos/cosmos-sdk/issues/3875) Replace `async` flag with `--broadcast-mode` flag where the default - value is `sync`. The `block` mode should not be used. The REST client now - uses `mode` parameter instead of the `return` parameter. - -#### Gaia CLI - -* [\#3938](https://github.com/cosmos/cosmos-sdk/issues/3938) Remove REST server's SSL support altogether. - -#### SDK - -* [\#3245](https://github.com/cosmos/cosmos-sdk/issues/3245) Rename validator.GetJailed() to validator.IsJailed() -* [\#3516](https://github.com/cosmos/cosmos-sdk/issues/3516) Remove concept of shares from staking unbonding and redelegation UX; - replaced by direct coin amount. - -#### Tendermint - -* [\#4029](https://github.com/cosmos/cosmos-sdk/issues/4029) Upgrade Tendermint to v0.31.3 - -### New features - -#### SDK - -* [\#2935](https://github.com/cosmos/cosmos-sdk/issues/2935) New module Crisis which can test broken invariant with messages -* [\#3813](https://github.com/cosmos/cosmos-sdk/issues/3813) New sdk.NewCoins safe constructor to replace bare sdk.Coins{} declarations. -* [\#3858](https://github.com/cosmos/cosmos-sdk/issues/3858) add website, details and identity to gentx cli command -* Implement coin conversion and denomination registration utilities - -#### Gaia - -* [\#2935](https://github.com/cosmos/cosmos-sdk/issues/2935) Optionally assert invariants on a blockly basis using `gaiad --assert-invariants-blockly` -* [\#3886](https://github.com/cosmos/cosmos-sdk/issues/3886) Implement minting module querier and CLI/REST clients. - -#### Gaia CLI - -* [\#3937](https://github.com/cosmos/cosmos-sdk/issues/3937) Add command to query community-pool - -#### Gaia REST API - -* [\#3937](https://github.com/cosmos/cosmos-sdk/issues/3937) Add route to fetch community-pool -* [\#3949](https://github.com/cosmos/cosmos-sdk/issues/3949) added /slashing/signing_infos to get signing_info for all validators - -### Improvements - -#### Gaia - -* [\#3808](https://github.com/cosmos/cosmos-sdk/issues/3808) `gaiad` and `gaiacli` integration tests use ./build/ binaries. -* \[\#3819](https://github.com/cosmos/cosmos-sdk/issues/3819) Simulation refactor, log output now stored in ~/.gaiad/simulation/ - * Simulation moved to its own module (not a part of mock) - * Logger type instead of passing function variables everywhere - * Logger json output (for reloadable simulation running) - * Cleanup bank simulation messages / remove dup code in bank simulation - * Simulations saved in `~/.gaiad/simulations/` - * "Lean" simulation output option to exclude No-ops and !ok functions (`--SimulationLean` flag) -* [\#3893](https://github.com/cosmos/cosmos-sdk/issues/3893) Improve `gaiacli tx sign` command - * Add shorthand flags -a and -s for the account and sequence numbers respectively - * Mark the account and sequence numbers required during "offline" mode - * Always do an RPC query for account and sequence number during "online" mode -* [\#4018](https://github.com/cosmos/cosmos-sdk/issues/4018) create genesis port script for release v.0.34.0 - -#### Gaia CLI - -* [\#3833](https://github.com/cosmos/cosmos-sdk/issues/3833) Modify stake to atom in gaia's doc. -* [\#3841](https://github.com/cosmos/cosmos-sdk/issues/3841) Add indent to JSON of `gaiacli keys [add|show|list]` -* [\#3859](https://github.com/cosmos/cosmos-sdk/issues/3859) Add newline to echo of `gaiacli keys ...` -* [\#3959](https://github.com/cosmos/cosmos-sdk/issues/3959) Improving error messages when signing with ledger devices fails - -#### SDK - -* [\#3238](https://github.com/cosmos/cosmos-sdk/issues/3238) Add block time to tx responses when querying for - txs by tags or hash. -* \[\#3752](https://github.com/cosmos/cosmos-sdk/issues/3752) Explanatory docs for minting mechanism (`docs/spec/mint/01_concepts.md`) -* [\#3801](https://github.com/cosmos/cosmos-sdk/issues/3801) `baseapp` safety improvements -* [\#3820](https://github.com/cosmos/cosmos-sdk/issues/3820) Make Coins.IsAllGT() more robust and consistent. -* [\#3828](https://github.com/cosmos/cosmos-sdk/issues/3828) New sdkch tool to maintain changelogs -* [\#3864](https://github.com/cosmos/cosmos-sdk/issues/3864) Make Coins.IsAllGTE() more consistent. -* [\#3907](https://github.com/cosmos/cosmos-sdk/issues/3907): dep -> go mod migration - * Drop dep in favor of go modules. - * Upgrade to Go 1.12.1. -* [\#3917](https://github.com/cosmos/cosmos-sdk/issues/3917) Allow arbitrary decreases to validator commission rates. -* [\#3937](https://github.com/cosmos/cosmos-sdk/issues/3937) Implement community pool querier. -* [\#3940](https://github.com/cosmos/cosmos-sdk/issues/3940) Codespace should be lowercase. -* [\#3986](https://github.com/cosmos/cosmos-sdk/issues/3986) Update the Stringer implementation of the Proposal type. -* [\#926](https://github.com/cosmos/cosmos-sdk/issues/926) circuit breaker high level explanation -* [\#3896](https://github.com/cosmos/cosmos-sdk/issues/3896) Fixed various linters warnings in the context of the gometalinter -> golangci-lint migration -* [\#3916](https://github.com/cosmos/cosmos-sdk/issues/3916) Hex encode data in tx responses - -### Bug Fixes - -#### Gaia - -* [\#3825](https://github.com/cosmos/cosmos-sdk/issues/3825) Validate genesis before running gentx -* [\#3889](https://github.com/cosmos/cosmos-sdk/issues/3889) When `--generate-only` is provided, the Keybase is not used and as a result - the `--from` value must be a valid Bech32 cosmos address. -* 3974 Fix go env setting in installation.md -* 3996 Change 'make get_tools' to 'make tools' in DOCS_README.md. - -#### Gaia CLI - -* [\#3883](https://github.com/cosmos/cosmos-sdk/issues/3883) Remove Height Flag from CLI Queries -* [\#3899](https://github.com/cosmos/cosmos-sdk/issues/3899) Using 'gaiacli config node' breaks ~/config/config.toml - -#### SDK - -* [\#3837](https://github.com/cosmos/cosmos-sdk/issues/3837) Fix `WithdrawValidatorCommission` to properly set the validator's remaining commission. -* [\#3870](https://github.com/cosmos/cosmos-sdk/issues/3870) Fix DecCoins#TruncateDecimal to never return zero coins in - either the truncated coins or the change coins. -* [\#3915](https://github.com/cosmos/cosmos-sdk/issues/3915) Remove ';' delimiting support from ParseDecCoins -* [\#3977](https://github.com/cosmos/cosmos-sdk/issues/3977) Fix docker image build -* [\#4020](https://github.com/cosmos/cosmos-sdk/issues/4020) Fix queryDelegationRewards by returning an error -when the validator or delegation do not exist. -* [\#4050](https://github.com/cosmos/cosmos-sdk/issues/4050) Fix DecCoins APIs -where rounding or truncation could result in zero decimal coins. -* [\#4088](https://github.com/cosmos/cosmos-sdk/issues/4088) Fix `calculateDelegationRewards` -by accounting for rounding errors when multiplying stake by slashing fractions. - -## 0.33.2 - -### Improvements - -#### Tendermint - -* Upgrade Tendermint to `v0.31.0-dev0-fix0` which includes critical security fixes. - -## 0.33.1 - -### Bug Fixes - -#### Gaia - -* [\#3999](https://github.com/cosmos/cosmos-sdk/pull/3999) Fix distribution delegation for zero height export bug - -## 0.33.0 - -BREAKING CHANGES - -* Gaia REST API - * [\#3641](https://github.com/cosmos/cosmos-sdk/pull/3641) Remove the ability to use a Keybase from the REST API client: - * `password` and `generate_only` have been removed from the `base_req` object - * All txs that used to sign or use the Keybase now only generate the tx - * `keys` routes completely removed - * [\#3692](https://github.com/cosmos/cosmos-sdk/pull/3692) Update tx encoding and broadcasting endpoints: - * Remove duplicate broadcasting endpoints in favor of POST @ `/txs` - * The `Tx` field now accepts a `StdTx` and not raw tx bytes - * Move encoding endpoint to `/txs/encode` - -* Gaia - * [\#3787](https://github.com/cosmos/cosmos-sdk/pull/3787) Fork the `x/bank` module into the Gaia application with only a - modified message handler, where the modified message handler behaves the same as - the standard `x/bank` message handler except for `MsgMultiSend` that must burn - exactly 9 atoms and transfer 1 atom, and `MsgSend` is disabled. - * [\#3789](https://github.com/cosmos/cosmos-sdk/pull/3789) Update validator creation flow: - * Remove `NewMsgCreateValidatorOnBehalfOf` and corresponding business logic - * Ensure the validator address equals the delegator address during - `MsgCreateValidator#ValidateBasic` - -* SDK - * [\#3750](https://github.com/cosmos/cosmos-sdk/issues/3750) Track outstanding rewards per-validator instead of globally, - and fix the main simulation issue, which was that slashes of - re-delegations to a validator were not correctly accounted for - in fee distribution when the redelegation in question had itself - been slashed (from a fault committed by a different validator) - in the same BeginBlock. Outstanding rewards are now available - on a per-validator basis in REST. - * [\#3669](https://github.com/cosmos/cosmos-sdk/pull/3669) Ensure consistency in message naming, codec registration, and JSON - tags. - * [\#3788](https://github.com/cosmos/cosmos-sdk/pull/3788) Change order of operations for greater accuracy when calculating delegation share token value - * [\#3788](https://github.com/cosmos/cosmos-sdk/pull/3788) DecCoins.Cap -> DecCoins.Intersect - * [\#3666](https://github.com/cosmos/cosmos-sdk/pull/3666) Improve coins denom validation. - * [\#3751](https://github.com/cosmos/cosmos-sdk/pull/3751) Disable (temporarily) support for ED25519 account key pairs. - -* Tendermint - * [\#3804] Update to Tendermint `v0.31.0-dev0` - -FEATURES - -* SDK - * [\#3719](https://github.com/cosmos/cosmos-sdk/issues/3719) DBBackend can now be set at compile time. - Defaults: goleveldb. Supported: cleveldb. - -IMPROVEMENTS - -* Gaia REST API - * Update the `TxResponse` type allowing for the `Logs` result to be JSON decoded automatically. - -* Gaia CLI - * [\#3653](https://github.com/cosmos/cosmos-sdk/pull/3653) Prompt user confirmation prior to signing and broadcasting a transaction. - * [\#3670](https://github.com/cosmos/cosmos-sdk/pull/3670) CLI support for showing bech32 addresses in Ledger devices - * [\#3711](https://github.com/cosmos/cosmos-sdk/pull/3711) Update `tx sign` to use `--from` instead of the deprecated `--name` - CLI flag. - * [\#3738](https://github.com/cosmos/cosmos-sdk/pull/3738) Improve multisig UX: - * `gaiacli keys show -o json` now includes constituent pubkeys, respective weights and threshold - * `gaiacli keys show --show-multisig` now displays constituent pubkeys, respective weights and threshold - * `gaiacli tx sign --validate-signatures` now displays multisig signers with their respective weights - * [\#3730](https://github.com/cosmos/cosmos-sdk/issues/3730) Improve workflow for - `gaiad gentx` with offline public keys, by outputting stdtx file that needs to be signed. - * [\#3761](https://github.com/cosmos/cosmos-sdk/issues/3761) Querying account related information using custom querier in auth module - -* SDK - * [\#3753](https://github.com/cosmos/cosmos-sdk/issues/3753) Remove no-longer-used governance penalty parameter - * [\#3679](https://github.com/cosmos/cosmos-sdk/issues/3679) Consistent operators across Coins, DecCoins, Int, Dec - replaced: Minus->Sub Plus->Add Div->Quo - * [\#3665](https://github.com/cosmos/cosmos-sdk/pull/3665) Overhaul sdk.Uint type in preparation for Coins Int -> Uint migration. - * [\#3691](https://github.com/cosmos/cosmos-sdk/issues/3691) Cleanup error messages - * [\#3456](https://github.com/cosmos/cosmos-sdk/issues/3456) Integrate in the Int.ToDec() convenience function - * [\#3300](https://github.com/cosmos/cosmos-sdk/pull/3300) Update the spec-spec, spec file reorg, and TOC updates. - * [\#3694](https://github.com/cosmos/cosmos-sdk/pull/3694) Push tagged docker images on docker hub when tag is created. - * [\#3716](https://github.com/cosmos/cosmos-sdk/pull/3716) Update file permissions the client keys directory and contents to `0700`. - * [\#3681](https://github.com/cosmos/cosmos-sdk/issues/3681) Migrate ledger-cosmos-go from ZondaX to Cosmos organization - -* Tendermint - * [\#3699](https://github.com/cosmos/cosmos-sdk/pull/3699) Upgrade to Tendermint 0.30.1 - -BUG FIXES - -* Gaia CLI - * [\#3731](https://github.com/cosmos/cosmos-sdk/pull/3731) `keys add --interactive` bip32 passphrase regression fix - * [\#3714](https://github.com/cosmos/cosmos-sdk/issues/3714) Fix USB raw access issues with gaiacli when installed via snap - -* Gaia - * [\#3777](https://github.com/cosmso/cosmos-sdk/pull/3777) `gaiad export` no longer panics when the database is empty - * [\#3806](https://github.com/cosmos/cosmos-sdk/pull/3806) Properly return errors from a couple of struct Unmarshal functions - -* SDK - * [\#3728](https://github.com/cosmos/cosmos-sdk/issues/3728) Truncate decimal multiplication & division in distribution to ensure - no more than the collected fees / inflation are distributed - * [\#3727](https://github.com/cosmos/cosmos-sdk/issues/3727) Return on zero-length (including []byte{}) PrefixEndBytes() calls - * [\#3559](https://github.com/cosmos/cosmos-sdk/issues/3559) fix occasional failing due to non-determinism in lcd test TestBonding - where validator is unexpectedly slashed throwing off test calculations - * [\#3411](https://github.com/cosmos/cosmos-sdk/pull/3411) Include the `RequestInitChain.Time` in the block header init during - `InitChain`. - * [\#3717](https://github.com/cosmos/cosmos-sdk/pull/3717) Update the vesting specification and implementation to cap deduction from - `DelegatedVesting` by at most `DelegatedVesting`. This accounts for the case where - the undelegation amount may exceed the original delegation amount due to - truncation of undelegation tokens. - * [\#3717](https://github.com/cosmos/cosmos-sdk/pull/3717) Ignore unknown proposers in allocating rewards for proposers, in case - unbonding period was just 1 block and proposer was already deleted. - * [\#3726](https://github.com/cosmos/cosmos-sdk/pull/3724) Cap(clip) reward to remaining coins in AllocateTokens. - -## 0.32.0 - -BREAKING CHANGES - -* Gaia REST API - * [\#3642](https://github.com/cosmos/cosmos-sdk/pull/3642) `GET /tx/{hash}` now returns `404` instead of `500` if the transaction is not found - -* SDK - * [\#3580](https://github.com/cosmos/cosmos-sdk/issues/3580) Migrate HTTP request/response types and utilities to types/rest. - * [\#3592](https://github.com/cosmos/cosmos-sdk/issues/3592) Drop deprecated keybase implementation's New() constructor in - favor of a new crypto/keys.New(string, string) implementation that - returns a lazy keybase instance. Remove client.MockKeyBase, - superseded by crypto/keys.NewInMemory() - * [\#3621](https://github.com/cosmos/cosmos-sdk/issues/3621) staking.GenesisState.Bonds -> Delegations - -IMPROVEMENTS - -* SDK - * [\#3311](https://github.com/cosmos/cosmos-sdk/pull/3311) Reconcile the `DecCoin/s` API with the `Coin/s` API. - * [\#3614](https://github.com/cosmos/cosmos-sdk/pull/3614) Add coin denom length checks to the coins constructors. - * [\#3621](https://github.com/cosmos/cosmos-sdk/issues/3621) remove many inter-module dependancies - * [\#3601](https://github.com/cosmos/cosmos-sdk/pull/3601) JSON-stringify the ABCI log response which includes the log and message - index. - * [\#3604](https://github.com/cosmos/cosmos-sdk/pull/3604) Improve SDK funds related error messages and allow for unicode in - JSON ABCI log. - * [\#3620](https://github.com/cosmos/cosmos-sdk/pull/3620) Version command shows build tags - * [\#3638](https://github.com/cosmos/cosmos-sdk/pull/3638) Add Bcrypt benchmarks & justification of security parameter choice - * [\#3648](https://github.com/cosmos/cosmos-sdk/pull/3648) Add JSON struct tags to vesting accounts. - -* Tendermint - * [\#3618](https://github.com/cosmos/cosmos-sdk/pull/3618) Upgrade to Tendermint 0.30.03 - -BUG FIXES - -* SDK - * [\#3646](https://github.com/cosmos/cosmos-sdk/issues/3646) `x/mint` now uses total token supply instead of total bonded tokens to calculate inflation - - -## 0.31.2 - -BREAKING CHANGES - -* SDK - * [\#3592](https://github.com/cosmos/cosmos-sdk/issues/3592) Drop deprecated keybase implementation's - New constructor in favor of a new - crypto/keys.New(string, string) implementation that - returns a lazy keybase instance. Remove client.MockKeyBase, - superseded by crypto/keys.NewInMemory() - -IMPROVEMENTS - -* SDK - * [\#3604](https://github.com/cosmos/cosmos-sdk/pulls/3604) Improve SDK funds related error messages and allow for unicode in - JSON ABCI log. - -* Tendermint - * [\#3563](https://github.com/cosmos/cosmos-sdk/3563) Update to Tendermint version `0.30.0-rc0` - - -BUG FIXES - -* Gaia - * [\#3585] Fix setting the tx hash in `NewResponseFormatBroadcastTxCommit`. - * [\#3585] Return an empty `TxResponse` when Tendermint returns an empty - `ResultBroadcastTx`. - -* SDK - * [\#3582](https://github.com/cosmos/cosmos-sdk/pull/3582) Running `make test_unit` was failing due to a missing tag - * [\#3617](https://github.com/cosmos/cosmos-sdk/pull/3582) Fix fee comparison when the required fees does not contain any denom - present in the tx fees. - -## 0.31.0 - -BREAKING CHANGES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [\#3284](https://github.com/cosmos/cosmos-sdk/issues/3284) Rename the `name` - field to `from` in the `base_req` body. - * [\#3485](https://github.com/cosmos/cosmos-sdk/pull/3485) Error responses are now JSON objects. - * [\#3477][distribution] endpoint changed "all_delegation_rewards" -> "delegator_total_rewards" - -* Gaia CLI (`gaiacli`) - - [#3399](https://github.com/cosmos/cosmos-sdk/pull/3399) Add `gaiad validate-genesis` command to facilitate checking of genesis files - - [\#1894](https://github.com/cosmos/cosmos-sdk/issues/1894) `version` prints out short info by default. Add `--long` flag. Proper handling of `--format` flag introduced. - - [\#3465](https://github.com/cosmos/cosmos-sdk/issues/3465) `gaiacli rest-server` switched back to insecure mode by default: - - `--insecure` flag is removed. - - `--tls` is now used to enable secure layer. - - [\#3451](https://github.com/cosmos/cosmos-sdk/pull/3451) `gaiacli` now returns transactions in plain text including tags. - - [\#3497](https://github.com/cosmos/cosmos-sdk/issues/3497) `gaiad init` now takes moniker as required arguments, not as parameter. - * [\#3501](https://github.com/cosmos/cosmos-sdk/issues/3501) Change validator - address Bech32 encoding to consensus address in `tendermint-validator-set`. - -* Gaia - * [\#3457](https://github.com/cosmos/cosmos-sdk/issues/3457) Changed governance tally validatorGovInfo to use sdk.Int power instead of sdk.Dec - * [\#3495](https://github.com/cosmos/cosmos-sdk/issues/3495) Added Validator Minimum Self Delegation - * Reintroduce OR semantics for tx fees - -* SDK - * [\#2513](https://github.com/cosmos/cosmos-sdk/issues/2513) Tendermint updates are adjusted by 10^-6 relative to staking tokens, - * [\#3487](https://github.com/cosmos/cosmos-sdk/pull/3487) Move HTTP/REST utilities out of client/utils into a new dedicated client/rest package. - * [\#3490](https://github.com/cosmos/cosmos-sdk/issues/3490) ReadRESTReq() returns bool to avoid callers to write error responses twice. - * [\#3502](https://github.com/cosmos/cosmos-sdk/pull/3502) Fixes issue when comparing genesis states - * [\#3514](https://github.com/cosmos/cosmos-sdk/pull/3514) Various clean ups: - - Replace all GetKeyBase\* functions family in favor of NewKeyBaseFromDir and NewKeyBaseFromHomeFlag. - - Remove Get prefix from all TxBuilder's getters. - * [\#3522](https://github.com/cosmos/cosmos-sdk/pull/3522) Get rid of double negatives: Coins.IsNotNegative() -> Coins.IsAnyNegative(). - * [\#3561](https://github.com/cosmos/cosmos-sdk/issues/3561) Don't unnecessarily store denominations in staking - - -FEATURES - -* Gaia REST API - -* [\#2358](https://github.com/cosmos/cosmos-sdk/issues/2358) Add distribution module REST interface - -* Gaia CLI (`gaiacli`) - * [\#3429](https://github.com/cosmos/cosmos-sdk/issues/3429) Support querying - for all delegator distribution rewards. - * [\#3449](https://github.com/cosmos/cosmos-sdk/issues/3449) Proof verification now works with absence proofs - * [\#3484](https://github.com/cosmos/cosmos-sdk/issues/3484) Add support - vesting accounts to the add-genesis-account command. - -* Gaia - - [\#3397](https://github.com/cosmos/cosmos-sdk/pull/3397) Implement genesis file sanitization to avoid failures at chain init. - * [\#3428](https://github.com/cosmos/cosmos-sdk/issues/3428) Run the simulation from a particular genesis state loaded from a file - -* SDK - * [\#3270](https://github.com/cosmos/cosmos-sdk/issues/3270) [x/staking] limit number of ongoing unbonding delegations /redelegations per pair/trio - * [\#3477][distribution] new query endpoint "delegator_validators" - * [\#3514](https://github.com/cosmos/cosmos-sdk/pull/3514) Provided a lazy loading implementation of Keybase that locks the underlying - storage only for the time needed to perform the required operation. Also added Keybase reference to TxBuilder struct. - * [types] [\#2580](https://github.com/cosmos/cosmos-sdk/issues/2580) Addresses now Bech32 empty addresses to an empty string - - -IMPROVEMENTS - -* Gaia REST API - * [\#3284](https://github.com/cosmos/cosmos-sdk/issues/3284) Update Gaia Lite - REST service to support the following: - * Automatic account number and sequence population when fields are omitted - * Generate only functionality no longer requires access to a local Keybase - * `from` field in the `base_req` body can be a Keybase name or account address - * [\#3423](https://github.com/cosmos/cosmos-sdk/issues/3423) Allow simulation - (auto gas) to work with generate only. - * [\#3514](https://github.com/cosmos/cosmos-sdk/pull/3514) REST server calls to keybase does not lock the underlying storage anymore. - * [\#3523](https://github.com/cosmos/cosmos-sdk/pull/3523) Added `/tx/encode` endpoint to serialize a JSON tx to base64-encoded Amino. - -* Gaia CLI (`gaiacli`) - * [\#3476](https://github.com/cosmos/cosmos-sdk/issues/3476) New `withdraw-all-rewards` command to withdraw all delegations rewards for delegators. - * [\#3497](https://github.com/cosmos/cosmos-sdk/issues/3497) `gaiad gentx` supports `--ip` and `--node-id` flags to override defaults. - * [\#3518](https://github.com/cosmos/cosmos-sdk/issues/3518) Fix flow in - `keys add` to show the mnemonic by default. - * [\#3517](https://github.com/cosmos/cosmos-sdk/pull/3517) Increased test coverage - * [\#3523](https://github.com/cosmos/cosmos-sdk/pull/3523) Added `tx encode` command to serialize a JSON tx to base64-encoded Amino. - -* Gaia - * [\#3418](https://github.com/cosmos/cosmos-sdk/issues/3418) Add vesting account - genesis validation checks to `GaiaValidateGenesisState`. - * [\#3420](https://github.com/cosmos/cosmos-sdk/issues/3420) Added maximum length to governance proposal descriptions and titles - * [\#3256](https://github.com/cosmos/cosmos-sdk/issues/3256) Add gas consumption - for tx size in the ante handler. - * [\#3454](https://github.com/cosmos/cosmos-sdk/pull/3454) Add `--jail-whitelist` to `gaiad export` to enable testing of complex exports - * [\#3424](https://github.com/cosmos/cosmos-sdk/issues/3424) Allow generation of gentxs with empty memo field. - * [\#3507](https://github.com/cosmos/cosmos-sdk/issues/3507) General cleanup, removal of unnecessary struct fields, undelegation bugfix, and comment clarification in x/staking and x/slashing - -* SDK - * [\#2605] x/params add subkey accessing - * [\#2986](https://github.com/cosmos/cosmos-sdk/pull/2986) Store Refactor - * [\#3435](https://github.com/cosmos/cosmos-sdk/issues/3435) Test that store implementations do not allow nil values - * [\#2509](https://github.com/cosmos/cosmos-sdk/issues/2509) Sanitize all usage of Dec.RoundInt64() - * [\#556](https://github.com/cosmos/cosmos-sdk/issues/556) Increase `BaseApp` - test coverage. - * [\#3357](https://github.com/cosmos/cosmos-sdk/issues/3357) develop state-transitions.md for staking spec, missing states added to `state.md` - * [\#3552](https://github.com/cosmos/cosmos-sdk/pull/3552) Validate bit length when - deserializing `Int` types. - - -BUG FIXES - -* Gaia CLI (`gaiacli`) - - [\#3417](https://github.com/cosmos/cosmos-sdk/pull/3417) Fix `q slashing signing-info` panic by ensuring safety of user input and properly returning not found error - - [\#3345](https://github.com/cosmos/cosmos-sdk/issues/3345) Upgrade ledger-cosmos-go dependency to v0.9.3 to pull - https://github.com/ZondaX/ledger-cosmos-go/commit/ed9aa39ce8df31bad1448c72d3d226bf2cb1a8d1 in order to fix a derivation path issue that causes `gaiacli keys add --recover` - to malfunction. - - [\#3419](https://github.com/cosmos/cosmos-sdk/pull/3419) Fix `q distr slashes` panic - - [\#3453](https://github.com/cosmos/cosmos-sdk/pull/3453) The `rest-server` command didn't respect persistent flags such as `--chain-id` and `--trust-node` if they were - passed on the command line. - - [\#3441](https://github.com/cosmos/cosmos-sdk/pull/3431) Improved resource management and connection handling (ledger devices). Fixes issue with DER vs BER signatures. - -* Gaia - * [\#3486](https://github.com/cosmos/cosmos-sdk/pull/3486) Use AmountOf in - vesting accounts instead of zipping/aligning denominations. - - -## 0.30.0 - -BREAKING CHANGES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [gaia-lite] [\#2182] Renamed and merged all redelegations endpoints into `/staking/redelegations` - * [\#3176](https://github.com/cosmos/cosmos-sdk/issues/3176) `tx/sign` endpoint now expects `BaseReq` fields as nested object. - * [\#2222] all endpoints renamed from `/stake` -> `/staking` - * [\#1268] `LooseTokens` -> `NotBondedTokens` - * [\#3289] misc renames: - * `Validator.UnbondingMinTime` -> `Validator.UnbondingCompletionTime` - * `Delegation` -> `Value` in `MsgCreateValidator` and `MsgDelegate` - * `MsgBeginUnbonding` -> `MsgUndelegate` - -* Gaia CLI (`gaiacli`) - * [\#810](https://github.com/cosmos/cosmos-sdk/issues/810) Don't fallback to any default values for chain ID. - * Users need to supply chain ID either via config file or the `--chain-id` flag. - * Change `chain_id` and `trust_node` in `gaiacli` configuration to `chain-id` and `trust-node` respectively. - * [\#3069](https://github.com/cosmos/cosmos-sdk/pull/3069) `--fee` flag renamed to `--fees` to support multiple coins - * [\#3156](https://github.com/cosmos/cosmos-sdk/pull/3156) Remove unimplemented `gaiacli init` command - * [\#2222] `gaiacli tx stake` -> `gaiacli tx staking`, `gaiacli query stake` -> `gaiacli query staking` - * [\#1894](https://github.com/cosmos/cosmos-sdk/issues/1894) `version` command now shows latest commit, vendor dir hash, and build machine info. - * [\#3320](https://github.com/cosmos/cosmos-sdk/pull/3320) Ensure all `gaiacli query` commands respect the `--output` and `--indent` flags - -* Gaia - * https://github.com/cosmos/cosmos-sdk/issues/2838 - Move store keys to constants - * [\#3162](https://github.com/cosmos/cosmos-sdk/issues/3162) The `--gas` flag now takes `auto` instead of `simulate` - in order to trigger a simulation of the tx before the actual execution. - * [\#3285](https://github.com/cosmos/cosmos-sdk/pull/3285) New `gaiad tendermint version` to print libs versions - * [\#1894](https://github.com/cosmos/cosmos-sdk/pull/1894) `version` command now shows latest commit, vendor dir hash, and build machine info. - * [\#3249\(https://github.com/cosmos/cosmos-sdk/issues/3249) `tendermint`'s `show-validator` and `show-address` `--json` flags removed in favor of `--output-format=json`. - -* SDK - * [distribution] [\#3359](https://github.com/cosmos/cosmos-sdk/issues/3359) Always round down when calculating rewards-to-be-withdrawn in F1 fee distribution - * [#3336](https://github.com/cosmos/cosmos-sdk/issues/3336) Ensure all SDK - messages have their signature bytes contain canonical fields `value` and `type`. - * [\#3333](https://github.com/cosmos/cosmos-sdk/issues/3333) - F1 storage efficiency improvements - automatic withdrawals when unbonded, historical reward reference counting - * [staking] [\#2513](https://github.com/cosmos/cosmos-sdk/issues/2513) Validator power type from Dec -> Int - * [staking] [\#3233](https://github.com/cosmos/cosmos-sdk/issues/3233) key and value now contain duplicate fields to simplify code - * [\#3064](https://github.com/cosmos/cosmos-sdk/issues/3064) Sanitize `sdk.Coin` denom. Coins denoms are now case insensitive, i.e. 100fooToken equals to 100FOOTOKEN. - * [\#3195](https://github.com/cosmos/cosmos-sdk/issues/3195) Allows custom configuration for syncable strategy - * [\#3242](https://github.com/cosmos/cosmos-sdk/issues/3242) Fix infinite gas - meter utilization during aborted ante handler executions. - * [x/distribution] [\#3292](https://github.com/cosmos/cosmos-sdk/issues/3292) Enable or disable withdraw addresses with a parameter in the param store - * [staking] [\#2222](https://github.com/cosmos/cosmos-sdk/issues/2222) `/stake` -> `/staking` module rename - * [staking] [\#1268](https://github.com/cosmos/cosmos-sdk/issues/1268) `LooseTokens` -> `NotBondedTokens` - * [staking] [\#1402](https://github.com/cosmos/cosmos-sdk/issues/1402) Redelegation and unbonding-delegation structs changed to include multiple an array of entries - * [staking] [\#3289](https://github.com/cosmos/cosmos-sdk/issues/3289) misc renames: - * `Validator.UnbondingMinTime` -> `Validator.UnbondingCompletionTime` - * `Delegation` -> `Value` in `MsgCreateValidator` and `MsgDelegate` - * `MsgBeginUnbonding` -> `MsgUndelegate` - * [\#3315] Increase decimal precision to 18 - * [\#3323](https://github.com/cosmos/cosmos-sdk/issues/3323) Update to Tendermint 0.29.0 - * [\#3328](https://github.com/cosmos/cosmos-sdk/issues/3328) [x/gov] Remove redundant action tag - -* Tendermint - * [\#3298](https://github.com/cosmos/cosmos-sdk/issues/3298) Upgrade to Tendermint 0.28.0 - -FEATURES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [\#3067](https://github.com/cosmos/cosmos-sdk/issues/3067) Add support for fees on transactions - * [\#3069](https://github.com/cosmos/cosmos-sdk/pull/3069) Add a custom memo on transactions - * [\#3027](https://github.com/cosmos/cosmos-sdk/issues/3027) Implement - `/gov/proposals/{proposalID}/proposer` to query for a proposal's proposer. - -* Gaia CLI (`gaiacli`) - * [\#2399](https://github.com/cosmos/cosmos-sdk/issues/2399) Implement `params` command to query slashing parameters. - * [\#2730](https://github.com/cosmos/cosmos-sdk/issues/2730) Add tx search pagination parameter - * [\#3027](https://github.com/cosmos/cosmos-sdk/issues/3027) Implement - `query gov proposer [proposal-id]` to query for a proposal's proposer. - * [\#3198](https://github.com/cosmos/cosmos-sdk/issues/3198) New `keys add --multisig` flag to store multisig keys locally. - * [\#3198](https://github.com/cosmos/cosmos-sdk/issues/3198) New `multisign` command to generate multisig signatures. - * [\#3198](https://github.com/cosmos/cosmos-sdk/issues/3198) New `sign --multisig` flag to enable multisig mode. - * [\#2715](https://github.com/cosmos/cosmos-sdk/issues/2715) Reintroduce gaia server's insecure mode. - * [\#3334](https://github.com/cosmos/cosmos-sdk/pull/3334) New `gaiad completion` and `gaiacli completion` to generate Bash/Zsh completion scripts. - * [\#2607](https://github.com/cosmos/cosmos-sdk/issues/2607) Make `gaiacli config` handle the boolean `indent` flag to beautify commands JSON output. - -* Gaia - * [\#2182] [x/staking] Added querier for querying a single redelegation - * [\#3305](https://github.com/cosmos/cosmos-sdk/issues/3305) Add support for - vesting accounts at genesis. - * [\#3198](https://github.com/cosmos/cosmos-sdk/issues/3198) [x/auth] Add multisig transactions support - * [\#3198](https://github.com/cosmos/cosmos-sdk/issues/3198) `add-genesis-account` can take both account addresses and key names - -* SDK - - [\#3099](https://github.com/cosmos/cosmos-sdk/issues/3099) Implement F1 fee distribution - - [\#2926](https://github.com/cosmos/cosmos-sdk/issues/2926) Add TxEncoder to client TxBuilder. - * [\#2694](https://github.com/cosmos/cosmos-sdk/issues/2694) Vesting account implementation. - * [\#2996](https://github.com/cosmos/cosmos-sdk/issues/2996) Update the `AccountKeeper` to contain params used in the context of - the ante handler. - * [\#3179](https://github.com/cosmos/cosmos-sdk/pull/3179) New CodeNoSignatures error code. - * [\#3319](https://github.com/cosmos/cosmos-sdk/issues/3319) [x/distribution] Queriers for all distribution state worth querying; distribution query commands - * [\#3356](https://github.com/cosmos/cosmos-sdk/issues/3356) [x/auth] bech32-ify accounts address in error message. - -IMPROVEMENTS - -* Gaia REST API - * [\#3176](https://github.com/cosmos/cosmos-sdk/issues/3176) Validate tx/sign endpoint POST body. - * [\#2948](https://github.com/cosmos/cosmos-sdk/issues/2948) Swagger UI now makes requests to light client node - -* Gaia CLI (`gaiacli`) - * [\#3224](https://github.com/cosmos/cosmos-sdk/pull/3224) Support adding offline public keys to the keystore - -* Gaia - * [\#2186](https://github.com/cosmos/cosmos-sdk/issues/2186) Add Address Interface - * [\#3158](https://github.com/cosmos/cosmos-sdk/pull/3158) Validate slashing genesis - * [\#3172](https://github.com/cosmos/cosmos-sdk/pull/3172) Support minimum fees in a local testnet. - * [\#3250](https://github.com/cosmos/cosmos-sdk/pull/3250) Refactor integration tests and increase coverage - * [\#3248](https://github.com/cosmos/cosmos-sdk/issues/3248) Refactor tx fee - model: - * Validators specify minimum gas prices instead of minimum fees - * Clients may provide either fees or gas prices directly - * The gas prices of a tx must meet a validator's minimum - * `gaiad start` and `gaia.toml` take --minimum-gas-prices flag and minimum-gas-price config key respectively. - * [\#2859](https://github.com/cosmos/cosmos-sdk/issues/2859) Rename `TallyResult` in gov proposals to `FinalTallyResult` - * [\#3286](https://github.com/cosmos/cosmos-sdk/pull/3286) Fix `gaiad gentx` printout of account's addresses, i.e. user bech32 instead of hex. - * [\#3249\(https://github.com/cosmos/cosmos-sdk/issues/3249) `--json` flag removed, users should use `--output=json` instead. - -* SDK - * [\#3137](https://github.com/cosmos/cosmos-sdk/pull/3137) Add tag documentation - for each module along with cleaning up a few existing tags in the governance, - slashing, and staking modules. - * [\#3093](https://github.com/cosmos/cosmos-sdk/issues/3093) Ante handler does no longer read all accounts in one go when processing signatures as signature - verification may fail before last signature is checked. - * [staking] [\#1402](https://github.com/cosmos/cosmos-sdk/issues/1402) Add for multiple simultaneous redelegations or unbonding-delegations within an unbonding period - * [staking] [\#1268](https://github.com/cosmos/cosmos-sdk/issues/1268) staking spec rewrite - -* CI - * [\#2498](https://github.com/cosmos/cosmos-sdk/issues/2498) Added macos CI job to CircleCI - * [#142](https://github.com/tendermint/devops/issues/142) Increased the number of blocks to be tested during multi-sim - * [#147](https://github.com/tendermint/devops/issues/142) Added docker image build to CI - -BUG FIXES - -* Gaia CLI (`gaiacli`) - * [\#3141](https://github.com/cosmos/cosmos-sdk/issues/3141) Fix the bug in GetAccount when `len(res) == 0` and `err == nil` - * [\#810](https://github.com/cosmos/cosmos-sdk/pull/3316) Fix regression in gaiacli config file handling - -* Gaia - * [\#3148](https://github.com/cosmos/cosmos-sdk/issues/3148) Fix `gaiad export` by adding a boolean to `NewGaiaApp` determining whether or not to load the latest version - * [\#3181](https://github.com/cosmos/cosmos-sdk/issues/3181) Correctly reset total accum update height and jailed-validator bond height / unbonding height on export-for-zero-height - * [\#3172](https://github.com/cosmos/cosmos-sdk/pull/3172) Fix parsing `gaiad.toml` - when it already exists. - * [\#3223](https://github.com/cosmos/cosmos-sdk/issues/3223) Fix unset governance proposal queues when importing state from old chain - * [#3187](https://github.com/cosmos/cosmos-sdk/issues/3187) Fix `gaiad export` - by resetting each validator's slashing period. - -## 0.29.1 - -BUG FIXES - -* SDK - * [\#3207](https://github.com/cosmos/cosmos-sdk/issues/3207) - Fix token printing bug - -## 0.29.0 - -BREAKING CHANGES - -* Gaia - * [\#3148](https://github.com/cosmos/cosmos-sdk/issues/3148) Fix `gaiad export` by adding a boolean to `NewGaiaApp` determining whether or not to load the latest version - -* SDK - * [\#3163](https://github.com/cosmos/cosmos-sdk/issues/3163) Withdraw commission on self bond removal - - -## 0.28.1 - -BREAKING CHANGES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [lcd] [\#3045](https://github.com/cosmos/cosmos-sdk/pull/3045) Fix quoted json return on GET /keys (keys list) - * [gaia-lite] [\#2191](https://github.com/cosmos/cosmos-sdk/issues/2191) Split `POST /stake/delegators/{delegatorAddr}/delegations` into `POST /stake/delegators/{delegatorAddr}/delegations`, `POST /stake/delegators/{delegatorAddr}/unbonding_delegations` and `POST /stake/delegators/{delegatorAddr}/redelegations` - * [gaia-lite] [\#3056](https://github.com/cosmos/cosmos-sdk/pull/3056) `generate_only` and `simulate` have moved from query arguments to POST requests body. -* Tendermint - * [tendermint] Now using Tendermint 0.27.3 - -FEATURES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [slashing] [\#2399](https://github.com/cosmos/cosmos-sdk/issues/2399) Implement `/slashing/parameters` endpoint to query slashing parameters. -* Gaia CLI (`gaiacli`) - * [gaiacli] [\#2399](https://github.com/cosmos/cosmos-sdk/issues/2399) Implement `params` command to query slashing parameters. -* SDK - - [client] [\#2926](https://github.com/cosmos/cosmos-sdk/issues/2926) Add TxEncoder to client TxBuilder. -* Other - - Introduced the logjack tool for saving logs w/ rotation - -IMPROVEMENTS - -* Gaia REST API (`gaiacli advanced rest-server`) - * [\#2879](https://github.com/cosmos/cosmos-sdk/issues/2879), [\#2880](https://github.com/cosmos/cosmos-sdk/issues/2880) Update deposit and vote endpoints to perform a direct txs query - when a given proposal is inactive and thus having votes and deposits removed - from state. -* Gaia CLI (`gaiacli`) - * [\#2879](https://github.com/cosmos/cosmos-sdk/issues/2879), [\#2880](https://github.com/cosmos/cosmos-sdk/issues/2880) Update deposit and vote CLI commands to perform a direct txs query - when a given proposal is inactive and thus having votes and deposits removed - from state. -* Gaia - * [\#3021](https://github.com/cosmos/cosmos-sdk/pull/3021) Add `--gentx-dir` to `gaiad collect-gentxs` to specify a directory from which collect and load gentxs. Add `--output-document` to `gaiad init` to allow one to redirect output to file. - - -## 0.28.0 - -BREAKING CHANGES - -* Gaia CLI (`gaiacli`) - * [cli] [\#2595](https://github.com/cosmos/cosmos-sdk/issues/2595) Remove `keys new` in favor of `keys add` incorporating existing functionality with addition of key recovery functionality. - * [cli] [\#2987](https://github.com/cosmos/cosmos-sdk/pull/2987) Add shorthand `-a` to `gaiacli keys show` and update docs - * [cli] [\#2971](https://github.com/cosmos/cosmos-sdk/pull/2971) Additional verification when running `gaiad gentx` - * [cli] [\#2734](https://github.com/cosmos/cosmos-sdk/issues/2734) Rewrite `gaiacli config`. It is now a non-interactive config utility. - -* Gaia - * [#128](https://github.com/tendermint/devops/issues/128) Updated CircleCI job to trigger website build on every push to master/develop. - * [\#2994](https://github.com/cosmos/cosmos-sdk/pull/2994) Change wrong-password error message. - * [\#3009](https://github.com/cosmos/cosmos-sdk/issues/3009) Added missing Gaia genesis verification - * [#128](https://github.com/tendermint/devops/issues/128) Updated CircleCI job to trigger website build on every push to master/develop. - * [\#2994](https://github.com/cosmos/cosmos-sdk/pull/2994) Change wrong-password error message. - * [\#3009](https://github.com/cosmos/cosmos-sdk/issues/3009) Added missing Gaia genesis verification - * [gas] [\#3052](https://github.com/cosmos/cosmos-sdk/issues/3052) Updated gas costs to more reasonable numbers - -* SDK - * [auth] [\#2952](https://github.com/cosmos/cosmos-sdk/issues/2952) Signatures are no longer serialized on chain with the account number and sequence number - * [auth] [\#2952](https://github.com/cosmos/cosmos-sdk/issues/2952) Signatures are no longer serialized on chain with the account number and sequence number - * [stake] [\#3055](https://github.com/cosmos/cosmos-sdk/issues/3055) Use address instead of bond height / intratxcounter for deduplication - -FEATURES - -* Gaia CLI (`gaiacli`) - * [\#2961](https://github.com/cosmos/cosmos-sdk/issues/2961) Add --force flag to gaiacli keys delete command to skip passphrase check and force key deletion unconditionally. - -IMPROVEMENTS - -* Gaia CLI (`gaiacli`) - * [\#2991](https://github.com/cosmos/cosmos-sdk/issues/2991) Fully validate transaction signatures during `gaiacli tx sign --validate-signatures` - -* SDK - * [\#1277](https://github.com/cosmos/cosmos-sdk/issues/1277) Complete bank module specification - * [\#2963](https://github.com/cosmos/cosmos-sdk/issues/2963) Complete auth module specification - * [\#2914](https://github.com/cosmos/cosmos-sdk/issues/2914) No longer withdraw validator rewards on bond/unbond, but rather move - the rewards to the respective validator's pools. - - -BUG FIXES - -* Gaia CLI (`gaiacli`) - * [\#2921](https://github.com/cosmos/cosmos-sdk/issues/2921) Fix `keys delete` inability to delete offline and ledger keys. - -* Gaia - * [\#3003](https://github.com/cosmos/cosmos-sdk/issues/3003) CollectStdTxs() must validate DelegatorAddr against genesis accounts. - -* SDK - * [\#2967](https://github.com/cosmos/cosmos-sdk/issues/2967) Change ordering of `mint.BeginBlocker` and `distr.BeginBlocker`, recalculate inflation each block - * [\#3068](https://github.com/cosmos/cosmos-sdk/issues/3068) check for uint64 gas overflow during `Std#ValidateBasic`. - * [\#3071](https://github.com/cosmos/cosmos-sdk/issues/3071) Catch overflow on block gas meter - - -## 0.27.0 - -BREAKING CHANGES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [gaia-lite] [\#2819](https://github.com/cosmos/cosmos-sdk/pull/2819) Txs query param format is now: `/txs?tag=value` (removed '' wrapping the query parameter `value`) - -* Gaia CLI (`gaiacli`) - * [cli] [\#2728](https://github.com/cosmos/cosmos-sdk/pull/2728) Seperate `tx` and `query` subcommands by module - * [cli] [\#2727](https://github.com/cosmos/cosmos-sdk/pull/2727) Fix unbonding command flow - * [cli] [\#2786](https://github.com/cosmos/cosmos-sdk/pull/2786) Fix redelegation command flow - * [cli] [\#2829](https://github.com/cosmos/cosmos-sdk/pull/2829) add-genesis-account command now validates state when adding accounts - * [cli] [\#2804](https://github.com/cosmos/cosmos-sdk/issues/2804) Check whether key exists before passing it on to `tx create-validator`. - * [cli] [\#2874](https://github.com/cosmos/cosmos-sdk/pull/2874) `gaiacli tx sign` takes an optional `--output-document` flag to support output redirection. - * [cli] [\#2875](https://github.com/cosmos/cosmos-sdk/pull/2875) Refactor `gaiad gentx` and avoid redirection to `gaiacli tx sign` for tx signing. - -* Gaia - * [mint] [\#2825] minting now occurs every block, inflation parameter updates still hourly - -* SDK - * [\#2752](https://github.com/cosmos/cosmos-sdk/pull/2752) Don't hardcode bondable denom. - * [\#2701](https://github.com/cosmos/cosmos-sdk/issues/2701) Account numbers and sequence numbers in `auth` are now `uint64` instead of `int64` - * [\#2019](https://github.com/cosmos/cosmos-sdk/issues/2019) Cap total number of signatures. Current per-transaction limit is 7, and if that is exceeded transaction is rejected. - * [\#2801](https://github.com/cosmos/cosmos-sdk/pull/2801) Remove AppInit structure. - * [\#2798](https://github.com/cosmos/cosmos-sdk/issues/2798) Governance API has miss-spelled English word in JSON response ('depositer' -> 'depositor') - * [\#2943](https://github.com/cosmos/cosmos-sdk/pull/2943) Transaction action tags equal the message type. Staking EndBlocker tags are included. - -* Tendermint - * Update to Tendermint 0.27.0 - -FEATURES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [gov] [\#2479](https://github.com/cosmos/cosmos-sdk/issues/2479) Added governance parameter - query REST endpoints. - -* Gaia CLI (`gaiacli`) - * [gov][cli] [\#2479](https://github.com/cosmos/cosmos-sdk/issues/2479) Added governance - parameter query commands. - * [stake][cli] [\#2027] Add CLI query command for getting all delegations to a specific validator. - * [\#2840](https://github.com/cosmos/cosmos-sdk/pull/2840) Standardize CLI exports from modules - -* Gaia - * [app] [\#2791](https://github.com/cosmos/cosmos-sdk/issues/2791) Support export at a specific height, with `gaiad export --height=HEIGHT`. - * [x/gov] [#2479](https://github.com/cosmos/cosmos-sdk/issues/2479) Implemented querier - for getting governance parameters. - * [app] [\#2663](https://github.com/cosmos/cosmos-sdk/issues/2663) - Runtime-assertable invariants - * [app] [\#2791](https://github.com/cosmos/cosmos-sdk/issues/2791) Support export at a specific height, with `gaiad export --height=HEIGHT`. - * [app] [\#2812](https://github.com/cosmos/cosmos-sdk/issues/2812) Support export alterations to prepare for restarting at zero-height - -* SDK - * [simulator] [\#2682](https://github.com/cosmos/cosmos-sdk/issues/2682) MsgEditValidator now looks at the validator's max rate, thus it now succeeds a significant portion of the time - * [core] [\#2775](https://github.com/cosmos/cosmos-sdk/issues/2775) Add deliverTx maximum block gas limit - - -IMPROVEMENTS - -* Gaia REST API (`gaiacli advanced rest-server`) - * [gaia-lite] [\#2819](https://github.com/cosmos/cosmos-sdk/pull/2819) Tx search now supports multiple tags as query parameters - * [\#2836](https://github.com/cosmos/cosmos-sdk/pull/2836) Expose LCD router to allow users to register routes there. - -* Gaia CLI (`gaiacli`) - * [\#2749](https://github.com/cosmos/cosmos-sdk/pull/2749) Add --chain-id flag to gaiad testnet - * [\#2819](https://github.com/cosmos/cosmos-sdk/pull/2819) Tx search now supports multiple tags as query parameters - -* Gaia - * [\#2772](https://github.com/cosmos/cosmos-sdk/issues/2772) Update BaseApp to not persist state when the ante handler fails on DeliverTx. - * [\#2773](https://github.com/cosmos/cosmos-sdk/issues/2773) Require moniker to be provided on `gaiad init`. - * [\#2672](https://github.com/cosmos/cosmos-sdk/issues/2672) [Makefile] Updated for better Windows compatibility and ledger support logic, get_tools was rewritten as a cross-compatible Makefile. - * [\#2766](https://github.com/cosmos/cosmos-sdk/issues/2766) [Makefile] Added goimports tool to get_tools. Get_tools now only builds new versions if binaries are missing. - * [#110](https://github.com/tendermint/devops/issues/110) Updated CircleCI job to trigger website build when cosmos docs are updated. - -* SDK - & [x/mock/simulation] [\#2720] major cleanup, introduction of helper objects, reorganization - * [\#2821](https://github.com/cosmos/cosmos-sdk/issues/2821) Codespaces are now strings - * [types] [\#2776](https://github.com/cosmos/cosmos-sdk/issues/2776) Improve safety of `Coin` and `Coins` types. Various functions - and methods will panic when a negative amount is discovered. - * [\#2815](https://github.com/cosmos/cosmos-sdk/issues/2815) Gas unit fields changed from `int64` to `uint64`. - * [\#2821](https://github.com/cosmos/cosmos-sdk/issues/2821) Codespaces are now strings - * [\#2779](https://github.com/cosmos/cosmos-sdk/issues/2779) Introduce `ValidateBasic` to the `Tx` interface and call it in the ante - handler. - * [\#2825](https://github.com/cosmos/cosmos-sdk/issues/2825) More staking and distribution invariants - * [\#2912](https://github.com/cosmos/cosmos-sdk/issues/2912) Print commit ID in hex when commit is synced. - -* Tendermint - * [\#2796](https://github.com/cosmos/cosmos-sdk/issues/2796) Update to go-amino 0.14.1 - - -BUG FIXES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [gaia-lite] [\#2868](https://github.com/cosmos/cosmos-sdk/issues/2868) Added handler for governance tally endpoint - * [\#2907](https://github.com/cosmos/cosmos-sdk/issues/2907) Refactor and fix the way Gaia Lite is started. - -* Gaia - * [\#2723] Use `cosmosvalcons` Bech32 prefix in `tendermint show-address` - * [\#2742](https://github.com/cosmos/cosmos-sdk/issues/2742) Fix time format of TimeoutCommit override - * [\#2898](https://github.com/cosmos/cosmos-sdk/issues/2898) Remove redundant '$' in docker-compose.yml - -* SDK - * [\#2733](https://github.com/cosmos/cosmos-sdk/issues/2733) [x/gov, x/mock/simulation] Fix governance simulation, update x/gov import/export - * [\#2854](https://github.com/cosmos/cosmos-sdk/issues/2854) [x/bank] Remove unused bank.MsgIssue, prevent possible panic - * [\#2884](https://github.com/cosmos/cosmos-sdk/issues/2884) [docs/examples] Fix `basecli version` panic - -* Tendermint - * [\#2797](https://github.com/tendermint/tendermint/pull/2797) AddressBook requires addresses to have IDs; Do not crap out immediately after sending pex addrs in seed mode - -## 0.26.0 - -BREAKING CHANGES - -* Gaia - * [gaiad init] [\#2602](https://github.com/cosmos/cosmos-sdk/issues/2602) New genesis workflow - -* SDK - * [simulation] [\#2665](https://github.com/cosmos/cosmos-sdk/issues/2665) only argument to sdk.Invariant is now app - -* Tendermint - * Upgrade to version 0.26.0 - -FEATURES - -* Gaia CLI (`gaiacli`) - * [cli] [\#2569](https://github.com/cosmos/cosmos-sdk/pull/2569) Add commands to query validator unbondings and redelegations - * [cli] [\#2569](https://github.com/cosmos/cosmos-sdk/pull/2569) Add commands to query validator unbondings and redelegations - * [cli] [\#2524](https://github.com/cosmos/cosmos-sdk/issues/2524) Add support offline mode to `gaiacli tx sign`. Lookups are not performed if the flag `--offline` is on. - * [cli] [\#2558](https://github.com/cosmos/cosmos-sdk/issues/2558) Rename --print-sigs to --validate-signatures. It now performs a complete set of sanity checks and reports to the user. Also added --print-signature-only to print the signature only, not the whole transaction. - * [cli] [\#2704](https://github.com/cosmos/cosmos-sdk/pull/2704) New add-genesis-account convenience command to populate genesis.json with genesis accounts. - -* SDK - * [\#1336](https://github.com/cosmos/cosmos-sdk/issues/1336) Mechanism for SDK Users to configure their own Bech32 prefixes instead of using the default cosmos prefixes. - -IMPROVEMENTS - -* Gaia - * [\#2637](https://github.com/cosmos/cosmos-sdk/issues/2637) [x/gov] Switched inactive and active proposal queues to an iterator based queue - -* SDK - * [\#2573](https://github.com/cosmos/cosmos-sdk/issues/2573) [x/distribution] add accum invariance - * [\#2556](https://github.com/cosmos/cosmos-sdk/issues/2556) [x/mock/simulation] Fix debugging output - * [\#2396](https://github.com/cosmos/cosmos-sdk/issues/2396) [x/mock/simulation] Change parameters to get more slashes - * [\#2617](https://github.com/cosmos/cosmos-sdk/issues/2617) [x/mock/simulation] Randomize all genesis parameters - * [\#2669](https://github.com/cosmos/cosmos-sdk/issues/2669) [x/stake] Added invarant check to make sure validator's power aligns with its spot in the power store. - * [\#1924](https://github.com/cosmos/cosmos-sdk/issues/1924) [x/mock/simulation] Use a transition matrix for block size - * [\#2660](https://github.com/cosmos/cosmos-sdk/issues/2660) [x/mock/simulation] Staking transactions get tested far more frequently - * [\#2610](https://github.com/cosmos/cosmos-sdk/issues/2610) [x/stake] Block redelegation to and from the same validator - * [\#2652](https://github.com/cosmos/cosmos-sdk/issues/2652) [x/auth] Add benchmark for get and set account - * [\#2685](https://github.com/cosmos/cosmos-sdk/issues/2685) [store] Add general merkle absence proof (also for empty substores) - * [\#2708](https://github.com/cosmos/cosmos-sdk/issues/2708) [store] Disallow setting nil values - -BUG FIXES - -* Gaia - * [\#2670](https://github.com/cosmos/cosmos-sdk/issues/2670) [x/stake] fixed incorrect `IterateBondedValidators` and split into two functions: `IterateBondedValidators` and `IterateLastBlockConsValidators` - * [\#2691](https://github.com/cosmos/cosmos-sdk/issues/2691) Fix local testnet creation by using a single canonical genesis time - * [\#2648](https://github.com/cosmos/cosmos-sdk/issues/2648) [gaiad] Fix `gaiad export` / `gaiad import` consistency, test in CI - -* SDK - * [\#2625](https://github.com/cosmos/cosmos-sdk/issues/2625) [x/gov] fix AppendTag function usage error - * [\#2677](https://github.com/cosmos/cosmos-sdk/issues/2677) [x/stake, x/distribution] various staking/distribution fixes as found by the simulator - * [\#2674](https://github.com/cosmos/cosmos-sdk/issues/2674) [types] Fix coin.IsLT() impl, coins.IsLT() impl, and renamed coins.Is\* to coins.IsAll\* (see [\#2686](https://github.com/cosmos/cosmos-sdk/issues/2686)) - * [\#2711](https://github.com/cosmos/cosmos-sdk/issues/2711) [x/stake] Add commission data to `MsgCreateValidator` signature bytes. - * Temporarily disable insecure mode for Gaia Lite - -## 0.25.0 - -*October 24th, 2018* - -BREAKING CHANGES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [x/stake] Validator.Owner renamed to Validator.Operator - * [\#595](https://github.com/cosmos/cosmos-sdk/issues/595) Connections to the REST server are now secured using Transport Layer Security by default. The --insecure flag is provided to switch back to insecure HTTP. - * [gaia-lite] [\#2258](https://github.com/cosmos/cosmos-sdk/issues/2258) Split `GET stake/delegators/{delegatorAddr}` into `GET stake/delegators/{delegatorAddr}/delegations`, `GET stake/delegators/{delegatorAddr}/unbonding_delegations` and `GET stake/delegators/{delegatorAddr}/redelegations` - -* Gaia CLI (`gaiacli`) - * [x/stake] Validator.Owner renamed to Validator.Operator - * [cli] unsafe_reset_all, show_validator, and show_node_id have been renamed to unsafe-reset-all, show-validator, and show-node-id - * [cli] [\#1983](https://github.com/cosmos/cosmos-sdk/issues/1983) --print-response now defaults to true in commands that create and send a transaction - * [cli] [\#1983](https://github.com/cosmos/cosmos-sdk/issues/1983) you can now pass --pubkey or --address to gaiacli keys show to return a plaintext representation of the key's address or public key for use with other commands - * [cli] [\#2061](https://github.com/cosmos/cosmos-sdk/issues/2061) changed proposalID in governance REST endpoints to proposal-id - * [cli] [\#2014](https://github.com/cosmos/cosmos-sdk/issues/2014) `gaiacli advanced` no longer exists - to access `ibc`, `rest-server`, and `validator-set` commands use `gaiacli ibc`, `gaiacli rest-server`, and `gaiacli tendermint`, respectively - * [makefile] `get_vendor_deps` no longer updates lock file it just updates vendor directory. Use `update_vendor_deps` to update the lock file. [#2152](https://github.com/cosmos/cosmos-sdk/pull/2152) - * [cli] [\#2221](https://github.com/cosmos/cosmos-sdk/issues/2221) All commands that - utilize a validator's operator address must now use the new Bech32 prefix, - `cosmosvaloper`. - * [cli] [\#2190](https://github.com/cosmos/cosmos-sdk/issues/2190) `gaiacli init --gen-txs` is now `gaiacli init --with-txs` to reduce confusion - * [cli] [\#2073](https://github.com/cosmos/cosmos-sdk/issues/2073) --from can now be either an address or a key name - * [cli] [\#1184](https://github.com/cosmos/cosmos-sdk/issues/1184) Subcommands reorganisation, see [\#2390](https://github.com/cosmos/cosmos-sdk/pull/2390) for a comprehensive list of changes. - * [cli] [\#2524](https://github.com/cosmos/cosmos-sdk/issues/2524) Add support offline mode to `gaiacli tx sign`. Lookups are not performed if the flag `--offline` is on. - * [cli] [\#2570](https://github.com/cosmos/cosmos-sdk/pull/2570) Add commands to query deposits on proposals - -* Gaia - * Make the transient store key use a distinct store key. [#2013](https://github.com/cosmos/cosmos-sdk/pull/2013) - * [x/stake] [\#1901](https://github.com/cosmos/cosmos-sdk/issues/1901) Validator type's Owner field renamed to Operator; Validator's GetOwner() renamed accordingly to comply with the SDK's Validator interface. - * [docs] [#2001](https://github.com/cosmos/cosmos-sdk/pull/2001) Update slashing spec for slashing period - * [x/stake, x/slashing] [#1305](https://github.com/cosmos/cosmos-sdk/issues/1305) - Rename "revoked" to "jailed" - * [x/stake] [#1676] Revoked and jailed validators put into the unbonding state - * [x/stake] [#1877] Redelegations/unbonding-delegation from unbonding validator have reduced time - * [x/slashing] [\#1789](https://github.com/cosmos/cosmos-sdk/issues/1789) Slashing changes for Tendermint validator set offset (NextValSet) - * [x/stake] [\#2040](https://github.com/cosmos/cosmos-sdk/issues/2040) Validator - operator type has now changed to `sdk.ValAddress` - * [x/stake] [\#2221](https://github.com/cosmos/cosmos-sdk/issues/2221) New - Bech32 prefixes have been introduced for a validator's consensus address and - public key: `cosmosvalcons` and `cosmosvalconspub` respectively. Also, existing Bech32 prefixes have been - renamed for accounts and validator operators: - * `cosmosaccaddr` / `cosmosaccpub` => `cosmos` / `cosmospub` - * `cosmosvaladdr` / `cosmosvalpub` => `cosmosvaloper` / `cosmosvaloperpub` - * [x/stake] [#1013] TendermintUpdates now uses transient store - * [x/stake] [\#2435](https://github.com/cosmos/cosmos-sdk/issues/2435) Remove empty bytes from the ValidatorPowerRank store key - * [x/gov] [\#2195](https://github.com/cosmos/cosmos-sdk/issues/2195) Governance uses BFT Time - * [x/gov] [\#2256](https://github.com/cosmos/cosmos-sdk/issues/2256) Removed slashing for governance non-voting validators - * [simulation] [\#2162](https://github.com/cosmos/cosmos-sdk/issues/2162) Added back correct supply invariants - * [x/slashing] [\#2430](https://github.com/cosmos/cosmos-sdk/issues/2430) Simulate more slashes, check if validator is jailed before jailing - * [x/stake] [\#2393](https://github.com/cosmos/cosmos-sdk/issues/2393) Removed `CompleteUnbonding` and `CompleteRedelegation` Msg types, and instead added unbonding/redelegation queues to endblocker - * [x/mock/simulation] [\#2501](https://github.com/cosmos/cosmos-sdk/issues/2501) Simulate transactions & invariants for fee distribution, and fix bugs discovered in the process - * [x/auth] Simulate random fee payments - * [cmd/gaia/app] Simulate non-zero inflation - * [x/stake] Call hooks correctly in several cases related to delegation/validator updates - * [x/stake] Check full supply invariants, including yet-to-be-withdrawn fees - * [x/stake] Remove no-longer-in-use store key - * [x/slashing] Call hooks correctly when a validator is slashed - * [x/slashing] Truncate withdrawals (unbonding, redelegation) and burn change - * [x/mock/simulation] Ensure the simulation cannot set a proposer address of nil - * [x/mock/simulation] Add more event logs on begin block / end block for clarity - * [x/mock/simulation] Correctly set validator power in abci.RequestBeginBlock - * [x/minting] Correctly call stake keeper to track inflated supply - * [x/distribution] Sanity check for nonexistent rewards - * [x/distribution] Truncate withdrawals and return change to the community pool - * [x/distribution] Add sanity checks for incorrect accum / total accum relations - * [x/distribution] Correctly calculate total power using Tendermint updates - * [x/distribution] Simulate withdrawal transactions - * [x/distribution] Fix a bug where the fee pool was not correctly tracked on WithdrawDelegatorRewardsAll - * [x/stake] [\#1673](https://github.com/cosmos/cosmos-sdk/issues/1673) Validators are no longer deleted until they can no longer possibly be slashed - * [\#1890](https://github.com/cosmos/cosmos-sdk/issues/1890) Start chain with initial state + sequence of transactions - * [cli] Rename `gaiad init gentx` to `gaiad gentx`. - * [cli] Add `--skip-genesis` flag to `gaiad init` to prevent `genesis.json` generation. - * Drop `GenesisTx` in favor of a signed `StdTx` with only one `MsgCreateValidator` message. - * [cli] Port `gaiad init` and `gaiad testnet` to work with `StdTx` genesis transactions. - * [cli] Add `--moniker` flag to `gaiad init` to override moniker when generating `genesis.json` - i.e. it takes effect when running with the `--with-txs` flag, it is ignored otherwise. - -* SDK - * [core] [\#2219](https://github.com/cosmos/cosmos-sdk/issues/2219) Update to Tendermint 0.24.0 - * Validator set updates delayed by one block - * BFT timestamp that can safely be used by applications - * Fixed maximum block size enforcement - * [core] [\#1807](https://github.com/cosmos/cosmos-sdk/issues/1807) Switch from use of rational to decimal - * [types] [\#1901](https://github.com/cosmos/cosmos-sdk/issues/1901) Validator interface's GetOwner() renamed to GetOperator() - * [x/slashing] [#2122](https://github.com/cosmos/cosmos-sdk/pull/2122) - Implement slashing period - * [types] [\#2119](https://github.com/cosmos/cosmos-sdk/issues/2119) Parsed error messages and ABCI log errors to make them more human readable. - * [types] [\#2407](https://github.com/cosmos/cosmos-sdk/issues/2407) MulInt method added to big decimal in order to improve efficiency of slashing - * [simulation] Rename TestAndRunTx to Operation [#2153](https://github.com/cosmos/cosmos-sdk/pull/2153) - * [simulation] Remove log and testing.TB from Operation and Invariants, in favor of using errors [\#2282](https://github.com/cosmos/cosmos-sdk/issues/2282) - * [simulation] Remove usage of keys and addrs in the types, in favor of simulation.Account [\#2384](https://github.com/cosmos/cosmos-sdk/issues/2384) - * [tools] Removed gocyclo [#2211](https://github.com/cosmos/cosmos-sdk/issues/2211) - * [baseapp] Remove `SetTxDecoder` in favor of requiring the decoder be set in baseapp initialization. [#1441](https://github.com/cosmos/cosmos-sdk/issues/1441) - * [baseapp] [\#1921](https://github.com/cosmos/cosmos-sdk/issues/1921) Add minimumFees field to BaseApp. - * [store] Change storeInfo within the root multistore to use tmhash instead of ripemd160 [\#2308](https://github.com/cosmos/cosmos-sdk/issues/2308) - * [codec] [\#2324](https://github.com/cosmos/cosmos-sdk/issues/2324) All referrences to wire have been renamed to codec. Additionally, wire.NewCodec is now codec.New(). - * [types] [\#2343](https://github.com/cosmos/cosmos-sdk/issues/2343) Make sdk.Msg have a names field, to facilitate automatic tagging. - * [baseapp] [\#2366](https://github.com/cosmos/cosmos-sdk/issues/2366) Automatically add action tags to all messages - * [x/auth] [\#2377](https://github.com/cosmos/cosmos-sdk/issues/2377) auth.StdSignMsg -> txbuilder.StdSignMsg - * [x/staking] [\#2244](https://github.com/cosmos/cosmos-sdk/issues/2244) staking now holds a consensus-address-index instead of a consensus-pubkey-index - * [x/staking] [\#2236](https://github.com/cosmos/cosmos-sdk/issues/2236) more distribution hooks for distribution - * [x/stake] [\#2394](https://github.com/cosmos/cosmos-sdk/issues/2394) Split up UpdateValidator into distinct state transitions applied only in EndBlock - * [x/slashing] [\#2480](https://github.com/cosmos/cosmos-sdk/issues/2480) Fix signing info handling bugs & faulty slashing - * [x/stake] [\#2412](https://github.com/cosmos/cosmos-sdk/issues/2412) Added an unbonding validator queue to EndBlock to automatically update validator.Status when finished Unbonding - * [x/stake] [\#2500](https://github.com/cosmos/cosmos-sdk/issues/2500) Block conflicting redelegations until we add an index - * [x/params] Global Paramstore refactored - * [types] [\#2506](https://github.com/cosmos/cosmos-sdk/issues/2506) sdk.Dec MarshalJSON now marshals as a normal Decimal, with 10 digits of decimal precision - * [x/stake] [\#2508](https://github.com/cosmos/cosmos-sdk/issues/2508) Utilize Tendermint power for validator power key - * [x/stake] [\#2531](https://github.com/cosmos/cosmos-sdk/issues/2531) Remove all inflation logic - * [x/mint] [\#2531](https://github.com/cosmos/cosmos-sdk/issues/2531) Add minting module and inflation logic - * [x/auth] [\#2540](https://github.com/cosmos/cosmos-sdk/issues/2540) Rename `AccountMapper` to `AccountKeeper`. - * [types] [\#2456](https://github.com/cosmos/cosmos-sdk/issues/2456) Renamed msg.Name() and msg.Type() to msg.Type() and msg.Route() respectively - -* Tendermint - * Update tendermint version from v0.23.0 to v0.25.0, notable changes - * Mempool now won't build too large blocks, or too computationally expensive blocks - * Maximum tx sizes and gas are now removed, and are implicitly the blocks maximums - * ABCI validators no longer send the pubkey. The pubkey is only sent in validator updates - * Validator set changes are now delayed by one block - * Block header now includes the next validator sets hash - * BFT time is implemented - * Secp256k1 signature format has changed - * There is now a threshold multisig format - * See the [tendermint changelog](https://github.com/tendermint/tendermint/blob/master/CHANGELOG.md) for other changes. - -FEATURES - -* Gaia REST API (`gaiacli advanced rest-server`) - * [gaia-lite] Endpoints to query staking pool and params - * [gaia-lite] [\#2110](https://github.com/cosmos/cosmos-sdk/issues/2110) Add support for `simulate=true` requests query argument to endpoints that send txs to run simulations of transactions - * [gaia-lite] [\#966](https://github.com/cosmos/cosmos-sdk/issues/966) Add support for `generate_only=true` query argument to generate offline unsigned transactions - * [gaia-lite] [\#1953](https://github.com/cosmos/cosmos-sdk/issues/1953) Add /sign endpoint to sign transactions generated with `generate_only=true`. - * [gaia-lite] [\#1954](https://github.com/cosmos/cosmos-sdk/issues/1954) Add /broadcast endpoint to broadcast transactions signed by the /sign endpoint. - * [gaia-lite] [\#2113](https://github.com/cosmos/cosmos-sdk/issues/2113) Rename `/accounts/{address}/send` to `/bank/accounts/{address}/transfers`, rename `/accounts/{address}` to `/auth/accounts/{address}`, replace `proposal-id` with `proposalId` in all gov endpoints - * [gaia-lite] [\#2478](https://github.com/cosmos/cosmos-sdk/issues/2478) Add query gov proposal's deposits endpoint - * [gaia-lite] [\#2477](https://github.com/cosmos/cosmos-sdk/issues/2477) Add query validator's outgoing redelegations and unbonding delegations endpoints - -* Gaia CLI (`gaiacli`) - * [cli] Cmds to query staking pool and params - * [gov][cli] [\#2062](https://github.com/cosmos/cosmos-sdk/issues/2062) added `--proposal` flag to `submit-proposal` that allows a JSON file containing a proposal to be passed in - * [\#2040](https://github.com/cosmos/cosmos-sdk/issues/2040) Add `--bech` to `gaiacli keys show` and respective REST endpoint to - provide desired Bech32 prefix encoding - * [cli] [\#2047](https://github.com/cosmos/cosmos-sdk/issues/2047) [\#2306](https://github.com/cosmos/cosmos-sdk/pull/2306) Passing --gas=simulate triggers a simulation of the tx before the actual execution. - The gas estimate obtained via the simulation will be used as gas limit in the actual execution. - * [cli] [\#2047](https://github.com/cosmos/cosmos-sdk/issues/2047) The --gas-adjustment flag can be used to adjust the estimate obtained via the simulation triggered by --gas=simulate. - * [cli] [\#2110](https://github.com/cosmos/cosmos-sdk/issues/2110) Add --dry-run flag to perform a simulation of a transaction without broadcasting it. The --gas flag is ignored as gas would be automatically estimated. - * [cli] [\#2204](https://github.com/cosmos/cosmos-sdk/issues/2204) Support generating and broadcasting messages with multiple signatures via command line: - * [\#966](https://github.com/cosmos/cosmos-sdk/issues/966) Add --generate-only flag to build an unsigned transaction and write it to STDOUT. - * [\#1953](https://github.com/cosmos/cosmos-sdk/issues/1953) New `sign` command to sign transactions generated with the --generate-only flag. - * [\#1954](https://github.com/cosmos/cosmos-sdk/issues/1954) New `broadcast` command to broadcast transactions generated offline and signed with the `sign` command. - * [cli] [\#2220](https://github.com/cosmos/cosmos-sdk/issues/2220) Add `gaiacli config` feature to interactively create CLI config files to reduce the number of required flags - * [stake][cli] [\#1672](https://github.com/cosmos/cosmos-sdk/issues/1672) Introduced - new commission flags for validator commands `create-validator` and `edit-validator`. - * [stake][cli] [\#1890](https://github.com/cosmos/cosmos-sdk/issues/1890) Add `--genesis-format` flag to `gaiacli tx create-validator` to produce transactions in genesis-friendly format. - * [cli][\#2554](https://github.com/cosmos/cosmos-sdk/issues/2554) Make `gaiacli keys show` multisig ready. - -* Gaia - * [cli] [\#2170](https://github.com/cosmos/cosmos-sdk/issues/2170) added ability to show the node's address via `gaiad tendermint show-address` - * [simulation] [\#2313](https://github.com/cosmos/cosmos-sdk/issues/2313) Reworked `make test_sim_gaia_slow` to `make test_sim_gaia_full`, now simulates from multiple starting seeds in parallel - * [cli] [\#1921] (https://github.com/cosmos/cosmos-sdk/issues/1921) - * New configuration file `gaiad.toml` is now created to host Gaia-specific configuration. - * New --minimum_fees/minimum_fees flag/config option to set a minimum fee. - -* SDK - * [querier] added custom querier functionality, so ABCI query requests can be handled by keepers - * [simulation] [\#1924](https://github.com/cosmos/cosmos-sdk/issues/1924) allow operations to specify future operations - * [simulation] [\#1924](https://github.com/cosmos/cosmos-sdk/issues/1924) Add benchmarking capabilities, with makefile commands "test_sim_gaia_benchmark, test_sim_gaia_profile" - * [simulation] [\#2349](https://github.com/cosmos/cosmos-sdk/issues/2349) Add time-based future scheduled operations to simulator - * [x/auth] [\#2376](https://github.com/cosmos/cosmos-sdk/issues/2376) Remove FeePayer() from StdTx - * [x/stake] [\#1672](https://github.com/cosmos/cosmos-sdk/issues/1672) Implement - basis for the validator commission model. - * [x/auth] Support account removal in the account mapper. - - -IMPROVEMENTS -* [tools] Improved terraform and ansible scripts for infrastructure deployment -* [tools] Added ansible script to enable process core dumps - -* Gaia REST API (`gaiacli advanced rest-server`) - * [x/stake] [\#2000](https://github.com/cosmos/cosmos-sdk/issues/2000) Added tests for new staking endpoints - * [gaia-lite] [\#2445](https://github.com/cosmos/cosmos-sdk/issues/2445) Standarized REST error responses - * [gaia-lite] Added example to Swagger specification for /keys/seed. - * [x/stake] Refactor REST utils - -* Gaia CLI (`gaiacli`) - * [cli] [\#2060](https://github.com/cosmos/cosmos-sdk/issues/2060) removed `--select` from `block` command - * [cli] [\#2128](https://github.com/cosmos/cosmos-sdk/issues/2128) fixed segfault when exporting directly after `gaiad init` - * [cli] [\#1255](https://github.com/cosmos/cosmos-sdk/issues/1255) open KeyBase in read-only mode - for query-purpose CLI commands - * [docs] Added commands for querying governance deposits, votes and tally - -* Gaia - * [x/stake] [#2023](https://github.com/cosmos/cosmos-sdk/pull/2023) Terminate iteration loop in `UpdateBondedValidators` and `UpdateBondedValidatorsFull` when the first revoked validator is encountered and perform a sanity check. - * [x/auth] Signature verification's gas cost now accounts for pubkey type. [#2046](https://github.com/tendermint/tendermint/pull/2046) - * [x/stake] [x/slashing] Ensure delegation invariants to jailed validators [#1883](https://github.com/cosmos/cosmos-sdk/issues/1883). - * [x/stake] Improve speed of GetValidator, which was shown to be a performance bottleneck. [#2046](https://github.com/tendermint/tendermint/pull/2200) - * [x/stake] [\#2435](https://github.com/cosmos/cosmos-sdk/issues/2435) Improve memory efficiency of getting the various store keys - * [genesis] [\#2229](https://github.com/cosmos/cosmos-sdk/issues/2229) Ensure that there are no duplicate accounts or validators in the genesis state. - * [genesis] [\#2450](https://github.com/cosmos/cosmos-sdk/issues/2450) Validate staking genesis parameters. - * Add SDK validation to `config.toml` (namely disabling `create_empty_blocks`) [\#1571](https://github.com/cosmos/cosmos-sdk/issues/1571) - * [\#1941](https://github.com/cosmos/cosmos-sdk/issues/1941)(https://github.com/cosmos/cosmos-sdk/issues/1941) Version is now inferred via `git describe --tags`. - * [x/distribution] [\#1671](https://github.com/cosmos/cosmos-sdk/issues/1671) add distribution types and tests - -* SDK - * [tools] Make get_vendor_deps deletes `.vendor-new` directories, in case scratch files are present. - * [spec] Added simple piggy bank distribution spec - * [cli] [\#1632](https://github.com/cosmos/cosmos-sdk/issues/1632) Add integration tests to ensure `basecoind init && basecoind` start sequences run successfully for both `democoin` and `basecoin` examples. - * [store] Speedup IAVL iteration, and consequently everything that requires IAVL iteration. [#2143](https://github.com/cosmos/cosmos-sdk/issues/2143) - * [store] [\#1952](https://github.com/cosmos/cosmos-sdk/issues/1952), [\#2281](https://github.com/cosmos/cosmos-sdk/issues/2281) Update IAVL dependency to v0.11.0 - * [simulation] Make timestamps randomized [#2153](https://github.com/cosmos/cosmos-sdk/pull/2153) - * [simulation] Make logs not just pure strings, speeding it up by a large factor at greater block heights [\#2282](https://github.com/cosmos/cosmos-sdk/issues/2282) - * [simulation] Add a concept of weighting the operations [\#2303](https://github.com/cosmos/cosmos-sdk/issues/2303) - * [simulation] Logs get written to file if large, and also get printed on panics [\#2285](https://github.com/cosmos/cosmos-sdk/issues/2285) - * [simulation] Bank simulations now makes testing auth configurable [\#2425](https://github.com/cosmos/cosmos-sdk/issues/2425) - * [gaiad] [\#1992](https://github.com/cosmos/cosmos-sdk/issues/1992) Add optional flag to `gaiad testnet` to make config directory of daemon (default `gaiad`) and cli (default `gaiacli`) configurable - * [x/stake] Add stake `Queriers` for Gaia-lite endpoints. This increases the staking endpoints performance by reusing the staking `keeper` logic for queries. [#2249](https://github.com/cosmos/cosmos-sdk/pull/2149) - * [store] [\#2017](https://github.com/cosmos/cosmos-sdk/issues/2017) Refactor - gas iterator gas consumption to only consume gas for iterator creation and `Next` - calls which includes dynamic consumption of value length. - * [types/decimal] [\#2378](https://github.com/cosmos/cosmos-sdk/issues/2378) - Added truncate functionality to decimal - * [client] [\#1184](https://github.com/cosmos/cosmos-sdk/issues/1184) Remove unused `client/tx/sign.go`. - * [tools] [\#2464](https://github.com/cosmos/cosmos-sdk/issues/2464) Lock binary dependencies to a specific version - * #2573 [x/distribution] add accum invariance - -BUG FIXES - -* Gaia CLI (`gaiacli`) - * [cli] [\#1997](https://github.com/cosmos/cosmos-sdk/issues/1997) Handle panics gracefully when `gaiacli stake {delegation,unbond}` fail to unmarshal delegation. - * [cli] [\#2265](https://github.com/cosmos/cosmos-sdk/issues/2265) Fix JSON formatting of the `gaiacli send` command. - * [cli] [\#2547](https://github.com/cosmos/cosmos-sdk/issues/2547) Mark --to and --amount as required flags for `gaiacli tx send`. - -* Gaia - * [x/stake] Return correct Tendermint validator update set on `EndBlocker` by not - including non previously bonded validators that have zero power. [#2189](https://github.com/cosmos/cosmos-sdk/issues/2189) - * [docs] Fixed light client section links - -* SDK - * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger) [#1988] (https://github.com/cosmos/cosmos-sdk/issues/1988) - * [\#2105](https://github.com/cosmos/cosmos-sdk/issues/2105) Fix DB Iterator leak, which may leak a go routine. - * [ledger] [\#2064](https://github.com/cosmos/cosmos-sdk/issues/2064) Fix inability to sign and send transactions via the LCD by - loading a Ledger device at runtime. - * [\#2158](https://github.com/cosmos/cosmos-sdk/issues/2158) Fix non-deterministic ordering of validator iteration when slashing in `gov EndBlocker` - * [simulation] [\#1924](https://github.com/cosmos/cosmos-sdk/issues/1924) Make simulation stop on SIGTERM - * [\#2388](https://github.com/cosmos/cosmos-sdk/issues/2388) Remove dependency on deprecated tendermint/tmlibs repository. - * [\#2416](https://github.com/cosmos/cosmos-sdk/issues/2416) Refactored `InitializeTestLCD` to properly include proposing validator in genesis state. - * #2573 [x/distribution] accum invariance bugfix - * #2573 [x/slashing] unbonding-delegation slashing invariance bugfix - -## 0.24.2 - -*August 22nd, 2018* - -BUG FIXES - -* Tendermint - - Fix unbounded consensus WAL growth - -## 0.24.1 - -*August 21st, 2018* - -BUG FIXES - -* Gaia - - [x/slashing] Evidence tracking now uses validator address instead of validator pubkey - -## 0.24.0 - -*August 13th, 2018* - -BREAKING CHANGES - -* Gaia REST API (`gaiacli advanced rest-server`) - - [x/stake] [\#1880](https://github.com/cosmos/cosmos-sdk/issues/1880) More REST-ful endpoints (large refactor) - - [x/slashing] [\#1866](https://github.com/cosmos/cosmos-sdk/issues/1866) `/slashing/signing_info` takes cosmosvalpub instead of cosmosvaladdr - - use time.Time instead of int64 for time. See Tendermint v0.23.0 - - Signatures are no longer Amino encoded with prefixes (just encoded as raw - bytes) - see Tendermint v0.23.0 - -* Gaia CLI (`gaiacli`) - - [x/stake] change `--keybase-sig` to `--identity` - - [x/stake] [\#1828](https://github.com/cosmos/cosmos-sdk/issues/1828) Force user to specify amount on create-validator command by removing default - - [x/gov] Change `--proposalID` to `--proposal-id` - - [x/stake, x/gov] [\#1606](https://github.com/cosmos/cosmos-sdk/issues/1606) Use `--from` instead of adhoc flags like `--address-validator` - and `--proposer` to indicate the sender address. - - [\#1551](https://github.com/cosmos/cosmos-sdk/issues/1551) Remove `--name` completely - - Genesis/key creation (`gaiad init`) now supports user-provided key passwords - -* Gaia - - [x/stake] Inflation doesn't use rationals in calculation (performance boost) - - [x/stake] Persist a map from `addr->pubkey` in the state since BeginBlock - doesn't provide pubkeys. - - [x/gov] [\#1781](https://github.com/cosmos/cosmos-sdk/issues/1781) Added tags sub-package, changed tags to use dash-case - - [x/gov] [\#1688](https://github.com/cosmos/cosmos-sdk/issues/1688) Governance parameters are now stored in globalparams store - - [x/gov] [\#1859](https://github.com/cosmos/cosmos-sdk/issues/1859) Slash validators who do not vote on a proposal - - [x/gov] [\#1914](https://github.com/cosmos/cosmos-sdk/issues/1914) added TallyResult type that gets stored in Proposal after tallying is finished - -* SDK - - [baseapp] Msgs are no longer run on CheckTx, removed `ctx.IsCheckTx()` - - [baseapp] NewBaseApp constructor takes sdk.TxDecoder as argument instead of wire.Codec - - [types] sdk.NewCoin takes sdk.Int, sdk.NewInt64Coin takes int64 - - [x/auth] Default TxDecoder can be found in `x/auth` rather than baseapp - - [client] [\#1551](https://github.com/cosmos/cosmos-sdk/issues/1551): Refactored `CoreContext` to `TxContext` and `QueryContext` - - Removed all tx related fields and logic (building & signing) to separate - structure `TxContext` in `x/auth/client/context` - -* Tendermint - - v0.22.5 -> See [Tendermint PR](https://github.com/tendermint/tendermint/pull/1966) - - change all the cryptography imports. - - v0.23.0 -> See - [Changelog](https://github.com/tendermint/tendermint/blob/v0.23.0/CHANGELOG.md#0230) - and [SDK PR](https://github.com/cosmos/cosmos-sdk/pull/1927) - - BeginBlock no longer includes crypto.Pubkey - - use time.Time instead of int64 for time. - -FEATURES - -* Gaia REST API (`gaiacli advanced rest-server`) - - [x/gov] Can now query governance proposals by ProposalStatus - -* Gaia CLI (`gaiacli`) - - [x/gov] added `query-proposals` command. Can filter by `depositer`, `voter`, and `status` - - [x/stake] [\#2043](https://github.com/cosmos/cosmos-sdk/issues/2043) Added staking query cli cmds for unbonding-delegations and redelegations - -* Gaia - - [networks] Added ansible scripts to upgrade seed nodes on a network - -* SDK - - [x/mock/simulation] Randomized simulation framework - - Modules specify invariants and operations, preferably in an x/[module]/simulation package - - Modules can test random combinations of their own operations - - Applications can integrate operations and invariants from modules together for an integrated simulation - - Simulates Tendermint's algorithm for validator set updates - - Simulates validator signing/downtime with a Markov chain, and occaisional double-signatures - - Includes simulated operations & invariants for staking, slashing, governance, and bank modules - - [store] [\#1481](https://github.com/cosmos/cosmos-sdk/issues/1481) Add transient store - - [baseapp] Initialize validator set on ResponseInitChain - - [baseapp] added BaseApp.Seal - ability to seal baseapp parameters once they've been set - - [cosmos-sdk-cli] New `cosmos-sdk-cli` tool to quickly initialize a new - SDK-based project - - [scripts] added log output monitoring to DataDog using Ansible scripts - -IMPROVEMENTS - -* Gaia - - [spec] [\#967](https://github.com/cosmos/cosmos-sdk/issues/967) Inflation and distribution specs drastically improved - - [x/gov] [\#1773](https://github.com/cosmos/cosmos-sdk/issues/1773) Votes on a proposal can now be queried - - [x/gov] Initial governance parameters can now be set in the genesis file - - [x/stake] [\#1815](https://github.com/cosmos/cosmos-sdk/issues/1815) Sped up the processing of `EditValidator` txs. - - [config] [\#1930](https://github.com/cosmos/cosmos-sdk/issues/1930) Transactions indexer indexes all tags by default. - - [ci] [#2057](https://github.com/cosmos/cosmos-sdk/pull/2057) Run `make localnet-start` on every commit and ensure network reaches at least 10 blocks - -* SDK - - [baseapp] [\#1587](https://github.com/cosmos/cosmos-sdk/issues/1587) Allow any alphanumeric character in route - - [baseapp] Allow any alphanumeric character in route - - [tools] Remove `rm -rf vendor/` from `make get_vendor_deps` - - [x/auth] Recover ErrorOutOfGas panic in order to set sdk.Result attributes correctly - - [x/auth] [\#2376](https://github.com/cosmos/cosmos-sdk/issues/2376) No longer runs any signature in a multi-msg, if any account/sequence number is wrong. - - [x/auth] [\#2376](https://github.com/cosmos/cosmos-sdk/issues/2376) No longer charge gas for subtracting fees - - [x/bank] Unit tests are now table-driven - - [tests] Add tests to example apps in docs - - [tests] Fixes ansible scripts to work with AWS too - - [tests] [\#1806](https://github.com/cosmos/cosmos-sdk/issues/1806) CLI tests are now behind the build flag 'cli_test', so go test works on a new repo - -BUG FIXES - -* Gaia CLI (`gaiacli`) - - [\#1766](https://github.com/cosmos/cosmos-sdk/issues/1766) Fixes bad example for keybase identity - - [x/stake] [\#2021](https://github.com/cosmos/cosmos-sdk/issues/2021) Fixed repeated CLI commands in staking - -* Gaia - - [x/stake] [#2077](https://github.com/cosmos/cosmos-sdk/pull/2077) Fixed invalid cliff power comparison - - [\#1804](https://github.com/cosmos/cosmos-sdk/issues/1804) Fixes gen-tx genesis generation logic temporarily until upstream updates - - [\#1799](https://github.com/cosmos/cosmos-sdk/issues/1799) Fix `gaiad export` - - [\#1839](https://github.com/cosmos/cosmos-sdk/issues/1839) Fixed bug where intra-tx counter wasn't set correctly for genesis validators - - [x/stake] [\#1858](https://github.com/cosmos/cosmos-sdk/issues/1858) Fixed bug where the cliff validator was not updated correctly - - [tests] [\#1675](https://github.com/cosmos/cosmos-sdk/issues/1675) Fix non-deterministic `test_cover` - - [tests] [\#1551](https://github.com/cosmos/cosmos-sdk/issues/1551) Fixed invalid LCD test JSON payload in `doIBCTransfer` - - [basecoin] Fixes coin transaction failure and account query [discussion](https://forum.cosmos.network/t/unmarshalbinarybare-expected-to-read-prefix-bytes-75fbfab8-since-it-is-registered-concrete-but-got-0a141dfa/664/6) - - [x/gov] [\#1757](https://github.com/cosmos/cosmos-sdk/issues/1757) Fix VoteOption conversion to String - * [x/stake] [#2083] Fix broken invariant of bonded validator power decrease - -## 0.23.1 - -*July 27th, 2018* - -BUG FIXES - * [tendermint] Update to v0.22.8 - - [consensus, blockchain] Register the Evidence interface so it can be - marshalled/unmarshalled by the blockchain and consensus reactors - -## 0.23.0 - -*July 25th, 2018* - -BREAKING CHANGES -* [x/stake] Fixed the period check for the inflation calculation - -IMPROVEMENTS -* [cli] Improve error messages for all txs when the account doesn't exist -* [tendermint] Update to v0.22.6 - - Updates the crypto imports/API (#1966) -* [x/stake] Add revoked to human-readable validator - -BUG FIXES -* [tendermint] Update to v0.22.6 - - Fixes some security vulnerabilities reported in the [Bug Bounty](https://hackerone.com/tendermint) -* [\#1797](https://github.com/cosmos/cosmos-sdk/issues/1797) Fix off-by-one error in slashing for downtime -* [\#1787](https://github.com/cosmos/cosmos-sdk/issues/1787) Fixed bug where Tally fails due to revoked/unbonding validator -* [\#1666](https://github.com/cosmos/cosmos-sdk/issues/1666) Add intra-tx counter to the genesis validators - -## 0.22.0 - -*July 16th, 2018* - -BREAKING CHANGES -* [x/gov] Increase VotingPeriod, DepositPeriod, and MinDeposit - -IMPROVEMENTS -* [gaiad] Default config updates: - - `timeout_commit=5000` so blocks only made every 5s - - `prof_listen_addr=localhost:6060` so profile server is on by default - - `p2p.send_rate` and `p2p.recv_rate` increases 10x (~5MB/s) - -BUG FIXES -* [server] Fix to actually overwrite default tendermint config - -## 0.21.1 - -*July 14th, 2018* - -BUG FIXES -* [build] Added Ledger build support via `LEDGER_ENABLED=true|false` - * True by default except when cross-compiling - -## 0.21.0 - -*July 13th, 2018* - -BREAKING CHANGES -* [x/stake] Specify DelegatorAddress in MsgCreateValidator -* [x/stake] Remove the use of global shares in the pool - * Remove the use of `PoolShares` type in `x/stake/validator` type - replace with `Status` `Tokens` fields -* [x/auth] NewAccountMapper takes a constructor instead of a prototype -* [keys] Keybase.Update function now takes in a function to get the newpass, rather than the password itself - -FEATURES -* [baseapp] NewBaseApp now takes option functions as parameters - -IMPROVEMENTS -* Updated docs folder to accommodate cosmos.network docs project -* [store] Added support for tracing multi-store operations via `--trace-store` -* [store] Pruning strategy configurable with pruning flag on gaiad start - -BUG FIXES -* [\#1630](https://github.com/cosmos/cosmos-sdk/issues/1630) - redelegation nolonger removes tokens from the delegator liquid account -* [keys] [\#1629](https://github.com/cosmos/cosmos-sdk/issues/1629) - updating password no longer asks for a new password when the first entered password was incorrect -* [lcd] importing an account would create a random account -* [server] 'gaiad init' command family now writes provided name as the moniker in `config.toml` -* [build] Added Ledger build support via `LEDGER_ENABLED=true|false` - * True by default except when cross-compiling - -## 0.20.0 - -*July 10th, 2018* - -BREAKING CHANGES -* msg.GetSignBytes() returns sorted JSON (by key) -* msg.GetSignBytes() field changes - * `msg_bytes` -> `msgs` - * `fee_bytes` -> `fee` -* Update Tendermint to v0.22.2 - * Default ports changed from 466xx to 266xx - * Amino JSON uses type names instead of prefix bytes - * ED25519 addresses are the first 20-bytes of the SHA256 of the raw 32-byte - pubkey (Instead of RIPEMD160) - * go-crypto, abci, tmlibs have been merged into Tendermint - * The keys sub-module is now in the SDK - * Various other fixes -* [auth] Signers of a transaction now only sign over their own account and sequence number -* [auth] Removed MsgChangePubKey -* [auth] Removed SetPubKey from account mapper -* [auth] AltBytes renamed to Memo, now a string, max 100 characters, costs a bit of gas -* [types] `GetMsg()` -> `GetMsgs()` as txs wrap many messages -* [types] Removed GetMemo from Tx (it is still on StdTx) -* [types] renamed rational.Evaluate to rational.Round{Int64, Int} -* [types] Renamed `sdk.Address` to `sdk.AccAddress`/`sdk.ValAddress` -* [types] `sdk.AccAddress`/`sdk.ValAddress` natively marshals to Bech32 in String, Sprintf (when used with `%s`), and MarshalJSON -* [keys] Keybase and Ledger support from go-crypto merged into the SDK in the `crypto` folder -* [cli] Rearranged commands under subcommands -* [x/slashing] Update slashing for unbonding period - * Slash according to power at time of infraction instead of power at - time of discovery - * Iterate through unbonding delegations & redelegations which contributed - to an infraction, slash them proportional to their stake at the time - * Add REST endpoint to unrevoke a validator previously revoked for downtime - * Add REST endpoint to retrieve liveness signing information for a validator -* [x/stake] Remove Tick and add EndBlocker -* [x/stake] most index keys nolonger hold a value - inputs are rearranged to form the desired key -* [x/stake] store-value for delegation, validator, ubd, and red do not hold duplicate information contained store-key -* [x/stake] Introduce concept of unbonding for delegations and validators - * `gaiacli stake unbond` replaced with `gaiacli stake begin-unbonding` - * Introduced: - * `gaiacli stake complete-unbonding` - * `gaiacli stake begin-redelegation` - * `gaiacli stake complete-redelegation` -* [lcd] Switch key creation output to return bech32 -* [lcd] Removed shorthand CLI flags (`a`, `c`, `n`, `o`) -* [gaiad] genesis transactions now use bech32 addresses / pubkeys -* [gov] VoteStatus renamed to ProposalStatus -* [gov] VoteOption, ProposalType, and ProposalStatus all marshal to string form in JSON - -DEPRECATED -* [cli] Deprecated `--name` flag in commands that send txs, in favor of `--from` - -FEATURES -* [x/gov] Implemented MVP - * Supported proposal types: just binary (pass/fail) TextProposals for now - * Proposals need deposits to be votable; deposits are burned if proposal fails - * Delegators delegate votes to validator by default but can override (for their stake) -* [gaiacli] Ledger support added - - You can now use a Ledger with `gaiacli --ledger` for all key-related commands - - Ledger keys can be named and tracked locally in the key DB -* [gaiacli] You can now attach a simple text-only memo to any transaction, with the `--memo` flag -* [gaiacli] added the following flags for commands that post transactions to the chain: - * async -- send the tx without waiting for a tendermint response - * json -- return the output in json format for increased readability - * print-response -- return the tx response. (includes fields like gas cost) -* [lcd] Queried TXs now include the tx hash to identify each tx -* [mockapp] CompleteSetup() no longer takes a testing parameter -* [x/bank] Add benchmarks for signing and delivering a block with a single bank transaction - * Run with `cd x/bank && go test --bench=.` -* [tools] make get_tools installs tendermint's linter, and gometalinter -* [tools] Switch gometalinter to the stable version -* [tools] Add the following linters - * misspell - * gofmt - * go vet -composites=false - * unconvert - * ineffassign - * errcheck - * unparam - * gocyclo -* [tools] Added `make format` command to automate fixing misspell and gofmt errors. -* [server] Default config now creates a profiler at port 6060, and increase p2p send/recv rates -* [types] Switches internal representation of Int/Uint/Rat to use pointers -* [types] Added MinInt and MinUint functions -* [gaiad] `unsafe_reset_all` now resets addrbook.json -* [democoin] add x/oracle, x/assoc -* [tests] created a randomized testing framework. - - Currently bank has limited functionality in the framework - - Auth has its invariants checked within the framework -* [tests] Add WaitForNextNBlocksTM helper method -* [keys] New keys now have 24 word recovery keys, for heightened security -- [keys] Add a temporary method for exporting the private key - -IMPROVEMENTS -* [x/bank] Now uses go-wire codec instead of 'encoding/json' -* [x/auth] Now uses go-wire codec instead of 'encoding/json' -* revised use of endblock and beginblock -* [stake] module reorganized to include `types` and `keeper` package -* [stake] keeper always loads the store (instead passing around which doesn't really boost efficiency) -* [stake] edit-validator changes now can use the keyword [do-not-modify] to not modify unspecified `--flag` (aka won't set them to `""` value) -* [stake] offload more generic functionality from the handler into the keeper -* [stake] clearer staking logic -* [types] added common tag constants -* [keys] improve error message when deleting non-existent key -* [gaiacli] improve error messages on `send` and `account` commands -* added contributing guidelines -* [docs] Added commands for governance CLI on testnet README - -BUG FIXES -* [x/slashing] [\#1510](https://github.com/cosmos/cosmos-sdk/issues/1510) Unrevoked validators cannot un-revoke themselves -* [x/stake] [\#1513](https://github.com/cosmos/cosmos-sdk/issues/1513) Validators slashed to zero power are unbonded and removed from the store -* [x/stake] [\#1567](https://github.com/cosmos/cosmos-sdk/issues/1567) Validators decreased in power but not unbonded are now updated in Tendermint -* [x/stake] error strings lower case -* [x/stake] pool loose tokens now accounts for unbonding and unbonding tokens not associated with any validator -* [x/stake] fix revoke bytes ordering (was putting revoked candidates at the top of the list) -* [x/stake] bond count was counting revoked validators as bonded, fixed -* [gaia] Added self delegation for validators in the genesis creation -* [lcd] tests now don't depend on raw json text -* Retry on HTTP request failure in CLI tests, add option to retry tests in Makefile -* Fixed bug where chain ID wasn't passed properly in x/bank REST handler, removed Viper hack from ante handler -* Fixed bug where `democli account` didn't decode the account data correctly -* [\#872](https://github.com/cosmos/cosmos-sdk/issues/872) - recovery phrases no longer all end in `abandon` -* [\#887](https://github.com/cosmos/cosmos-sdk/issues/887) - limit the size of rationals that can be passed in from user input -* [\#1052](https://github.com/cosmos/cosmos-sdk/issues/1052) - Make all now works -* [\#1258](https://github.com/cosmos/cosmos-sdk/issues/1258) - printing big.rat's can no longer overflow int64 -* [\#1259](https://github.com/cosmos/cosmos-sdk/issues/1259) - fix bug where certain tests that could have a nil pointer in defer -* [\#1343](https://github.com/cosmos/cosmos-sdk/issues/1343) - fixed unnecessary parallelism in CI -* [\#1353](https://github.com/cosmos/cosmos-sdk/issues/1353) - CLI: Show pool shares fractions in human-readable format -* [\#1367](https://github.com/cosmos/cosmos-sdk/issues/1367) - set ChainID in InitChain -* [\#1461](https://github.com/cosmos/cosmos-sdk/issues/1461) - CLI tests now no longer reset your local environment data -* [\#1505](https://github.com/cosmos/cosmos-sdk/issues/1505) - `gaiacli stake validator` no longer panics if validator doesn't exist -* [\#1565](https://github.com/cosmos/cosmos-sdk/issues/1565) - fix cliff validator persisting when validator set shrinks from max -* [\#1287](https://github.com/cosmos/cosmos-sdk/issues/1287) - prevent zero power validators at genesis -* [x/stake] fix bug when unbonding/redelegating using `--shares-percent` -* [\#1010](https://github.com/cosmos/cosmos-sdk/issues/1010) - two validators can't bond with the same pubkey anymore - - -## 0.19.0 - -*June 13, 2018* - -BREAKING CHANGES -* msg.GetSignBytes() now returns bech32-encoded addresses in all cases -* [lcd] REST end-points now include gas -* sdk.Coin now uses sdk.Int, a big.Int wrapper with 256bit range cap - -FEATURES -* [x/auth] Added AccountNumbers to BaseAccount and StdTxs to allow for replay protection with account pruning -* [lcd] added an endpoint to query for the SDK version of the connected node - -IMPROVEMENTS -* export command now writes current validator set for Tendermint -* [tests] Application module tests now use a mock application -* [gaiacli] Fix error message when account isn't found when running gaiacli account -* [lcd] refactored to eliminate use of global variables, and interdependent tests -* [tests] Added testnet command to gaiad -* [tests] Added localnet targets to Makefile -* [x/stake] More stake tests added to test ByPower index - -FIXES -* Fixes consensus fault on testnet - see postmortem [here](https://github.com/cosmos/cosmos-sdk/issues/1197#issuecomment-396823021) -* [x/stake] bonded inflation removed, non-bonded inflation partially implemented -* [lcd] Switch to bech32 for addresses on all human readable inputs and outputs -* [lcd] fixed tx indexing/querying -* [cli] Added `--gas` flag to specify transaction gas limit -* [gaia] Registered slashing message handler -* [x/slashing] Set signInfo.StartHeight correctly for newly bonded validators - -FEATURES -* [docs] Reorganize documentation -* [docs] Update staking spec, create WIP spec for slashing, and fees - -## 0.18.0 - -*June 9, 2018* - -BREAKING CHANGES - -* [stake] candidate -> validator throughout (details in refactor comment) -* [stake] delegate-bond -> delegation throughout -* [stake] `gaiacli query validator` takes and argument instead of using the `--address-candidate` flag -* [stake] introduce `gaiacli query delegations` -* [stake] staking refactor - * ValidatorsBonded store now take sorted pubKey-address instead of validator owner-address, - is sorted like Tendermint by pk's address - * store names more understandable - * removed temporary ToKick store, just needs a local map! - * removed distinction between candidates and validators - * everything is now a validator - * only validators with a status == bonded are actively validating/receiving rewards - * Introduction of Unbonding fields, lowlevel logic throughout (not fully implemented with queue) - * Introduction of PoolShares type within validators, - replaces three rational fields (BondedShares, UnbondingShares, UnbondedShares -* [x/auth] move stuff specific to auth anteHandler to the auth module rather than the types folder. This includes: - * StdTx (and its related stuff i.e. StdSignDoc, etc) - * StdFee - * StdSignature - * Account interface - * Related to this organization, I also: -* [x/auth] got rid of AccountMapper interface (in favor of the struct already in auth module) -* [x/auth] removed the FeeHandler function from the AnteHandler, Replaced with FeeKeeper -* [x/auth] Removed GetSignatures() from Tx interface (as different Tx styles might use something different than StdSignature) -* [store] Removed SubspaceIterator and ReverseSubspaceIterator from KVStore interface and replaced them with helper functions in /types -* [cli] rearranged commands under subcommands -* [stake] remove Tick and add EndBlocker -* Switch to bech32cosmos on all human readable inputs and outputs - - -FEATURES - -* [x/auth] Added ability to change pubkey to auth module -* [baseapp] baseapp now has settable functions for filtering peers by address/port & public key -* [sdk] Gas consumption is now measured as transactions are executed - * Transactions which run out of gas stop execution and revert state changes - * A "simulate" query has been added to determine how much gas a transaction will need - * Modules can include their own gas costs for execution of particular message types -* [stake] Seperation of fee distribution to a new module -* [stake] Creation of a validator/delegation generics in `/types` -* [stake] Helper Description of the store in x/stake/store.md -* [stake] removed use of caches in the stake keeper -* [stake] Added REST API -* [Makefile] Added terraform/ansible playbooks to easily create remote testnets on Digital Ocean - - -BUG FIXES - -* [stake] staking delegator shares exchange rate now relative to equivalent-bonded-tokens the validator has instead of bonded tokens - ^ this is important for unbonded validators in the power store! -* [cli] fixed cli-bash tests -* [ci] added cli-bash tests -* [basecoin] updated basecoin for stake and slashing -* [docs] fixed references to old cli commands -* [docs] Downgraded Swagger to v2 for downstream compatibility -* auto-sequencing transactions correctly -* query sequence via account store -* fixed duplicate pub_key in stake.Validator -* Auto-sequencing now works correctly -* [gaiacli] Fix error message when account isn't found when running gaiacli account - - -## 0.17.5 - -*June 5, 2018* - -Update to Tendermint v0.19.9 (Fix evidence reactor, mempool deadlock, WAL panic, -memory leak) - -## 0.17.4 - -*May 31, 2018* - -Update to Tendermint v0.19.7 (WAL fixes and more) - -## 0.17.3 - -*May 29, 2018* - -Update to Tendermint v0.19.6 (fix fast-sync halt) - -## 0.17.5 - -*June 5, 2018* - -Update to Tendermint v0.19.9 (Fix evidence reactor, mempool deadlock, WAL panic, -memory leak) - -## 0.17.4 - -*May 31, 2018* - -Update to Tendermint v0.19.7 (WAL fixes and more) - -## 0.17.3 - -*May 29, 2018* - -Update to Tendermint v0.19.6 (fix fast-sync halt) - -## 0.17.2 - -_May 20, 2018_ - -Update to Tendermint v0.19.5 (reduce WAL use, bound the mempool and some rpcs, improve logging) - -## 0.17.1 (May 17, 2018) - -Update to Tendermint v0.19.4 (fixes a consensus bug and improves logging) - -## 0.17.0 (May 15, 2018) - -BREAKING CHANGES - -* [stake] MarshalJSON -> MarshalBinaryLengthPrefixed -* Queries against the store must be prefixed with the path "/store" - -FEATURES - -* [gaiacli] Support queries for candidates, delegator-bonds -* [gaiad] Added `gaiad export` command to export current state to JSON -* [x/bank] Tx tags with sender/recipient for indexing & later retrieval -* [x/stake] Tx tags with delegator/candidate for delegation & unbonding, and candidate info for declare candidate / edit validator - -IMPROVEMENTS - -* [gaiad] Update for Tendermint v0.19.3 (improve `/dump_consensus_state` and add - `/consensus_state`) -* [spec/ibc] Added spec! -* [spec/stake] Cleanup structure, include details about slashing and - auto-unbonding -* [spec/governance] Fixup some names and pseudocode -* NOTE: specs are still a work-in-progress ... - -BUG FIXES - -* Auto-sequencing now works correctly - - -## 0.16.0 (May 14th, 2018) - -BREAKING CHANGES - -* Move module REST/CLI packages to x/[module]/client/rest and x/[module]/client/cli -* Gaia simple-staking bond and unbond functions replaced -* [stake] Delegator bonds now store the height at which they were updated -* All module keepers now require a codespace, see basecoin or democoin for usage -* Many changes to names throughout - * Type as a prefix naming convention applied (ex. BondMsg -> MsgBond) - * Removed redundancy in names (ex. stake.StakingKeeper -> stake.Keeper) -* Removed SealedAccountMapper -* gaiad init now requires use of `--name` flag -* Removed Get from Msg interface -* types/rational now extends big.Rat - -FEATURES: - -* Gaia stake commands include, CreateValidator, EditValidator, Delegate, Unbond -* MountStoreWithDB without providing a custom store works. -* Repo is now lint compliant / GoMetaLinter with tendermint-lint integrated into CI -* Better key output, pubkey go-amino hex bytes now output by default -* gaiad init overhaul - * Create genesis transactions with `gaiad init gen-tx` - * New genesis account keys are automatically added to the client keybase (introduce `--client-home` flag) - * Initialize with genesis txs using `--gen-txs` flag -* Context now has access to the application-configured logger -* Add (non-proof) subspace query helper functions -* Add more staking query functions: candidates, delegator-bonds - -BUG FIXES - -* Gaia now uses stake, ported from github.com/cosmos/gaia - - -## 0.15.1 (April 29, 2018) - -IMPROVEMENTS: - -* Update Tendermint to v0.19.1 (includes many rpc fixes) - - -## 0.15.0 (April 29, 2018) - -NOTE: v0.15.0 is a large breaking change that updates the encoding scheme to use -[Amino](github.com/tendermint/go-amino). - -For details on how this changes encoding for public keys and addresses, -see the [docs](https://github.com/tendermint/tendermint/blob/v0.19.1/docs/specification/new-spec/encoding.md#public-key-cryptography). - -BREAKING CHANGES - -* Remove go-wire, use go-amino -* [store] Add `SubspaceIterator` and `ReverseSubspaceIterator` to `KVStore` interface -* [basecoin] NewBasecoinApp takes a `dbm.DB` and uses namespaced DBs for substores - -FEATURES: - -* Add CacheContext -* Add auto sequencing to client -* Add FeeHandler to ante handler - -BUG FIXES - -* MountStoreWithDB without providing a custom store works. - -## 0.14.1 (April 9, 2018) - -BUG FIXES - -* [gaiacli] Fix all commands (just a duplicate of basecli for now) - -## 0.14.0 (April 9, 2018) - -BREAKING CHANGES: - -* [client/builder] Renamed to `client/core` and refactored to use a CoreContext - struct -* [server] Refactor to improve useability and de-duplicate code -* [types] `Result.ToQuery -> Error.QueryResult` -* [makefile] `make build` and `make install` only build/install `gaiacli` and - `gaiad`. Use `make build_examples` and `make install_examples` for - `basecoind/basecli` and `democoind/democli` -* [staking] Various fixes/improvements - -FEATURES: - -* [democoin] Added Proof-of-Work module - -BUG FIXES - -* [client] Reuse Tendermint RPC client to avoid excessive open files -* [client] Fix setting log level -* [basecoin] Sort coins in genesis - -## 0.13.1 (April 3, 2018) - -BUG FIXES - -* [x/ibc] Fix CLI and relay for IBC txs -* [x/stake] Various fixes/improvements - -## 0.13.0 (April 2, 2018) - -BREAKING CHANGES - -* [basecoin] Remove cool/sketchy modules -> moved to new `democoin` -* [basecoin] NewBasecoinApp takes a `map[string]dbm.DB` as temporary measure - to allow mounting multiple stores with their own DB until they can share one -* [x/staking] Renamed to `simplestake` -* [builder] Functions don't take `passphrase` as argument -* [server] GenAppParams returns generated seed and address -* [basecoind] `init` command outputs JSON of everything necessary for testnet -* [basecoind] `basecoin.db -> data/basecoin.db` -* [basecli] `data/keys.db -> keys/keys.db` - -FEATURES - -* [types] `Coin` supports direct arithmetic operations -* [basecoind] Add `show_validator` and `show_node_id` commands -* [x/stake] Initial merge of full staking module! -* [democoin] New example application to demo custom modules - -IMPROVEMENTS - -* [makefile] `make install` -* [testing] Use `/tmp` for directories so they don't get left in the repo - -BUG FIXES - -* [basecoin] Allow app to be restarted -* [makefile] Fix build on Windows -* [basecli] Get confirmation before overriding key with same name - -## 0.12.0 (March 27 2018) - -BREAKING CHANGES - -* Revert to old go-wire for now -* glide -> godep -* [types] ErrBadNonce -> ErrInvalidSequence -* [types] Replace tx.GetFeePayer with FeePayer(tx) - returns the first signer -* [types] NewStdTx takes the Fee -* [types] ParseAccount -> AccountDecoder; ErrTxParse -> ErrTxDecoder -* [x/auth] AnteHandler deducts fees -* [x/bank] Move some errors to `types` -* [x/bank] Remove sequence and signature from Input - -FEATURES - -* [examples/basecoin] New cool module to demonstrate use of state and custom transactions -* [basecoind] `show_node_id` command -* [lcd] Implement the Light Client Daemon and endpoints -* [types/stdlib] Queue functionality -* [store] Subspace iterator on IAVLTree -* [types] StdSignDoc is the document that gets signed (chainid, msg, sequence, fee) -* [types] CodeInvalidPubKey -* [types] StdFee, and StdTx takes the StdFee -* [specs] Progression of MVPs for IBC -* [x/ibc] Initial shell of IBC functionality (no proofs) -* [x/simplestake] Simple staking module with bonding/unbonding - -IMPROVEMENTS - -* Lots more tests! -* [client/builder] Helpers for forming and signing transactions -* [types] sdk.Address -* [specs] Staking - -BUG FIXES - -* [x/auth] Fix setting pubkey on new account -* [x/auth] Require signatures to include the sequences -* [baseapp] Dont panic on nil handler -* [basecoin] Check for empty bytes in account and tx - -## 0.11.0 (March 1, 2017) - -BREAKING CHANGES - -* [examples] dummy -> kvstore -* [examples] Remove gaia -* [examples/basecoin] MakeTxCodec -> MakeCodec -* [types] CommitMultiStore interface has new `GetCommitKVStore(key StoreKey) CommitKVStore` method - -FEATURES - -* [examples/basecoin] CLI for `basecli` and `basecoind` (!) -* [baseapp] router.AddRoute returns Router - -IMPROVEMENTS - -* [baseapp] Run msg handlers on CheckTx -* [docs] Add spec for REST API -* [all] More tests! - -BUG FIXES - -* [baseapp] Fix panic on app restart -* [baseapp] InitChain does not call Commit -* [basecoin] Remove IBCStore because mounting multiple stores is currently broken - -## 0.10.0 (February 20, 2017) - -BREAKING CHANGES - -* [baseapp] NewBaseApp(logger, db) -* [baseapp] NewContext(isCheckTx, header) -* [x/bank] CoinMapper -> CoinKeeper - -FEATURES - -* [examples/gaia] Mock CLI ! -* [baseapp] InitChainer, BeginBlocker, EndBlocker -* [baseapp] MountStoresIAVL - -IMPROVEMENTS - -* [docs] Various improvements. -* [basecoin] Much simpler :) - -BUG FIXES - -* [baseapp] initialize and reset msCheck and msDeliver properly - -## 0.9.0 (February 13, 2017) - -BREAKING CHANGES - -* Massive refactor. Basecoin works. Still needs <3 - -## 0.8.1 - -* Updates for dependencies - -## 0.8.0 (December 18, 2017) - -* Updates for dependencies - -## 0.7.1 (October 11, 2017) - -IMPROVEMENTS: - -* server/commands: GetInitCmd takes list of options - -## 0.7.0 (October 11, 2017) - -BREAKING CHANGES: - -* Everything has changed, and it's all about to change again, so don't bother using it yet! - -## 0.6.2 (July 27, 2017) - -IMPROVEMENTS: - -* auto-test all tutorials to detect breaking changes -* move deployment scripts from `/scripts` to `/publish` for clarity - -BUG FIXES: - -* `basecoin init` ensures the address in genesis.json is valid -* fix bug that certain addresses couldn't receive ibc packets - -## 0.6.1 (June 28, 2017) - -Make lots of small cli fixes that arose when people were using the tools for -the testnet. - -IMPROVEMENTS: - -* basecoin - * `basecoin start` supports all flags that `tendermint node` does, such as - `--rpc.laddr`, `--p2p.seeds`, and `--p2p.skip_upnp` - * fully supports `--log_level` and `--trace` for logger configuration - * merkleeyes no longers spams the logs... unless you want it - * Example: `basecoin start --log_level="merkleeyes:info,state:info,*:error"` - * Example: `basecoin start --log_level="merkleeyes:debug,state:info,*:error"` -* basecli - * `basecli init` is more intelligent and only complains if there really was - a connected chain, not just random files - * support `localhost:46657` or `http://localhost:46657` format for nodes, - not just `tcp://localhost:46657` - * Add `--genesis` to init to specify chain-id and validator hash - * Example: `basecli init --node=localhost:46657 --genesis=$HOME/.basecoin/genesis.json` - * `basecli rpc` has a number of methods to easily accept tendermint rpc, and verifies what it can - -BUG FIXES: - -* basecli - * `basecli query account` accepts hex account address with or without `0x` - prefix - * gives error message when running commands on an unitialized chain, rather - than some unintelligable panic - -## 0.6.0 (June 22, 2017) - -Make the basecli command the only way to use client-side, to enforce best -security practices. Lots of enhancements to get it up to production quality. - -BREAKING CHANGES: - -* ./cmd/commands -> ./cmd/basecoin/commands -* basecli - * `basecli proof state get` -> `basecli query key` - * `basecli proof tx get` -> `basecli query tx` - * `basecli proof state get --app=account` -> `basecli query account` - * use `--chain-id` not `--chainid` for consistency - * update to use `--trace` not `--debug` for stack traces on errors - * complete overhaul on how tx and query subcommands are added. (see counter or trackomatron for examples) - * no longer supports counter app (see new countercli) -* basecoin - * `basecoin init` takes an argument, an address to allocate funds to in the genesis - * removed key2.json - * removed all client side functionality from it (use basecli now for proofs) - * no tx subcommand - * no query subcommand - * no account (query) subcommand - * a few other random ones... - * enhanced relay subcommand - * relay start did what relay used to do - * relay init registers both chains on one another (to set it up so relay start just works) -* docs - * removed `example-plugin`, put `counter` inside `docs/guide` -* app - * Implements ABCI handshake by proxying merkleeyes.Info() - -IMPROVEMENTS: - -* `basecoin init` support `--chain-id` -* intergrates tendermint 0.10.0 (not the rc-2, but the real thing) -* commands return error code (1) on failure for easier script testing -* add `reset_all` to basecli, and never delete keys on `init` -* new shutil based unit tests, with better coverage of the cli actions -* just `make fresh` when things are getting stale ;) - -BUG FIXES: - -* app: no longer panics on missing app_options in genesis (thanks, anton) -* docs: updated all docs... again -* ibc: fix panic on getting BlockID from commit without 100% precommits (still a TODO) - -## 0.5.2 (June 2, 2017) - -BUG FIXES: - -* fix parsing of the log level from Tendermint config (#97) - -## 0.5.1 (May 30, 2017) - -BUG FIXES: - -* fix ibc demo app to use proper tendermint flags, 0.10.0-rc2 compatibility -* Make sure all cli uses new json.Marshal not wire.JSONBytes - -## 0.5.0 (May 27, 2017) - -BREAKING CHANGES: - -* only those related to the tendermint 0.9 -> 0.10 upgrade - -IMPROVEMENTS: - -* basecoin cli - * integrates tendermint 0.10.0 and unifies cli (init, unsafe_reset_all, ...) - * integrate viper, all command line flags can also be defined in environmental variables or config.toml -* genesis file - * you can define accounts with either address or pub_key - * sorts coins for you, so no silent errors if not in alphabetical order -* [light-client](https://github.com/tendermint/light-client) integration - * no longer must you trust the node you connect to, prove everything! - * new [basecli command](./cmd/basecli/README.md) - * integrated [key management](https://github.com/tendermint/go-crypto/blob/master/cmd/README.md), stored encrypted locally - * tracks validator set changes and proves everything from one initial validator seed - * `basecli proof state` gets complete proofs for any abci state - * `basecli proof tx` gets complete proof where a tx was stored in the chain - * `basecli proxy` exposes tendermint rpc, but only passes through results after doing complete verification - -BUG FIXES: - -* no more silently ignored error with invalid coin names (eg. "17.22foo coin" used to parse as "17 foo", not warning/error) - -## 0.4.1 (April 26, 2017) - -BUG FIXES: - -* Fix bug in `basecoin unsafe_reset_X` where the `priv_validator.json` was not being reset - -## 0.4.0 (April 21, 2017) - -BREAKING CHANGES: - -* CLI now uses Cobra, which forced changes to some of the flag names and orderings - -IMPROVEMENTS: - -* `basecoin init` doesn't generate error if already initialized -* Much more testing - -## 0.3.1 (March 23, 2017) - -IMPROVEMENTS: - -* CLI returns exit code 1 and logs error before exiting - -## 0.3.0 (March 23, 2017) - -BREAKING CHANGES: - -* Remove `--data` flag and use `BCHOME` to set the home directory (defaults to `~/.basecoin`) -* Remove `--in-proc` flag and start Tendermint in-process by default (expect Tendermint files in $BCHOME/tendermint). - To start just the ABCI app/server, use `basecoin start --without-tendermint`. -* Consolidate genesis files so the Basecoin genesis is an object under `app_options` in Tendermint genesis. For instance: - -``` -{ - "app_hash": "", - "chain_id": "foo_bar_chain", - "genesis_time": "0001-01-01T00:00:00.000Z", - "validators": [ - { - "amount": 10, - "name": "", - "pub_key": [ - 1, - "7B90EA87E7DC0C7145C8C48C08992BE271C7234134343E8A8E8008E617DE7B30" - ] - } - ], - "app_options": { - "accounts": [{ - "pub_key": { - "type": "ed25519", - "data": "6880db93598e283a67c4d88fc67a8858aa2de70f713fe94a5109e29c137100c2" - }, - "coins": [ - { - "denom": "blank", - "amount": 12345 - }, - { - "denom": "ETH", - "amount": 654321 - } - ] - }], - "plugin_options": ["plugin1/key1", "value1", "plugin1/key2", "value2"] - } -} -``` - -Note the array of key-value pairs is now under `app_options.plugin_options` while the `app_options` themselves are well formed. -We also changed `chainID` to `chain_id` and consolidated to have just one of them. - -FEATURES: - -* Introduce `basecoin init` and `basecoin unsafe_reset_all` - -## 0.2.0 (March 6, 2017) - -BREAKING CHANGES: - -* Update to ABCI v0.4.0 and Tendermint v0.9.0 -* Coins are specified on the CLI as `Xcoin`, eg. `5gold` -* `Cost` is now `Fee` - -FEATURES: - -* CLI for sending transactions and querying the state, - designed to be easily extensible as plugins are implemented -* Run Basecoin in-process with Tendermint -* Add `/account` path in Query -* IBC plugin for InterBlockchain Communication -* Demo script of IBC between two chains - -IMPROVEMENTS: - -* Use new Tendermint `/commit` endpoint for crafting IBC transactions -* More unit tests -* Use go-crypto S structs and go-data for more standard JSON -* Demo uses fewer sleeps - -BUG FIXES: - -* Various little fixes in coin arithmetic -* More commit validation in IBC -* Return results from transactions - -## PreHistory - -##### January 14-18, 2017 - -* Update to Tendermint v0.8.0 -* Cleanup a bit and release blog post - -##### September 22, 2016 - -* Basecoin compiles again +* (cosmos-sdk) [v0.42.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.42.1). +Please refer [CHANGELOG_OF_COSMOS_SDK_v0.42.1](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/CHANGELOG.md) - -[Unreleased]: https://github.com/cosmos/cosmos-sdk/compare/v0.38.2...HEAD -[v0.38.2]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.38.2 -[v0.38.1]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.38.1 -[v0.38.0]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.38.0 -[v0.37.9]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.9 -[v0.37.8]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.8 -[v0.37.7]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.7 -[v0.37.6]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.6 -[v0.37.5]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.5 -[v0.37.4]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.4 -[v0.37.3]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.3 -[v0.37.1]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.1 -[v0.37.0]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.37.0 -[v0.36.0]: https://github.com/cosmos/cosmos-sdk/releases/tag/v0.36.0 diff --git a/CHANGELOG_PENDING.md b/CHANGELOG_PENDING.md deleted file mode 100644 index f2166e1485..0000000000 --- a/CHANGELOG_PENDING.md +++ /dev/null @@ -1,32 +0,0 @@ -# Unreleased Changes - -## lbm-sdk v2 - -Write the changes made after branching from cosmos-sdk v0.42.1. - -### BREAKING CHANGES - -- CLI/RPC/Config -* (rpc) [\#97](https://github.com/line/lbm-sdk/pull/97) Send response with 404 status when quering non-exist account - -- Apps - -- P2P Protocol - -- Go API -* (global) [\#90](https://github.com/line/lbm-sdk/pull/90) Rename module path to `github.com/line/lbm-sdk/v2` - -- Blockchain Protocol - -### FEATURES -* (global) [\#97](https://github.com/line/lbm-sdk/pull/97) Add codespace to response -* (global) [\#97](https://github.com/line/lbm-sdk/pull/97) Add codespace to query error -* (config) [\#114](https://github.com/line/lbm-sdk/pull/114) Add idle-timeout to rest server and rpc server config -* (x/wasm) [\#127](https://github.com/line/lbm-sdk/pull/127) Add wasm with Staragate migration completed. -* (x/wasm) [\#151](https://github.com/line/lbm-sdk/pull/151) Add contract access control. -* (x/wasm) [\#194](https://github.com/line/lbm-sdk/pull/194) Replace importing CosmWasm/wasmvm with line/wasmvm. - -### IMPROVEMENTS - -### BUG FIXES - diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index c9f9cc2405..198dd6e4e6 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,46 +1,133 @@ + # Contributor Covenant Code of Conduct ## Our Pledge -In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. +We as members, contributors, and leaders pledge to make participation in our +community a harassment-free experience for everyone, regardless of age, body +size, visible or invisible disability, ethnicity, sex characteristics, gender +identity and expression, level of experience, education, socio-economic status, +nationality, personal appearance, race, religion, or sexual identity +and orientation. + +We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community. ## Our Standards -Examples of behavior that contributes to creating a positive environment include: +Examples of behavior that contributes to a positive environment for our +community include: -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members +* Demonstrating empathy and kindness toward other people +* Being respectful of differing opinions, viewpoints, and experiences +* Giving and gracefully accepting constructive feedback +* Accepting responsibility and apologizing to those affected by our mistakes, + and learning from the experience +* Focusing on what is best not just for us as individuals, but for the + overall community -Examples of unacceptable behavior by participants include: +Examples of unacceptable behavior include: -* The use of sexualized language or imagery and unwelcome sexual attention or advances -* Trolling, insulting/derogatory comments, and personal or political attacks +* The use of sexualized language or imagery, and sexual attention or + advances of any kind +* Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment -* Publishing others' private information, such as a physical or electronic address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a professional setting +* Publishing others' private information, such as a physical or email + address, without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting -## Our Responsibilities +## Enforcement Responsibilities -Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. +Community leaders are responsible for clarifying and enforcing our standards of +acceptable behavior and will take appropriate and fair corrective action in +response to any behavior that they deem inappropriate, threatening, offensive, +or harmful. -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. +Community leaders have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, and will communicate reasons for moderation +decisions when appropriate. ## Scope -This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. +This Code of Conduct applies within all community spaces, and also applies when +an individual is officially representing the community in public spaces. +Examples of representing our community include using an official e-mail address, +posting via an official social media account, or acting as an appointed +representative at an online or offline event. ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at community@interchain.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported to the community leaders responsible for enforcement at +[dl_oss_dev@linecorp.com](mailto:dl_oss_dev@linecorp.com). +All complaints will be reviewed and investigated promptly and fairly. + +All community leaders are obligated to respect the privacy and security of the +reporter of any incident. + +## Enforcement Guidelines + +Community leaders will follow these Community Impact Guidelines in determining +the consequences for any action they deem in violation of this Code of Conduct: + +### 1. Correction + +**Community Impact**: Use of inappropriate language or other behavior deemed +unprofessional or unwelcome in the community. + +**Consequence**: A private, written warning from community leaders, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested. + +### 2. Warning -Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. +**Community Impact**: A violation through a single incident or series +of actions. + +**Consequence**: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or +permanent ban. + +### 3. Temporary Ban + +**Community Impact**: A serious violation of community standards, including +sustained inappropriate behavior. + +**Consequence**: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, is allowed during this period. +Violating these terms may lead to a permanent ban. + +### 4. Permanent Ban + +**Community Impact**: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals. + +**Consequence**: A permanent ban from any sort of public interaction within +the community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 2.0, available at +[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. + +Community Impact Guidelines were inspired by +[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. + +For answers to common questions about this code of conduct, see the FAQ at +[https://www.contributor-covenant.org/faq][FAQ]. Translations are available +at [https://www.contributor-covenant.org/translations][translations]. -[homepage]: http://contributor-covenant.org -[version]: http://contributor-covenant.org/version/1/4/ +[homepage]: https://www.contributor-covenant.org +[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html +[Mozilla CoC]: https://github.com/mozilla/diversity +[FAQ]: https://www.contributor-covenant.org/faq +[translations]: https://www.contributor-covenant.org/translations diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9da63ff5a4..4844791bce 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,41 +1,218 @@ -# How to contribute to LBM(Line Blockchain Mainnet) +# Contributing -First of all, thank you so much for taking your time to contribute! -It will be amazing if you could help us by doing any of the following: +- [Contributing](#contributing) + - [Architecture Decision Records (ADR)](#architecture-decision-records-adr) + - [Pull Requests](#pull-requests) + - [Process for reviewing PRs](#process-for-reviewing-prs) + - [Updating Documentation](#updating-documentation) + - [Forking](#forking) + - [Dependencies](#dependencies) + - [Protobuf](#protobuf) + - [Testing](#testing) + - [Branching Model and Release](#branching-model-and-release) + - [PR Targeting](#pr-targeting) + - [Development Procedure](#development-procedure) + - [Pull Merge Procedure](#pull-merge-procedure) + - [Release Procedure](#release-procedure) + - [Point Release Procedure](#point-release-procedure) + - [Code Owner Membership](#code-owner-membership) -- File an issue in [the issue tracker](https://github.com/line/lbm/issues) to report bugs and propose new features and - improvements. -- Ask a question by creating a new issue in [the issue tracker](https://github.com/line/lbm/issues). - - Browse [the list of previously answered questions](https://github.com/line/lbm/issues?q=label%3Aquestion). -- Contribute your work by sending [a pull request](https://github.com/line/lbm/pulls). +Thank you for considering making contributions to lbm-sdk and related +repositories! -## Contributor license agreement +Contributing to this repo can mean many things such as participating in +discussion or proposing code changes. To ensure a smooth workflow for all +contributors, the general procedure for contributing has been established: -When you are sending a pull request and it's a non-trivial change beyond fixing typos, please sign -the ICLA (individual contributor license agreement). Please -[contact us](mailto:dl_oss_dev@linecorp.com) if you need the CCLA (corporate contributor license agreement). +1. Either [open](https://github.com/line/lbm-sdk/issues/new/choose) or + [find](https://github.com/line/lbm-sdk/issues) an issue you'd like to help with +2. Participate in thoughtful discussion on that issue +3. If you would like to contribute: + 1. If the issue is a proposal, ensure that the proposal has been accepted + 2. Ensure that nobody else has already begun working on this issue. If they have, + make sure to contact them to collaborate + 3. If nobody has been assigned for the issue and you would like to work on it, + make a comment on the issue to inform the community of your intentions + to begin work + 4. Follow standard Github best practices: fork the repo, branch from the + HEAD of `master`, make some commits, and submit a PR to `master` + - For core developers working within the cosmos-sdk repo, to ensure a clear + ownership of branches, branches must be named with the convention + `{moniker}/{issue#}-branch-name` + 5. Be sure to submit the PR in `Draft` mode submit your PR early, even if + it's incomplete as this indicates to the community you're working on + something and allows them to provide comments early in the development process + 6. When the code is complete it can be marked `Ready for Review` + 7. Be sure to include a relevant change log entry in the `Unreleased` section + of `CHANGELOG.md` (see file for log format) -## Code of conduct +Note that for very small or blatantly obvious problems (such as typos) it is +not required to an open issue to submit a PR, but be aware that for more complex +problems/features, if a PR is opened before an adequate design discussion has +taken place in a github issue, that PR runs a high likelihood of being rejected. -We expect contributors to follow [our code of conduct](https://github.com/line/lbm/blob/v2/develop/CODE_OF_CONDUCT.md). +Other notes: -## Setting up your IDE +- Please make sure to run `make format` before every commit - the easiest way + to do this is have your editor run it for you upon saving a file. Additionally + please ensure that your code is lint compliant by running `golangci-lint run`. + A convenience git `pre-commit` hook that runs the formatters automatically + before each commit is available in the `contrib/githooks/` directory. + +## Architecture Decision Records (ADR) + +When proposing an architecture decision for the SDK, please create an [ADR](./docs/architecture/README.md) +so further discussions can be made. We are following this process so all involved parties are in +agreement before any party begins coding the proposed implementation. If you would like to see some examples +of how these are written refer to the current [ADRs](./docs/architecture) + +## Pull Requests + +To accommodate review process we suggest that PRs are categorically broken up. +Ideally each PR addresses only a single issue. Additionally, as much as possible +code refactoring and cleanup should be submitted as a separate PRs from bugfixes/feature-additions. + +### Process for reviewing PRs + +All PRs require two Reviews before merge (except docs changes, or variable name-changes which only require one). When reviewing PRs please use the following review explanations: + +- `LGTM` without an explicit approval means that the changes look good, but you haven't pulled down the code, run tests locally and thoroughly reviewed it. +- `Approval` through the GH UI means that you understand the code, documentation/spec is updated in the right places, you have pulled down and tested the code locally. In addition: + - You must also think through anything which ought to be included but is not + - You must think through whether any added code could be partially combined (DRYed) with existing code + - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes + - Naming must be consistent with conventions and the rest of the codebase + - Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code). + - if you approve of the PR, you are responsible for fixing any of the issues mentioned here and more +- If you sat down with the PR submitter and did a pairing review please note that in the `Approval`, or your PR comments. +- If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review. + +### Updating Documentation + +If you open a PR on the LBM SDK, it is mandatory to update the relevant documentation in /docs. + +- If your change relates to the core SDK (baseapp, store, ...), please update the `docs/basics/`, `docs/core/` and/or `docs/building-modules/` folders. +- If your changes relate to the core of the CLI or Light-client (not specifically to module's CLI/Rest), please modify the `docs/interfaces/` folder. +- If your changes relate to a module, please update the module's spec in `x/moduleName/docs/spec/`. + +## Forking + +Please note that Go requires code to live under absolute paths, which complicates forking. +While my fork lives at `https://github.com/someone/lbm-sdk`, +the code should never exist at `$GOPATH/src/github.com/someone/lbm-sdk`. +Instead, we use `git remote` to add the fork as a new remote for the original repo, +`$GOPATH/src/github.com/line/lbm-sdk`, and do all the work there. + +For instance, to create a fork and work on a branch of it, I would: + +- Create the fork on github, using the fork button. +- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/line/lbm-sdk`) +- `git remote rename origin upstream` +- `git remote add origin git@github.com:someone/lbm-sdk.git` + +Now `origin` refers to my fork and `upstream` refers to the lbm-sdk version. +So I can `git push -u origin master` to update my fork, and make pull requests to lbm-sdk from there. +Of course, replace `someone` with your git handle. + +To pull in updates from the origin repo, run + +- `git fetch upstream` +- `git rebase upstream/master` (or whatever branch you want) + +Please don't make Pull Requests from `master`. + +## Dependencies + +We use [Go 1.15 Modules](https://github.com/golang/go/wiki/Modules) to manage +dependency versions. + +The master branch of every LBM repository should just build with `go get`, +which means they should be kept up-to-date with their dependencies, so we can +get away with telling people they can just `go get` our software. + +Since some dependencies are not under our control, a third party may break our +build, in which case we can fall back on `go mod tidy -v`. + +## Protobuf + +We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along with [gogoproto](https://github.com/gogo/protobuf) to generate code for use in lbm-sdk. + +For determinstic behavior around Protobuf tooling, everything is containerized using Docker. Make sure to have Docker installed on your machine, or head to [Docker's website](https://docs.docker.com/get-docker/) to install it. + +For formatting code in `.proto` files, you can run `make proto-format` command. + +For linting and checking breaking changes, we use [buf](https://buf.build/). You can use the commands `make proto-lint` and `make proto-check-breaking` to respectively lint your proto files and check for breaking changes. + +To generate the protobuf stubs, you can run `make proto-gen`. + +We also added the `make proto-all` command to run all the above commands sequentially. + +In order for imports to properly compile in your IDE, you may need to manually set your protobuf path in your IDE's workspace settings/config. + +For example, in vscode your `.vscode/settings.json` should look like: + +``` +{ + "protoc": { + "options": [ + "--proto_path=${workspaceRoot}/proto", + "--proto_path=${workspaceRoot}/third_party/proto" + ] + } +} +``` + +## Testing + +Tests can be ran by running `make test` at the top level of the SDK repository. + +We expect tests to use `require` or `assert` rather than `t.Skip` or `t.Fail`, +unless there is a reason to do otherwise. +When testing a function under a variety of different inputs, we prefer to use +[table driven tests](https://github.com/golang/go/wiki/TableDrivenTests). +Table driven test error messages should follow the following format +`, tc #, i #`. +`` is an optional short description of whats failing, `tc` is the +index within the table of the testcase that is failing, and `i` is when there +is a loop, exactly which iteration of the loop failed. +The idea is you should be able to see the +error message and figure out exactly what failed. +Here is an example check: + +```go + +for tcIndex, tc := range cases { + + for i := 0; i < tc.numTxsToTest; i++ { + + require.Equal(t, expectedTx[:32], calculatedTx[:32], + "First 32 bytes of the txs differed. tc #%d, i #%d", tcIndex, i) +``` + +## Branching Model and Release TBD -## Commit message and Pull Request message +### PR Targeting -- Follow [Conventional Commit](https://www.conventionalcommits.org) to release note automation. -- Don't mention or link that can't accessable from public. -- Use English only. Because this project will be published to the world-wide open-source world. But no worries. We are fully aware of that most of us are not the English-native. +TBD -## Pull Request Process +### Development Procedure -1. Ensure any install or build dependencies are removed before the end of the layer when doing a - build. -2. Update the [README.md](README.md) with details of changes to the interface, this includes new environment - variables, exposed ports, useful file locations and container parameters. -3. Fill out all sections of the pull request template. That makes it easier to review your PR for the reviewers. -4. You may merge the pull request in once you have the sign-off of two other developers, or if you - do not have permission to do that, you may request the second reviewer to merge it for you. +TBD + +### Pull Merge Procedure + +TBD + +### Release Procedure + +TBD + +### Point Release Procedure + +TBD + +## Code Owner Membership +TBD diff --git a/LICENSE b/LICENSE index 4e31b6cf9f..bd6c812b8e 100644 --- a/LICENSE +++ b/LICENSE @@ -189,7 +189,7 @@ License: Apache2.0 same "printed page" as the copyright notice for easier identification within third-party archives. - Copyright 2016 All in Bits, Inc + Copyright 2021 LINE TECH PLUS Pte., Ltd. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. diff --git a/NOTICE b/NOTICE new file mode 100644 index 0000000000..1d95b865cd --- /dev/null +++ b/NOTICE @@ -0,0 +1,14 @@ + Copyright 2016 All in Bits, Inc + Copyright 2021 LINE TECH PLUS Pte., Ltd. + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. \ No newline at end of file diff --git a/PULL_REQUEST_TEMPLATE.md b/PULL_REQUEST_TEMPLATE.md index a4cf81c4de..0bd6becdaa 100644 --- a/PULL_REQUEST_TEMPLATE.md +++ b/PULL_REQUEST_TEMPLATE.md @@ -17,6 +17,6 @@ ## Checklist: -- [ ] I followed the [contributing guidelines](https://github.com/line/link/blob/master/CONTRIBUTING.md). +- [ ] I followed the [contributing guidelines](./CONTRIBUTING.md). - [ ] I have updated the documentation accordingly. - [ ] I have added tests to cover my changes. diff --git a/README.md b/README.md index 39904e8d51..4c063e579d 100644 --- a/README.md +++ b/README.md @@ -1,72 +1,34 @@ - +The LBM SDK is a framework for building blockchain applications in Golang. +It is being used to build [`LBM`](https://github.com/line/lbm), the first implementation of the LINE Blockchain Mainnet. +This is forked from [`cosmos-sdk`](https://github.com/cosmos/cosmos-sdk) at 2021-03-15. -
-

Cosmos SDK

-
+**WARNING**: Breaking changes may occur because this repository is still in the pre-release development phase. -![banner](docs/cosmos-sdk-image.jpg) - - - - - - - -The Cosmos-SDK is a framework for building blockchain applications in Golang. -It is being used to build [`Gaia`](https://github.com/cosmos/gaia), the first implementation of the Cosmos Hub. +**Note**: Requires [Go 1.15+](https://golang.org/dl/) -**WARNING**: The SDK has mostly stabilized, but we are still making some -breaking changes. +## What is the LBM SDK? -**Note**: Requires [Go 1.15+](https://golang.org/dl/) +The [LBM SDK](https://github.com/line/lbm-sdk) is an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains, as well as permissioned Proof-Of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**. -## Quick Start +The purpose of `LBM SDK` is to succeed to [the objectives of `Cosmos sdk`](https://github.com/cosmos/cosmos-sdk/blob/master/docs/intro/overview.md) while helping develop blockchains that requires faster transaction processing to be applied to reality. -To learn how the SDK works from a high-level perspective, go to the [SDK Intro](./docs/intro/overview.md). +## Why the LBM SDK? -If you want to get started quickly and learn how to build on top of the SDK, please follow the [SDK Application Tutorial](https://tutorials.cosmos.network/nameservice/tutorial/00-intro.html). You can also fork the tutorial's repository to get started building your own Cosmos SDK application. +Cosmos-sdk, which created the philosophy of application-specific blockchain, established its status as a framework for various application blockchain development. `LBM SDK` inherited this `cosmos-sdk` philosophy, addressing slow transaction processing problem that was difficult for cosmos-sdk to apply in real financial system. Real financial systems require thousands of processing performance per second, with LBM SDK adding many performance improvements to meet that demand. +The following work was carried out to improve performance. -For more, please go to the [Cosmos SDK Docs](./docs/). +- Concurrent checkTx, deliverTx +- Use [fastcache](https://github.com/victoriametrics/fastcache) for inter block cache and nodedb cache of iavl +- Lock granularity enhancement -## Cosmos Hub Mainnet +In addition, the following functions were added: -The Cosmos Hub application, `gaia`, has moved to its [own repository](https://github.com/cosmos/gaia). Go there to join the Cosmos Hub mainnet and more. +- Virtual machine using `cosmwasm` that makes smart contracts possible to be executed +- Use [Ostracon](https://github.com/line/ostracon) as consensus engine instead of `Tendermint` -## Starport -If you are starting a new app or a new module you can use [Starport](https://github.com/tendermint/starport) to help you get started and speed up development. If you have any questions or find a bug, feel free to open an issue in the repo. +To learn about Cosmos SDK, please refer [Cosmos SDK Docs](https://github.com/cosmos/cosmos-sdk/blob/master/docs). -## Disambiguation +## Quick Start -This Cosmos-SDK project is not related to the [React-Cosmos](https://github.com/react-cosmos/react-cosmos) project (yet). Many thanks to Evan Coury and Ovidiu (@skidding) for this Github organization name. As per our agreement, this disambiguation notice will stay here. +TBD diff --git a/RELEASE_NOTES.md b/RELEASE_NOTES.md deleted file mode 100644 index 80c80889a0..0000000000 --- a/RELEASE_NOTES.md +++ /dev/null @@ -1,16 +0,0 @@ -# Cosmos SDK v0.42.0 "Stargate" Release Notes - -This release includes an important security fix for all non "Cosmos Hub" chains (e.g. any chain that does not use the default `cosmos` bech32 prefix), and a few performance improvements. - -See the [Cosmos SDK v0.42.0 milestone](https://github.com/cosmos/cosmos-sdk/milestone/42?closed=1) on our issue tracker for further details. - -# Security fix: validator address conversion in evidence handling - -The security fix resolves the issue regarding incorrect handling of validators' consensus addresses. Because of this incorrect handling, Cosmos SDK apps that were not using the default `cosmos` Bech32 address prefix were not able to jail validators that committed misbehaviors such as double signing. - -Although the issue does **not** affect the Cosmos Hub, this issue potentially renders the `v0.41` and `v0.40` release series unsafe for most chains. - -# Full header is emitted on IBC UpdateClient message event - -The event emitted by the IBC UpdateClient message now contains the full header. -This change makes header tracking easier and improves the handling of misbehaviors. diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index ce82a957f9..0000000000 --- a/SECURITY.md +++ /dev/null @@ -1,54 +0,0 @@ -# Security - -> **IMPORTANT**: If you find a security issue, you can contact our team directly at -security@tendermint.com, or report it to our [bug bounty program](https://hackerone.com/tendermint) on HackerOne. *DO NOT* open a public issue on the repository. - -## Bug Bounty - -As part of our [Coordinated Vulnerability Disclosure Policy](https://tendermint.com/security), we operate a -[bug bounty program](https://hackerone.com/tendermint) with Hacker One. - -See the policy linked above for more details on submissions and rewards and read -this [blog post](https://blog.cosmos.network/bug-bounty-program-for-tendermint-cosmos-833c67693586) for the program scope. - -The following is a list of examples of the kinds of bugs we're most interested -in for the Cosmos SDK. See [here](https://github.com/tendermint/tendermint/blob/master/SECURITY.md) for vulnerabilities we are interested -in for Tendermint and other lower-level libraries (eg. [IAVL](https://github.com/tendermint/iavl)). - -### Core packages - -- [`/baseapp`](https://github.com/cosmos/cosmos-sdk/tree/master/baseapp) -- [`/crypto`](https://github.com/cosmos/cosmos-sdk/tree/master/crypto) -- [`/types`](https://github.com/cosmos/cosmos-sdk/tree/master/types) -- [`/store`](https://github.com/cosmos/cosmos-sdk/tree/master/store) - -### Modules - -- [`x/auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth) -- [`x/bank`](https://github.com/cosmos/cosmos-sdk/tree/master/x/bank) -- [`x/capability`](https://github.com/cosmos/cosmos-sdk/tree/master/x/capability) -- [`x/staking`](https://github.com/cosmos/cosmos-sdk/tree/master/x/staking) -- [`x/slashing`](https://github.com/cosmos/cosmos-sdk/tree/master/x/slashing) -- [`x/evidence`](https://github.com/cosmos/cosmos-sdk/tree/master/x/evidence) -- [`x/distribution`](https://github.com/cosmos/cosmos-sdk/tree/master/x/distribution) -- [`x/ibc`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc) -- [`x/ibc-transfer`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc-transfer) -- [`x/mint`](https://github.com/cosmos/cosmos-sdk/tree/master/x/mint) - -We are interested in bugs in other modules, however the above are most likely to -have significant vulnerabilities, due to the complexity / nuance involved. We -also recommend you to read the [specification](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/README.md) of each module before digging into -the code. - -### How we process Tx parameters - -- Integer operations on tx parameters, especially `sdk.Int` / `sdk.Dec` -- Gas calculation & parameter choices -- Tx signature verification (see [`x/auth/ante`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/ante)) -- Possible Node DoS vectors (perhaps due to gas weighting / non constant timing) - -### Handling private keys - -- HD key derivation, local and Ledger, and all key-management functionality -- Side-channel attack vectors with our implementations - - e.g. key exfiltration based on time or memory-access patterns when decrypting privkey diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md deleted file mode 100644 index fd6a882135..0000000000 --- a/STABLE_RELEASES.md +++ /dev/null @@ -1,131 +0,0 @@ -# Stable Releases - -*Stable Release Series* continue to receive bug fixes until they reach **End Of Life**. - -Only the following release series are currently supported and receive bug fixes: - -The `0.37.x` release series will continue receiving bug fixes until the Cosmos Hub -migrates to a newer release of the Cosmos-SDK. - -* **0.37** will continue receiving bug fixes until the Cosmos Hub migrates to a newer release series of the Cosmos-SDK. -* **0.39 «Launchpad»** will be supported until 6 months after **0.40.0** is published. A fairly strict **bugfix-only** rule applies to pull requests that are requested to be included into a stable point-release. - -The **0.39 «Launchpad»** release series is maintained in compliance with the **Stable Release Policy** as described in this document. - -## Stable Release Policy - -This policy presently applies *only* to the following release series: - -* **0.39 «Launchpad»** - -### Point Releases - -Once a Cosmos-SDK release has been completed and published, updates for it are released under certain circumstances -and must follow the [Point Release Procedure](CONTRIBUTING.md). - -### Rationale - -Unlike in-development `master` branch snapshots, **Cosmos-SDK** releases are subject to much wider adoption, -and by a significantly different demographic of users. During development, changes in the `master` branch -affect SDK users, application developers, early adopters, and other advanced users that elect to use -unstable experimental software at their own risk. - -Conversely, users of a stable release expect a high degree of stability. They build their applications on it, and the -problems they experience with it could be potentially highly disruptive to their projects. - -Stable release updates are recommended to the vast majority of developers, and so it is crucial to treat them -with great caution. Hence, when updates are proposed, they must be accompanied by a strong rationale and present -a low risk of regressions, i.e. even one-line changes could cause unexpected regressions due to side effects or -poorly tested code. We never assume that any change, no matter how little or non-intrusive, is completely exempt -of regression risks. - -Therefore, the requirements for stable changes are different than those that are candidates to be merged in -the `master` branch. When preparing future major releases, our aim is to design the most elegant, user-friendly and -maintainable SDK possible which often entails fundamental changes to the SDK's architecture design, rearranging and/or -renaming packages as well as reducing code duplication so that we maintain common functions and data structures in one -place rather than leaving them scattered all over the code base. However, once a release is published, the -priority is to minimise the risk caused by changes that are not strictly required to fix qualifying bugs; this tends to -be correlated with minimising the size of such changes. As such, the same bug may need to be fixed in different -ways in stable releases and `master` branch. - -### What qualifies as a Stable Release Update (SRU) - -* **High-impact bugs** - * Bugs that may directly cause a security vulnerability. - * *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues - that may cause the core packages or the `x/` modules unusable. - * Bugs that may cause **loss of user's data**. -* Other safe cases: - * Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known. - * Relatively small yet strictly non-breaking changes that introduce forward-compatible client - features to smoothen the migration to successive releases. - -### What does not qualify as SRU - -* State machine changes. -* New features that introduces API breakages (e.g. public functions removal/renaming). -* Cosmetic fixes, such as formatting or linter warning fixes. - -## What pull requests will be included in stable point-releases - -Pull requests that fix bugs that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release: - - * **Severe regressions**. - * Bugs that may cause **client applications** to be **largely unusable**. - * Bugs that may cause **state corruption or data loss**. - * Bugs that may directly or indirectly cause a **security vulnerability**. - -## What pull requests will NOT be automatically included in stable point-releases - -As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases: - - * **State machine changes**. - * **Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code. - - In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a *Stable Release Exception*. - -## Stable Release Exception - Procedure - -1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [0.39 «Launchpad»](https://github.com/cosmos/cosmos-sdk/labels/0.39%20LTS%20%28Launchpad%29) to the issue. -2. Add a comment to the issue and ensure it contains the following information (see the bug template below): - * **[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release. - * A **[Test Case]** section containing detailed instructions on how to reproduce the bug. - * A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release. -3. **Stable Release Managers** will review and discuss the PR. Once *consensus* surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/launchpad/0.39.X` being `X` the Launchpad's upcoming point-release) and the PR included in the point-release's respective milestone (e.g. `0.39.5`). - -### Stable Release Exception - Bug template - -``` -#### Impact - -Brief xplanation of the effects of the bug on users and a justification for backporting the fix to the stable release. - -#### Test Case - -Detailed instructions on how to reproduce the bug on Launchpad's most recently published point-release. - -#### Regression Potential - -Explanation on how regressions might manifest - even if it's unlikely. -It is assumed that stable release fixes are well-tested and they come with a low risk of regressions. -It's crucial to make the effort of thinking about what could happen in case a regression emerges. -``` - -## Stable Release Managers - -The **Stable Release Managers** evaluate and approve or reject updates and backports to Cosmos-SDK Stable Release series, -according to the [stable release policy](#stable-release-policy) and [release procedure](#stable-release-exception-procedure). -Decisions are made by consensus. - -Their responsibilites include: - * Driving the Stable Release Exception process. - * Approving/rejecting proposed changes to a stable release series. - * Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md). - -The Stable Release Managers are appointed by the Interchain Foundation. - -*Stable Release Managers* for the **0.39 «Launchpad»** release series follow: - -* @alessio - Alessio Treglia -* @clevinson - Cory Levinson- -* @ethanfrey - Ethan Frey diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js deleted file mode 100644 index 6ad37a1d6d..0000000000 --- a/docs/.vuepress/config.js +++ /dev/null @@ -1,213 +0,0 @@ -module.exports = { - theme: "cosmos", - title: "Cosmos SDK", - locales: { - "/": { - lang: "en-US" - }, - kr: { - lang: "kr" - }, - cn: { - lang: "cn" - }, - ru: { - lang: "ru" - } - }, - base: process.env.VUEPRESS_BASE || "/", - head: [ - ['link', { rel: "apple-touch-icon", sizes: "180x180", href: "/apple-touch-icon.png" }], - ['link', { rel: "icon", type: "image/png", sizes: "32x32", href: "/favicon-32x32.png" }], - ['link', { rel: "icon", type: "image/png", sizes: "16x16", href: "/favicon-16x16.png" }], - ['link', { rel: "manifest", href: "/site.webmanifest" }], - ['meta', { name: "msapplication-TileColor", content: "#2e3148" }], - ['meta', { name: "theme-color", content: "#ffffff" }], - ['link', { rel: "icon", type: "image/svg+xml", href: "/favicon-svg.svg" }], - ['link', { rel: "apple-touch-icon-precomposed", href: "/apple-touch-icon-precomposed.png" }], - ], - themeConfig: { - repo: "cosmos/cosmos-sdk", - docsRepo: "cosmos/cosmos-sdk", - docsDir: "docs", - editLinks: true, - label: "sdk", - algolia: { - id: "BH4D9OD16A", - key: "ac317234e6a42074175369b2f42e9754", - index: "cosmos-sdk" - }, - versions: [ - { - "label": "v0.39", - "key": "v0.39" - }, - { - "label": "v0.41", - "key": "v0.41" - }, - { - "label": "master", - "key": "master" - } - ], - topbar: { - banner: true - }, - sidebar: { - auto: true, - nav: [ - { - title: "Using the SDK", - children: [ - { - title: "Modules", - directory: true, - path: "/modules" - } - ] - }, - { - title: "Resources", - children: [ - { - title: "Tutorials", - path: "https://tutorials.cosmos.network" - }, - { - title: "SDK API Reference", - path: "https://godoc.org/github.com/cosmos/cosmos-sdk" - }, - { - title: "REST API Spec", - path: "https://cosmos.network/rpc/" - } - ] - } - ] - }, - gutter: { - title: "Help & Support", - editLink: true, - chat: { - title: "Discord", - text: "Chat with Cosmos developers on Discord.", - url: "https://discordapp.com/channels/669268347736686612", - bg: "linear-gradient(225.11deg, #2E3148 0%, #161931 95.68%)" - }, - forum: { - title: "Cosmos SDK Forum", - text: "Join the SDK Developer Forum to learn more.", - url: "https://forum.cosmos.network/", - bg: "linear-gradient(225deg, #46509F -1.08%, #2F3564 95.88%)", - logo: "cosmos" - }, - github: { - title: "Found an Issue?", - text: "Help us improve this page by suggesting edits on GitHub." - } - }, - footer: { - question: { - text: "Chat with Cosmos developers in Discord or reach out on the SDK Developer Forum to learn more." - }, - logo: "/logo-bw.svg", - textLink: { - text: "cosmos.network", - url: "https://cosmos.network" - }, - services: [ - { - service: "medium", - url: "https://blog.cosmos.network/" - }, - { - service: "twitter", - url: "https://twitter.com/cosmos" - }, - { - service: "linkedin", - url: "https://www.linkedin.com/company/tendermint/" - }, - { - service: "reddit", - url: "https://reddit.com/r/cosmosnetwork" - }, - { - service: "telegram", - url: "https://t.me/cosmosproject" - }, - { - service: "youtube", - url: "https://www.youtube.com/c/CosmosProject" - } - ], - smallprint: - "This website is maintained by Tendermint Inc. The contents and opinions of this website are those of Tendermint Inc.", - links: [ - { - title: "Documentation", - children: [ - { - title: "Cosmos SDK", - url: "https://docs.cosmos.network" - }, - { - title: "Cosmos Hub", - url: "https://hub.cosmos.network" - }, - { - title: "Tendermint Core", - url: "https://docs.tendermint.com" - } - ] - }, - { - title: "Community", - children: [ - { - title: "Cosmos blog", - url: "https://blog.cosmos.network" - }, - { - title: "Forum", - url: "https://forum.cosmos.network" - }, - { - title: "Chat", - url: "https://discord.gg/W8trcGV" - } - ] - }, - { - title: "Contributing", - children: [ - { - title: "Contributing to the docs", - url: - "https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md" - }, - { - title: "Source code on GitHub", - url: "https://github.com/cosmos/cosmos-sdk/" - } - ] - } - ] - } - }, - plugins: [ - [ - "@vuepress/google-analytics", - { - ga: "UA-51029217-12" - } - ], - [ - "sitemap", - { - hostname: "https://docs.cosmos.network" - } - ] - ] -}; diff --git a/docs/.vuepress/public/android-chrome-192x192.png b/docs/.vuepress/public/android-chrome-192x192.png deleted file mode 100644 index 6d04cf4c08..0000000000 Binary files a/docs/.vuepress/public/android-chrome-192x192.png and /dev/null differ diff --git a/docs/.vuepress/public/android-chrome-256x256.png b/docs/.vuepress/public/android-chrome-256x256.png deleted file mode 100644 index 1c30cc0267..0000000000 Binary files a/docs/.vuepress/public/android-chrome-256x256.png and /dev/null differ diff --git a/docs/.vuepress/public/apple-touch-icon-precomposed.png b/docs/.vuepress/public/apple-touch-icon-precomposed.png deleted file mode 100644 index bd789213a5..0000000000 Binary files a/docs/.vuepress/public/apple-touch-icon-precomposed.png and /dev/null differ diff --git a/docs/.vuepress/public/apple-touch-icon.png b/docs/.vuepress/public/apple-touch-icon.png deleted file mode 100644 index 397e21af2a..0000000000 Binary files a/docs/.vuepress/public/apple-touch-icon.png and /dev/null differ diff --git a/docs/.vuepress/public/browserconfig.xml b/docs/.vuepress/public/browserconfig.xml deleted file mode 100644 index b3930d0f04..0000000000 --- a/docs/.vuepress/public/browserconfig.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - #da532c - - - diff --git a/docs/.vuepress/public/favicon-16x16.png b/docs/.vuepress/public/favicon-16x16.png deleted file mode 100644 index 5f15c3b0af..0000000000 Binary files a/docs/.vuepress/public/favicon-16x16.png and /dev/null differ diff --git a/docs/.vuepress/public/favicon-32x32.png b/docs/.vuepress/public/favicon-32x32.png deleted file mode 100644 index 9433c807fd..0000000000 Binary files a/docs/.vuepress/public/favicon-32x32.png and /dev/null differ diff --git a/docs/.vuepress/public/favicon-svg.svg b/docs/.vuepress/public/favicon-svg.svg deleted file mode 100644 index dbefbad9f4..0000000000 --- a/docs/.vuepress/public/favicon-svg.svg +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - - - - - - diff --git a/docs/.vuepress/public/logo-bw.svg b/docs/.vuepress/public/logo-bw.svg deleted file mode 100644 index f2575260a7..0000000000 --- a/docs/.vuepress/public/logo-bw.svg +++ /dev/null @@ -1,8 +0,0 @@ - - - - - - - - diff --git a/docs/.vuepress/public/logo.svg b/docs/.vuepress/public/logo.svg deleted file mode 100644 index 95ca6d30da..0000000000 --- a/docs/.vuepress/public/logo.svg +++ /dev/null @@ -1,18 +0,0 @@ - - - - - - - - - - - - - - - - - - diff --git a/docs/.vuepress/public/mstile-150x150.png b/docs/.vuepress/public/mstile-150x150.png deleted file mode 100644 index b1770354a1..0000000000 Binary files a/docs/.vuepress/public/mstile-150x150.png and /dev/null differ diff --git a/docs/.vuepress/public/safari-pinned-tab.svg b/docs/.vuepress/public/safari-pinned-tab.svg deleted file mode 100644 index db52b2cd4d..0000000000 --- a/docs/.vuepress/public/safari-pinned-tab.svg +++ /dev/null @@ -1,25 +0,0 @@ - - - - -Created by potrace 1.11, written by Peter Selinger 2001-2013 - - - - - diff --git a/docs/.vuepress/public/site.webmanifest b/docs/.vuepress/public/site.webmanifest deleted file mode 100644 index 5b4c0a3c67..0000000000 --- a/docs/.vuepress/public/site.webmanifest +++ /dev/null @@ -1,19 +0,0 @@ -{ - "name": "Cosmos SDK Documentation", - "short_name": "Cosmos SDK", - "icons": [ - { - "src": "/android-chrome-192x192.png", - "sizes": "192x192", - "type": "image/png" - }, - { - "src": "/android-chrome-256x256.png", - "sizes": "256x256", - "type": "image/png" - } - ], - "theme_color": "#ffffff", - "background_color": "#ffffff", - "display": "standalone" -} diff --git a/docs/.vuepress/styles/index.styl b/docs/.vuepress/styles/index.styl deleted file mode 100644 index be0b8d0568..0000000000 --- a/docs/.vuepress/styles/index.styl +++ /dev/null @@ -1,3 +0,0 @@ -:root - --color-primary #5064fb - --color-link #5064fb \ No newline at end of file diff --git a/docs/DOCS_README.md b/docs/DOCS_README.md deleted file mode 100644 index 98dbb33c32..0000000000 --- a/docs/DOCS_README.md +++ /dev/null @@ -1,121 +0,0 @@ -# Updating the docs - -If you want to open a PR on the Cosmos SDK to update the documentation, please follow the guidelines in the [`CONTRIBUTING.md`](https://github.com/cosmos/cosmos-sdk/tree/master/CONTRIBUTING.md#updating-documentation) - -## Translating - -- Docs translations live in a `docs/country-code/` folder, where `country-code` stands for the country code of the language used (`cn` for Chinese, `kr` for Korea, `fr` for France, ...). -- Always translate content living on `master`. -- Only content under `/docs/intro/`, `/docs/basics/`, `/docs/core/`, `/docs/building-modules/` and `docs/interfaces` needs to be translated, as well as `docs/README.md`. It is also nice (but not mandatory) to translate `/docs/spec/`. -- Specify the release/tag of the translation in the README of your translation folder. Update the release/tag each time you update the translation. - -## Docs Build Workflow - -The documentation for the Cosmos SDK is hosted at https://cosmos.network/docs/ - -built from the files in this (`/docs`) directory for -[master](https://github.com/cosmos/cosmos-sdk/tree/master/docs). - -### How It Works - -There is a CircleCI job listening for changes in the `/docs` directory, on -the `master` branch. Any updates to files in this directory -on that branch will automatically trigger a website deployment. Under the hood, -the private website repository has a `make build-docs` target consumed by a CircleCI job in that repo. - -## README - -The [README.md](./README.md) is also the landing page for the documentation -on the website. During the Jenkins build, the current commit is added to the bottom -of the README. - -## Config.js - -The [config.js](./.vuepress/config.js) generates the sidebar and Table of Contents -on the website docs. Note the use of relative links and the omission of -file extensions. Additional features are available to improve the look -of the sidebar. - -## Links - -**NOTE:** Strongly consider the existing links - both within this directory -and to the website docs - when moving or deleting files. - -Relative links should be used nearly everywhere, having discovered and weighed the following: - -### Relative - -Where is the other file, relative to the current one? - -- works both on GitHub and for the VuePress build -- confusing / annoying to have things like: `../../../../myfile.md` -- requires more updates when files are re-shuffled - -### Absolute - -Where is the other file, given the root of the repo? - -- works on GitHub, doesn't work for the VuePress build -- this is much nicer: `/docs/hereitis/myfile.md` -- if you move that file around, the links inside it are preserved (but not to it, of course) - -### Full - -The full GitHub URL to a file or directory. Used occasionally when it makes sense -to send users to the GitHub. - -## Building Locally - -Make sure you are in the `docs` directory and run the following commands: - -```sh -rm -rf node_modules -``` - -This command will remove old version of the visual theme and required packages. This step is optional. - -```sh -npm install -``` - -Install the theme and all dependencies. - -```sh -npm run serve -``` - -Run `pre` and `post` hooks and start a hot-reloading web-server. See output of this command for the URL (it is often https://localhost:8080). - -To build documentation as a static website run `npm run build`. You will find the website in `.vuepress/dist` directory. - -## Build RPC Docs - -First, run `make tools` from the root of repo, to install the swagger-ui tool. - -Then, edit the `swagger.yaml` manually; it is found [here](https://github.com/cosmos/cosmos-sdk/blob/master/client/lcd/swagger-ui/swagger.yaml) - -Finally, run `make update_gaia_lite_docs` from the root of the repo. - -## Search - -We are using [Algolia](https://www.algolia.com) to power full-text search. This uses a public API search-only key in the `config.js` as well as a [cosmos_network.json](https://github.com/algolia/docsearch-configs/blob/master/configs/cosmos_network.json) configuration file that we can update with PRs. - -## Consistency - -Because the build processes are identical (as is the information contained herein), this file should be kept in sync as -much as possible with its [counterpart in the Tendermint Core repo](https://github.com/tendermint/tendermint/blob/v0.34.0/docs/DOCS_README.md). - -### Update and Build the RPC docs - -1. Execute the following command at the root directory to install the swagger-ui generate tool. - ```bash - make tools - ``` -2. Edit API docs - 1. Directly Edit API docs manually: `client/lcd/swagger-ui/swagger.yaml`. - 2. Edit API docs within the [Swagger Editor](https://editor.swagger.io/). Please refer to this [document](https://swagger.io/docs/specification/2-0/basic-structure/) for the correct structure in `.yaml`. -3. Download `swagger.yaml` and replace the old `swagger.yaml` under fold `client/lcd/swagger-ui`. -4. Compile gaiacli - ```bash - make install - ``` diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index 18398752a0..0000000000 --- a/docs/README.md +++ /dev/null @@ -1,83 +0,0 @@ - - -# Cosmos SDK Documentation - -## Get Started - -- **[SDK Intro](./intro/overview.md)**: High-level overview of the Cosmos SDK. -- **[Quick Start Guide](./using-the-sdk/quick-start.md)**: Scaffold a standard Cosmos SDK app and run a node. -- **[SDK Application Tutorial](https://github.com/cosmos/sdk-application-tutorial)**: A tutorial that showcases how to build an SDK-based blockchain from scratch and explains the basic principles of the SDK in the process. - -## Reference - -- **[Basics](./basics/)**: Documentation on the basic concepts of the Cosmos SDK, like the standard anatomy of an application, the transaction lifecycle and accounts management. -- **[Core](./core/)**: Documentation on the core concepts of the Cosmos SDK, like `baseapp`, the `store` or the `server`. -- **[Building Modules](./building-modules/)**: Important concepts for module developers like `message`s, `keeper`s, `handler`s and `querier`s. -- **[IBC](./ibc/)**: Documentation for the IBC protocol integration and concepts. -- **[Running a Node, API, CLI](./run-node/)**: Documentation on how to run a node, and how to interact with it using the CLI and the API. -- **[Migrations](./migrations/)**: Migration guides for updating to Stargate. - -## Other Resources - -- **[Module Directory](../x/)**: Module implementations and their respective documentation. -- **[Specifications](./spec/)**: Specifications of modules and other parts of the Cosmos SDK. -- **[SDK API Reference](https://godoc.org/github.com/cosmos/cosmos-sdk)**: Godocs of the Cosmos SDK. -- **[REST API spec](https://cosmos.network/rpc/)**: List of endpoints to interact with a `gaia` full-node through REST. - -## Cosmos Hub - -The Cosmos Hub (`gaia`) docs have moved [here](https://github.com/cosmos/gaia/tree/master/docs). - -## Languages - -The Cosmos-SDK is currently written in [Golang](https://golang.org/), though the -framework could be implemented similarly in other languages. -Contact us for information about funding an implementation in another language. - -## Contribute - -See [this file](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md) for details of the build process and -considerations when making changes. diff --git a/docs/architecture/PROCESS.md b/docs/architecture/PROCESS.md deleted file mode 100644 index 4ed4621162..0000000000 --- a/docs/architecture/PROCESS.md +++ /dev/null @@ -1,60 +0,0 @@ -# ADR Creation Process - -1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md` -2. Create a draft Pull Request if you want to get an early feedback. -3. Make sure the context and a solution is clear and well documented. -4. Add an entry to a list in the [README](./README.md) file. -5. Create a Pull Request to propose a new ADR. - - -## ADR life cycle - -ADR creation is an **iterative** process. Instead of trying to solve all decisions in a single ADR pull request, we MUST firstly understand the problem and collect feedback through a GitHub Issue. - -1. Every proposal SHOULD start with a new GitHub Issue or be a result of existing Issues. The Issue should contain just a brief proposal summary. - -2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`. - -3. An ADR doesn't have to arrive to `master` with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge it and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests. - -4. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue. - -5. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it. - -6. Merged ADRs SHOULD NOT be pruned. - - -### ADR status - -Status has two components: - -``` -{CONSENSUS STATUS} {IMPLEMENTATION STATUS} -``` - -IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`. - -#### Consensus Status - -``` -DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEEDED by ADR-xxx - \ | - \ | - v v - ABANDONED -``` - - -+ `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form. -+ `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet. -+ `LAST CALL `: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze. -+ `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design. -+ `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so. -+ `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR. -+ `ABANDONED`: the ADR is no longer pursued by the original authors. - - -## Language used in ADR - -+ The context/background should be written in the present tense. -+ Avoid using a first, personal form. diff --git a/docs/architecture/README.md b/docs/architecture/README.md deleted file mode 100644 index 54cc9c89e4..0000000000 --- a/docs/architecture/README.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -order: false -parent: - order: false ---- - -# Architecture Decision Records (ADR) - -This is a location to record all high-level architecture decisions in the Cosmos-SDK. - -An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant. -An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality. -An Architectural Decision Record (**ADR**) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM). - -You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). - -## Rationale - -ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions. -An ADR should provide: - -- Context on the relevant goals and the current state -- Proposed changes to achieve the goals -- Summary of pros and cons -- References -- Changelog - -Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and -justification for a change in architecture, or for the architecture of something -new. The spec is much more compressed and streamlined summary of everything as -it stands today. - -If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. - - -## Creating new ADR - -Read about the [PROCESS](./PROCESS.md). - -## ADR Table of Contents - -### Accepted - -- [ADR 001: Coin Source Tracing](./adr-001-coin-source-tracing.md) -- [ADR 002: SDK Documentation Structure](./adr-002-docs-structure.md) -- [ADR 004: Split Denomination Keys](./adr-004-split-denomination-keys.md) -- [ADR 006: Secret Store Replacement](./adr-006-secret-store-replacement.md) -- [ADR 009: Evidence Module](./adr-009-evidence-module.md) -- [ADR 010: Modular AnteHandler](./adr-010-modular-antehandler.md) -- [ADR 019: Protocol Buffer State Encoding](./adr-019-protobuf-state-encoding.md) -- [ADR 020: Protocol Buffer Transaction Encoding](./adr-020-protobuf-transaction-encoding.md) -- [ADR 021: Protocol Buffer Query Encoding](./adr-021-protobuf-query-encoding.md) -- [ADR 023: Protocol Buffer Naming and Versioning](./adr-023-protobuf-naming.md) -- [ADR 026: IBC Client Recovery Mechanisms](./adr-026-ibc-client-recovery-mechanisms.md) -- [ADR 029: Fee Grant Module](./adr-029-fee-grant-module.md) -- [ADR 031: Protobuf Msg Services](./adr-031-msg-service.md) - -### Proposed - -- [ADR 003: Dynamic Capability Store](./adr-003-dynamic-capability-store.md) -- [ADR 011: Generalize Genesis Accounts](./adr-011-generalize-genesis-accounts.md) -- [ADR 012: State Accessors](./adr-012-state-accessors.md) -- [ADR 013: Metrics](./adr-013-metrics.md) -- [ADR 015: IBC Packet Receiver](./adr-015-ibc-packet-receiver.md) -- [ADR 016: Validator Consensus Key Rotation](./adr-016-validator-consensus-key-rotation.md) -- [ADR 017: Historical Header Module](./adr-017-historical-header-module.md) -- [ADR 018: Extendable Voting Periods](./adr-018-extendable-voting-period.md) -- [ADR 022: Custom baseapp panic handling](./adr-022-custom-panic-handling.md) -- [ADR 024: Coin Metadata](./adr-024-coin-metadata.md) -- [ADR 025: IBC Passive Channels](./adr-025-ibc-passive-channels.md) -- [ADR 027: Deterministic Protobuf Serialization](./adr-027-deterministic-protobuf-serialization.md) -- [ADR 028: Public Key Addresses](./adr-028-public-key-addresses.md) -- [ADR 032: Typed Events](./adr-032-typed-events.md) -- [ADR 035: Rosetta API Support](./adr-035-rosetta-api-support.md) -- [ADR 037: Governance Split Votes](./adr-037-gov-split-vote.md) \ No newline at end of file diff --git a/docs/architecture/adr-001-coin-source-tracing.md b/docs/architecture/adr-001-coin-source-tracing.md deleted file mode 100644 index 1d4267c30d..0000000000 --- a/docs/architecture/adr-001-coin-source-tracing.md +++ /dev/null @@ -1,376 +0,0 @@ -# ADR 001: Coin Source Tracing - -## Changelog - -- 2020-07-09: Initial Draft -- 2020-08-11: Implementation changes - -## Status - -Accepted, Implemented - -## Context - -The specification for IBC cross-chain fungible token transfers -([ICS20](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer)), needs to -be aware of the origin of any token denomination in order to relay a `Packet` which contains the sender -and recipient addressed in the -[`FungibleTokenPacketData`](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer#data-structures). - -The Packet relay sending works based in 2 cases (per -[specification](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer#packet-relay) and [Colin Axnér](https://github.com/colin-axner)'s description): - -1. Sender chain is acting as the source zone. The coins are transferred -to an escrow address (i.e locked) on the sender chain and then transferred -to the receiving chain through IBC TAO logic. It is expected that the -receiving chain will mint vouchers to the receiving address. - -2. Sender chain is acting as the sink zone. The coins (vouchers) are burned -on the sender chain and then transferred to the receiving chain though IBC -TAO logic. It is expected that the receiving chain, which had previously -sent the original denomination, will unescrow the fungible token and send -it to the receiving address. - -Another way of thinking of source and sink zones is through the token's -timeline. Each send to any chain other than the one it was previously -received from is a movement forwards in the token's timeline. This causes -trace to be added to the token's history and the destination port and -destination channel to be prefixed to the denomination. In these instances -the sender chain is acting as the source zone. When the token is sent back -to the chain it previously received from, the prefix is removed. This is -a backwards movement in the token's timeline and the sender chain -is acting as the sink zone. - -### Example - -Assume the following channel connections exist and that all channels use the port ID `transfer`: - -- chain `A` has channels with chain `B` and chain `C` with the IDs `channelToB` and `channelToC`, respectively -- chain `B` has channels with chain `A` and chain `C` with the IDs `channelToA` and `channelToC`, respectively -- chain `C` has channels with chain `A` and chain `B` with the IDs `channelToA` and `channelToB`, respectively - -These steps of transfer between chains occur in the following order: `A -> B -> C -> A -> C`. In particular: - -1. `A -> B`: sender chain is source zone. `A` sends packet with `denom` (escrowed on `A`), `B` receives `denom` and mints and sends voucher `transfer/channelToA/denom` to recipient. -2. `B -> C`: sender chain is source zone. `B` sends packet with `transfer/channelToA/denom` (escrowed on `B`), `C` receives `transfer/channelToA/denom` and mints and sends voucher `transfer/channelToB/transfer/channelToA/denom` to recipient. -3. `C -> A`: sender chain is source zone. `C` sends packet with `transfer/channelToB/transfer/channelToA/denom` (escrowed on `C`), `A` receives `transfer/channelToB/transfer/channelToA/denom` and mints and sends voucher `transfer/channelToC/transfer/channelToB/transfer/channelToA/denom` to recipient. -4. `A -> C`: sender chain is sink zone. `A` sends packet with `transfer/channelToC/transfer/channelToB/transfer/channelToA/denom` (burned on `A`), `C` receives `transfer/channelToC/transfer/channelToB/transfer/channelToA/denom`, and unescrows and sends `transfer/channelToB/transfer/channelToA/denom` to recipient. - -The token has a final denomination on chain `C` of `transfer/channelToB/transfer/channelToA/denom`, where `transfer/channelToB/transfer/channelToA` is the trace information. - -In this context, upon a receive of a cross-chain fungible token transfer, if the sender chain is the source of the token, the protocol prefixes the denomination with the port and channel identifiers in the following format: - -```typescript -prefix + denom = {destPortN}/{destChannelN}/.../{destPort0}/{destChannel0}/denom -``` - -Example: transferring `100 uatom` from port `HubPort` and channel `HubChannel` on the Hub to -Ethermint's port `EthermintPort` and channel `EthermintChannel` results in `100 -EthermintPort/EthermintChannel/uatom`, where `EthermintPort/EthermintChannel/uatom` is the new -denomination on the receiving chain. - -In the case those tokens are transferred back to the Hub (i.e the **source** chain), the prefix is -trimmed and the token denomination updated to the original one. - -### Problem - -The problem of adding additional information to the coin denomination is twofold: - -1. The ever increasing length if tokens are transferred to zones other than the source: - -If a token is transferred `n` times via IBC to a sink chain, the token denom will contain `n` pairs -of prefixes, as shown on the format example above. This poses a problem because, while port and -channel identifiers have a maximum length of 64 each, the SDK `Coin` type only accepts denoms up to -64 characters. Thus, a single cross-chain token, which again, is composed by the port and channels -identifiers plus the base denomination, can exceed the length validation for the SDK `Coins`. - -This can result in undesired behaviours such as tokens not being able to be transferred to multiple -sink chains if the denomination exceeds the length or unexpected `panics` due to denomination -validation failing on the receiving chain. - -2. The existence of special characters and uppercase letters on the denomination: - -In the SDK every time a `Coin` is initialized through the constructor function `NewCoin`, a validation -of a coin's denom is performed according to a -[Regex](https://github.com/cosmos/cosmos-sdk/blob/a940214a4923a3bf9a9161cd14bd3072299cd0c9/types/coin.go#L583), -where only lowercase alphanumeric characters are accepted. While this is desirable for native denominations -to keep a clean UX, it presents a challenge for IBC as ports and channels might be randomly -generated with special and uppercase characters as per the [ICS 024 - Host -Requirements](https://github.com/cosmos/ics/tree/master/spec/ics-024-host-requirements#paths-identifiers-separators) -specification. - -## Decision - -The issues outlined above, are applicable only to SDK-based chains, and thus the proposed solution -are do not require specification changes that would result in modification to other implementations -of the ICS20 spec. - -Instead of adding the identifiers on the coin denomination directly, the proposed solution hashes -the denomination prefix in order to get a consistent length for all the cross-chain fungible tokens. - -This will be used for internal storage only, and when transferred via IBC to a different chain, the -denomination specified on the packed data will be the full prefix path of the identifiers needed to -trace the token back to the originating chain, as specified on ICS20. - -The new proposed format will be the following: - -```golang -ibcDenom = "ibc/" + hash(trace path + "/" + base denom) -``` - -The hash function will be a SHA256 hash of the fields of the `DenomTrace`: - -```protobuf -// DenomTrace contains the base denomination for ICS20 fungible tokens and the source tracing -// information -message DenomTrace { - // chain of port/channel identifiers used for tracing the source of the fungible token - string path = 1; - // base denomination of the relayed fungible token - string base_denom = 2; -} -``` - -The `IBCDenom` function constructs the `Coin` denomination used when creating the ICS20 fungible token packet data: - -```golang -// Hash returns the hex bytes of the SHA256 hash of the DenomTrace fields using the following formula: -// -// hash = sha256(tracePath + "/" + baseDenom) -func (dt DenomTrace) Hash() ostbytes.HexBytes { - return tmhash.Sum(dt.Path + "/" + dt.BaseDenom) -} - -// IBCDenom a coin denomination for an ICS20 fungible token in the format 'ibc/{hash(tracePath + baseDenom)}'. -// If the trace is empty, it will return the base denomination. -func (dt DenomTrace) IBCDenom() string { - if dt.Path != "" { - return fmt.Sprintf("ibc/%s", dt.Hash()) - } - return dt.BaseDenom -} -``` - -### `x/ibc-transfer` Changes - -In order to retrieve the trace information from an IBC denomination, a lookup table needs to be -added to the `ibc-transfer` module. These values need to also be persisted between upgrades, meaning -that a new `[]DenomTrace` `GenesisState` field state needs to be added to the module: - -```golang -// GetDenomTrace retrieves the full identifiers trace and base denomination from the store. -func (k Keeper) GetDenomTrace(ctx Context, denomTraceHash []byte) (DenomTrace, bool) { - store := ctx.KVStore(k.storeKey) - bz := store.Get(types.KeyDenomTrace(traceHash)) - if bz == nil { - return &DenomTrace, false - } - - var denomTrace DenomTrace - k.cdc.MustUnmarshalBinaryBare(bz, &denomTrace) - return denomTrace, true -} - -// HasDenomTrace checks if a the key with the given trace hash exists on the store. -func (k Keeper) HasDenomTrace(ctx Context, denomTraceHash []byte) bool { - store := ctx.KVStore(k.storeKey) - return store.Has(types.KeyTrace(denomTraceHash)) -} - -// SetDenomTrace sets a new {trace hash -> trace} pair to the store. -func (k Keeper) SetDenomTrace(ctx Context, denomTrace DenomTrace) { - store := ctx.KVStore(k.storeKey) - bz := k.cdc.MustMarshalBinaryBare(&denomTrace) - store.Set(types.KeyTrace(denomTrace.Hash()), bz) -} -``` - -The `MsgTransfer` will validate that the `Coin` denomination from the `Token` field contains a valid -hash, if the trace info is provided, or that the base denominations matches: - -```golang -func (msg MsgTransfer) ValidateBasic() error { - // ... - return ValidateIBCDenom(msg.Token.Denom) -} -``` - -```golang -// ValidateIBCDenom validates that the given denomination is either: -// -// - A valid base denomination (eg: 'uatom') -// - A valid fungible token representation (i.e 'ibc/{hash}') per ADR 001 https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-001-coin-source-tracing.md -func ValidateIBCDenom(denom string) error { - denomSplit := strings.SplitN(denom, "/", 2) - - switch { - case strings.TrimSpace(denom) == "", - len(denomSplit) == 1 && denomSplit[0] == "ibc", - len(denomSplit) == 2 && (denomSplit[0] != "ibc" || strings.TrimSpace(denomSplit[1]) == ""): - return sdkerrors.Wrapf(ErrInvalidDenomForTransfer, "denomination should be prefixed with the format 'ibc/{hash(trace + \"/\" + %s)}'", denom) - - case denomSplit[0] == denom && strings.TrimSpace(denom) != "": - return sdk.ValidateDenom(denom) - } - - if _, err := ParseHexHash(denomSplit[1]); err != nil { - return Wrapf(err, "invalid denom trace hash %s", denomSplit[1]) - } - - return nil -} -``` - -The denomination trace info only needs to be updated when token is received: - -- Receiver is **source** chain: The receiver created the token and must have the trace lookup already stored (if necessary _ie_ native token case wouldn't need a lookup). -- Receiver is **not source** chain: Store the received info. For example, during step 1, when chain `B` receives `transfer/channelToA/denom`. - -```golang -// SendTransfer -// ... - - fullDenomPath := token.Denom - -// deconstruct the token denomination into the denomination trace info -// to determine if the sender is the source chain -if strings.HasPrefix(token.Denom, "ibc/") { - fullDenomPath, err = k.DenomPathFromHash(ctx, token.Denom) - if err != nil { - return err - } -} - -if types.SenderChainIsSource(sourcePort, sourceChannel, fullDenomPath) { -//... -``` - -```golang -// DenomPathFromHash returns the full denomination path prefix from an ibc denom with a hash -// component. -func (k Keeper) DenomPathFromHash(ctx sdk.Context, denom string) (string, error) { - hexHash := denom[4:] - hash, err := ParseHexHash(hexHash) - if err != nil { - return "", Wrap(ErrInvalidDenomForTransfer, err.Error()) - } - - denomTrace, found := k.GetDenomTrace(ctx, hash) - if !found { - return "", Wrap(ErrTraceNotFound, hexHash) - } - - fullDenomPath := denomTrace.GetFullDenomPath() - return fullDenomPath, nil -} -``` - - -```golang -// OnRecvPacket -// ... - -// This is the prefix that would have been prefixed to the denomination -// on sender chain IF and only if the token originally came from the -// receiving chain. -// -// NOTE: We use SourcePort and SourceChannel here, because the counterparty -// chain would have prefixed with DestPort and DestChannel when originally -// receiving this coin as seen in the "sender chain is the source" condition. -if ReceiverChainIsSource(packet.GetSourcePort(), packet.GetSourceChannel(), data.Denom) { - // sender chain is not the source, unescrow tokens - - // remove prefix added by sender chain - voucherPrefix := types.GetDenomPrefix(packet.GetSourcePort(), packet.GetSourceChannel()) - unprefixedDenom := data.Denom[len(voucherPrefix):] - token := sdk.NewCoin(unprefixedDenom, sdk.NewIntFromUint64(data.Amount)) - - // unescrow tokens - escrowAddress := types.GetEscrowAddress(packet.GetDestPort(), packet.GetDestChannel()) - return k.bankKeeper.SendCoins(ctx, escrowAddress, receiver, sdk.NewCoins(token)) -} - -// sender chain is the source, mint vouchers - -// since SendPacket did not prefix the denomination, we must prefix denomination here -sourcePrefix := types.GetDenomPrefix(packet.GetDestPort(), packet.GetDestChannel()) -// NOTE: sourcePrefix contains the trailing "/" -prefixedDenom := sourcePrefix + data.Denom - -// construct the denomination trace from the full raw denomination -denomTrace := types.ParseDenomTrace(prefixedDenom) - -// set the value to the lookup table if not stored already -traceHash := denomTrace.Hash() -if !k.HasDenomTrace(ctx, traceHash) { - k.SetDenomTrace(ctx, traceHash, denomTrace) -} - -voucherDenom := denomTrace.IBCDenom() -voucher := sdk.NewCoin(voucherDenom, sdk.NewIntFromUint64(data.Amount)) - -// mint new tokens if the source of the transfer is the same chain -if err := k.bankKeeper.MintCoins( - ctx, types.ModuleName, sdk.NewCoins(voucher), -); err != nil { - return err -} - -// send to receiver -return k.bankKeeper.SendCoinsFromModuleToAccount( - ctx, types.ModuleName, receiver, sdk.NewCoins(voucher), -) -``` - -```golang -func NewDenomTraceFromRawDenom(denom string) DenomTrace{ - denomSplit := strings.Split(denom, "/") - trace := "" - if len(denomSplit) > 1 { - trace = strings.Join(denomSplit[:len(denomSplit)-1], "/") - } - return DenomTrace{ - BaseDenom: denomSplit[len(denomSplit)-1], - Trace: trace, - } -} -``` - -One final remark is that the `FungibleTokenPacketData` will remain the same, i.e with the prefixed full denomination, since the receiving chain may not be an SDK-based chain. - -### Coin Changes - -The coin denomination validation will need to be updated to reflect these changes. In particular, the denomination validation -function will now: - -- Accept slash separators (`"/"`) and uppercase characters (due to the `HexBytes` format) -- Bump the maximum character length to 128, as the hex representation used by Tendermint's - `HexBytes` type contains 64 characters. - -Additional validation logic, such as verifying the length of the hash, the may be added to the bank module in the future if the [custom base denomination validation](https://github.com/cosmos/cosmos-sdk/pull/6755) is integrated into the SDK. - -### Positive - -- Clearer separation of the source tracing behaviour of the token (transfer prefix) from the original - `Coin` denomination -- Consistent validation of `Coin` fields (i.e no special characters, fixed max length) -- Cleaner `Coin` and standard denominations for IBC -- No additional fields to SDK `Coin` - -### Negative - -- Store each set of tracing denomination identifiers on the `ibc-transfer` module store -- Clients will have to fetch the base denomination every time they receive a new relayed fungible token over IBC. This can be mitigated using a map/cache for already seen hashes on the client side. Other forms of mitigation, would be opening a websocket connection subscribe to incoming events. - -### Neutral - -- Slight difference with the ICS20 spec -- Additional validation logic for IBC coins on the `ibc-transfer` module -- Additional genesis fields -- Slightly increases the gas usage on cross-chain transfers due to access to the store. This should - be inter-block cached if transfers are frequent. - -## References - -- [ICS 20 - Fungible token transfer](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer) -- [Custom Coin Denomination validation](https://github.com/cosmos/cosmos-sdk/pull/6755) diff --git a/docs/architecture/adr-002-docs-structure.md b/docs/architecture/adr-002-docs-structure.md deleted file mode 100644 index 1c8201890c..0000000000 --- a/docs/architecture/adr-002-docs-structure.md +++ /dev/null @@ -1,86 +0,0 @@ -# ADR 002: SDK Documentation Structure - -## Context - -There is a need for a scalable structure of the SDK documentation. Current documentation includes a lot of non-related SDK material, is difficult to maintain and hard to follow as a user. - -Ideally, we would have: - -- All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.) -- All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website. - -## Decision - -Re-structure the `/docs` folder of the SDK github repo as follows: - -``` -docs/ -├── README -├── intro/ -├── concepts/ -│ ├── baseapp -│ ├── types -│ ├── store -│ ├── server -│ ├── modules/ -│ │ ├── keeper -│ │ ├── handler -│ │ ├── cli -│ ├── gas -│ └── commands -├── clients/ -│ ├── lite/ -│ ├── service-providers -├── modules/ -├── spec/ -├── translations/ -└── architecture/ -``` - -The files in each sub-folders do not matter and will likely change. What matters is the sectioning: - -- `README`: Landing page of the docs. -- `intro`: Introductory material. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`. -- `concepts`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`. -- `clients`: Contains specs and info about the various SDK clients. -- `spec`: Contains specs of modules, and others. -- `modules`: Contains links to `godocs` and the spec of the modules. -- `architecture`: Contains architecture-related docs like the present one. -- `translations`: Contains different translations of the documentation. - -Website docs sidebar will only include the following sections: - -- `README` -- `intro` -- `concepts` -- `clients` - -`architecture` need not be displayed on the website. - -## Status - -Accepted - -## Consequences - -### Positive - -- Much clearer organisation of the SDK docs. -- The `/docs` folder now only contains SDK and gaia related material. Later, it will only contain SDK related material. -- Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example). -- Easier for developers to find what they need to update in the docs thanks to reworked architecture. -- Cleaner vuepress build for website docs. -- Will help build an executable doc (cf https://github.com/cosmos/cosmos-sdk/issues/2611) - -### Neutral - -- We need to move a bunch of deprecated stuff to `/_attic` folder. -- We need to integrate content in `docs/sdk/docs/core` in `concepts`. -- We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository. -- Update `DOCS_README.md` - -## References - -- https://github.com/cosmos/cosmos-sdk/issues/1460 -- https://github.com/cosmos/cosmos-sdk/pull/2695 -- https://github.com/cosmos/cosmos-sdk/issues/2611 diff --git a/docs/architecture/adr-003-dynamic-capability-store.md b/docs/architecture/adr-003-dynamic-capability-store.md deleted file mode 100644 index 21843649b4..0000000000 --- a/docs/architecture/adr-003-dynamic-capability-store.md +++ /dev/null @@ -1,344 +0,0 @@ -# ADR 3: Dynamic Capability Store - -## Changelog - -- 12 December 2019: Initial version -- 02 April 2020: Memory Store Revisions - -## Context - -Full implementation of the [IBC specification](https://github.com/cosmos/ics) requires the ability to create and authenticate object-capability keys at runtime (i.e., during transaction execution), -as described in [ICS 5](https://github.com/cosmos/ics/tree/master/spec/ics-005-port-allocation#technical-specification). In the IBC specification, capability keys are created for each newly initialised -port & channel, and are used to authenticate future usage of the port or channel. Since channels and potentially ports can be initialised during transaction execution, the state machine must be able to create -object-capability keys at this time. - -At present, the Cosmos SDK does not have the ability to do this. Object-capability keys are currently pointers (memory addresses) of `StoreKey` structs created at application initialisation in `app.go` ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L132)) -and passed to Keepers as fixed arguments ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L160)). Keepers cannot create or store capability keys during transaction execution — although they could call `NewKVStoreKey` and take the memory address -of the returned struct, storing this in the Merklised store would result in a consensus fault, since the memory address will be different on each machine (this is intentional — were this not the case, the keys would be predictable and couldn't serve as object capabilities). - -Keepers need a way to keep a private map of store keys which can be altered during transaction execution, along with a suitable mechanism for regenerating the unique memory addresses (capability keys) in this map whenever the application is started or restarted, along with a mechanism to revert capability creation on tx failure. -This ADR proposes such an interface & mechanism. - -## Decision - -The SDK will include a new `CapabilityKeeper` abstraction, which is responsible for provisioning, -tracking, and authenticating capabilities at runtime. During application initialisation in `app.go`, -the `CapabilityKeeper` will be hooked up to modules through unique function references -(by calling `ScopeToModule`, defined below) so that it can identify the calling module when later -invoked. - -When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialise` function will create -new capability keys for all previously allocated capability identifiers (allocated during execution of -past transactions and assigned to particular modes), and keep them in a memory-only store while the -chain is running. - -The `CapabilityKeeper` will include a persistent `KVStore`, a `MemoryStore`, and an in-memory map. -The persistent `KVStore` tracks which capability is owned by which modules. -The `MemoryStore` stores a forward mapping that map from module name, capability tuples to capability names and -a reverse mapping that map from module name, capability name to the capability index. -Since we cannot marshal the capability into a `KVStore` and unmarshal without changing the memory location of the capability, -the reverse mapping in the KVStore will simply map to an index. This index can then be used as a key in the ephemeral -go-map to retrieve the capability at the original memory location. - -The `CapabilityKeeper` will define the following types & functions: - -The `Capability` is similar to `StoreKey`, but has a globally unique `Index()` instead of -a name. A `String()` method is provided for debugging. - -A `Capability` is simply a struct, the address of which is taken for the actual capability. - -```golang -type Capability struct { - index uint64 -} -``` - -A `CapabilityKeeper` contains a persistent store key, memory store key, and mapping of allocated module names. - -```golang -type CapabilityKeeper struct { - persistentKey StoreKey - memKey StoreKey - capMap map[uint64]*Capability - moduleNames map[string]interface{} - sealed bool -} -``` - -The `CapabilityKeeper` provides the ability to create *scoped* sub-keepers which are tied to a -particular module name. These `ScopedCapabilityKeeper`s must be created at application initialisation -and passed to modules, which can then use them to claim capabilities they receive and retrieve -capabilities which they own by name, in addition to creating new capabilities & authenticating capabilities -passed by other modules. - -```golang -type ScopedCapabilityKeeper struct { - persistentKey StoreKey - memKey StoreKey - capMap map[uint64]*Capability - moduleName string -} -``` - -`ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique. -It MUST be called before `InitialiseAndSeal`. - -```golang -func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper { - if k.sealed { - panic("cannot scope to module via a sealed capability keeper") - } - - if _, ok := k.scopedModules[moduleName]; ok { - panic(fmt.Sprintf("cannot create multiple scoped keepers for the same module name: %s", moduleName)) - } - - k.scopedModules[moduleName] = struct{}{} - - return ScopedKeeper{ - cdc: k.cdc, - storeKey: k.storeKey, - memKey: k.memKey, - capMap: k.capMap, - module: moduleName, - } -} -``` - -`InitialiseAndSeal` MUST be called exactly once, after loading the initial state and creating all -necessary `ScopedCapabilityKeeper`s, in order to populate the memory store with newly-created -capability keys in accordance with the keys previously claimed by particular modules and prevent the -creation of any new `ScopedCapabilityKeeper`s. - -```golang -func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { - if ck.sealed { - panic("capability keeper is sealed") - } - - persistentStore := ctx.KVStore(ck.persistentKey) - map := ctx.KVStore(ck.memKey) - - // initialise memory store for all names in persistent store - for index, value := range persistentStore.Iter() { - capability = &CapabilityKey{index: index} - - for moduleAndCapability := range value { - moduleName, capabilityName := moduleAndCapability.Split("/") - memStore.Set(moduleName + "/fwd/" + capability, capabilityName) - memStore.Set(moduleName + "/rev/" + capabilityName, index) - - ck.capMap[index] = capability - } - } - - ck.sealed = true -} -``` - -`NewCapability` can be called by any module to create a new unique, unforgeable object-capability -reference. The newly created capability is automatically persisted; the calling module need not -call `ClaimCapability`. - -```golang -func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capability, error) { - // check name not taken in memory store - if capStore.Get("rev/" + name) != nil { - return nil, errors.New("name already taken") - } - - // fetch the current index - index := persistentStore.Get("index") - - // create a new capability - capability := &CapabilityKey{index: index} - - // set persistent store - persistentStore.Set(index, Set.singleton(sck.moduleName + "/" + name)) - - // update the index - index++ - persistentStore.Set("index", index) - - // set forward mapping in memory store from capability to name - memStore.Set(sck.moduleName + "/fwd/" + capability, name) - - // set reverse mapping in memory store from name to index - memStore.Set(sck.moduleName + "/rev/" + name, index) - - // set the in-memory mapping from index to capability pointer - capMap[index] = capability - - // return the newly created capability - return capability -} -``` - -`AuthenticateCapability` can be called by any module to check that a capability -does in fact correspond to a particular name (the name can be untrusted user input) -with which the calling module previously associated it. - -```golang -func (sck ScopedCapabilityKeeper) AuthenticateCapability(name string, capability Capability) bool { - // return whether forward mapping in memory store matches name - return memStore.Get(sck.moduleName + "/fwd/" + capability) === name -} -``` - -`ClaimCapability` allows a module to claim a capability key which it has received from another module -so that future `GetCapability` calls will succeed. - -`ClaimCapability` MUST be called if a module which receives a capability wishes to access it by name -in the future. Capabilities are multi-owner, so if multiple modules have a single `Capability` reference, -they will all own it. - -```golang -func (sck ScopedCapabilityKeeper) ClaimCapability(ctx Context, capability Capability, name string) error { - persistentStore := ctx.KVStore(sck.persistentKey) - - // set forward mapping in memory store from capability to name - memStore.Set(sck.moduleName + "/fwd/" + capability, name) - - // set reverse mapping in memory store from name to capability - memStore.Set(sck.moduleName + "/rev/" + name, capability) - - // update owner set in persistent store - owners := persistentStore.Get(capability.Index()) - owners.add(sck.moduleName + "/" + name) - persistentStore.Set(capability.Index(), owners) -} -``` - -`GetCapability` allows a module to fetch a capability which it has previously claimed by name. -The module is not allowed to retrieve capabilities which it does not own. - -```golang -func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capability, error) { - // fetch the index of capability using reverse mapping in memstore - index := memStore.Get(sck.moduleName + "/rev/" + name) - - // fetch capability from go-map using index - capability := capMap[index] - - // return the capability - return capability -} -``` - -`ReleaseCapability` allows a module to release a capability which it had previously claimed. If no -more owners exist, the capability will be deleted globally. - -```golang -func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capability) err { - persistentStore := ctx.KVStore(sck.persistentKey) - - name := capStore.Get(sck.moduleName + "/fwd/" + capability) - if name == nil { - return error("capability not owned by module") - } - - // delete forward mapping in memory store - memoryStore.Delete(sck.moduleName + "/fwd/" + capability, name) - - // delete reverse mapping in memory store - memoryStore.Delete(sck.moduleName + "/rev/" + name, capability) - - // update owner set in persistent store - owners := persistentStore.Get(capability.Index()) - owners.remove(sck.moduleName + "/" + name) - if owners.size() > 0 { - // there are still other owners, keep the capability around - persistentStore.Set(capability.Index(), owners) - } else { - // no more owners, delete the capability - persistentStore.Delete(capability.Index()) - delete(capMap[capability.Index()]) - } -} -``` - -### Usage patterns - -#### Initialisation - -Any modules which use dynamic capabilities must be provided a `ScopedCapabilityKeeper` in `app.go`: - -```golang -ck := NewCapabilityKeeper(persistentKey, memoryKey) -mod1Keeper := NewMod1Keeper(ck.ScopeToModule("mod1"), ....) -mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....) - -// other initialisation logic ... - -// load initial state... - -ck.InitialiseAndSeal(initialContext) -``` - -#### Creating, passing, claiming and using capabilities - -Consider the case where `mod1` wants to create a capability, associate it with a resource (e.g. an IBC channel) by name, then pass it to `mod2` which will use it later: - -Module 1 would have the following code: - -```golang -capability := scopedCapabilityKeeper.NewCapability(ctx, "resourceABC") -mod2Keeper.SomeFunction(ctx, capability, args...) -``` - -`SomeFunction`, running in module 2, could then claim the capability: - -```golang -func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) { - k.sck.ClaimCapability(ctx, capability, "resourceABC") - // other logic... -} -``` - -Later on, module 2 can retrieve that capability by name and pass it to module 1, which will authenticate it against the resource: - -```golang -func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) { - capability := k.sck.GetCapability(ctx, name) - mod1.UseResource(ctx, capability, "resourceABC") -} -``` - -Module 1 will then check that this capability key is authenticated to use the resource before allowing module 2 to use it: - -```golang -func (k Mod1Keeper) UseResource(ctx Context, capability Capability, resource string) { - if !k.sck.AuthenticateCapability(name, capability) { - return errors.New("unauthenticated") - } - // do something with the resource -} -``` - -If module 2 passed the capability key to module 3, module 3 could then claim it and call module 1 just like module 2 did -(in which case module 1, module 2, and module 3 would all be able to use this capability). - -## Status - -Proposed. - -## Consequences - -### Positive - -- Dynamic capability support. -- Allows CapabilityKeeper to return same capability pointer from go-map while reverting any writes to the persistent `KVStore` and in-memory `MemoryStore` on tx failure. - -### Negative - -- Requires an additional keeper. -- Some overlap with existing `StoreKey` system (in the future they could be combined, since this is a superset functionality-wise). -- Requires an extra level of indirection in the reverse mapping, since MemoryStore must map to index which must then be used as key in a go map to retrieve the actual capability - -### Neutral - -(none known) - -## References - -- [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513) diff --git a/docs/architecture/adr-004-split-denomination-keys.md b/docs/architecture/adr-004-split-denomination-keys.md deleted file mode 100644 index a718d9b0ca..0000000000 --- a/docs/architecture/adr-004-split-denomination-keys.md +++ /dev/null @@ -1,122 +0,0 @@ -# ADR 004: Split Denomination Keys - -## Changelog - -- 2020-01-08: Initial version -- 2020-01-09: Alterations to handle vesting accounts -- 2020-01-14: Updates from review feedback -- 2020-01-30: Updates from implementation - - -### Glossary - -* denom / denomination key -- unique token identifier. - - -## Context - -With permissionless IBC, anyone will be able to send arbitrary denominations to any other account. Currently, all non-zero balances are stored along with the account in an `sdk.Coins` struct, which creates a potential denial-of-service concern, as too many denominations will become expensive to load & store each time the account is modified. See issues [5467](https://github.com/cosmos/cosmos-sdk/issues/5467) and [4982](https://github.com/cosmos/cosmos-sdk/issues/4982) for additional context. - -Simply rejecting incoming deposits after a denomination count limit doesn't work, since it opens up a griefing vector: someone could send a user lots of nonsensical coins over IBC, and then prevent the user from receiving real denominations (such as staking rewards). - -## Decision - -Balances shall be stored per-account & per-denomination under a denomination- and account-unique key, thus enabling O(1) read & write access to the balance of a particular account in a particular denomination. - -### Account interface (x/auth) - -`GetCoins()` and `SetCoins()` will be removed from the account interface, since coin balances will -now be stored in & managed by the bank module. - -The vesting account interface will replace `SpendableCoins` in favor of `LockedCoins` which does -not require the account balance anymore. In addition, `TrackDelegation()` will now accept the -account balance of all tokens denominated in the vesting balance instead of loading the entire -account balance. - -Vesting accounts will continue to store original vesting, delegated free, and delegated -vesting coins (which is safe since these cannot contain arbitrary denominations). - -### Bank keeper (x/bank) - -The following APIs will be added to the `x/bank` keeper: - -- `GetAllBalances(ctx Context, addr AccAddress) Coins` -- `GetBalance(ctx Context, addr AccAddress, denom string) Coin` -- `SetBalance(ctx Context, addr AccAddress, coin Coin)` -- `LockedCoins(ctx Context, addr AccAddress) Coins` -- `SpendableCoins(ctx Context, addr AccAddress) Coins` - -Additional APIs may be added to facilitate iteration and auxiliary functionality not essential to -core functionality or persistence. - -Balances will be stored first by the address, then by the denomination (the reverse is also possible, -but retrieval of all balances for a single account is presumed to be more frequent): - -```golang -var BalancesPrefix = []byte("balances") - -func (k Keeper) SetBalance(ctx Context, addr AccAddress, balance Coin) error { - if !balance.IsValid() { - return err - } - - store := ctx.KVStore(k.storeKey) - balancesStore := prefix.NewStore(store, BalancesPrefix) - accountStore := prefix.NewStore(balancesStore, addr.Bytes()) - - bz := Marshal(balance) - accountStore.Set([]byte(balance.Denom), bz) - - return nil -} -``` - -This will result in the balances being indexed by the byte representation of -`balances/{address}/{denom}`. - -`DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual -account balance by denomination found in the (un)delegation amount. As a result, -any mutations to the account balance by will made by denomination. - -`SubtractCoins()` and `AddCoins()` will be altered to read & write the balances -directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist). - -`trackDelegation()` and `trackUndelegation()` will be altered to no longer update -account balances. - -External APIs will need to scan all balances under an account to retain backwards-compatibility. It -is advised that these APIs use `GetBalance` and `SetBalance` instead of `GetAllBalances` when -possible as to not load the entire account balance. - -### Supply module - -The supply module, in order to implement the total supply invariant, will now need -to scan all accounts & call `GetAllBalances` using the `x/bank` Keeper, then sum -the balances and check that they match the expected total supply. - -## Status - -Accepted. - -## Consequences - -### Positive - -- O(1) reads & writes of balances (with respect to the number of denominations for -which an account has non-zero balances). Note, this does not relate to the actual -I/O cost, rather the total number of direct reads needed. - -### Negative - -- Slightly less efficient reads/writes when reading & writing all balances of a -single account in a transaction. - -### Neutral - -None in particular. - -## References - -- Ref: https://github.com/cosmos/cosmos-sdk/issues/4982 -- Ref: https://github.com/cosmos/cosmos-sdk/issues/5467 -- Ref: https://github.com/cosmos/cosmos-sdk/issues/5492 diff --git a/docs/architecture/adr-006-secret-store-replacement.md b/docs/architecture/adr-006-secret-store-replacement.md deleted file mode 100644 index 5357aea176..0000000000 --- a/docs/architecture/adr-006-secret-store-replacement.md +++ /dev/null @@ -1,58 +0,0 @@ -# ADR 006: Secret Store Replacement - -## Changelog - -- July 29th, 2019: Initial draft -- September 11th, 2019: Work has started -- November 4th: SDK changes merged in -- November 18th: Gaia changes merged in - -## Context - -Currently, an SDK application's CLI directory stores key material and metadata in a plain text database in the user’s home directory. Key material is encrypted by a passphrase, protected by bcrypt hashing algorithm. Metadata (e.g. addresses, public keys, key storage details) is available in plain text. - -This is not desirable for a number of reasons. Perhaps the biggest reason is insufficient security protection of key material and metadata. Leaking the plain text allows an attacker to surveil what keys a given computer controls via a number of techniques, like compromised dependencies without any privilege execution. This could be followed by a more targeted attack on a particular user/computer. - -All modern desktop computers OS (Ubuntu, Debian, MacOS, Windows) provide a built-in secret store that is designed to allow applications to store information that is isolated from all other applications and requires passphrase entry to access the data. - -We are seeking solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store. - - -## Decision - -We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99-designs application. - -This appears to fulfill the requirement of protecting both key material and metadata from rouge software on a user’s machine. - - - -## Status - -Accepted - -## Consequences - -### Positive - -Increased safety for users. - -### Negative - -Users must manually migrate. - -Testing against all supported backends is difficult. - -Running tests locally on a Mac require numerous repetitive password entries. - -### Neutral - -{neutral consequences} - -## References - -- #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__] -- #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__] -- #5097 Add keys migrate command [__MERGED__] -- #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_] -- cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_] - diff --git a/docs/architecture/adr-007-specialization-groups.md b/docs/architecture/adr-007-specialization-groups.md deleted file mode 100644 index 96df747fbe..0000000000 --- a/docs/architecture/adr-007-specialization-groups.md +++ /dev/null @@ -1,179 +0,0 @@ -# ADR 007: Specialization Groups - -## Changelog - -- 2019 Jul 31: Initial Draft - -## Context - -This idea was first conceived of in order to fulfill the use case of the -creation of a decentralized Computer Emergency Response Team (dCERT), whose -members would be elected by a governing community and would fulfill the role of -coordinating the community under emergency situations. This thinking -can be further abstracted into the conception of "blockchain specialization -groups". - -The creation of these groups are the beginning of specialization capabilities -within a wider blockchain community which could be used to enable a certain -level of delegated responsibilities. Examples of specialization which could be -beneficial to a blockchain community include: code auditing, emergency response, -code development etc. This type of community organization paves the way for -individual stakeholders to delegate votes by issue type, if in the future -governance proposals include a field for issue type. - - -## Decision - -A specialization group can be broadly broken down into the following functions -(herein containing examples): - - - Membership Admittance - - Membership Acceptance - - Membership Revocation - - (probably) Without Penalty - - member steps down (self-Revocation) - - replaced by new member from governance - - (probably) With Penalty - - due to breach of soft-agreement (determined through governance) - - due to breach of hard-agreement (determined by code) - - Execution of Duties - - Special transactions which only execute for members of a specialization - group (for example, dCERT members voting to turn off transaction routes in - an emergency scenario) - - Compensation - - Group compensation (further distribution decided by the specialization group) - - Individual compensation for all constituents of a group from the - greater community - -Membership admittance to a specialization group could take place over a wide -variety of mechanisms. The most obvious example is through a general vote among -the entire community, however in certain systems a community may want to allow -the members already in a specialization group to internally elect new members, -or maybe the community may assign a permission to a particular specialization -group to appoint members to other 3rd party groups. The sky is really the limit -as to how membership admittance can be structured. We attempt to capture -some of these possiblities in a common interface dubbed the `Electionator`. For -its initial implementation as a part of this ADR we recommend that the general -election abstraction (`Electionator`) is provided as well as a basic -implementation of that abstraction which allows for a continuous election of -members of a specialization group. - -``` golang -// The Electionator abstraction covers the concept space for -// a wide variety of election kinds. -type Electionator interface { - - // is the election object accepting votes. - Active() bool - - // functionality to execute for when a vote is cast in this election, here - // the vote field is anticipated to be marshalled into a vote type used - // by an election. - // - // NOTE There are no explicit ids here. Just votes which pertain specifically - // to one electionator. Anyone can create and send a vote to the electionator item - // which will presumably attempt to marshal those bytes into a particular struct - // and apply the vote information in some arbitrary way. There can be multiple - // Electionators within the Cosmos-Hub for multiple specialization groups, votes - // would need to be routed to the Electionator upstream of here. - Vote(addr sdk.AccAddress, vote []byte) - - // here lies all functionality to authenticate and execute changes for - // when a member accepts being elected - AcceptElection(sdk.AccAddress) - - // Register a revoker object - RegisterRevoker(Revoker) - - // No more revokers may be registered after this function is called - SealRevokers() - - // register hooks to call when an election actions occur - RegisterHooks(ElectionatorHooks) - - // query for the current winner(s) of this election based on arbitrary - // election ruleset - QueryElected() []sdk.AccAddress - - // query metadata for an address in the election this - // could include for example position that an address - // is being elected for within a group - // - // this metadata may be directly related to - // voting information and/or privileges enabled - // to members within a group. - QueryMetadata(sdk.AccAddress) []byte -} - -// ElectionatorHooks, once registered with an Electionator, -// trigger execution of relevant interface functions when -// Electionator events occur. -type ElectionatorHooks interface { - AfterVoteCast(addr sdk.AccAddress, vote []byte) - AfterMemberAccepted(addr sdk.AccAddress) - AfterMemberRevoked(addr sdk.AccAddress, cause []byte) -} - -// Revoker defines the function required for a membership revocation rule-set -// used by a specialization group. This could be used to create self revoking, -// and evidence based revoking, etc. Revokers types may be created and -// reused for different election types. -// -// When revoking the "cause" bytes may be arbitrarily marshalled into evidence, -// memos, etc. -type Revoker interface { - RevokeName() string // identifier for this revoker type - RevokeMember(addr sdk.AccAddress, cause []byte) error -} -``` - -Certain level of commonality likely exists between the existing code within -`x/governance` and required functionality of elections. This common -functionality should be abstracted during implementation. Similarly for each -vote implementation client CLI/REST functionality should be abstracted -to be reused for multiple elections. - -The specialization group abstraction firstly extends the `Electionator` -but also further defines traits of the group. - -``` golang -type SpecializationGroup interface { - Electionator - GetName() string - GetDescription() string - - // general soft contract the group is expected - // to fulfill with the greater community - GetContract() string - - // messages which can be executed by the members of the group - Handler(ctx sdk.Context, msg sdk.Msg) sdk.Result - - // logic to be executed at endblock, this may for instance - // include payment of a stipend to the group members - // for participation in the security group. - EndBlocker(ctx sdk.Context) -} -``` - -## Status - -> Proposed - -## Consequences - -### Positive - - - increases specialization capabilities of a blockchain - - improve abstractions in `x/gov/` such that they can be used with specialization groups - -### Negative - - - could be used to increase centralization within a community - -### Neutral - -## References - - - (dCERT ADR)[./adr-008-dCERT-group.md] - diff --git a/docs/architecture/adr-008-dCERT-group.md b/docs/architecture/adr-008-dCERT-group.md deleted file mode 100644 index 96109fc9b5..0000000000 --- a/docs/architecture/adr-008-dCERT-group.md +++ /dev/null @@ -1,167 +0,0 @@ -# ADR 008: Decentralized Computer Emergency Response Team (dCERT) Group - -## Changelog - -- 2019 Jul 31: Initial Draft - -## Context - -In order to reduce the number of parties involved with handling sensitive -information in an emergency scenario, we propose the creation of a -specialization group named The Decentralized Computer Emergency Response Team -(dCERT). Initially this group's role is intended to serve as coordinators -between various actors within a blockchain community such as validators, -bug-hunters, and developers. During a time of crisis, the dCERT group would -aggregate and relay input from a variety of stakeholders to the developers who -are actively devising a patch to the software, this way sensitive information -does not need to be publicly disclosed while some input from the community can -still be gained. - -Additionally, a special privilege is proposed for the dCERT group: the capacity -to "circuit-break" (aka. temporarily disable) a particular message path. Note -that this privilege should be enabled/disabled globally with a governance -parameter such that this privilege could start disabled and later be enabled -through a parameter change proposal, once a dCERT group has been established. - -In the future it is foreseeable that the community may wish to expand the roles -of dCERT with further responsibilities such as the capacity to "pre-approve" a -security update on behalf of the community prior to a full community -wide vote whereby the sensitive information would be revealed prior to a -vulnerability being patched on the live network. - -## Decision - -The dCERT group is proposed to include an implementation of a `SpecializationGroup` -as defined in [ADR 007](./adr-007-specialization-groups.md). This will include the -implementation of: - - continuous voting - - slashing due to breach of soft contract - - revoking a member due to breach of soft contract - - emergency disband of the entire dCERT group (ex. for colluding maliciously) - - compensation stipend from the community pool or other means decided by - governance - -This system necessitates the following new parameters: - - blockly stipend allowance per dCERT member - - maximum number of dCERT members - - required staked slashable tokens for each dCERT member - - quorum for suspending a particular member - - proposal wager for disbanding the dCERT group - - stabilization period for dCERT member transition - - circuit break dCERT privileges enabled - -These parameters are expected to be implemented through the param keeper such -that governance may change them at any given point. - -### Continuous Voting Electionator - -An `Electionator` object is to be implemented as continuous voting and with the -following specifications: - - All delegation addresses may submit votes at any point which updates their - preferred representation on the dCERT group. - - Preferred representation may be arbitrarily split between addresses (ex. 50% - to John, 25% to Sally, 25% to Carol) - - In order for a new member to be added to the dCERT group they must - send a transaction accepting their admission at which point the validity of - their admission is to be confirmed. - - A sequence number is assigned when a member is added to dCERT group. - If a member leaves the dCERT group and then enters back, a new sequence number - is assigned. - - Addresses which control the greatest amount of preferred-representation are - eligible to join the dCERT group (up the _maximum number of dCERT members_). - If the dCERT group is already full and new member is admitted, the existing - dCERT member with the lowest amount of votes is kicked from the dCERT group. - - In the split situation where the dCERT group is full but a vying candidate - has the same amount of vote as an existing dCERT member, the existing - member should maintain its position. - - In the split situation where somebody must be kicked out but the two - addresses with the smallest number of votes have the same number of votes, - the address with the smallest sequence number maintains its position. - - A stabilization period can be optionally included to reduce the - "flip-flopping" of the dCERT membership tail members. If a stabilization - period is provided which is greater than 0, when members are kicked due to - insufficient support, a queue entry is created which documents which member is - to replace which other member. While this entry is in the queue, no new entries - to kick that same dCERT member can be made. When the entry matures at the - duration of the stabilization period, the new member is instantiated, and old - member kicked. - -### Staking/Slashing - -All members of the dCERT group must stake tokens _specifically_ to maintain -eligibility as a dCERT member. These tokens can be staked directly by the vying -dCERT member or out of the good will of a 3rd party (who shall gain no on-chain -benefits for doing so). This staking mechanism should use the existing global -unbonding time of tokens staked for network validator security. A dCERT member -can _only be_ a member if it has the required tokens staked under this -mechanism. If those tokens are unbonded then the dCERT member must be -automatically kicked from the group. - -Slashing of a particular dCERT member due to soft-contract breach should be -performed by governance on a per member basis based on the magnitude of the -breach. The process flow is anticipated to be that a dCERT member is suspended -by the dCERT group prior to being slashed by governance. - -Membership suspension by the dCERT group takes place through a voting procedure -by the dCERT group members. After this suspension has taken place, a governance -proposal to slash the dCERT member must be submitted, if the proposal is not -approved by the time the rescinding member has completed unbonding their -tokens, then the tokens are no longer staked and unable to be slashed. - -Additionally in the case of an emergency situation of a colluding and malicious -dCERT group, the community needs the capability to disband the entire dCERT -group and likely fully slash them. This could be achieved though a special new -proposal type (implemented as a general governance proposal) which would halt -the functionality of the dCERT group until the proposal was concluded. This -special proposal type would likely need to also have a fairly large wager which -could be slashed if the proposal creator was malicious. The reason a large -wager should be required is because as soon as the proposal is made, the -capability of the dCERT group to halt message routes is put on temporarily -suspended, meaning that a malicious actor who created such a proposal could -then potentially exploit a bug during this period of time, with no dCERT group -capable of shutting down the exploitable message routes. - -### dCERT membership transactions - -Active dCERT members - - change of the description of the dCERT group - - circuit break a message route - - vote to suspend a dCERT member. - -Here circuit-breaking refers to the capability to disable a groups of messages, -This could for instance mean: "disable all staking-delegation messages", or -"disable all distribution messages". This could be accomplished by verifying -that the message route has not been "circuit-broken" at CheckTx time (in -`baseapp/baseapp.go`). - -"unbreaking" a circuit is anticipated only to occur during a hard fork upgrade -meaning that no capability to unbreak a message route on a live chain is -required. - -Note also, that if there was a problem with governance voting (for instance a -capability to vote many times) then governance would be broken and should be -halted with this mechanism, it would be then up to the validator set to -coordinate and hard-fork upgrade to a patched version of the software where -governance is re-enabled (and fixed). If the dCERT group abuses this privilege -they should all be severely slashed. - -## Status - -> Proposed - -## Consequences - -### Positive - - - Potential to reduces the number of parties to coordinate with during an emergency - - Reduction in possibility of disclosing sensitive information to malicious parties - -### Negative - - - Centralization risks - -### Neutral - -## References - - (Specialization Groups ADR)[./adr-007-specialization-groups.md] diff --git a/docs/architecture/adr-009-evidence-module.md b/docs/architecture/adr-009-evidence-module.md deleted file mode 100644 index f6f47170c9..0000000000 --- a/docs/architecture/adr-009-evidence-module.md +++ /dev/null @@ -1,182 +0,0 @@ -# ADR 009: Evidence Module - -## Changelog - -- 2019 July 31: Initial draft -- 2019 October 24: Initial implementation - -## Status - -Accepted - -## Context - -In order to support building highly secure, robust and interoperable blockchain -applications, it is vital for the Cosmos SDK to expose a mechanism in which arbitrary -evidence can be submitted, evaluated and verified resulting in some agreed upon -penalty for any misbehavior committed by a validator, such as equivocation (double-voting), -signing when unbonded, signing an incorrect state transition (in the future), etc. -Furthermore, such a mechanism is paramount for any -[IBC](https://github.com/cosmos/ics/blob/master/ibc/2_IBC_ARCHITECTURE.md) or -cross-chain validation protocol implementation in order to support the ability -for any misbehavior to be relayed back from a collateralized chain to a primary -chain so that the equivocating validator(s) can be slashed. - -## Decision - -We will implement an evidence module in the Cosmos SDK supporting the following -functionality: - -- Provide developers with the abstractions and interfaces necessary to define - custom evidence messages, message handlers, and methods to slash and penalize - accordingly for misbehavior. -- Support the ability to route evidence messages to handlers in any module to - determine the validity of submitted misbehavior. -- Support the ability, through governance, to modify slashing penalties of any - evidence type. -- Querier implementation to support querying params, evidence types, params, and - all submitted valid misbehavior. - -### Types - -First, we define the `Evidence` interface type. The `x/evidence` module may implement -its own types that can be used by many chains (e.g. `CounterFactualEvidence`). -In addition, other modules may implement their own `Evidence` types in a similar -manner in which governance is extensible. It is important to note any concrete -type implementing the `Evidence` interface may include arbitrary fields such as -an infraction time. We want the `Evidence` type to remain as flexible as possible. - -When submitting evidence to the `x/evidence` module, the concrete type must provide -the validator's consensus address, which should be known by the `x/slashing` -module (assuming the infraction is valid), the height at which the infraction -occurred and the validator's power at same height in which the infraction occurred. - -```go -type Evidence interface { - Route() string - Type() string - String() string - Hash() HexBytes - ValidateBasic() error - - // The consensus address of the malicious validator at time of infraction - GetConsensusAddress() ConsAddress - - // Height at which the infraction occurred - GetHeight() int64 - - // The total power of the malicious validator at time of infraction - GetValidatorPower() int64 - - // The total validator set power at time of infraction - GetTotalPower() int64 -} -``` - -### Routing & Handling - -Each `Evidence` type must map to a specific unique route and be registered with -the `x/evidence` module. It accomplishes this through the `Router` implementation. - -```go -type Router interface { - AddRoute(r string, h Handler) Router - HasRoute(r string) bool - GetRoute(path string) Handler - Seal() -} -``` - -Upon successful routing through the `x/evidence` module, the `Evidence` type -is passed through a `Handler`. This `Handler` is responsible for executing all -corresponding business logic necessary for verifying the evidence as valid. In -addition, the `Handler` may execute any necessary slashing and potential jailing. -Since slashing fractions will typically result from some form of static functions, -allow the `Handler` to do this provides the greatest flexibility. An example could -be `k * evidence.GetValidatorPower()` where `k` is an on-chain parameter controlled -by governance. The `Evidence` type should provide all the external information -necessary in order for the `Handler` to make the necessary state transitions. -If no error is returned, the `Evidence` is considered valid. - -```go -type Handler func(Context, Evidence) error -``` - -### Submission - -`Evidence` is submitted through a `MsgSubmitEvidence` message type which is internally -handled by the `x/evidence` module's `SubmitEvidence`. - -```go -type MsgSubmitEvidence struct { - Evidence -} - -func handleMsgSubmitEvidence(ctx Context, keeper Keeper, msg MsgSubmitEvidence) Result { - if err := keeper.SubmitEvidence(ctx, msg.Evidence); err != nil { - return err.Result() - } - - // emit events... - - return Result{ - // ... - } -} -``` - -The `x/evidence` module's keeper is responsible for matching the `Evidence` against -the module's router and invoking the corresponding `Handler` which may include -slashing and jailing the validator. Upon success, the submitted evidence is persisted. - -```go -func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { - handler := keeper.router.GetRoute(evidence.Route()) - if err := handler(ctx, evidence); err != nil { - return ErrInvalidEvidence(keeper.codespace, err) - } - - keeper.setEvidence(ctx, evidence) - return nil -} -``` - -### Genesis - -Finally, we need to represent the genesis state of the `x/evidence` module. The -module only needs a list of all submitted valid infractions and any necessary params -for which the module needs in order to handle submitted evidence. The `x/evidence` -module will naturally define and route native evidence types for which it'll most -likely need slashing penalty constants for. - -```go -type GenesisState struct { - Params Params - Infractions []Evidence -} -``` - -## Consequences - -### Positive - -- Allows the state machine to process misbehavior submitted on-chain and penalize - validators based on agreed upon slashing parameters. -- Allows evidence types to be defined and handled by any module. This further allows - slashing and jailing to be defined by more complex mechanisms. -- Does not solely rely on Tendermint to submit evidence. - -### Negative - -- No easy way to introduce new evidence types through governance on a live chain - due to the inability to introduce the new evidence type's corresponding handler - -### Neutral - -- Should we persist infractions indefinitely? Or should we rather rely on events? - -## References - -- [ICS](https://github.com/cosmos/ics) -- [IBC Architecture](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md) -- [Tendermint Fork Accountability](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md) diff --git a/docs/architecture/adr-010-modular-antehandler.md b/docs/architecture/adr-010-modular-antehandler.md deleted file mode 100644 index 56b2718b26..0000000000 --- a/docs/architecture/adr-010-modular-antehandler.md +++ /dev/null @@ -1,283 +0,0 @@ -# ADR 010: Modular AnteHandler - -## Changelog - -- 2019 Aug 31: Initial draft - -## Context - -The current AnteHandler design allows users to either use the default AnteHandler provided in `x/auth` or to build their own AnteHandler from scratch. Ideally AnteHandler functionality is split into multiple, modular functions that can be chained together along with custom ante-functions so that users do not have to rewrite common antehandler logic when they want to implement custom behavior. - -For example, let's say a user wants to implement some custom signature verification logic. In the current codebase, the user would have to write their own Antehandler from scratch largely reimplementing much of the same code and then set their own custom, monolithic antehandler in the baseapp. Instead, we would like to allow users to specify custom behavior when necessary and combine them with default ante-handler functionality in a way that is as modular and flexible as possible. - -## Proposals - -### Per-Module AnteHandler - -One approach is to use the [ModuleManager](https://godoc.org/github.com/cosmos/cosmos-sdk/types/module) and have each module implement its own antehandler if it requires custom antehandler logic. The ModuleManager can then be passed in an AnteHandler order in the same way it has an order for BeginBlockers and EndBlockers. The ModuleManager returns a single AnteHandler function that will take in a tx and run each module's `AnteHandle` in the specified order. The module manager's AnteHandler is set as the baseapp's AnteHandler. - -Pros: -1. Simple to implement -2. Utilizes the existing ModuleManager architecture - -Cons: -1. Improves granularity but still cannot get more granular than a per-module basis. e.g. If auth's `AnteHandle` function is in charge of validating memo and signatures, users cannot swap the signature-checking functionality while keeping the rest of auth's `AnteHandle` functionality. -2. Module AnteHandler are run one after the other. There is no way for one AnteHandler to wrap or "decorate" another. - -### Decorator Pattern - -The [weave project](https://github.com/iov-one/weave) achieves AnteHandler modularity through the use of a decorator pattern. The interface is designed as follows: - -```go -// Decorator wraps a Handler to provide common functionality -// like authentication, or fee-handling, to many Handlers -type Decorator interface { - Check(ctx Context, store KVStore, tx Tx, next Checker) (*CheckResult, error) - Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) (*DeliverResult, error) -} -``` - -Each decorator works like a modularized SDK antehandler function, but it can take in a `next` argument that may be another decorator or a Handler (which does not take in a next argument). These decorators can be chained together, one decorator being passed in as the `next` argument of the previous decorator in the chain. The chain ends in a Router which can take a tx and route to the appropriate msg handler. - -A key benefit of this approach is that one Decorator can wrap its internal logic around the next Checker/Deliverer. A weave Decorator may do the following: - -```go -// Example Decorator's Deliver function -func (example Decorator) Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) { - // Do some pre-processing logic - - res, err := next.Deliver(ctx, store, tx) - - // Do some post-processing logic given the result and error -} -``` - -Pros: -1. Weave Decorators can wrap over the next decorator/handler in the chain. The ability to both pre-process and post-process may be useful in certain settings. -2. Provides a nested modular structure that isn't possible in the solution above, while also allowing for a linear one-after-the-other structure like the solution above. - -Cons: -1. It is hard to understand at first glance the state updates that would occur after a Decorator runs given the `ctx`, `store`, and `tx`. A Decorator can have an arbitrary number of nested Decorators being called within its function body, each possibly doing some pre- and post-processing before calling the next decorator on the chain. Thus to understand what a Decorator is doing, one must also understand what every other decorator further along the chain is also doing. This can get quite complicated to understand. A linear, one-after-the-other approach while less powerful, may be much easier to reason about. - -### Chained Micro-Functions - -The benefit of Weave's approach is that the Decorators can be very concise, which when chained together allows for maximum customizability. However, the nested structure can get quite complex and thus hard to reason about. - -Another approach is to split the AnteHandler functionality into tightly scoped "micro-functions", while preserving the one-after-the-other ordering that would come from the ModuleManager approach. - -We can then have a way to chain these micro-functions so that they run one after the other. Modules may define multiple ante micro-functions and then also provide a default per-module AnteHandler that implements a default, suggested order for these micro-functions. - -Users can order the AnteHandlers easily by simply using the ModuleManager. The ModuleManager will take in a list of AnteHandlers and return a single AnteHandler that runs each AnteHandler in the order of the list provided. If the user is comfortable with the default ordering of each module, this is as simple as providing a list with each module's antehandler (exactly the same as BeginBlocker and EndBlocker). - -If however, users wish to change the order or add, modify, or delete ante micro-functions in anyway; they can always define their own ante micro-functions and add them explicitly to the list that gets passed into module manager. - -#### Default Workflow: - -This is an example of a user's AnteHandler if they choose not to make any custom micro-functions. - -##### SDK code: - -```go -// Chains together a list of AnteHandler micro-functions that get run one after the other. -// Returned AnteHandler will abort on first error. -func Chainer(order []AnteHandler) AnteHandler { - return func(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - for _, ante := range order { - ctx, err := ante(ctx, tx, simulate) - if err != nil { - return ctx, err - } - } - return ctx, err - } -} -``` - -```go -// AnteHandler micro-function to verify signatures -func VerifySignatures(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - // verify signatures - // Returns InvalidSignature Result and abort=true if sigs invalid - // Return OK result and abort=false if sigs are valid -} - -// AnteHandler micro-function to validate memo -func ValidateMemo(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - // validate memo -} - -// Auth defines its own default ante-handler by chaining its micro-functions in a recommended order -AuthModuleAnteHandler := Chainer([]AnteHandler{VerifySignatures, ValidateMemo}) -``` - -```go -// Distribution micro-function to deduct fees from tx -func DeductFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - // Deduct fees from tx - // Abort if insufficient funds in account to pay for fees -} - -// Distribution micro-function to check if fees > mempool parameter -func CheckMempoolFees(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - // If CheckTx: Abort if the fees are less than the mempool's minFee parameter -} - -// Distribution defines its own default ante-handler by chaining its micro-functions in a recommended order -DistrModuleAnteHandler := Chainer([]AnteHandler{CheckMempoolFees, DeductFees}) -``` - -```go -type ModuleManager struct { - // other fields - AnteHandlerOrder []AnteHandler -} - -func (mm ModuleManager) GetAnteHandler() AnteHandler { - retun Chainer(mm.AnteHandlerOrder) -} -``` - -##### User Code: - -```go -// Note: Since user is not making any custom modifications, we can just SetAnteHandlerOrder with the default AnteHandlers provided by each module in our preferred order -moduleManager.SetAnteHandlerOrder([]AnteHandler(AuthModuleAnteHandler, DistrModuleAnteHandler)) - -app.SetAnteHandler(mm.GetAnteHandler()) -``` - -#### Custom Workflow - -This is an example workflow for a user that wants to implement custom antehandler logic. In this example, the user wants to implement custom signature verification and change the order of antehandler so that validate memo runs before signature verification. - -##### User Code - -```go -// User can implement their own custom signature verification antehandler micro-function -func CustomSigVerify(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - // do some custom signature verification logic -} -``` - -```go -// Micro-functions allow users to change order of when they get executed, and swap out default ante-functionality with their own custom logic. -// Note that users can still chain the default distribution module handler, and auth micro-function along with their custom ante function -moduleManager.SetAnteHandlerOrder([]AnteHandler(ValidateMemo, CustomSigVerify, DistrModuleAnteHandler)) -``` - -Pros: -1. Allows for ante functionality to be as modular as possible. -2. For users that do not need custom ante-functionality, there is little difference between how antehandlers work and how BeginBlock and EndBlock work in ModuleManager. -3. Still easy to understand - -Cons: -1. Cannot wrap antehandlers with decorators like you can with Weave. - -### Simple Decorators - -This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the SDK and maximizing simplicity. Like Weave decorators, this approach allows one `AnteDecorator` to wrap the next AnteHandler to do pre- and post-processing on the result. This is useful since decorators can do defer/cleanups after an AnteHandler returns as well as perform some setup beforehand. Unlike Weave decorators, these `AnteDecorator` functions can only wrap over the AnteHandler rather than the entire handler execution path. This is deliberate as we want decorators from different modules to perform authentication/validation on a `tx`. However, we do not want decorators being capable of wrapping and modifying the results of a `MsgHandler`. - -In addition, this approach will not break any core SDK API's. Since we preserve the notion of an AnteHandler and still set a single AnteHandler in baseapp, the decorator is simply an additional approach available for users that desire more customization. The API of modules (namely `x/auth`) may break with this approach, but the core API remains untouched. - -Allow Decorator interface that can be chained together to create an SDK AnteHandler. - -This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with SDK provided decorators in the order they wish. - -```go -// An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler -type AnteDecorator interface { - AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) -} -``` - -```go -// ChainAnteDecorators will recursively link all of the AnteDecorators in the chain and return a final AnteHandler function -// This is done to preserve the ability to set a single AnteHandler function in the baseapp. -func ChainAnteDecorators(chain ...AnteDecorator) AnteHandler { - if len(chain) == 1 { - return func(ctx Context, tx Tx, simulate bool) { - chain[0].AnteHandle(ctx, tx, simulate, nil) - } - } - return func(ctx Context, tx Tx, simulate bool) { - chain[0].AnteHandle(ctx, tx, simulate, ChainAnteDecorators(chain[1:])) - } -} -``` - -#### Example Code - -Define AnteDecorator functions - -```go -// Setup GasMeter, catch OutOfGasPanic and handle appropriately -type SetUpContextDecorator struct{} - -func (sud SetUpContextDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { - ctx.GasMeter = NewGasMeter(tx.Gas) - - defer func() { - // recover from OutOfGas panic and handle appropriately - } - - return next(ctx, tx, simulate) -} - -// Signature Verification decorator. Verify Signatures and move on -type SigVerifyDecorator struct{} - -func (svd SigVerifyDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { - // verify sigs. Return error if invalid - - // call next antehandler if sigs ok - return next(ctx, tx, simulate) -} - -// User-defined Decorator. Can choose to pre- and post-process on AnteHandler -type UserDefinedDecorator struct{ - // custom fields -} - -func (udd UserDefinedDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { - // pre-processing logic - - ctx, err = next(ctx, tx, simulate) - - // post-processing logic -} -``` - -Link AnteDecorators to create a final AnteHandler. Set this AnteHandler in baseapp. - -```go -// Create final antehandler by chaining the decorators together -antehandler := ChainAnteDecorators(NewSetUpContextDecorator(), NewSigVerifyDecorator(), NewUserDefinedDecorator()) - -// Set chained Antehandler in the baseapp -bapp.SetAnteHandler(antehandler) -``` - -Pros: - -1. Allows one decorator to pre- and post-process the next AnteHandler, similar to the Weave design. -2. Do not need to break baseapp API. Users can still set a single AnteHandler if they choose. - -Cons: - -1. Decorator pattern may have a deeply nested structure that is hard to understand, this is mitigated by having the decorator order explicitly listed in the `ChainAnteDecorators` function. -2. Does not make use of the ModuleManager design. Since this is already being used for BeginBlocker/EndBlocker, this proposal seems unaligned with that design pattern. - -## Status - -> Accepted Simple Decorators approach - -## Consequences - -Since pros and cons are written for each approach, it is omitted from this section - -## References - -- [#4572](https://github.com/cosmos/cosmos-sdk/issues/4572): Modular AnteHandler Issue -- [#4582](https://github.com/cosmos/cosmos-sdk/pull/4583): Initial Implementation of Per-Module AnteHandler Approach -- [Weave Decorator Code](https://github.com/iov-one/weave/blob/master/handler.go#L35) -- [Weave Design Videos](https://vimeo.com/showcase/6189877) diff --git a/docs/architecture/adr-011-generalize-genesis-accounts.md b/docs/architecture/adr-011-generalize-genesis-accounts.md deleted file mode 100644 index 136480d92c..0000000000 --- a/docs/architecture/adr-011-generalize-genesis-accounts.md +++ /dev/null @@ -1,170 +0,0 @@ -# ADR 011: Generalize Genesis Accounts - -## Changelog - -- 2019-08-30: initial draft - -## Context - -Currently, the SDK allows for custom account types; the `auth` keeper stores any type fulfilling its `Account` interface. However `auth` does not handle exporting or loading accounts to/from a genesis file, this is done by `genaccounts`, which only handles one of 4 concrete account types (`BaseAccount`, `ContinuousVestingAccount`, `DelayedVestingAccount` and `ModuleAccount`). - -Projects desiring to use custom accounts (say custom vesting accounts) need to fork and modify `genaccounts`. - -## Decision - -In summary, we will (un)marshal all accounts (interface types) directly using amino, rather than converting to `genaccounts`’s `GenesisAccount` type. Since doing this removes the majority of `genaccounts`'s code, we will merge `genaccounts` into `auth`. Marshalled accounts will be stored in `auth`'s genesis state. - -Detailed changes: - -### 1) (Un)Marshal accounts directly using amino - -The `auth` module's `GenesisState` gains a new field `Accounts`. Note these aren't of type `exported.Account` for reasons outlined in section 3. - -```go -// GenesisState - all auth state that must be provided at genesis -type GenesisState struct { - Params Params `json:"params" yaml:"params"` - Accounts []GenesisAccount `json:"accounts" yaml:"accounts"` -} -``` - -Now `auth`'s `InitGenesis` and `ExportGenesis` (un)marshal accounts as well as the defined params. - -```go -// InitGenesis - Init store state from genesis data -func InitGenesis(ctx sdk.Context, ak AccountKeeper, data GenesisState) { - ak.SetParams(ctx, data.Params) - // load the accounts - for _, a := range data.Accounts { - acc := ak.NewAccount(ctx, a) // set account number - ak.SetAccount(ctx, acc) - } -} - -// ExportGenesis returns a GenesisState for a given context and keeper -func ExportGenesis(ctx sdk.Context, ak AccountKeeper) GenesisState { - params := ak.GetParams(ctx) - - var genAccounts []exported.GenesisAccount - ak.IterateAccounts(ctx, func(account exported.Account) bool { - genAccount := account.(exported.GenesisAccount) - genAccounts = append(genAccounts, genAccount) - return false - }) - - return NewGenesisState(params, genAccounts) -} -``` - -### 2) Register custom account types on the `auth` codec - -The `auth` codec must have all custom account types registered to marshal them. We will follow the pattern established in `gov` for proposals. - -An example custom account definition: - -```go -import authtypes "github.com/line/lbm-sdk/v2/x/auth/types" - -// Register the module account type with the auth module codec so it can decode module accounts stored in a genesis file -func init() { - authtypes.RegisterAccountTypeCodec(ModuleAccount{}, "lbm-sdk/ModuleAccount") -} - -type ModuleAccount struct { - ... -``` - -The `auth` codec definition: - -```go -var ModuleCdc *codec.LegacyAmino - -func init() { - ModuleCdc = codec.NewLegacyAmino() - // register module msg's and Account interface - ... - // leave the codec unsealed -} - -// RegisterAccountTypeCodec registers an external account type defined in another module for the internal ModuleCdc. -func RegisterAccountTypeCodec(o interface{}, name string) { - ModuleCdc.RegisterConcrete(o, name, nil) -} -``` - -### 3) Genesis validation for custom account types - -Modules implement a `ValidateGenesis` method. As `auth` does not know of account implementations, accounts will need to validate themselves. - -We will unmarshal accounts into a `GenesisAccount` interface that includes a `Validate` method. - -```go -type GenesisAccount interface { - exported.Account - Validate() error -} -``` - -Then the `auth` `ValidateGenesis` function becomes: - -```go -// ValidateGenesis performs basic validation of auth genesis data returning an -// error for any failed validation criteria. -func ValidateGenesis(data GenesisState) error { - // Validate params - ... - - // Validate accounts - addrMap := make(map[string]bool, len(data.Accounts)) - for _, acc := range data.Accounts { - - // check for duplicated accounts - addrStr := acc.GetAddress().String() - if _, ok := addrMap[addrStr]; ok { - return fmt.Errorf("duplicate account found in genesis state; address: %s", addrStr) - } - addrMap[addrStr] = true - - // check account specific validation - if err := acc.Validate(); err != nil { - return fmt.Errorf("invalid account found in genesis state; address: %s, error: %s", addrStr, err.Error()) - } - - } - return nil -} -``` - -### 4) Move add-genesis-account cli to `auth` - -The `genaccounts` module contains a cli command to add base or vesting accounts to a genesis file. - -This will be moved to `auth`. We will leave it to projects to write their own commands to add custom accounts. An extensible cli handler, similar to `gov`, could be created but it is not worth the complexity for this minor use case. - -### 5) Update module and vesting accounts - -Under the new scheme, module and vesting account types need some minor updates: - -- Type registration on `auth`'s codec (shown above) -- A `Validate` method for each `Account` concrete type - -## Status - -Proposed - -## Consequences - -### Positive - -- custom accounts can be used without needing to fork `genaccounts` -- reduction in lines of code - -### Negative - -### Neutral - -- `genaccounts` module no longer exists -- accounts in genesis files are stored under `accounts` in `auth` rather than in the `genaccounts` module. --`add-genesis-account` cli command now in `auth` - -## References diff --git a/docs/architecture/adr-012-state-accessors.md b/docs/architecture/adr-012-state-accessors.md deleted file mode 100644 index b66e23eb67..0000000000 --- a/docs/architecture/adr-012-state-accessors.md +++ /dev/null @@ -1,155 +0,0 @@ -# ADR 012: State Accessors - -## Changelog - -- 2019 Sep 04: Initial draft - -## Context - -SDK modules currently use the `KVStore` interface and `Codec` to access their respective state. While -this provides a large degree of freedom to module developers, it is hard to modularize and the UX is -mediocre. - -First, each time a module tries to access the state, it has to marshal the value and set or get the -value and finally unmarshal. Usually this is done by declaring `Keeper.GetXXX` and `Keeper.SetXXX` functions, -which are repetitive and hard to maintain. - -Second, this makes it harder to align with the object capability theorem: the right to access the -state is defined as a `StoreKey`, which gives full access on the entire Merkle tree, so a module cannot -send the access right to a specific key-value pair (or a set of key-value pairs) to another module safely. - -Finally, because the getter/setter functions are defined as methods of a module's `Keeper`, the reviewers -have to consider the whole Merkle tree space when they reviewing a function accessing any part of the state. -There is no static way to know which part of the state that the function is accessing (and which is not). - -## Decision - -We will define a type named `Value`: - -```go -type Value struct { - m Mapping - key []byte -} -``` - -The `Value` works as a reference for a key-value pair in the state, where `Value.m` defines the key-value -space it will access and `Value.key` defines the exact key for the reference. - -We will define a type named `Mapping`: - -```go -type Mapping struct { - storeKey sdk.StoreKey - cdc *codec.LegacyAmino - prefix []byte -} -``` - -The `Mapping` works as a reference for a key-value space in the state, where `Mapping.storeKey` defines -the IAVL (sub-)tree and `Mapping.prefix` defines the optional subspace prefix. - -We will define the following core methods for the `Value` type: - -```go -// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal -func (Value) Get(ctx Context, ptr interface{}) {} - -// Get and unmarshal stored data, return error if not exists or cannot unmarshal -func (Value) GetSafe(ctx Context, ptr interface{}) {} - -// Get stored data as raw byte slice -func (Value) GetRaw(ctx Context) []byte {} - -// Marshal and set a raw value -func (Value) Set(ctx Context, o interface{}) {} - -// Check if a raw value exists -func (Value) Exists(ctx Context) bool {} - -// Delete a raw value value -func (Value) Delete(ctx Context) {} -``` - -We will define the following core methods for the `Mapping` type: - -```go -// Constructs key-value pair reference corresponding to the key argument in the Mapping space -func (Mapping) Value(key []byte) Value {} - -// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal -func (Mapping) Get(ctx Context, key []byte, ptr interface{}) {} - -// Get and unmarshal stored data, return error if not exists or cannot unmarshal -func (Mapping) GetSafe(ctx Context, key []byte, ptr interface{}) - -// Get stored data as raw byte slice -func (Mapping) GetRaw(ctx Context, key []byte) []byte {} - -// Marshal and set a raw value -func (Mapping) Set(ctx Context, key []byte, o interface{}) {} - -// Check if a raw value exists -func (Mapping) Has(ctx Context, key []byte) bool {} - -// Delete a raw value value -func (Mapping) Delete(ctx Context, key []byte) {} -``` - -Each method of the `Mapping` type that is passed the arugments `ctx`, `key`, and `args...` will proxy -the call to `Mapping.Value(key)` with arguments `ctx` and `args...`. - -In addition, we will define and provide a common set of types derived from the `Value` type: - -```go -type Boolean struct { Value } -type Enum struct { Value } -type Integer struct { Value; enc IntEncoding } -type String struct { Value } -// ... -``` - -Where the encoding schemes can be different, `o` arguments in core methods are typed, and `ptr` arguments -in core methods are replaced by explicit return types. - -Finally, we will define a family of types derived from the `Mapping` type: - -```go -type Indexer struct { - m Mapping - enc IntEncoding -} -``` - -Where the `key` argument in core method is typed. - -Some of the properties of the accessor types are: - -- State access happens only when a function which takes a `Context` as an argument is invoked -- Accessor type structs give rights to access the state only that the struct is referring, no other -- Marshalling/Unmarshalling happens implicitly within the core methods - -## Status - -Proposed - -## Consequences - -### Positive - -- Serialization will be done automatically -- Shorter code size, less boilerplate, better UX -- References to the state can be transferred safely -- Explicit scope of accessing - -### Negative - -- Serialization format will be hidden -- Different architecture from the current, but the use of accessor types can be opt-in -- Type-specific types (e.g. `Boolean` and `Integer`) have to be defined manually - -### Neutral - -## References - -- [#4554](https://github.com/cosmos/cosmos-sdk/issues/4554) diff --git a/docs/architecture/adr-013-metrics.md b/docs/architecture/adr-013-metrics.md deleted file mode 100644 index cf27d89648..0000000000 --- a/docs/architecture/adr-013-metrics.md +++ /dev/null @@ -1,157 +0,0 @@ -# ADR 013: Observability - -## Changelog - -- 20-01-2020: Initial Draft - -## Status - -Proposed - -## Context - -Telemetry is paramount into debugging and understanding what the application is doing and how it is -performing. We aim to expose metrics from modules and other core parts of the Cosmos SDK. - -In addition, we should aim to support multiple configurable sinks that an operator may choose from. -By default, when telemetry is enabled, the application should track and expose metrics that are -stored in-memory. The operator may choose to enable additional sinks, where we support only -[Prometheus](https://prometheus.io/) for now, as it's battle-tested, simple to setup, open source, -and is rich with ecosystem tooling. - -We must also aim to integrate metrics into the Cosmos SDK in the most seamless way possible such that -metrics may be added or removed at will and without much friction. To do this, we will use the -[go-metrics](https://github.com/armon/go-metrics) library. - -Finally, operators may enable telemetry along with specific configuration options. If enabled, metrics -will be exposed via `/metrics?format={text|prometheus}` via the API server. - -## Decision - -We will add an additional configuration block to `app.toml` that defines telemetry settings: - -```toml -############################################################################### -### Telemetry Configuration ### -############################################################################### - -[telemetry] - -# Prefixed with keys to separate services -service-name = {{ .Telemetry.ServiceName }} - -# Enabled enables the application telemetry functionality. When enabled, -# an in-memory sink is also enabled by default. Operators may also enabled -# other sinks such as Prometheus. -enabled = {{ .Telemetry.Enabled }} - -# Enable prefixing gauge values with hostname -enable-hostname = {{ .Telemetry.EnableHostname }} - -# Enable adding hostname to labels -enable-hostname-label = {{ .Telemetry.EnableHostnameLabel }} - -# Enable adding service to labels -enable-service-label = {{ .Telemetry.EnableServiceLabel }} - -# PrometheusRetentionTime, when positive, enables a Prometheus metrics sink. -prometheus-retention-time = {{ .Telemetry.PrometheusRetentionTime }} -``` - -The given configuration allows for two sinks -- in-memory and Prometheus. We create a `Metrics` -type that performs all the bootstrapping for the operator, so capturing metrics becomes seamless. - -```go -// Metrics defines a wrapper around application telemetry functionality. It allows -// metrics to be gathered at any point in time. When creating a Metrics object, -// internally, a global metrics is registered with a set of sinks as configured -// by the operator. In addition to the sinks, when a process gets a SIGUSR1, a -// dump of formatted recent metrics will be sent to STDERR. -type Metrics struct { - memSink *metrics.InmemSink - prometheusEnabled bool -} - -// Gather collects all registered metrics and returns a GatherResponse where the -// metrics are encoded depending on the type. Metrics are either encoded via -// Prometheus or JSON if in-memory. -func (m *Metrics) Gather(format string) (GatherResponse, error) { - switch format { - case FormatPrometheus: - return m.gatherPrometheus() - - case FormatText: - return m.gatherGeneric() - - case FormatDefault: - return m.gatherGeneric() - - default: - return GatherResponse{}, fmt.Errorf("unsupported metrics format: %s", format) - } -} -``` - -In addition, `Metrics` allows us to gather the current set of metrics at any given point in time. An -operator may also choose to send a signal, SIGUSR1, to dump and print formatted metrics to STDERR. - -During an application's bootstrapping and construction phase, if `Telemetry.Enabled` is `true`, the -API server will create an instance of a reference to `Metrics` object and will register a metrics -handler accordingly. - -```go -func (s *Server) Start(cfg config.Config) error { - // ... - - if cfg.Telemetry.Enabled { - m, err := telemetry.New(cfg.Telemetry) - if err != nil { - return err - } - - s.metrics = m - s.registerMetrics() - } - - // ... -} - -func (s *Server) registerMetrics() { - metricsHandler := func(w http.ResponseWriter, r *http.Request) { - format := strings.TrimSpace(r.FormValue("format")) - - gr, err := s.metrics.Gather(format) - if err != nil { - rest.WriteErrorResponse(w, http.StatusBadRequest, fmt.Sprintf("failed to gather metrics: %s", err)) - return - } - - w.Header().Set("Content-Type", gr.ContentType) - _, _ = w.Write(gr.Metrics) - } - - s.Router.HandleFunc("/metrics", metricsHandler).Methods("GET") -} -``` - -Application developers may track counters, gauges, summaries, and key/value metrics. There is no -additional lifting required by modules to leverage profiling metrics. To do so, it's as simple as: - -```go -func (k BaseKeeper) MintCoins(ctx sdk.Context, moduleName string, amt sdk.Coins) error { - defer metrics.MeasureSince(time.Now(), "MintCoins") - // ... -} -``` - -## Consequences - -### Positive - -- Exposure into the performance and behavior of an application - -### Negative - -### Neutral - -## References diff --git a/docs/architecture/adr-014-proportional-slashing.md b/docs/architecture/adr-014-proportional-slashing.md deleted file mode 100644 index d481916343..0000000000 --- a/docs/architecture/adr-014-proportional-slashing.md +++ /dev/null @@ -1,85 +0,0 @@ -# ADR 14: Proportional Slashing - -## Changelog - -- 2019-10-15: Initial draft -- 2020-05-25: Removed correlation root slashing -- 2020-07-01: Updated to include S-curve function instead of linear - -## Context - -In Proof of Stake-based chains, centralization of consensus power amongst a small set of validators can cause harm to the network due to increased risk of censorship, liveness failure, fork attacks, etc. However, while this centralization causes a negative externality to the network, it is not directly felt by the delegators contributing towards delegating towards already large validators. We would like a way to pass on the negative externality cost of centralization onto those large validators and their delegators. - -## Decision - -### Design - -To solve this problem, we will implement a procedure called Proportional Slashing. The desire is that the larger a validator is, the more they should be slashed. The first naive attempt is to make a validator's slash percent proportional to their share of consensus voting power. - -``` -slash_amount = k * power // power is the faulting validator's voting power and k is some on-chain constant -``` - -However, this will incentivize validators with large amounts of stake to split up their voting power amongst accounts (sybil attack), so that if they fault, they all get slashed at a lower percent. The solution to this is to take into account not just a validator's own voting percentage, but also the voting percentage of all the other validators who get slashed in a specified time frame. - -``` -slash_amount = k * (power_1 + power_2 + ... + power_n) // where power_i is the voting power of the ith validator faulting in the specified time frame and k is some on-chain constant -``` - -Now, if someone splits a validator of 10% into two validators of 5% each which both fault, then they both fault in the same time frame, they both will get slashed at the sum 10% amount. - -However in practice, we likely don't want a linear relation between amount of stake at fault, and the percentage of stake to slash. In particular, solely 5% of stake double signing effectively did nothing to majorly threaten security, whereas 30% of stake being at fault clearly merits a large slashing factor, due to being very close to the point at which Tendermint security is threatened. A linear relation would require a factor of 6 gap between these two, whereas the difference in risk posed to the network is much larger. We propose using S-curves (formally [logistic functions](https://en.wikipedia.org/wiki/Logistic_function) to solve this). S-Curves capture the desired criterion quite well. They allow the slashing factor to be minimal for small values, and then grow very rapidly near some threshold point where the risk posed becomes notable. - -#### Parameterization - -This requires parameterizing a logistic function. It is very well understood how to parameterize this. It has four parameters: -1) A minimum slashing factor -2) A maximum slashing factor -3) The inflection point of the S-curve (essentially where do you want to center the S) -4) The rate of growth of the S-curve (How elongated is the S) - -#### Correlation across non-sybil validators - -One will note, that this model doesn't differentiate between multiple validators run by the same operators vs validators run by different operators. This can be seen as an additional benefit in fact. It incentivizes validators to differentiate their setups from other validators, to avoid having correlated faults with them or else they risk a higher slash. So for example, operators should avoid using the same popular cloud hosting platforms or using the same Staking as a Service providers. This will lead to a more resilient and decentralized network. - -#### Griefing - -Griefing, the act of intentionally getting oneself slashed in order to make another's slash worse, could be a concern here. However, using the protocol described here, the attacker also gets equally impacted by the grief as the victim, so it would not provide much benefit to the griefer. - -### Implementation - -In the slashing module, we will add two queues that will track all of the recent slash events. For double sign faults, we will define "recent slashes" as ones that have occured within the last `unbonding period`. For liveness faults, we will define "recent slashes" as ones that have occured withing the last `jail period`. - -``` -type SlashEvent struct { - Address sdk.ValAddress - ValidatorVotingPercent sdk.Dec - SlashedSoFar sdk.Dec -} -``` - -These slash events will be pruned from the queue once they are older than their respective "recent slash period". - -Whenever a new slash occurs, a `SlashEvent` struct is created with the faulting validator's voting percent and a `SlashedSoFar` of 0. Because recent slash events are pruned before the unbonding period and unjail period expires, it should not be possible for the same validator to have multiple SlashEvents in the same Queue at the same time. - -We then will iterate over all the SlashEvents in the queue, adding their `ValidatorVotingPercent` to calculate the new percent to slash all the validators in the queue at, using the "Square of Sum of Roots" formula introduced above. - -Once we have the `NewSlashPercent`, we then iterate over all the `SlashEvent`s in the queue once again, and if `NewSlashPercent > SlashedSoFar` for that SlashEvent, we call the `staking.Slash(slashEvent.Address, slashEvent.Power, Math.Min(Math.Max(minSlashPercent, NewSlashPercent - SlashedSoFar), maxSlashPercent)` (we pass in the power of the validator before any slashes occured, so that we slash the right amount of tokens). We then set `SlashEvent.SlashedSoFar` amount to `NewSlashPercent`. - - -## Status - -Proposed - -## Consequences - -### Positive - -- Increases decentralization by disincentivizing delegating to large validators -- Incentivizes Decorrelation of Validators -- More severely punishes attacks than accidental faults -- More flexibility in slashing rates parameterization - -### Negative - -- More computationally expensive than current implementation. Will require more data about "recent slashing events" to be stored on chain. diff --git a/docs/architecture/adr-015-ibc-packet-receiver.md b/docs/architecture/adr-015-ibc-packet-receiver.md deleted file mode 100644 index 924ddc7eb6..0000000000 --- a/docs/architecture/adr-015-ibc-packet-receiver.md +++ /dev/null @@ -1,299 +0,0 @@ -# ADR 015: IBC Packet Receiver - -## Changelog - -- 2019 Oct 22: Initial Draft - -## Context - -[ICS 26 - Routing Module](https://github.com/cosmos/ics/tree/master/spec/ics-026-routing-module) defines a function [`handlePacketRecv`](https://github.com/cosmos/ics/tree/master/spec/ics-026-routing-module#packet-relay). - -In ICS 26, the routing module is defined as a layer above each application module -which verifies and routes messages to the destination modules. It is possible to -implement it as a separate module, however, we already have functionality to route -messages upon the destination identifiers in the baseapp. This ADR suggests -to utilize existing `baseapp.router` to route packets to application modules. - -Generally, routing module callbacks have two separate steps in them, -verification and execution. This corresponds to the `AnteHandler`-`Handler` -model inside the SDK. We can do the verification inside the `AnteHandler` -in order to increase developer ergonomics by reducing boilerplate -verification code. - -For atomic multi-message transaction, we want to keep the IBC related -state modification to be preserved even the application side state change -reverts. One of the example might be IBC token sending message following with -stake delegation which uses the tokens received by the previous packet message. -If the token receiving fails for any reason, we might not want to keep -executing the transaction, but we also don't want to abort the transaction -or the sequence and commitment will be reverted and the channel will be stuck. -This ADR suggests new `CodeType`, `CodeTxBreak`, to fix this problem. - -## Decision - -`PortKeeper` will have the capability key that is able to access only the -channels bound to the port. Entities that hold a `PortKeeper` will be -able to call the methods on it which are corresponding with the methods with -the same names on the `ChannelKeeper`, but only with the -allowed port. `ChannelKeeper.Port(string, ChannelChecker)` will be defined to -easily construct a capability-safe `PortKeeper`. This will be addressed in -another ADR and we will use insecure `ChannelKeeper` for now. - -`baseapp.runMsgs` will break the loop over the messages if one of the handlers -returns `!Result.IsOK()`. However, the outer logic will write the cached -store if `Result.IsOK() || Result.Code.IsBreak()`. `Result.Code.IsBreak()` if -`Result.Code == CodeTxBreak`. - -```go -func (app *BaseApp) runTx(tx Tx) (result Result) { - msgs := tx.GetMsgs() - - // AnteHandler - if app.anteHandler != nil { - anteCtx, msCache := app.cacheTxContext(ctx) - newCtx, err := app.anteHandler(anteCtx, tx) - if !newCtx.IsZero() { - ctx = newCtx.WithMultiStore(ms) - } - - if err != nil { - // error handling logic - return res - } - - msCache.Write() - } - - // Main Handler - runMsgCtx, msCache := app.cacheTxContext(ctx) - result = app.runMsgs(runMsgCtx, msgs) - // BEGIN modification made in this ADR - if result.IsOK() || result.IsBreak() { - // END - msCache.Write() - } - - return result -} -``` - -The Cosmos SDK will define an `AnteDecorator` for IBC packet receiving. The -`AnteDecorator` will iterate over the messages included in the transaction, type -`switch` to check whether the message contains an incoming IBC packet, and if so -verify the Merkle proof. - -```go -type ProofVerificationDecorator struct { - clientKeeper ClientKeeper - channelKeeper ChannelKeeper -} - -func (pvr ProofVerificationDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (Context, error) { - for _, msg := range tx.GetMsgs() { - var err error - switch msg := msg.(type) { - case client.MsgUpdateClient: - err = pvr.clientKeeper.UpdateClient(msg.ClientID, msg.Header) - case channel.MsgPacket: - err = pvr.channelKeeper.RecvPacket(msg.Packet, msg.Proofs, msg.ProofHeight) - case chanel.MsgAcknowledgement: - err = pvr.channelKeeper.AcknowledgementPacket(msg.Acknowledgement, msg.Proof, msg.ProofHeight) - case channel.MsgTimeoutPacket: - err = pvr.channelKeeper.TimeoutPacket(msg.Packet, msg.Proof, msg.ProofHeight, msg.NextSequenceRecv) - case channel.MsgChannelOpenInit; - err = pvr.channelKeeper.CheckOpen(msg.PortID, msg.ChannelID, msg.Channel) - default: - continue - } - - if err != nil { - return ctx, err - } - } - - return next(ctx, tx, simulate) -} -``` - -Where `MsgUpdateClient`, `MsgPacket`, `MsgAcknowledgement`, `MsgTimeoutPacket` -are `sdk.Msg` types correspond to `handleUpdateClient`, `handleRecvPacket`, -`handleAcknowledgementPacket`, `handleTimeoutPacket` of the routing module, -respectively. - -The side effects of `RecvPacket`, `VerifyAcknowledgement`, -`VerifyTimeout` will be extracted out into separated functions, -`WriteAcknowledgement`, `DeleteCommitment`, `DeleteCommitmentTimeout`, respectively, -which will be called by the application handlers after the execution. - -`WriteAcknowledgement` writes the acknowledgement to the state that can be -verified by the counter-party chain and increments the sequence to prevent -double execution. `DeleteCommitment` will delete the commitment stored, -`DeleteCommitmentTimeout` will delete the commitment and close channel in case -of ordered channel. - -```go -func (keeper ChannelKeeper) WriteAcknowledgement(ctx Context, packet Packet, ack []byte) { - keeper.SetPacketAcknowledgement(ctx, packet.GetDestPort(), packet.GetDestChannel(), packet.GetSequence(), ack) - keeper.SetNextSequenceRecv(ctx, packet.GetDestPort(), packet.GetDestChannel(), packet.GetSequence()) -} - -func (keeper ChannelKeeper) DeleteCommitment(ctx Context, packet Packet) { - keeper.deletePacketCommitment(ctx, packet.GetSourcePort(), packet.GetSourceChannel(), packet.GetSequence()) -} - -func (keeper ChannelKeeper) DeleteCommitmentTimeout(ctx Context, packet Packet) { - k.deletePacketCommitment(ctx, packet.GetSourcePort(), packet.GetSourceChannel(), packet.GetSequence()) - - if channel.Ordering == types.ORDERED [ - channel.State = types.CLOSED - k.SetChannel(ctx, packet.GetSourcePort(), packet.GetSourceChannel(), channel) - } -} -``` - -Each application handler should call respective finalization methods on the `PortKeeper` -in order to increase sequence (in case of packet) or remove the commitment -(in case of acknowledgement and timeout). -Calling those functions implies that the application logic has successfully executed. -However, the handlers can return `Result` with `CodeTxBreak` after calling those methods -which will persist the state changes that has been already done but prevent any further -messages to be executed in case of semantically invalid packet. This will keep the sequence -increased in the previous IBC packets(thus preventing double execution) without -proceeding to the following messages. -In any case the application modules should never return state reverting result, -which will make the channel unable to proceed. - -`ChannelKeeper.CheckOpen` method will be introduced. This will replace `onChanOpen*` defined -under the routing module specification. Instead of define each channel handshake callback -functions, application modules can provide `ChannelChecker` function with the `AppModule` -which will be injected to `ChannelKeeper.Port()` at the top level application. -`CheckOpen` will find the correct `ChennelChecker` using the -`PortID` and call it, which will return an error if it is unacceptable by the application. - -The `ProofVerificationDecorator` will be inserted to the top level application. -It is not safe to make each module responsible to call proof verification -logic, whereas application can misbehave(in terms of IBC protocol) by -mistake. - -The `ProofVerificationDecorator` should come right after the default sybil attack -resistent layer from the current `auth.NewAnteHandler`: - -```go -// add IBC ProofVerificationDecorator to the Chain of -func NewAnteHandler( - ak keeper.AccountKeeper, supplyKeeper types.SupplyKeeper, ibcKeeper ibc.Keeper, - sigGasConsumer SignatureVerificationGasConsumer) sdk.AnteHandler { - return sdk.ChainAnteDecorators( - NewSetUpContextDecorator(), // outermost AnteDecorator. SetUpContext must be called first - ... - NewIncrementSequenceDecorator(ak), - ibcante.ProofVerificationDecorator(ibcKeeper.ClientKeeper, ibcKeeper.ChannelKeeper), // innermost AnteDecorator - ) -} -``` - -The implementation of this ADR will also create a `Data` field of the `Packet` of type `[]byte`, which can be deserialised by the receiving module into its own private type. It is up to the application modules to do this according to their own interpretation, not by the IBC keeper. This is crucial for dynamic IBC. - -Example application-side usage: - -```go -type AppModule struct {} - -// CheckChannel will be provided to the ChannelKeeper as ChannelKeeper.Port(module.CheckChannel) -func (module AppModule) CheckChannel(portID, channelID string, channel Channel) error { - if channel.Ordering != UNORDERED { - return ErrUncompatibleOrdering() - } - if channel.CounterpartyPort != "bank" { - return ErrUncompatiblePort() - } - if channel.Version != "" { - return ErrUncompatibleVersion() - } - return nil -} - -func NewHandler(k Keeper) Handler { - return func(ctx Context, msg Msg) Result { - switch msg := msg.(type) { - case MsgTransfer: - return handleMsgTransfer(ctx, k, msg) - case ibc.MsgPacket: - var data PacketDataTransfer - if err := types.ModuleCodec.UnmarshalBinaryBare(msg.GetData(), &data); err != nil { - return err - } - return handlePacketDataTransfer(ctx, k, msg, data) - case ibc.MsgTimeoutPacket: - var data PacketDataTransfer - if err := types.ModuleCodec.UnmarshalBinaryBare(msg.GetData(), &data); err != nil { - return err - } - return handleTimeoutPacketDataTransfer(ctx, k, packet) - // interface { PortID() string; ChannelID() string; Channel() ibc.Channel } - // MsgChanInit, MsgChanTry implements ibc.MsgChannelOpen - case ibc.MsgChannelOpen: - return handleMsgChannelOpen(ctx, k, msg) - } - } -} - -func handleMsgTransfer(ctx Context, k Keeper, msg MsgTransfer) Result { - err := k.SendTransfer(ctx,msg.PortID, msg.ChannelID, msg.Amount, msg.Sender, msg.Receiver) - if err != nil { - return sdk.ResultFromError(err) - } - - return sdk.Result{} -} - -func handlePacketDataTransfer(ctx Context, k Keeper, packet Packet, data PacketDataTransfer) Result { - err := k.ReceiveTransfer(ctx, packet.GetSourcePort(), packet.GetSourceChannel(), packet.GetDestinationPort(), packet.GetDestinationChannel(), data) - if err != nil { - // TODO: Source chain sent invalid packet, shutdown channel - } - k.ChannelKeeper.WriteAcknowledgement([]byte{0x00}) // WriteAcknowledgement increases the sequence, preventing double spending - return sdk.Result{} -} - -func handleCustomTimeoutPacket(ctx Context, k Keeper, packet CustomPacket) Result { - err := k.RecoverTransfer(ctx, packet.GetSourcePort(), packet.GetSourceChannel(), packet.GetDestinationPort(), packet.GetDestinationChannel(), data) - if err != nil { - // This chain sent invalid packet or cannot recover the funds - panic(err) - } - k.ChannelKeeper.DeleteCommitmentTimeout(ctx, packet) - // packet timeout should not fail - return sdk.Result{} -} - -func handleMsgChannelOpen(sdk.Context, k Keeper, msg MsgOpenChannel) Result { - k.AllocateEscrowAddress(ctx, msg.ChannelID()) - return sdk.Result{} -} -``` - -## Status - -Proposed - -## Consequences - -### Positive - -- Intuitive interface for developers - IBC handlers do not need to care about IBC authentication -- State change commitment logic is embedded into `baseapp.runTx` logic - -### Negative - -- Cannot support dynamic ports, routing is tied to the baseapp router - -### Neutral - -- Introduces new `AnteHandler` decorator. -- Dynamic ports can be supported using hierarchical port identifier, see #5290 for detail - -## References - -- Relevant comment: [cosmos/ics#289](https://github.com/cosmos/ics/issues/289#issuecomment-544533583) -- [ICS26 - Routing Module](https://github.com/cosmos/ics/blob/master/spec/ics-026-routing-module) diff --git a/docs/architecture/adr-016-validator-consensus-key-rotation.md b/docs/architecture/adr-016-validator-consensus-key-rotation.md deleted file mode 100644 index c668b7d29d..0000000000 --- a/docs/architecture/adr-016-validator-consensus-key-rotation.md +++ /dev/null @@ -1,126 +0,0 @@ -# ADR 016: Validator Consensus Key Rotation - -## Changelog - -- 2019 Oct 23: Initial draft -- 2019 Nov 28: Add key rotation fee - -## Context - -Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos-SDK. - -We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another. - -Also, it should be noted that this ADR includes only the simplest form of consensus key rotation without considering multiple consensus keys concept. Such multiple consensus keys concept shall remain a long term goal of Tendermint and Cosmos-SDK. - -## Decision - -### Pseudo procedure for consensus key rotation - -- create new random consensus key. -- create and broadcast a transaction with a `MsgRotateConsPubKey` that states the new consensus key is now coupled with the validator operator with signature from the validator's operator key. -- old consensus key becomes unable to participate on consensus immediately after the update of key mapping state on-chain. -- start validating with new consensus key. -- validators using HSM and KMS should update the consensus key in HSM to use the new rotated key after the height `h` when `MsgRotateConsPubKey` committed to the blockchain. - - -### Considerations - -- consensus key mapping information management strategy - - store history of each key mapping changes in the kvstore. - - the state machine can search corresponding consensus key paired with given validator operator for any arbitrary height in a recent unbonding period. - - the state machine does not need any historical mapping information which is past more than unbonding period. -- key rotation costs related to LCD and IBC - - LCD and IBC will have traffic/computation burden when there exists frequent power changes - - In current Tendermint design, consensus key rotations are seen as power changes from LCD or IBC perspective - - Therefore, to minimize unnecessary frequent key rotation behavior, we limited maximum number of rotation in recent unbonding period and also applied exponentially increasing rotation fee -- limits - - a validator cannot rotate its consensus key more than `MaxConsPubKeyRotations` time for any unbonding period, to prevent spam. - - parameters can be decided by governance and stored in genesis file. -- key rotation fee - - a validator should pay `KeyRotationFee` to rotate the consensus key which is calculated as below - - `KeyRotationFee` = (max(`VotingPowerPercentage` * 100, 1) * `InitialKeyRotationFee`) * 2^(number of rotations in `ConsPubKeyRotationHistory` in recent unbonding period) -- evidence module - - evidence module can search corresponding consensus key for any height from slashing keeper so that it can decide which consensus key is supposed to be used for given height. -- abci.ValidatorUpdate - - tendermint already has ability to change a consensus key by ABCI communication(`ValidatorUpdate`). - - validator consensus key update can be done via creating new + delete old by change the power to zero. - - therefore, we expect we even do not need to change tendermint codebase at all to implement this feature. -- new genesis parameters in `staking` module - - `MaxConsPubKeyRotations` : maximum number of rotation can be executed by a validator in recent unbonding period. default value 10 is suggested(11th key rotation will be rejected) - - `InitialKeyRotationFee` : the initial key rotation fee when no key rotation has happened in recent unbonding period. default value 1atom is suggested(1atom fee for the first key rotation in recent unbonding period) - - -### Workflow - -1. The validator generates a new consensus keypair. -2. The validator generates and signs a `MsgRotateConsPubKey` tx with their operator key and new ConsPubKey - - ```go - type MsgRotateConsPubKey struct { - ValidatorAddress sdk.ValAddress - NewPubKey crypto.PubKey - } - ``` - -3. `handleMsgRotateConsPubKey` gets `MsgRotateConsPubKey`, calls `RotateConsPubKey` with emits event -4. `RotateConsPubKey` - - checks if `NewPubKey` is not duplicated on `ValidatorsByConsAddr` - - checks if the validator is does not exceed parameter `MaxConsPubKeyRotations` by iterating `ConsPubKeyRotationHistory` - - checks if the signing account has enough balance to pay `KeyRotationFee` - - pays `KeyRotationFee` to community fund - - overwrites `NewPubKey` in `validator.ConsPubKey` - - deletes old `ValidatorByConsAddr` - - `SetValidatorByConsAddr` for `NewPubKey` - - Add `ConsPubKeyRotationHistory` for tracking rotation - - ```go - type ConsPubKeyRotationHistory struct { - OperatorAddress sdk.ValAddress - OldConsPubKey crypto.PubKey - NewConsPubKey crypto.PubKey - RotatedHeight int64 - } - ``` - -5. `ApplyAndReturnValidatorSetUpdates` checks if there is `ConsPubKeyRotationHistory` with `ConsPubKeyRotationHistory.RotatedHeight == ctx.BlockHeight()` and if so, generates 2 `ValidatorUpdate` , one for a remove validator and one for create new validator - - ```go - abci.ValidatorUpdate{ - PubKey: tmtypes.TM2PB.PubKey(OldConsPubKey), - Power: 0, - } - - abci.ValidatorUpdate{ - PubKey: tmtypes.TM2PB.PubKey(NewConsPubKey), - Power: v.ConsensusPower(), - } - ``` - -6. at `previousVotes` Iteration logic of `AllocateTokens`, `previousVote` using `OldConsPubKey` match up with `ConsPubKeyRotationHistory`, and replace validator for token allocation -7. Migrate `ValidatorSigningInfo` and `ValidatorMissedBlockBitArray` from `OldConsPubKey` to `NewConsPubKey` -- Note : All above features shall be implemented in `staking` module. - -## Status - -Proposed - -## Consequences - -### Positive - -- Validators can immediately or periodically rotate their consensus key to have better security policy -- improved security against Long-Range attacks (https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) given a validator throws away the old consensus key(s) - -### Negative - -- Slash module needs more computation because it needs to lookup corresponding consensus key of validators for each height -- frequent key rotations will make light client bisection less efficient - -### Neutral - -## References - -- on tendermint repo : https://github.com/tendermint/tendermint/issues/1136 -- on cosmos-sdk repo : https://github.com/cosmos/cosmos-sdk/issues/5231 -- about multiple consensus keys : https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698 diff --git a/docs/architecture/adr-017-historical-header-module.md b/docs/architecture/adr-017-historical-header-module.md deleted file mode 100644 index 0077ebb72a..0000000000 --- a/docs/architecture/adr-017-historical-header-module.md +++ /dev/null @@ -1,61 +0,0 @@ -# ADR 17: Historical Header Module - -## Changelog - -- 26 November 2019: Start of first version -- 2 December 2019: Final draft of first version - -## Context - -In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the SDK must have the ability to introspect recent consensus states (validator sets & commitment roots) as proofs of these values on other chains must be checked during the handshakes. - -## Decision - -The application MUST store the most recent `n` headers in a persistent store. At first, this store MAY be the current Merklised store. A non-Merklised store MAY be used later as no proofs are necessary. - -The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`: - -```golang -func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper, req abci.RequestBeginBlock) abci.ResponseBeginBlock { - info := HistoricalInfo{ - Header: ctx.BlockHeader(), - ValSet: keeper.StakingKeeper.GetAllValidators(ctx), // note that this must be stored in a canonical order - } - keeper.SetHistoricalInfo(ctx, ctx.BlockHeight(), info) - n := keeper.GetParamRecentHeadersToStore() - keeper.PruneHistoricalInfo(ctx, ctx.BlockHeight() - n) - // continue handling request -} -``` - -Alternatively, the application MAY store only the hash of the validator set. - -The application MUST make these past `n` committed headers available for querying by SDK modules through the `Keeper`'s `GetHistoricalInfo` function. This MAY be implemented in a new module, or it MAY also be integrated into an existing one (likely `x/staking` or `x/ibc`). - -`n` MAY be configured as a parameter store parameter, in which case it could be changed by `ParameterChangeProposal`s, although it will take some blocks for the stored information to catch up if `n` is increased. - -## Status - -Proposed. - -## Consequences - -Implementation of this ADR will require changes to the Cosmos SDK. It will not require changes to Tendermint. - -### Positive - -- Easy retrieval of headers & state roots for recent past heights by modules anywhere in the SDK. -- No RPC calls to Tendermint required. -- No ABCI alterations required. - -### Negative - -- Duplicates `n` headers data in Tendermint & the application (additional disk usage) - in the long term, an approach such as [this](https://github.com/tendermint/tendermint/issues/4210) might be preferable. - -### Neutral - -(none known) - -## References - -- [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ics/tree/master/spec/ics-024-host-requirements#consensus-state-introspection) diff --git a/docs/architecture/adr-018-extendable-voting-period.md b/docs/architecture/adr-018-extendable-voting-period.md deleted file mode 100644 index fdf5bb2584..0000000000 --- a/docs/architecture/adr-018-extendable-voting-period.md +++ /dev/null @@ -1,66 +0,0 @@ -# ADR 18: Extendable Voting Periods - -## Changelog - -- 1 January 2020: Start of first version - -## Context - -Currently the voting period for all governance proposals is the same. However, this is suboptimal as all governance proposals do not require the same time period. For more non-contentious proposals, they can be dealt with more efficently with a faster period, while more contentious or complex proposals may need a longer period for extended discussion/consideration. - -## Decision - -We would like to design a mechanism for making the voting period of a governance proposal variable based on the demand of voters. We would like it to be based on the view of the governance participants, rather than just the proposer of a governance proposal (thus, allowing the proposer to select the voting period length is not sufficient). - -However, we would like to avoid the creation of an entire second voting process to determine the length of the voting period, as it just pushed the problem to determining the length of that first voting period. - -Thus, we propose the following mechanism: - -### Params: - -- The current gov param `VotingPeriod` is to be replaced by a `MinVotingPeriod` param. This is the the default voting period that all governance proposal voting periods start with. -- There is a new gov param called `MaxVotingPeriodExtension`. - -### Mechanism - -There is a new `Msg` type called `MsgExtendVotingPeriod`, which can be sent by any staked account during a proposal's voting period. It allows the sender to unilaterally extend the length of the voting period by `MaxVotingPeriodExtension * sender's share of voting power`. Every address can only call `MsgExtendVotingPeriod` once per proposal. - -So for example, if the `MaxVotingPeriodExtension` is set to 100 Days, then anyone with 1% of voting power can extend the voting power by 1 day. If 33% of voting power has sent the message, the voting period will be extended by 33 days. Thus, if absolutely everyone chooses to extend the voting period, the absolute maximum voting period will be `MinVotingPeriod + MaxVotingPeriodExtension`. - -This system acts as a sort of distributed coordination, where individual stakers choosing to extend or not, allows the system the guage the conentiousness/complexity of the proposal. It is extremely unlikely that many stakers will choose to extend at the exact same time, it allows stakers to view how long others have already extended thus far, to decide whether or not to extend further. - -### Dealing with Unbonding/Redelegation - -There is one thing that needs to be addressed. How to deal with redelegation/unbonding during the voting period. If a staker of 5% calls `MsgExtendVotingPeriod` and then unbonds, does the voting period then decrease by 5 days again? This is not good as it can give people a false sense of how long they have to make their decision. For this reason, we want to design it such that the voting period length can only be extended, not shortened. To do this, the current extension amount is based on the highest percent that voted extension at any time. This is best explained by example: - -1. Let's say 2 stakers of voting power 4% and 3% respectively vote to extend. The voting period will be extended by 7 days. -2. Now the staker of 3% decides to unbond before the end of the voting period. The voting period extension remains 7 days. -3. Now, let's say another staker of 2% voting power decides to extend voting period. There is now 6% of active voting power choosing the extend. The voting power remains 7 days. -4. If a fourth staker of 10% chooses to extend now, there is a total of 16% of active voting power wishing to extend. The voting period will be extended to 16 days. - -### Delegators - -Just like votes in the actual voting period, delegators automatically inherit the extension of their validators. If their validator chooses to extend, their voting power will be used in the validator's extension. However, the delegator is unable to override their validator and "unextend" as that would contradict the "voting power length can only be ratcheted up" principle described in the previous section. However, a delegator may choose the extend using their personal voting power, if their validator has not done so. - -## Status - -Proposed - -## Consequences - -### Positive - -- More complex/contentious governance proposals will have more time to properly digest and deliberate - -### Negative - -- Governance process becomes more complex and requires more understanding to interact with effectively -- Can no longer predict when a governance proposal will end. Can't assume order in which governance proposals will end. - -### Neutral - -- The minimum voting period can be made shorter - -## References - -- [Cosmos Forum post where idea first originated](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9) diff --git a/docs/architecture/adr-019-protobuf-state-encoding.md b/docs/architecture/adr-019-protobuf-state-encoding.md deleted file mode 100644 index 177f8c8eb7..0000000000 --- a/docs/architecture/adr-019-protobuf-state-encoding.md +++ /dev/null @@ -1,375 +0,0 @@ -# ADR 019: Protocol Buffer State Encoding - -## Changelog - -- 2020 Feb 15: Initial Draft -- 2020 Feb 24: Updates to handle messages with interface fields -- 2020 Apr 27: Convert usages of `oneof` for interfaces to `Any` -- 2020 May 15: Describe `cosmos_proto` extensions and amino compatibility -- 2020 Dec 4: Move and rename `MarshalAny` and `UnmarshalAny` into the `codec.Marshaler` interface. - -## Status - -Accepted - -## Context - -Currently, the Cosmos SDK utilizes [go-amino](https://github.com/tendermint/go-amino/) for binary -and JSON object encoding over the wire bringing parity between logical objects and persistence objects. - -From the Amino docs: - -> Amino is an object encoding specification. It is a subset of Proto3 with an extension for interface -> support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) for more -> information on Proto3, which Amino is largely compatible with (but not with Proto2). -> -> The goal of the Amino encoding protocol is to bring parity into logic objects and persistence objects. - -Amino also aims to have the following goals (not a complete list): - -- Binary bytes must be decode-able with a schema. -- Schema must be upgradeable. -- The encoder and decoder logic must be reasonably simple. - -However, we believe that Amino does not fulfill these goals completely and does not fully meet the -needs of a truly flexible cross-language and multi-client compatible encoding protocol in the Cosmos SDK. -Namely, Amino has proven to be a big pain-point in regards to supporting object serialization across -clients written in various languages while providing virtually little in the way of true backwards -compatibility and upgradeability. Furthermore, through profiling and various benchmarks, Amino has -been shown to be an extremely large performance bottleneck in the Cosmos SDK 1. This is -largely reflected in the performance of simulations and application transaction throughput. - -Thus, we need to adopt an encoding protocol that meets the following criteria for state serialization: - -- Language agnostic -- Platform agnostic -- Rich client support and thriving ecosystem -- High performance -- Minimal encoded message size -- Codegen-based over reflection-based -- Supports backward and forward compatibility - -Note, migrating away from Amino should be viewed as a two-pronged approach, state and client encoding. -This ADR focuses on state serialization in the Cosmos SDK state machine. A corresponding ADR will be -made to address client-side encoding. - -## Decision - -We will adopt [Protocol Buffers](https://developers.google.com/protocol-buffers) for serializing -persisted structured data in the Cosmos SDK while providing a clean mechanism and developer UX for -applications wishing to continue to use Amino. We will provide this mechanism by updating modules to -accept a codec interface, `Marshaler`, instead of a concrete Amino codec. Furthermore, the Cosmos SDK -will provide three concrete implementations of the `Marshaler` interface: `AminoCodec`, `ProtoCodec`, -and `HybridCodec`. - -- `AminoCodec`: Uses Amino for both binary and JSON encoding. -- `ProtoCodec`: Uses Protobuf for or both binary and JSON encoding. -- `HybridCodec`: Uses Amino for JSON encoding and Protobuf for binary encoding. - -Until the client migration landscape is fully understood and designed, modules will use a `HybridCodec` -as the concrete codec it accepts and/or extends. This means that all client JSON encoding, including -genesis state, will still use Amino. The ultimate goal will be to replace Amino JSON encoding with -Protbuf encoding and thus have modules accept and/or extend `ProtoCodec`. - -### Module Codecs - -Modules that do not require the ability to work with and serialize interfaces, the path to Protobuf -migration is pretty straightforward. These modules are to simply migrate any existing types that -are encoded and persisted via their concrete Amino codec to Protobuf and have their keeper accept a -`Marshaler` that will be a `HybridCodec`. This migration is simple as things will just work as-is. - -Note, any business logic that needs to encode primitive types like `bool` or `int64` should use -[gogoprotobuf](https://github.com/gogo/protobuf) Value types. - -Example: - -```go - ts, err := gogotypes.TimestampProto(completionTime) - if err != nil { - // ... - } - - bz := cdc.MustMarshalBinaryBare(ts) -``` - -However, modules can vary greatly in purpose and design and so we must support the ability for modules -to be able to encode and work with interfaces (e.g. `Account` or `Content`). For these modules, they -must define their own codec interface that extends `Marshaler`. These specific interfaces are unique -to the module and will contain method contracts that know how to serialize the needed interfaces. - -Example: - -```go -// x/auth/types/codec.go - -type Codec interface { - codec.Marshaler - - MarshalAccount(acc exported.Account) ([]byte, error) - UnmarshalAccount(bz []byte) (exported.Account, error) - - MarshalAccountJSON(acc exported.Account) ([]byte, error) - UnmarshalAccountJSON(bz []byte) (exported.Account, error) -} -``` - -### Usage of `Any` to encode interfaces - -In general, module-level .proto files should define messages which encode interfaces -using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). -After [extension discussion](https://github.com/cosmos/cosmos-sdk/issues/6030), -this was chosen as the preferred alternative to application-level `oneof`s -as in our original protobuf design. The arguments in favor of `Any` can be -summarized as follows: - -* `Any` provides a simpler, more consistent client UX for dealing with -interfaces than app-level `oneof`s that will need to be coordinated more -carefully across applications. Creating a generic transaction -signing library using `oneof`s may be cumbersome and critical logic may need -to be reimplemented for each chain -* `Any` provides more resistance against human error than `oneof` -* `Any` is generally simpler to implement for both modules and apps - -The main counter-argument to using `Any` centers around its additional space -and possibly performance overhead. The space overhead could be dealt with using -compression at the persistence layer in the future and the performance impact -is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization, -with user experience as the higher order concern. - -Note, that given the SDK's decision to adopt the `Codec` interfaces described -above, apps can still choose to use `oneof` to encode state and transactions -but it is not the recommended approach. If apps do choose to use `oneof`s -instead of `Any` they will likely lose compatibility with client apps that -support multiple chains. Thus developers should think carefully about whether -they care more about what is possibly a pre-mature optimization or end-user -and client developer UX. - -### Safe usage of `Any` - -By default, the [gogo protobuf implementation of `Any`](https://godoc.org/github.com/gogo/protobuf/types) -uses [global type registration]( https://github.com/gogo/protobuf/blob/master/proto/properties.go#L540) -to decode values packed in `Any` into concrete -go types. This introduces a vulnerability where any malicious module -in the dependency tree could registry a type with the global protobuf registry -and cause it to be loaded and unmarshaled by a transaction that referenced -it in the `type_url` field. - -To prevent this, we introduce a type registration mechanism for decoding `Any` -values into concrete types through the `InterfaceRegistry` interface which -bears some similarity to type registration with Amino: - -```go -type InterfaceRegistry interface { - // RegisterInterface associates protoName as the public name for the - // interface passed in as iface - // Ex: - // registry.RegisterInterface("cosmos_sdk.Msg", (*sdk.Msg)(nil)) - RegisterInterface(protoName string, iface interface{}) - - // RegisterImplementations registers impls as a concrete implementations of - // the interface iface - // Ex: - // registry.RegisterImplementations((*sdk.Msg)(nil), &MsgSend{}, &MsgMultiSend{}) - RegisterImplementations(iface interface{}, impls ...proto.Message) - -} -``` - -In addition to serving as a whitelist, `InterfaceRegistry` can also serve -to communicate the list of concrete types that satisfy an interface to clients. - -In .proto files: -* fields which accept interfaces should be annotated with `cosmos_proto.accepts_interface` -using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` -* interface implementations should be annotated with `cosmos_proto.implements_interface` -using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` - -In the future, `protoName`, `cosmos_proto.accepts_interface`, `cosmos_proto.implements_interface` -may be used via code generation, reflection &/or static linting. - -The same struct that implements `InterfaceRegistry` will also implement an -interface `InterfaceUnpacker` to be used for unpacking `Any`s: - -```go -type InterfaceUnpacker interface { - // UnpackAny unpacks the value in any to the interface pointer passed in as - // iface. Note that the type in any must have been registered with - // RegisterImplementations as a concrete type for that interface - // Ex: - // var msg sdk.Msg - // err := ctx.UnpackAny(any, &msg) - // ... - UnpackAny(any *Any, iface interface{}) error -} -``` - -Note that `InterfaceRegistry` usage does not deviate from standard protobuf -usage of `Any`, it just introduces a security and introspection layer for -golang usage. - -`InterfaceRegistry` will be a member of `ProtoCodec` and `HybridCodec` as -described above. In order for modules to register interface types, app modules -can optionally implement the following interface: - -```go -type InterfaceModule interface { - RegisterInterfaceTypes(InterfaceRegistry) -} -``` - -The module manager will include a method to call `RegisterInterfaceTypes` on -every module that implements it in order to populate the `InterfaceRegistry`. - -### Using `Any` to encode state - -The SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization. - -```go -import "github.com/line/lbm-sdk/v2/codec" - -// note: eviexported.Evidence is an interface type -func MarshalEvidence(cdc codec.BinaryMarshaler, e eviexported.Evidence) ([]byte, error) { - return cdc.MarshalInterface(e) -} - -func UnmarshalEvidence(cdc codec.BinaryMarshaler, bz []byte) (eviexported.Evidence, error) { - var evi eviexported.Evidence - err := cdc.UnmarshalInterface(&evi, bz) - return err, nil -} -``` - -### Using `Any` in `sdk.Msg`s - -A similar concept is to be applied for messages that contain interfaces fields. -For example, we can define `MsgSubmitEvidence` as follows where `Evidence` is -an interface: - -```protobuf -// x/evidence/types/types.proto - -message MsgSubmitEvidence { - bytes submitter = 1 - [ - (gogoproto.casttype) = "github.com/line/lbm-sdk/v2/types.AccAddress" - ]; - google.protobuf.Any evidence = 2; -} -``` - -Note that in order to unpack the evidence from `Any` we do need a reference to -`InterfaceRegistry`. In order to reference evidence in methods like -`ValidateBasic` which shouldn't have to know about the `InterfaceRegistry`, we -introduce an `UnpackInterfaces` phase to deserialization which unpacks -interfaces before they're needed. - -### Unpacking Interfaces - -To implement the `UnpackInterfaces` phase of deserialization which unpacks -interfaces wrapped in `Any` before they're needed, we create an interface -that `sdk.Msg`s and other types can implement: - -```go -type UnpackInterfacesMessage interface { - UnpackInterfaces(InterfaceUnpacker) error -} -``` - -We also introduce a private `cachedValue interface{}` field onto the `Any` -struct itself with a public getter `GetCachedValue() interface{}`. - -The `UnpackInterfaces` method is to be invoked during message deserialization right -after `Unmarshal` and any interface values packed in `Any`s will be decoded -and stored in `cachedValue` for reference later. - -Then unpacked interface values can safely be used in any code afterwards -without knowledge of the `InterfaceRegistry` -and messages can introduce a simple getter to cast the cached value to the -correct interface type. - -This has the added benefit that unmarshaling of `Any` values only happens once -during initial deserialization rather than every time the value is read. Also, -when `Any` values are first packed (for instance in a call to -`NewMsgSubmitEvidence`), the original interface value is cached so that -unmarshaling isn't needed to read it again. - -`MsgSubmitEvidence` could implement `UnpackInterfaces`, plus a convenience getter -`GetEvidence` as follows: - -```go -func (msg MsgSubmitEvidence) UnpackInterfaces(ctx sdk.InterfaceRegistry) error { - var evi eviexported.Evidence - return ctx.UnpackAny(msg.Evidence, *evi) -} - -func (msg MsgSubmitEvidence) GetEvidence() eviexported.Evidence { - return msg.Evidence.GetCachedValue().(eviexported.Evidence) -} -``` - -### Amino Compatibility - -Our custom implementation of `Any` can be used transparently with Amino if used -with the proper codec instance. What this means is that interfaces packed within -`Any`s will be amino marshaled like regular Amino interfaces (assuming they -have been registered properly with Amino). - -In order for this functionality to work: - -- **all legacy code must use `*codec.LegacyAmino` instead of `*amino.Codec` which is - now a wrapper which properly handles `Any`** -- **all new code should use `Marshaler` which is compatible with both amino and - protobuf** -- Also, before v0.39, `codec.LegacyAmino` will be renamed to `codec.LegacyAmino`. - -### Why Wasn't X Chosen Instead - -For a more complete comparison to alternative protocols, see [here](https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f). - -### Cap'n Proto - -While [Cap’n Proto](https://capnproto.org/) does seem like an advantageous alternative to Protobuf -due to it's native support for interfaces/generics and built in canonicalization, it does lack the -rich client ecosystem compared to Protobuf and is a bit less mature. - -### FlatBuffers - -[FlatBuffers](https://google.github.io/flatbuffers/) is also a potentially viable alternative, with the -primary difference being that FlatBuffers does not need a parsing/unpacking step to a secondary -representation before you can access data, often coupled with per-object memory allocation. - -However, it would require great efforts into research and full understanding the scope of the migration -and path forward -- which isn't immediately clear. In addition, FlatBuffers aren't designed for -untrusted inputs. - -## Future Improvements & Roadmap - -In the future we may consider a compression layer right above the persistence -layer which doesn't change tx or merkle tree hashes, but reduces the storage -overhead of `Any`. In addition, we may adopt protobuf naming conventions which -make type URLs a bit more concise while remaining descriptive. - -Additional code generation support around the usage of `Any` is something that -could also be explored in the future to make the UX for go developers more -seamless. - -## Consequences - -### Positive - -- Significant performance gains. -- Supports backward and forward type compatibility. -- Better support for cross-language clients. - -### Negative - -- Learning curve required to understand and implement Protobuf messages. -- Slightly larger message size due to use of `Any`, although this could be offset - by a compression layer in the future - -### Neutral - -## References - -1. https://github.com/cosmos/cosmos-sdk/issues/4977 -2. https://github.com/cosmos/cosmos-sdk/issues/5444 diff --git a/docs/architecture/adr-020-protobuf-transaction-encoding.md b/docs/architecture/adr-020-protobuf-transaction-encoding.md deleted file mode 100644 index 7d0aa5767c..0000000000 --- a/docs/architecture/adr-020-protobuf-transaction-encoding.md +++ /dev/null @@ -1,461 +0,0 @@ -# ADR 020: Protocol Buffer Transaction Encoding - -## Changelog - -- 2020 March 06: Initial Draft -- 2020 March 12: API Updates -- 2020 April 13: Added details on interface `oneof` handling -- 2020 April 30: Switch to `Any` -- 2020 May 14: Describe public key encoding -- 2020 June 08: Store `TxBody` and `AuthInfo` as bytes in `SignDoc`; Document `TxRaw` as broadcast and storage type. -- 2020 August 07: Use ADR 027 for serializing `SignDoc`. -- 2020 August 19: Move sequence field from `SignDoc` to `SignerInfo`, as discussed in [#6966](https://github.com/cosmos/cosmos-sdk/issues/6966). -- 2020 September 25: Remove `PublicKey` type in favor of `secp256k1.PubKey`, `ed25519.PubKey` and `multisig.LegacyAminoPubKey`. -- 2020 October 15: Add `GetAccount` and `GetAccountWithHeight` methods to the `AccountRetriever` interface. - -## Status - -Accepted - -## Context - -This ADR is a continuation of the motivation, design, and context established in -[ADR 019](./adr-019-protobuf-state-encoding.md), namely, we aim to design the -Protocol Buffer migration path for the client-side of the Cosmos SDK. - -Specifically, the client-side migration path primarily includes tx generation and -signing, message construction and routing, in addition to CLI & REST handlers and -business logic (i.e. queriers). - -With this in mind, we will tackle the migration path via two main areas, txs and -querying. However, this ADR solely focuses on transactions. Querying should be -addressed in a future ADR, but it should build off of these proposals. - -Based on detailed discussions ([\#6030](https://github.com/cosmos/cosmos-sdk/issues/6030) -and [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078)), the original -design for transactions was changed substantially from an `oneof` /JSON-signing -approach to the approach described below. - -## Decision - -### Transactions - -Since interface values are encoded with `google.protobuf.Any` in state (see [ADR 019](adr-019-protobuf-state-encoding.md)), -`sdk.Msg`s are encoding with `Any` in transactions. - -One of the main goals of using `Any` to encode interface values is to have a -core set of types which is reused by apps so that -clients can safely be compatible with as many chains as possible. - -It is one of the goals of this specification to provide a flexible cross-chain transaction -format that can serve a wide variety of use cases without breaking client -compatibility. - -In order to facilitate signing, transactions are separated into `TxBody`, -which will be re-used by `SignDoc` below, and `signatures`: - -```proto -// types/types.proto -package cosmos_sdk.v1; - -message Tx { - TxBody body = 1; - AuthInfo auth_info = 2; - // A list of signatures that matches the length and order of AuthInfo's signer_infos to - // allow connecting signature meta information like public key and signing mode by position. - repeated bytes signatures = 3; -} - -// A variant of Tx that pins the signer's exact binary represenation of body and -// auth_info. This is used for signing, broadcasting and verification. The binary -// `serialize(tx: TxRaw)` is stored in Tendermint and the hash `sha256(serialize(tx: TxRaw))` -// becomes the "txhash", commonly used as the transaction ID. -message TxRaw { - // A protobuf serialization of a TxBody that matches the representation in SignDoc. - bytes body = 1; - // A protobuf serialization of an AuthInfo that matches the representation in SignDoc. - bytes auth_info = 2; - // A list of signatures that matches the length and order of AuthInfo's signer_infos to - // allow connecting signature meta information like public key and signing mode by position. - repeated bytes signatures = 3; -} - -message TxBody { - // A list of messages to be executed. The required signers of those messages define - // the number and order of elements in AuthInfo's signer_infos and Tx's signatures. - // Each required signer address is added to the list only the first time it occurs. - // - // By convention, the first required signer (usually from the first message) is referred - // to as the primary signer and pays the fee for the whole transaction. - repeated google.protobuf.Any messages = 1; - string memo = 2; - int64 timeout_height = 3; - repeated google.protobuf.Any extension_options = 1023; -} - -message AuthInfo { - // This list defines the signing modes for the required signers. The number - // and order of elements must match the required signers from TxBody's messages. - // The first element is the primary signer and the one which pays the fee. - repeated SignerInfo signer_infos = 1; - // The fee can be calculated based on the cost of evaluating the body and doing signature verification of the signers. This can be estimated via simulation. - Fee fee = 2; -} - -message SignerInfo { - // The public key is optional for accounts that already exist in state. If unset, the - // verifier can use the required signer address for this position and lookup the public key. - google.protobuf.Any public_key = 1; - // ModeInfo describes the signing mode of the signer and is a nested - // structure to support nested multisig pubkey's - ModeInfo mode_info = 2; - // sequence is the sequence of the account, which describes the - // number of committed transactions signed by a given address. It is used to prevent - // replay attacks. - uint64 sequence = 3; -} - -message ModeInfo { - oneof sum { - Single single = 1; - Multi multi = 2; - } - - // Single is the mode info for a single signer. It is structured as a message - // to allow for additional fields such as locale for SIGN_MODE_TEXTUAL in the future - message Single { - SignMode mode = 1; - } - - // Multi is the mode info for a multisig public key - message Multi { - // bitarray specifies which keys within the multisig are signing - CompactBitArray bitarray = 1; - // mode_infos is the corresponding modes of the signers of the multisig - // which could include nested multisig public keys - repeated ModeInfo mode_infos = 2; - } -} - -enum SignMode { - SIGN_MODE_UNSPECIFIED = 0; - - SIGN_MODE_DIRECT = 1; - - SIGN_MODE_TEXTUAL = 2; - - SIGN_MODE_LEGACY_AMINO_JSON = 127; -} -``` - -As will be discussed below, in order to include as much of the `Tx` as possible -in the `SignDoc`, `SignerInfo` is separated from signatures so that only the -raw signatures themselves live outside of what is signed over. - -Because we are aiming for a flexible, extensible cross-chain transaction -format, new transaction processing options should be added to `TxBody` as soon -those use cases are discovered, even if they can't be implemented yet. - -Because there is coordination overhead in this, `TxBody` includes an -`extension_options` field which can be used for any transaction processing -options that are not already covered. App developers should, nevertheless, -attempt to upstream important improvements to `Tx`. - -### Signing - -All of the signing modes below aim to provide the following guarantees: - -- **No Malleability**: `TxBody` and `AuthInfo` cannot change once the transaction - is signed -- **Predictable Gas**: if I am signing a transaction where I am paying a fee, - the final gas is fully dependent on what I am signing - -These guarantees give the maximum amount confidence to message signers that -manipulation of `Tx`s by intermediaries can't result in any meaningful changes. - -#### `SIGN_MODE_DIRECT` - -The "direct" signing behavior is to sign the raw `TxBody` bytes as broadcast over -the wire. This has the advantages of: - -- requiring the minimum additional client capabilities beyond a standard protocol - buffers implementation -- leaving effectively zero holes for transaction malleability (i.e. there are no - subtle differences between the signing and encoding formats which could - potentially be exploited by an attacker) - -Signatures are structured using the `SignDoc` below which reuses the serialization of -`TxBody` and `AuthInfo` and only adds the fields which are needed for signatures: - -```proto -// types/types.proto -message SignDoc { - // A protobuf serialization of a TxBody that matches the representation in TxRaw. - bytes body = 1; - // A protobuf serialization of an AuthInfo that matches the representation in TxRaw. - bytes auth_info = 2; - string chain_id = 3; - uint64 account_number = 4; -} -``` - -In order to sign in the default mode, clients take the following steps: - -1. Serialize `TxBody` and `AuthInfo` using any valid protobuf implementation. -2. Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). -3. Sign the encoded `SignDoc` bytes. -4. Build a `TxRaw` and serialize it for broadcasting. - -Signature verification is based on comparing the raw `TxBody` and `AuthInfo` -bytes encoded in `TxRaw` not based on any ["canonicalization"](https://github.com/regen-network/canonical-proto3) -algorithm which creates added complexity for clients in addition to preventing -some forms of upgradeability (to be addressed later in this document). - -Signature verifiers do: - -1. Deserialize a `TxRaw` and pull out `body` and `auth_info`. -2. Create a list of required signer addresses from the messages. -3. For each required signer: - - Pull account number and sequence from the state. - - Obtain the public key either from state or `AuthInfo`'s `signer_infos`. - - Create a `SignDoc` and serialize it using [ADR 027](./adr-027-deterministic-protobuf-serialization.md). - - Verify the signature at the the same list position against the serialized `SignDoc`. - -#### `SIGN_MODE_LEGACY_AMINO` - -In order to support legacy wallets and exchanges, Amino JSON will be temporarily -supported transaction signing. Once wallets and exchanges have had a -chance to upgrade to protobuf based signing, this option will be disabled. In -the meantime, it is foreseen that disabling the current Amino signing would cause -too much breakage to be feasible. Note that this is mainly a requirement of the -Cosmos Hub and other chains may choose to disable Amino signing immediately. - -Legacy clients will be able to sign a transaction using the current Amino -JSON format and have it encoded to protobuf using the REST `/tx/encode` -endpoint before broadcasting. - -#### `SIGN_MODE_TEXTUAL` - -As was discussed extensively in [\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078), -there is a desire for a human-readable signing encoding, especially for hardware -wallets like the [Ledger](https://www.ledger.com) which display -transaction contents to users before signing. JSON was an attempt at this but -falls short of the ideal. - -`SIGN_MODE_TEXTUAL` is intended as a placeholder for a human-readable -encoding which will replace Amino JSON. This new encoding should be even more -focused on readability than JSON, possibly based on formatting strings like -[MessageFormat](http://userguide.icu-project.org/formatparse/messages). - -In order to ensure that the new human-readable format does not suffer from -transaction malleability issues, `SIGN_MODE_TEXTUAL` -requires that the _human-readable bytes are concatenated with the raw `SignDoc`_ -to generate sign bytes. - -Multiple human-readable formats (maybe even localized messages) may be supported -by `SIGN_MODE_TEXTUAL` when it is implemented. - -### Unknown Field Filtering - -Unknown fields in protobuf messages should generally be rejected by transaction -processors because: - -- important data may be present in the unknown fields, that if ignored, will - cause unexpected behavior for clients -- they present a malleability vulnerability where attackers can bloat tx size - by adding random uninterpreted data to unsigned content (i.e. the master `Tx`, - not `TxBody`) - -There are also scenarios where we may choose to safely ignore unknown fields -(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188) to -provide graceful forwards compatibility with newer clients. - -We propose that field numbers with bit 11 set (for most use cases this is -the range of 1024-2047) be considered non-critical fields that can safely be -ignored if unknown. - -To handle this we will need a unknown field filter that: - -- always rejects unknown fields in unsigned content (i.e. top-level `Tx` and - unsigned parts of `AuthInfo` if present based on the signing mode) -- rejects unknown fields in all messages (including nested `Any`s) other than - fields with bit 11 set - -This will likely need to be a custom protobuf parser pass that takes message bytes -and `FileDescriptor`s and returns a boolean result. - -### Public Key Encoding - -Public keys in the Cosmos SDK implement Tendermint's `crypto.PubKey` interface. -We propose to use `Any` for protobuf encoding as we are doing with other interfaces (e.g. in `BaseAccount` `PubKey` or `SignerInfo` `PublicKey`). -Following public keys are implemented: secp256k1, ed25519 and multisignature. - -Ex: - -```proto -message PubKey { - bytes key = 1; -} -``` - -`multisig.LegacyAminoPubKey` has an array of `Any`'s member to support any -protobuf public key type. - -Apps should only attempt to handle a registered set of public keys that they -have tested. The provided signature verification ante handler decorators will -enforce this. - -### CLI & REST - -Currently, the REST and CLI handlers encode and decode types and txs via Amino -JSON encoding using a concrete Amino codec. Being that some of the types dealt with -in the client can be interfaces, similar to how we described in [ADR 019](./adr-019-protobuf-state-encoding.md), -the client logic will now need to take a codec interface that knows not only how -to handle all the types, but also knows how to generate transactions, signatures, -and messages. - -```go -type AccountRetriever interface { - GetAccount(clientCtx Context, addr sdk.AccAddress) (client.Account, error) - GetAccountWithHeight(clientCtx Context, addr sdk.AccAddress) (client.Account, int64, error) - EnsureExists(clientCtx client.Context, addr sdk.AccAddress) error - GetAccountNumberSequence(clientCtx client.Context, addr sdk.AccAddress) (uint64, uint64, error) -} - -type Generator interface { - NewTx() TxBuilder - NewFee() ClientFee - NewSignature() ClientSignature - MarshalTx(tx types.Tx) ([]byte, error) -} - -type TxBuilder interface { - GetTx() sdk.Tx - - SetMsgs(...sdk.Msg) error - GetSignatures() []sdk.Signature - SetSignatures(...sdk.Signature) - GetFee() sdk.Fee - SetFee(sdk.Fee) - GetMemo() string - SetMemo(string) -} -``` - -We then update `Context` to have new fields: `JSONMarshaler`, `TxGenerator`, -and `AccountRetriever`, and we update `AppModuleBasic.GetTxCmd` to take -a `Context` which should have all of these fields pre-populated. - -Each client method should then use one of the `Init` methods to re-initialize -the pre-populated `Context`. `tx.GenerateOrBroadcastTx` can be used to -generate or broadcast a transaction. For example: - -```go -import "github.com/spf13/cobra" -import "github.com/line/lbm-sdk/v2/client" -import "github.com/line/lbm-sdk/v2/client/tx" - -func NewCmdDoSomething(clientCtx client.Context) *cobra.Command { - return &cobra.Command{ - RunE: func(cmd *cobra.Command, args []string) error { - clientCtx := ctx.InitWithInput(cmd.InOrStdin()) - msg := NewSomeMsg{...} - tx.GenerateOrBroadcastTx(clientCtx, msg) - }, - } -} -``` - -## Future Improvements - -### `SIGN_MODE_TEXTUAL` specification - -A concrete specification and implementation of `SIGN_MODE_TEXTUAL` is intended -as a near-term future improvement so that the ledger app and other wallets -can gracefully transition away from Amino JSON. - -### `SIGN_MODE_DIRECT_AUX` - -(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933) - -We could add a mode `SIGN_MODE_DIRECT_AUX` -to support scenarios where multiple signatures -are being gathered into a single transaction but the message composer does not -yet know which signatures will be included in the final transaction. For instance, -I may have a 3/5 multisig wallet and want to send a `TxBody` to all 5 -signers to see who signs first. As soon as I have 3 signatures then I will go -ahead and build the full transaction. - -With `SIGN_MODE_DIRECT`, each signer needs -to sign the full `AuthInfo` which includes the full list of all signers and -their signing modes, making the above scenario very hard. - -`SIGN_MODE_DIRECT_AUX` would allow "auxiliary" signers to create their signature -using only `TxBody` and their own `PublicKey`. This allows the full list of -signers in `AuthInfo` to be delayed until signatures have been collected. - -An "auxiliary" signer is any signer besides the primary signer who is paying -the fee. For the primary signer, the full `AuthInfo` is actually needed to calculate gas and fees -because that is dependent on how many signers and which key types and signing -modes they are using. Auxiliary signers, however, do not need to worry about -fees or gas and thus can just sign `TxBody`. - -To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed: - -1. Encode `SignDocAux` (with the same requirement that fields must be serialized - in order): - -```proto -// types/types.proto -message SignDocAux { - bytes body_bytes = 1; - // PublicKey is included in SignDocAux : - // 1. as a special case for multisig public keys. For multisig public keys, - // the signer should use the top-level multisig public key they are signing - // against, not their own public key. This is to prevent against a form - // of malleability where a signature could be taken out of context of the - // multisig key that was intended to be signed for - // 2. to guard against scenario where configuration information is encoded - // in public keys (it has been proposed) such that two keys can generate - // the same signature but have different security properties - // - // By including it here, the composer of AuthInfo cannot reference the - // a public key variant the signer did not intend to use - PublicKey public_key = 2; - string chain_id = 3; - uint64 account_number = 4; -} -``` - -2. Sign the encoded `SignDocAux` bytes -3. Send their signature and `SignerInfo` to primary signer who will then - sign and broadcast the final transaction (with `SIGN_MODE_DIRECT` and `AuthInfo` - added) once enough signatures have been collected - -### `SIGN_MODE_DIRECT_RELAXED` - -(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_) - -This is a variation of `SIGN_MODE_DIRECT` where multiple signers wouldn't need to -coordinate public keys and signing modes in advance. It would involve an alternate -`SignDoc` similar to `SignDocAux` above with fee. This could be added in the future -if client developers found the burden of collecting public keys and modes in advance -too burdensome. - -## Consequences - -### Positive - -- Significant performance gains. -- Supports backward and forward type compatibility. -- Better support for cross-language clients. -- Multiple signing modes allow for greater protocol evolution - -### Negative - -- `google.protobuf.Any` type URLs increase transaction size although the effect - may be negligible or compression may be able to mitigate it. - -### Neutral - -## References diff --git a/docs/architecture/adr-021-protobuf-query-encoding.md b/docs/architecture/adr-021-protobuf-query-encoding.md deleted file mode 100644 index 60d4d2b2f6..0000000000 --- a/docs/architecture/adr-021-protobuf-query-encoding.md +++ /dev/null @@ -1,258 +0,0 @@ -# ADR 021: Protocol Buffer Query Encoding - -## Changelog - -- 2020 March 27: Initial Draft - -## Status - -Accepted - -## Context - -This ADR is a continuation of the motivation, design, and context established in -[ADR 019](./adr-019-protobuf-state-encoding.md) and -[ARD 020](./adr-019-protobuf-transaction-encoding.md), namely, we aim to design the -Protocol Buffer migration path for the client-side of the Cosmos SDK. - -This ADR continues from [ARD 020](./adr-020-protobuf-transaction-encoding.md) -to specify the encoding of queries. - -## Decision - -### Custom Query Definition - -Modules define custom queries through a protocol buffers `service` definition. -These `service` definitions are generally associated with and used by the -GRPC protocol. However, the protocol buffers specification indicates that -they can be used more generically by any request/response protocol that uses -protocol buffer encoding. Thus, we can use `service` definitions for specifying -custom ABCI queries and even reuse a substantial amount of the GRPC infrastructure. - -Each module with custom queries should define a service canonically named `Query`: - -```proto -// x/bank/types/types.proto - -service Query { - rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { } - rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { } -} -``` - -#### Handling of Interface Types - -Modules that use interface types and need true polymorphism generally force a -`oneof` up to the app-level that provides the set of concrete implementations of -that interface that the app supports. While app's are welcome to do the same for -queries and implement an app-level query service, it is recommended that modules -provide query methods that expose these interfaces via `google.protobuf.Any`. -There is a concern on the transaction level that the overhead of `Any` is too -high to justify its usage. However for queries this is not a concern, and -providing generic module-level queries that use `Any` does not preclude apps -from also providing app-level queries that return use the app-level `oneof`s. - - -A hypothetical example for the `gov` module would look something like: - -```proto -// x/gov/types/types.proto - -import "google/protobuf/any.proto"; - -service Query { - rpc GetProposal(GetProposalParams) returns (AnyProposal) { } -} - -message AnyProposal { - ProposalBase base = 1; - google.protobuf.Any content = 2; -} -``` - -### Custom Query Implementation - -In order to implement the query service, we can reuse the existing [gogo protobuf](https://github.com/gogo/protobuf) -grpc plugin, which for a service named `Query` generates an interface named -`QueryServer` as below: - -```go -type QueryServer interface { - QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) - QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) -} -``` - -The custom queries for our module are implemented by implementing this interface. - -The first parameter in this generated interface is a generic `context.Context`, -whereas querier methods generally need an instance of `sdk.Context` to read -from the store. Since arbitrary values can be attached to `context.Context` -using the `WithValue` and `Value` methods, the SDK should provide a function -`sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided -`context.Context`. - -An example implementation of `QueryBalance` for the bank module as above would -look something like: - -```go -type Querier struct { - Keeper -} - -func (q Querier) QueryBalance(ctx context.Context, params *types.QueryBalanceParams) (*sdk.Coin, error) { - balance := q.GetBalance(sdk.UnwrapSDKContext(ctx), params.Address, params.Denom) - return &balance, nil -} -``` - -### Custom Query Registration and Routing - -Query server implementations as above would be registered with `AppModule`s using -a new method `RegisterQueryService(grpc.Server)` which could be implemented simply -as below: - -```go -// x/bank/module.go -func (am AppModule) RegisterQueryService(server grpc.Server) { - types.RegisterQueryServer(server, keeper.Querier{am.keeper}) -} -``` - -Underneath the hood, a new method `RegisterService(sd *grpc.ServiceDesc, handler interface{})` -will be added to the existing `baseapp.QueryRouter` to add the queries to the custom -query routing table (with the routing method being described below). -The signature for this method matches the existing -`RegisterServer` method on the GRPC `Server` type where `handler` is the custom -query server implementation described above. - - -GRPC-like requests are routed by the service name (ex. `cosmos_sdk.x.bank.v1.Query`) -and method name (ex. `QueryBalance`) combined with `/`s to form a full -method name (ex. `/cosmos_sdk.x.bank.v1.Query/QueryBalance`). This gets translated -into an ABCI query as `custom/cosmos_sdk.x.bank.v1.Query/QueryBalance`. Service handlers -registered with `QueryRouter.RegisterService` will be routed this way. - -Beyond the method name, GRPC requests carry a protobuf encoded payload, which maps naturally -to `RequestQuery.Data`, and receive a protobuf encoded response or error. Thus -there is a quite natural mapping of GRPC-like rpc methods to the existing -`sdk.Query` and `QueryRouter` infrastructure. - -This basic specification allows us to reuse protocol buffer `service` definitions -for ABCI custom queries substantially reducing the need for manual decoding and -encoding in query methods. - -### GRPC Protocol Support - -In addition to providing an ABCI query pathway, we can easily provide a GRPC -proxy server that routes requests in the GRPC protocol to ABCI query requests -under the hood. In this way, clients could use their host languages' existing -GRPC implementations to make direct queries against Cosmos SDK app's using -these `service` definitions. In order for this server to work, the `QueryRouter` -on `BaseApp` will need to expose the service handlers registered with -`QueryRouter.RegisterService` to the proxy server implementation. Nodes could -launch the proxy server on a separate port in the same process as the ABCI app -with a command-line flag. - -### REST Queries and Swagger Generation - -[grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) is a project that -translates REST calls into GRPC calls using special annotations on service -methods. Modules that want to expose REST queries should add `google.api.http` -annotations to their `rpc` methods as in this example below. - -```proto -// x/bank/types/types.proto - -service Query { - rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { - option (google.api.http) = { - get: "/x/bank/v1/balance/{address}/{denom}" - }; - } - rpc QueryAllBalances(QueryAllBalancesParams) returns (QueryAllBalancesResponse) { - option (google.api.http) = { - get: "/x/bank/v1/balances/{address}" - }; - } -} -``` - -grpc-gateway will work direcly against the GRPC proxy described above which will -translate requests to ABCI queries under the hood. grpc-gateway can also -generate Swagger definitions automatically. - -In the current implementation of REST queries, each module needs to implement -REST queries manually in addition to ABCI querier methods. Using the grpc-gateway -approach, there will be no need to generate separate REST query handlers, just -query servers as described above as grpc-gateway handles the translation of protobuf -to REST as well as Swagger definitions. - -The SDK should provide CLI commands for apps to start GRPC gateway either in -a separate process or the same process as the ABCI app, as well as provide a -command for generating grpc-gateway proxy `.proto` files and the `swagger.json` -file. - -### Client Usage - -The gogo protobuf grpc plugin generates client interfaces in addition to server -interfaces. For the `Query` service defined above we would get a `QueryClient` -interface like: - -```go -type QueryClient interface { - QueryBalance(ctx context.Context, in *QueryBalanceParams, opts ...grpc.CallOption) (*types.Coin, error) - QueryAllBalances(ctx context.Context, in *QueryAllBalancesParams, opts ...grpc.CallOption) (*QueryAllBalancesResponse, error) -} -``` - -Via a small patch to gogo protobuf ([gogo/protobuf#675](https://github.com/gogo/protobuf/pull/675)) -we have tweaked the grpc codegen to use an interface rather than concrete type -for the generated client struct. This allows us to also reuse the GRPC infrastructure -for ABCI client queries. - -1Context` will receive a new method `QueryConn` that returns a `ClientConn` -that routes calls to ABCI queries - -Clients (such as CLI methods) will then be able to call query methods like this: - -```go -clientCtx := client.NewContext() -queryClient := types.NewQueryClient(clientCtx.QueryConn()) -params := &types.QueryBalanceParams{addr, denom} -result, err := queryClient.QueryBalance(gocontext.Background(), params) -``` - -### Testing - -Tests would be able to create a query client directly from keeper and `sdk.Context` -references using a `QueryServerTestHelper` as below: - -```go -queryHelper := baseapp.NewQueryServerTestHelper(ctx) -types.RegisterQueryServer(queryHelper, keeper.Querier{app.BankKeeper}) -queryClient := types.NewQueryClient(queryHelper) -``` - -## Future Improvements - -## Consequences - -### Positive - -* greatly simplified querier implementation (no manual encoding/decoding) -* easy query client generation (can use existing grpc and swagger tools) -* no need for REST query implementations -* type safe query methods (generated via grpc plugin) -* going forward, there will be less breakage of query methods because of the -backwards compatibility guarantees provided by buf - -### Negative - -* all clients using the existing ABCI/REST queries will need to be refactored -for both the new GRPC/REST query paths as well as protobuf/proto-json encoded -data, but this is more or less unavoidable in the protobuf refactoring - -### Neutral - -## References diff --git a/docs/architecture/adr-022-custom-panic-handling.md b/docs/architecture/adr-022-custom-panic-handling.md deleted file mode 100644 index 6b45447305..0000000000 --- a/docs/architecture/adr-022-custom-panic-handling.md +++ /dev/null @@ -1,214 +0,0 @@ -# ADR 022: Custom BaseApp panic handling - -## Changelog - -- 2020 Apr 24: Initial Draft - -## Context - -The current implementation of BaseApp does not allow developers to write custom error handlers during panic recovery -[runTx()](https://github.com/cosmos/cosmos-sdk/blob/bad4ca75f58b182f600396ca350ad844c18fc80b/baseapp/baseapp.go#L539) -method. We think that this method can be more flexible and can give SDK users more options for customizations without -the need to rewrite whole BaseApp. Also there's one special case for `sdk.ErrorOutOfGas` error handling, that case -might be handled in a "standard" way (middleware) alongside the others. - -We propose middleware-solution, which could help developers implement the following cases: -* add external logging (let's say sending reports to external services like [Sentry](https://sentry.io)); -* call panic for specific error cases; - -It will also make `OutOfGas` case and `default` case one of the middlewares. -`Default` case wraps recovery object to an error and logs it ([example middleware implementation](#Recovery-middleware)). - -Our project has a sidecar service running alongside the blockchain node (smart contracts virtual machine). It is -essential that node <-> sidecar connectivity stays stable for TXs processing. So when the communication breaks we need -to crash the node and reboot it once the problem is solved. That behaviour makes node's state machine execution -deterministic. As all keeper panics are caught by runTx's `defer()` handler, we have to adjust the BaseApp code -in order to customize it. - -## Decision - -### Design - -#### Overview - -Instead of hardcoding custom error handling into BaseApp we suggest using set of middlewares which can be customized -externally and will allow developers use as many custom error handlers as they want. Implementation with tests -can be found [here](https://github.com/cosmos/cosmos-sdk/pull/6053). - -#### Implementation details - -##### Recovery handler - -New `RecoveryHandler` type added. `recoveryObj` input argument is an object returned by the standard Go function -`recover()` from the `builtin` package. - -```go -type RecoveryHandler func(recoveryObj interface{}) error -``` - -Handler should type assert (or other methods) an object to define if object should be handled. -`nil` should be returned if input object can't be handled by that `RecoveryHandler` (not a handler's target type). -Not `nil` error should be returned if input object was handled and middleware chain execution should be stopped. - -An example: - -```go -func exampleErrHandler(recoveryObj interface{}) error { - err, ok := recoveryObj.(error) - if !ok { return nil } - - if someSpecificError.Is(err) { - panic(customPanicMsg) - } else { - return nil - } -} -``` - -This example breaks the application execution, but it also might enrich the error's context like the `OutOfGas` handler. - -##### Recovery middleware - -We also add a middleware type (decorator). That function type wraps `RecoveryHandler` and returns the next middleware in -execution chain and handler's `error`. Type is used to separate actual `recovery()` object handling from middleware -chain processing. - -```go -type recoveryMiddleware func(recoveryObj interface{}) (recoveryMiddleware, error) - -func newRecoveryMiddleware(handler RecoveryHandler, next recoveryMiddleware) recoveryMiddleware { - return func(recoveryObj interface{}) (recoveryMiddleware, error) { - if err := handler(recoveryObj); err != nil { - return nil, err - } - return next, nil - } -} -``` - -Function receives a `recoveryObj` object and returns: -* (next `recoveryMiddleware`, `nil`) if object wasn't handled (not a target type) by `RecoveryHandler`; -* (`nil`, not nil `error`) if input object was handled and other middlewares in the chain should not be executed; -* (`nil`, `nil`) in case of invalid behavior. Panic recovery might not have been properly handled; -this can be avoided by always using a `default` as a rightmost middleware in the chain (always returns an `error`'); - - -`OutOfGas` middleware example: -```go -func newOutOfGasRecoveryMiddleware(gasWanted uint64, ctx sdk.Context, next recoveryMiddleware) recoveryMiddleware { - handler := func(recoveryObj interface{}) error { - err, ok := recoveryObj.(sdk.ErrorOutOfGas) - if !ok { return nil } - - return sdkerrors.Wrap( - sdkerrors.ErrOutOfGas, fmt.Sprintf( - "out of gas in location: %v; gasWanted: %d, gasUsed: %d", err.Descriptor, gasWanted, ctx.GasMeter().GasConsumed(), - ), - ) - } - - return newRecoveryMiddleware(handler, next) -} -``` - -`Default` middleware example: -```go -func newDefaultRecoveryMiddleware() recoveryMiddleware { - handler := func(recoveryObj interface{}) error { - return sdkerrors.Wrap( - sdkerrors.ErrPanic, fmt.Sprintf("recovered: %v\nstack:\n%v", recoveryObj, string(debug.Stack())), - ) - } - - return newRecoveryMiddleware(handler, nil) -} -``` - -##### Recovery processing - -Basic chain of middlewares processing would look like: - -```go -func processRecovery(recoveryObj interface{}, middleware recoveryMiddleware) error { - if middleware == nil { return nil } - - next, err := middleware(recoveryObj) - if err != nil { return err } - if next == nil { return nil } - - return processRecovery(recoveryObj, next) -} -``` - -That way we can create a middleware chain which is executed from left to right, the rightmost middleware is a -`default` handler which must return an `error`. - -##### BaseApp changes - -The `default` middleware chain must exist in a `BaseApp` object. `Baseapp` modifications: - -```go -type BaseApp struct { - // ... - runTxRecoveryMiddleware recoveryMiddleware -} - -func NewBaseApp(...) { - // ... - app.runTxRecoveryMiddleware = newDefaultRecoveryMiddleware() -} - -func (app *BaseApp) runTx(...) { - // ... - defer func() { - if r := recover(); r != nil { - recoveryMW := newOutOfGasRecoveryMiddleware(gasWanted, ctx, app.runTxRecoveryMiddleware) - err, result = processRecovery(r, recoveryMW), nil - } - - gInfo = sdk.GasInfo{GasWanted: gasWanted, GasUsed: ctx.GasMeter().GasConsumed()} - }() - // ... -} -``` - -Developers can add their custom `RecoveryHandler`s by providing `AddRunTxRecoveryHandler` as a BaseApp option parameter to the `NewBaseapp` constructor: - -```go -func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) { - for _, h := range handlers { - app.runTxRecoveryMiddleware = newRecoveryMiddleware(h, app.runTxRecoveryMiddleware) - } -} -``` - -This method would prepend handlers to an existing chain. - -## Status - -Proposed - -## Consequences - -### Positive - -- Developers of Cosmos SDK based projects can add custom panic handlers to: - * add error context for custom panic sources (panic inside of custom keepers); - * emit `panic()`: passthrough recovery object to the Tendermint core; - * other necessary handling; -- Developers can use standard Cosmos SDK `BaseApp` implementation, rather that rewriting it in their projects; -- Proposed solution doesn't break the current "standard" `runTx()` flow; - -### Negative - -- Introduces changes to the execution model design. - -### Neutral - -- `OutOfGas` error handler becomes one of the middlewares; -- Default panic handler becomes one of the middlewares; - -## References - -- [PR-6053 with proposed solution](https://github.com/cosmos/cosmos-sdk/pull/6053) -- [Similar solution. ADR-010 Modular AnteHandler](https://github.com/cosmos/cosmos-sdk/blob/v0.38.3/docs/architecture/adr-010-modular-antehandler.md) diff --git a/docs/architecture/adr-023-protobuf-naming.md b/docs/architecture/adr-023-protobuf-naming.md deleted file mode 100644 index 1322f097f5..0000000000 --- a/docs/architecture/adr-023-protobuf-naming.md +++ /dev/null @@ -1,258 +0,0 @@ -# ADR 023: Protocol Buffer Naming and Versioning Conventions - -## Changelog - -- 2020 April 27: Initial Draft -- 2020 August 5: Update guidelines - -## Status - -Accepted - -## Context - -Protocol Buffers provide a basic [style guide](https://developers.google.com/protocol-buffers/docs/style) -and [Buf](https://buf.build/docs/style-guide) builds upon that. To the -extent possible, we want to follow industry accepted guidelines and wisdom for -the effective usage of protobuf, deviating from those only when there is clear -rationale for our use case. - -### Adoption of `Any` - -The adoption of `google.protobuf.Any` as the recommended approach for encoding -interface types (as opposed to `oneof`) makes package naming a central part -of the encoding as fully-qualified message names now appear in encoded -messages. - -### Current Directory Organization - -Thus far we have mostly followed [Buf's](https://buf.build) [DEFAULT](https://buf.build/docs/lint-checkers#default) -recommendations, with the minor deviation of disabling [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout) -which although being convenient for developing code comes with the warning -from Buf that: - -> you will have a very bad time with many Protobuf plugins across various languages if you do not do this - -### Adoption of gRPC Queries - -In [ADR 021](adr-021-protobuf-query-encoding.md), gRPC was adopted for Protobuf -native queries. The full gRPC service path thus becomes a key part of ABCI query -path. In the future, gRPC queries may be allowed from within persistent scripts -by technologies such as CosmWasm and these query routes would be stored within -script binaries. - -## Decision - -The goal of this ADR is to provide thoughtful naming conventions that: - -* encourage a good user experience for when users interact directly with -.proto files and fully-qualified protobuf names -* balance conciseness against the possibility of either over-optimizing (making -names too short and cryptic) or under-optimizing (just accepting bloated names -with lots of redundant information) - -These guidelines are meant to act as a style guide for both the SDK and -third-party modules. - -As a starting point, we should adopt all of the [DEFAULT](https://buf.build/docs/lint-checkers#default) -checkers in [Buf's](https://buf.build) including [`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout), -except: -* [PACKAGE_VERSION_SUFFIX](https://buf.build/docs/lint-checkers#package_version_suffix) -* [SERVICE_SUFFIX](https://buf.build/docs/lint-checkers#service_suffix) - -Further guidelines to be described below. - -### Principles - -#### Concise and Descriptive Names - -Names should be descriptive enough to convey their meaning and distinguish -them from other names. - -Given that we are using fully-qualifed names within -`google.protobuf.Any` as well as within gRPC query routes, we should aim to -keep names concise, without going overboard. The general rule of thumb should -be if a shorter name would convey more or else the same thing, pick the shorter -name. - -For instance, `cosmos.bank.MsgSend` (19 bytes) conveys roughly the same information -as `cosmos_sdk.x.bank.v1.MsgSend` (28 bytes) but is more concise. - -Such conciseness makes names both more pleasant to work with and take up less -space within transactions and on the wire. - -We should also resist the temptation to over-optimize, by making names -cryptically short with abbreviations. For instance, we shouldn't try to -reduce `cosmos.bank.MsgSend` to `csm.bk.MSnd` just to save a few bytes. - -The goal is to make names **_concise but not cryptic_**. - -#### Names are for Clients First - -Package and type names should be chosen for the benefit of users, not -necessarily because of legacy concerns related to the go code-base. - -#### Plan for Longevity - -In the interests of long-term support, we should plan on the names we do -choose to be in usage for a long time, so now is the opportunity to make -the best choices for the future. - -### Versioning - -#### Guidelines on Stable Package Versions - -In general, schema evolution is the way to update protobuf schemas. That means that new fields, -messages, and RPC methods are _added_ to existing schemas and old fields, messages and RPC methods -are maintained as long as possible. - -Breaking things is often unacceptable in a blockchain scenario. For instance, immutable smart contracts -may depend on certain data schemas on the host chain. If the host chain breaks those schemas, the smart -contract may be irreparably broken. Even when things can be fixed (for instance in client software), -this often comes at a high cost. - -Instead of breaking things, we should make every effort to evolve schemas rather than just breaking them. -[Buf](https://buf.build) breaking change detection should be used on all stable (non-alpha or beta) packages -to prevent such breakage. - -With that in mind, different stable versions (i.e. `v1` or `v2`) of a package should more or less be considered -different packages and this should be last resort approach for upgrading protobuf schemas. Scenarios where creating -a `v2` may make sense are: -* we want to create a new module with similar functionality to an existing module and adding `v2` is the most natural -way to do this. In that case, there are really just two different, but similar modules with different APIs. -* we want to add a new revamped API for an existing module and it's just too cumbersome to add it to the existing package, -so putting it in `v2` is cleaner for users. In this case, care should be made to not deprecate support for -`v1` if it is actively used in immutable smart contracts. - -#### Guidelines on unstable (alpha and beta) package versions - -The following guidelines are recommended for marking packages as alpha or beta: -* marking something as `alpha` or `beta` should be a last resort and just putting something in the -stable package (i.e. `v1` or `v2`) should be preferred -* a package *should* be marked as `alpha` *if and only if* there are active discussions to remove -or significantly alter the package in the near future -* a package *should* be marked as `beta` *if and only if* there is an active discussion to -significantly refactor/rework the functionality in the near future but not remove it -* modules *can and should* have types in both stable (i.e. `v1` or `v2`) and unstable (`alpha` or `beta`) packages. - -*`alpha` and `beta` should not be used to avoid responsibility for maintaining compatibility.* -Whenever code is released into the wild, especially on a blockchain, there is a high cost to changing things. In some -cases, for instance with immutable smart contracts, a breaking change may be impossible to fix. - -When marking something as `alpha` or `beta`, maintainers should ask the questions: -* what is the cost of asking others to change their code vs the benefit of us maintaining the optionality to change it? -* what is the plan for moving this to `v1` and how will that affect users? - -`alpha` or `beta` should really be used to communicate "changes are planned". - -As a case study, gRPC reflection is in the package `grpc.reflection.v1alpha`. It hasn't been changed since -2017 and it is now used in other widely used software like gRPCurl. Some folks probably use it in production services -and so if they actually went and changed the package to `grpc.reflection.v1`, some software would break and -they probably don't want to do that... So now the `v1alpha` package is more or less the de-facto `v1`. Let's not do that. - -The following are guidelines for working with non-stable packages: -* [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix) -(ex. `v1alpha1`) _should_ be used for non-stable packages -* non-stable packages should generally be excluded from breaking change detection -* immutable smart contract modules (i.e. CosmWasm) _should_ block smart contracts/persistent -scripts from interacting with `alpha`/`beta` packages - -#### Omit v1 suffix - -Instead of using [Buf's recommended version suffix](https://buf.build/docs/lint-checkers#package_version_suffix), -we can omit `v1` for packages that don't actually have a second version. This -allows for more concise names for common use cases like `cosmos.bank.Send`. -Packages that do have a second or third version can indicate that with `.v2` -or `.v3`. - -### Package Naming - -#### Adopt a short, unique top-level package name - -Top-level packages should adopt a short name that is known to not collide with -other names in common usage within the Cosmos ecosystem. In the near future, a -registry should be created to reserve and index top-level package names used -within the Cosmos ecosystem. Because the Cosmos SDK is intended to provide -the top-level types for the Cosmos project, the top-level package name `cosmos` -is recommended for usage within the Cosmos SDK instead of the longer `cosmos_sdk`. -[ICS](https://github.com/cosmos/ics) specifications could consider a -short top-level package like `ics23` based upon the standard number. - -#### Limit sub-package depth - -Sub-package depth should be increased with caution. Generally a single -sub-package is needed for a module or a library. Even though `x` or `modules` -is used in source code to denote modules, this is often unnecessary for .proto -files as modules are the primary thing sub-packages are used for. Only items which -are known to be used infrequently should have deep sub-package depths. - -For the Cosmos SDK, it is recommended that that we simply write `cosmos.bank`, -`cosmos.gov`, etc. rather than `cosmos.x.bank`. In practice, most non-module -types can go straight in the `cosmos` package or we can introduce a -`cosmos.base` package if needed. Note that this naming _will not_ change -go package names, i.e. the `cosmos.bank` protobuf package will still live in -`x/bank`. - -### Message Naming - -Message type names should be as concise possible without losing clarity. `sdk.Msg` -types which are used in transactions will retain the `Msg` prefix as that provides -helpful context. - -### Service and RPC Naming - -[ADR 021](adr-021-protobuf-query-encoding.md) specifies that modules should -implement a gRPC query service. We should consider the principle of conciseness -for query service and RPC names as these may be called from persistent script -modules such as CosmWasm. Also, users may use these query paths from tools like -[gRPCurl](https://github.com/fullstorydev/grpcurl). As an example, we can shorten -`/cosmos_sdk.x.bank.v1.QueryService/QueryBalance` to -`/cosmos.bank.Query/Balance` without losing much useful information. - -RPC request and response types _should_ follow the `ServiceNameMethodNameRequest`/ -`ServiceNameMethodNameResponse` naming convention. i.e. for an RPC method named `Balance` -on the `Query` service, the request and response types would be `QueryBalanceRequest` -and `QueryBalanceResponse`. This will be more self-explanatory than `BalanceRequest` -and `BalanceResponse`. - -#### Use just `Query` for the query service - -Instead of [Buf's default service suffix recommendation](https://github.com/cosmos/cosmos-sdk/pull/6033), -we should simply use the shorter `Query` for query services. - -For other types of gRPC services, we should consider sticking with Buf's -default recommendation. - -#### Omit `Get` and `Query` from query service RPC names - -`Get` and `Query` should be omitted from `Query` service names because they are -redundant in the fully-qualified name. For instance, `/cosmos.bank.Query/QueryBalance` -just says `Query` twice without any new information. - -## Future Improvements - -A registry of top-level package names should be created to coordinate naming -across the ecosystem, prevent collisions, and also help developers discover -useful schemas. A simple starting point would be a git repository with -community-based governance. - -## Consequences - -### Positive - -* names will be more concise and easier to read and type -* all transactions using `Any` will be at shorter (`_sdk.x` and `.v1` will be removed) -* `.proto` file imports will be more standard (without `"third_party/proto"` in -the path) -* code generation will be easier for clients because .proto files will be -in a single `proto/` directory which can be copied rather than scattered -throughout the SDK - -### Negative - -### Neutral - -* `.proto` files will need to be reorganized and refactored -* some modules may need to be marked as alpha or beta - -## References diff --git a/docs/architecture/adr-024-coin-metadata.md b/docs/architecture/adr-024-coin-metadata.md deleted file mode 100644 index 5195a9c400..0000000000 --- a/docs/architecture/adr-024-coin-metadata.md +++ /dev/null @@ -1,139 +0,0 @@ -# ADR 024: Coin Metadata - -## Changelog - -- 05/19/2020: Initial draft - -## Status - -Proposed - -## Context - -Assets in the Cosmos SDK are represented via a `Coins` type that consists of an `amount` and a `denom`, -where the `amount` can be any arbitrarily large or small value. In addition, the Cosmos SDK uses an -account-based model where there are two types of primary accounts -- basic accounts and module accounts. -All account types have a set of balances that are composed of `Coins`. The `x/bank` module keeps -track of all balances for all accounts and also keeps track of the total supply of balances in an -application. - -With regards to a balance `amount`, the Cosmos SDK assumes a static and fixed unit of denomination, -regardless of the denomination itself. In other words, clients and apps built atop a Cosmos-SDK-based -chain may choose to define and use arbitrary units of denomination to provide a richer UX, however, by -the time a tx or operation reaches the Cosmos SDK state machine, the `amount` is treated as a single -unit. For example, for the Cosmos Hub (Gaia), clients assume 1 ATOM = 10^6 uatom, and so all txs and -operations in the Cosmos SDK work off of units of 10^6. - -This clearly provides a poor and limited UX especially as interoperability of networks increases and -as a result the total amount of asset types increases. We propose to have `x/bank` additionally keep -track of metadata per `denom` in order to help clients, wallet providers, and explorers improve their -UX and remove the requirement for making any assumptions on the unit of denomination. - -## Decision - -The `x/bank` module will be updated to store and index metadata by `denom`, specifically the "base" or -smallest unit -- the unit the Cosmos SDK state-machine works with. - -Metadata may also include a non-zero length list of denominations. Each entry contains the name of -the denomination `denom`, the exponent to the base and a list of aliases. An entry is to be -interpreted as `1 denom = 10^exponent base_denom` (e.g. `1 ETH = 10^18 wei` and `1 uatom = 10^0 uatom`). - -There are two denominations that are of high importance for clients: the `base`, which is the smallest -possible unit and the `display`, which is the unit that is commonly referred to in human communication -and on exchanges. The values in those fields link to an entry in the list of denominations. - -The list in `denom_units` and the `display` entry may be changed via governance. - -As a result, we can define the type as follows: - -```protobuf -message DenomUnit { - string denom = 1; - uint32 exponent = 2; - repeated string aliases = 3; -} - -message Metadata { - string description = 1; - repeated DenomUnit denom_units = 2; - string base = 3; - string display = 4; -} -``` - -As an example, the ATOM's metadata can be defined as follows: - -```json -{ - "description": "The native staking token of the Cosmos Hub.", - "denom_units": [ - { - "denom": "uatom", - "exponent": 0, - "aliases": [ - "microatom" - ], - }, - { - "denom": "matom", - "exponent": 3, - "aliases": [ - "milliatom" - ] - }, - { - "denom": "atom", - "exponent": 6, - } - ], - "base": "uatom", - "display": "atom", -} -``` - -Given the above metadata, a client may infer the following things: - -- 4.3atom = 4.3 * (10^6) = 4,300,000uatom -- The string "atom" can be used as a display name in a list of tokens. -- The balance 4300000 can be displayed as 4,300,000uatom or 4,300matom or 4.3atom. - The `display` denomination 4.3atom is a good default if the authors of the client don't make - an explicit decision to choose a different representation. - -A client should be able to query for metadata by denom both via the CLI and REST interfaces. In -addition, we will add handlers to these interfaces to convert from any unit to another given unit, -as the base framework for this already exists in the Cosmos SDK. - -Finally, we need to ensure metadata exists in the `GenesisState` of the `x/bank` module which is also -indexed by the base `denom`. - -```go -type GenesisState struct { - SendEnabled bool `json:"send_enabled" yaml:"send_enabled"` - Balances []Balance `json:"balances" yaml:"balances"` - Supply sdk.Coins `json:"supply" yaml:"supply"` - DenomMetadata []Metadata `json:"denom_metadata" yaml:"denom_metadata"` -} -``` - -## Future Work - -In order for clients to avoid having to convert assets to the base denomination -- either manually or -via an endpoint, we may consider supporting automatic conversion of a given unit input. - -## Consequences - -### Positive - -- Provides clients, wallet providers and block explorers with additional data on - asset denomination to improve UX and remove any need to make assumptions on - denomination units. - -### Negative - -- A small amount of required additional storage in the `x/bank` module. The amount - of additional storage should be minimal as the amount of total assets should not - be large. - -### Neutral - -## References diff --git a/docs/architecture/adr-025-ibc-passive-channels.md b/docs/architecture/adr-025-ibc-passive-channels.md deleted file mode 100644 index 4f12a042ad..0000000000 --- a/docs/architecture/adr-025-ibc-passive-channels.md +++ /dev/null @@ -1,140 +0,0 @@ -# ADR 025: IBC Passive Channels - -## Changelog - -- 2020-05-23: Provide sample Go code and more details -- 2020-05-18: Initial Draft - -## Status - -Proposed - -## Context - -The current "naive" IBC Relayer strategy currently establishes a single predetermined IBC channel atop a single connection between two clients (each potentially of a different chain). This strategy then detects packets to be relayed by watching for `send_packet` and `recv_packet` events matching that channel, and sends the necessary transactions to relay those packets. - -We wish to expand this "naive" strategy to a "passive" one which detects and relays both channel handshake messages and packets on a given connection, without the need to know each channel in advance of relaying it. - -In order to accomplish this, we propose adding more comprehensive events to expose channel metadata for each transaction sent from the `x/ibc/core/04-channel/keeper/handshake.go` and `x/ibc/core/04-channel/keeper/packet.go` modules. - -Here is an example of what would be in `ChanOpenInit`: - -```go -const ( - EventTypeChannelMeta = "channel_meta" - AttributeKeyAction = "action" - AttributeKeyHops = "hops" - AttributeKeyOrder = "order" - AttributeKeySrcPort = "src_port" - AttributeKeySrcChannel = "src_channel" - AttributeKeySrcVersion = "src_version" - AttributeKeyDstPort = "dst_port" - AttributeKeyDstChannel = "dst_channel" - AttributeKeyDstVersion = "dst_version" -) -// ... - // Emit Event with Channel metadata for the relayer to pick up and - // relay to the other chain - // This appears immediately before the successful return statement. - ctx.EventManager().EmitEvents(sdk.Events{ - sdk.NewEvent( - types.EventTypeChannelMeta, - sdk.NewAttribute(types.AttributeKeyAction, "open_init"), - sdk.NewAttribute(types.AttributeKeySrcConnection, connectionHops[0]), - sdk.NewAttribute(types.AttributeKeyHops, strings.Join(connectionHops, ",")), - sdk.NewAttribute(types.AttributeKeyOrder, order.String()), - sdk.NewAttribute(types.AttributeKeySrcPort, portID), - sdk.NewAttribute(types.AttributeKeySrcChannel, chanenlID), - sdk.NewAttribute(types.AttributeKeySrcVersion, version), - sdk.NewAttribute(types.AttributeKeyDstPort, counterparty.GetPortID()), - sdk.NewAttribute(types.AttributeKeyDstChannel, counterparty.GetChannelID()), - // The destination version is not yet known, but a value is necessary to pad - // the event attribute offsets - sdk.NewAttribute(types.AttributeKeyDstVersion, ""), - ), - }) -``` - -These metadata events capture all the "header" information needed to route IBC channel handshake transactions without requiring the client to query any data except that of the connection ID that it is willing to relay. It is intended that `channel_meta.src_connection` is the only event key that needs to be indexed for a passive relayer to function. - -### Handling Channel Open Attempts - -In the case of the passive relayer, when one chain sends a `ChanOpenInit`, the relayer should inform the other chain of this open attempt and allow that chain to decide how (and if) it continues the handshake. Once both chains have actively approved the channel opening, then the rest of the handshake can happen as it does with the current "naive" relayer. - -To implement this behavior, we propose replacing the `cbs.OnChanOpenTry` callback with a new `cbs.OnAttemptChanOpenTry` callback which explicitly handles the `MsgChannelOpenTry`, usually by resulting in a call to `keeper.ChanOpenTry`. The typical implementation, in `x/ibc-transfer/module.go` would be compatible with the current "naive" relayer, as follows: - -```go -func (am AppModule) OnAttemptChanOpenTry( - ctx sdk.Context, - chanKeeper channel.Keeper, - portCap *capability.Capability, - msg channel.MsgChannelOpenTry, -) (*sdk.Result, error) { - // Require portID is the portID transfer module is bound to - boundPort := am.keeper.GetPort(ctx) - if boundPort != msg.PortID { - return nil, sdkerrors.Wrapf(porttypes.ErrInvalidPort, "invalid port: %s, expected %s", msg.PortID, boundPort) - } - - // BEGIN NEW CODE - // Assert our protocol version, overriding the relayer's suggestion. - msg.Version = types.Version - // Continue the ChanOpenTry. - res, chanCap, err := channel.HandleMsgChannelOpenTry(ctx, chanKeeper, portCap, msg) - if err != nil { - return nil, err - } - // END OF NEW CODE - - // ... the rest of the callback is similar to the existing OnChanOpenTry - // but uses msg.* directly. -``` - -Here is how this callback would be used, in the implementation of `x/ibc/handler.go`: - -```go -// ... - case channel.MsgChannelOpenTry: - // Lookup module by port capability - module, portCap, err := k.PortKeeper.LookupModuleByPort(ctx, msg.PortID) - if err != nil { - return nil, sdkerrors.Wrap(err, "could not retrieve module from port-id") - } - // Retrieve callbacks from router - cbs, ok := k.Router.GetRoute(module) - if !ok { - return nil, sdkerrors.Wrapf(port.ErrInvalidRoute, "route not found to module: %s", module) - } - // Delegate to the module's OnAttemptChanOpenTry. - return cbs.OnAttemptChanOpenTry(ctx, k.ChannelKeeper, portCap, msg) -``` - -The reason we do not have a more structured interaction between `x/ibc/handler.go` and the port's module (to explicitly negotiate versions, etc) is that we do not wish to constrain the app module to have to finish handling the `MsgChannelOpenTry` during this transaction or even this block. - -## Decision - -- Expose events to allow "passive" connection relayers. -- Enable application-initiated channels via such passive relayers. -- Allow port modules to control how to handle open-try messages. - -## Consequences - -### Positive - -Makes channels into a complete application-level abstraction. - -Applications have full control over initiating and accepting channels, rather than expecting a relayer to tell them when to do so. - -A passive relayer does not have to know what kind of channel (version string, ordering constraints, firewalling logic) the application supports. These are negotiated directly between applications. - -### Negative - -Increased event size for IBC messages. - -### Neutral - -More IBC events are exposed. - -## References - -- The Agoric VM's IBC handler currently [accomodates `attemptChanOpenTry`](https://github.com/Agoric/agoric-sdk/blob/904b3a0423222a1b32893453e44bbde598473960/packages/cosmic-swingset/lib/ag-solo/vats/ibc.js#L546) diff --git a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md b/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md deleted file mode 100644 index dc34bbf33e..0000000000 --- a/docs/architecture/adr-026-ibc-client-recovery-mechanisms.md +++ /dev/null @@ -1,75 +0,0 @@ -# ADR 026: IBC Client Recovery Mechanisms - -## Changelog - -- 2020/06/23: Initial version -- 2020/08/06: Revisions per review & to reference version - -## Status - -*Proposed* - -## Context - -### Summary - -At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behavior) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases. - -### Exceptional cases - -The state of concern is where a client associated with connection(s) and channel(s) can no longer be updated. This can happen for several reasons: - -1. The chain which the client is following has halted and is no longer producing blocks/headers, so no updates can be made to the client -1. The chain which the client is following has continued to operate, but no relayer has submitted a new header within the unbonding period, and the client has expired - 1. This could be due to real misbehaviour (intentional Byzantine behaviour) or merely a mistake by validators, but the client cannot distinguish these two cases -1. The chain which the client is following has experienced a misbehaviour event, and the client has been frozen & thus can no longer be updated - -### Security model - -Two-thirds of the validator set (the quorum for governance, module participation) can already sign arbitrary data, so allowing governance to manually force-update a client with a new header after a delay period does not substantially alter the security model. - -## Decision - -We elect not to deal with chains which have actually halted, which is necessarily Byzantine behaviour and in which case token recovery is not likely possible anyways (in-flight packets cannot be timed-out, but the relative impact of that is minor). - -1. Require Tendermint light clients (ICS 07) to be created with the following additional flags - 1. `allow_governance_override_after_expiry` (boolean, default false) -1. Require Tendermint light clients (ICS 07) to expose the following additional internal query functions - 1. `Expired() boolean`, which returns whether or not the client has passed the trusting period since the last update (in which case no headers can be validated) -1. Require Tendermint light clients (ICS 07) to expose the following additional state mutation functions - 1. `Unfreeze()`, which unfreezes a light client after misbehaviour and clears any frozen height previously set -1. Require Tendermint light clients (ICS 07) & solo machine clients (ICS 06) to be created with the following additional flags - 1. `allow_governance_override_after_misbehaviour` (boolean, default false) -1. Add a new governance proposal type, `ClientUpdateProposal`, in the `x/ibc` module - 1. Extend the base `Proposal` with a client identifier (`string`) and a header (`bytes`, encoded in a client-type-specific format) - 1. If this governance proposal passes, the client is updated with the provided header, if and only if: - 1. `allow_governance_override_after_expiry` is true and the client has expired (`Expired()` returns true) - 1. `allow_governance_override_after_misbehaviour` is true and the client has been frozen (`Frozen()` returns true) - 1. In this case, additionally, the client is unfrozen by calling `Unfreeze()` - -Note additionally that the header submitted by governance must be new enough that it will be possible to update the light client after the new header is inserted into the client state (which will only happen after the governance proposal has passed). - -This ADR does not address planned upgrades, which are handled separately as per the [specification](https://github.com/cosmos/ics/tree/master/spec/ics-007-tendermint-client#upgrades). - -## Consequences - -### Positive - -- Establishes a mechanism for client recovery in the case of expiry -- Establishes a mechanism for client recovery in the case of misbehaviour -- Clients can elect to disallow this recovery mechanism if they do not wish to allow for it - -### Negative - -- Additional complexity in client creation which must be understood by the user -- Governance participants must pick a new header, which is a bit different from their usual tasks - -### Neutral - -No neutral consequences. - -## References - -- [Prior discussion](https://github.com/cosmos/ics/issues/421) -- [Epoch number discussion](https://github.com/cosmos/ics/issues/439) -- [Upgrade plan discussion](https://github.com/cosmos/ics/issues/445) diff --git a/docs/architecture/adr-027-deterministic-protobuf-serialization.md b/docs/architecture/adr-027-deterministic-protobuf-serialization.md deleted file mode 100644 index 4de1cafb30..0000000000 --- a/docs/architecture/adr-027-deterministic-protobuf-serialization.md +++ /dev/null @@ -1,316 +0,0 @@ -# ADR 027: Deterministic Protobuf Serialization - -## Changelog - -- 2020-08-07: Initial Draft -- 2020-09-01: Further clarify rules - -## Status - -Proposed - -## Abstract - -Fully deterministic structure serialization, which works across many languages and clients, -is needed when signing messages. We need to be sure that whenever we serialize -a data structure, no matter in which supported language, the raw bytes -will stay the same. -[Protobuf](https://developers.google.com/protocol-buffers/docs/proto3) -serialization is not bijective (i.e. there exist a practically unlimited number of -valid binary representations for a given protobuf document)1. - -This document describes a deterministic serialization scheme for -a subset of protobuf documents, that covers this use case but can be reused in -other cases as well. - -### Context - -For signature verification in Cosmos SDK, the signer and verifier need to agree on -the same serialization of a `SignDoc` as defined in -[ADR-020](./adr-020-protobuf-transaction-encoding.md) without transmitting the -serialization. - -Currently, for block signatures we are using a workaround: we create a new [TxRaw](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L30) -instance (as defined in [adr-020-protobuf-transaction-encoding](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-020-protobuf-transaction-encoding.md#transactions)) -by converting all [Tx](https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L13) -fields to bytes on the client side. This adds an additional manual -step when sending and signing transactions. - -### Decision - -The following encoding scheme is to be used by other ADRs, -and in particular for `SignDoc` serialization. - -## Specification - -### Scope - -This ADR defines a protobuf3 serializer. The output is a valid protobuf -serialization, such that every protobuf parser can parse it. - -No maps are supported in version 1 due to the complexity of defining a -deterministic serialization. This might change in future. Implementations must -reject documents containing maps as invalid input. - -### Background - Protobuf3 Encoding - -Most numeric types in protobuf3 are encoded as -[varints](https://developers.google.com/protocol-buffers/docs/encoding#varints). -Varints are at most 10 bytes, and since each varint byte has 7 bits of data, -varints are a representation of `uint70` (70-bit unsigned integer). When -encoding, numeric values are casted from their base type to `uint70`, and when -decoding, the parsed `uint70` is casted to the appropriate numeric type. - -The maximum valid value for a varint that complies with protobuf3 is -`FF FF FF FF FF FF FF FF FF 7F` (i.e. `2**70 -1`). If the field type is -`{,u,s}int64`, the highest 6 bits of the 70 are dropped during decoding, -introducing 6 bits of malleability. If the field type is `{,u,s}int32`, the -highest 38 bits of the 70 are dropped during decoding, introducing 38 bits of -malleability. - -Among other sources of non-determinism, this ADR eliminates the possibility of -encoding malleability. - - -### Serialization rules - -The serialization is based on the -[protobuf3 encoding](https://developers.google.com/protocol-buffers/docs/encoding) -with the following additions: - -1. Fields must be serialized only once in ascending order -2. Extra fields or any extra data must not be added -3. [Default values](https://developers.google.com/protocol-buffers/docs/proto3#default) - must be omitted -4. `repeated` fields of scalar numeric types must use - [packed encoding](https://developers.google.com/protocol-buffers/docs/encoding#packed) -5. Varint encoding must not be longer than needed: - * No trailing zero bytes (in little endian, i.e. no leading zeroes in big - endian). Per rule 3 above, the default value of `0` must be omitted, so - this rule does not apply in such cases. - * The maximum value for a varint must be `FF FF FF FF FF FF FF FF FF 01`. - In other words, when decoded, the highest 6 bits of the 70-bit unsigned - integer must be `0`. (10-byte varints are 10 groups of 7 bits, i.e. - 70 bits, of which only the lowest 70-6=64 are useful.) - * The maximum value for 32-bit values in varint encoding must be `FF FF FF FF 0F` - with one exception (below). In other words, when decoded, the highest 38 - bits of the 70-bit unsigned integer must be `0`. - * The one exception to the above is _negative_ `int32`, which must be - encoded using the full 10 bytes for sign extension2. - * The maximum value for Boolean values in varint encoding must be `01` (i.e. - it must be `0` or `1`). Per rule 3 above, the default value of `0` must - be omitted, so if a Boolean is included it must have a value of `1`. - -While rule number 1. and 2. should be pretty straight forward and describe the -default behavior of all protobuf encoders the author is aware of, the 3rd rule -is more interesting. After a protobuf3 deserialization you cannot differentiate -between unset fields and fields set to the default value3. At -serialization level however, it is possible to set the fields with an empty -value or omitting them entirely. This is a significant difference to e.g. JSON -where a property can be empty (`""`, `0`), `null` or undefined, leading to 3 -different documents. - -Omitting fields set to default values is valid because the parser must assign -the default value to fields missing in the serialization4. For scalar -types, omitting defaults is required by the spec5. For `repeated` -fields, not serializing them is the only way to express empty lists. Enums must -have a first element of numeric value 0, which is the default6. And -message fields default to unset7. - -Omitting defaults allows for some amount of forward compatibility: users of -newer versions of a protobuf schema produce the same serialization as users of -older versions as long as newly added fields are not used (i.e. set to their -default value). - -### Implementation - -There are three main implementation strategies, ordered from the least to the -most custom development: - -- **Use a protobuf serializer that follows the above rules by default.** E.g. - [gogoproto](https://pkg.go.dev/github.com/gogo/protobuf/gogoproto) is known to - be compliant by in most cases, but not when certain annotations such as - `nullable = false` are used. It might also be an option to configure an - existing serializer accordingly. -- **Normalize default values before encoding them.** If your serializer follows - rule 1. and 2. and allows you to explicitly unset fields for serialization, - you can normalize default values to unset. This can be done when working with - [protobuf.js](https://www.npmjs.com/package/protobufjs): - - ```js - const bytes = SignDoc.encode({ - bodyBytes: body.length > 0 ? body : null, // normalize empty bytes to unset - authInfoBytes: authInfo.length > 0 ? authInfo : null, // normalize empty bytes to unset - chainId: chainId || null, // normalize "" to unset - accountNumber: accountNumber || null, // normalize 0 to unset - accountSequence: accountSequence || null, // normalize 0 to unset - }).finish(); - ``` - -- **Use a hand-written serializer for the types you need.** If none of the above - ways works for you, you can write a serializer yourself. For SignDoc this - would look something like this in Go, building on existing protobuf utilities: - - ```go - if !signDoc.body_bytes.empty() { - buf.WriteUVarInt64(0xA) // wire type and field number for body_bytes - buf.WriteUVarInt64(signDoc.body_bytes.length()) - buf.WriteBytes(signDoc.body_bytes) - } - - if !signDoc.auth_info.empty() { - buf.WriteUVarInt64(0x12) // wire type and field number for auth_info - buf.WriteUVarInt64(signDoc.auth_info.length()) - buf.WriteBytes(signDoc.auth_info) - } - - if !signDoc.chain_id.empty() { - buf.WriteUVarInt64(0x1a) // wire type and field number for chain_id - buf.WriteUVarInt64(signDoc.chain_id.length()) - buf.WriteBytes(signDoc.chain_id) - } - - if signDoc.account_number != 0 { - buf.WriteUVarInt64(0x20) // wire type and field number for account_number - buf.WriteUVarInt(signDoc.account_number) - } - - if signDoc.account_sequence != 0 { - buf.WriteUVarInt64(0x28) // wire type and field number for account_sequence - buf.WriteUVarInt(signDoc.account_sequence) - } - ``` - -### Test vectors - -Given the protobuf definition `Article.proto` - -```protobuf -package blog; -syntax = "proto3"; - -enum Type { - UNSPECIFIED = 0; - IMAGES = 1; - NEWS = 2; -}; - -enum Review { - UNSPECIFIED = 0; - ACCEPTED = 1; - REJECTED = 2; -}; - -message Article { - string title = 1; - string description = 2; - uint64 created = 3; - uint64 updated = 4; - bool public = 5; - bool promoted = 6; - Type type = 7; - Review review = 8; - repeated string comments = 9; - repeated string backlinks = 10; -}; -``` - -serializing the values - -```yaml -title: "The world needs change 🌳" -description: "" -created: 1596806111080 -updated: 0 -public: true -promoted: false -type: Type.NEWS -review: Review.UNSPECIFIED -comments: ["Nice one", "Thank you"] -backlinks: [] -``` - -must result in the serialization - -``` -0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 -``` - -When inspecting the serialized document, you see that every second field is -omitted: - -``` -$ echo 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e280138024a084e696365206f6e654a095468616e6b20796f75 | xxd -r -p | protoc --decode_raw -1: "The world needs change \360\237\214\263" -3: 1596806111080 -5: 1 -7: 2 -9: "Nice one" -9: "Thank you" -``` - -## Consequences - -Having such an encoding available allows us to get deterministic serialization -for all protobuf documents we need in the context of Cosmos SDK signing. - -### Positive - -- Well defined rules that can be verified independent of a reference - implementation -- Simple enough to keep the barrier to implement transaction signing low -- It allows us to continue to use 0 and other empty values in SignDoc, avoiding - the need to work around 0 sequences. This does not imply the change from - https://github.com/cosmos/cosmos-sdk/pull/6949 should not be merged, but not - too important anymore. - -### Negative - -- When implementing transaction signing, the encoding rules above must be - understood and implemented. -- The need for rule number 3. adds some complexity to implementations. -- Some data structures may require custom code for serialization. Thus - the code is not very portable - it will require additional work for each - client implementing serialization to properly handle custom data structures. - -### Neutral - - -### Usage in SDK - -For the reasons mentioned above ("Negative" section) we prefer to keep workarounds -for shared data structure. Example: the aforementioned `TxRaw` is using raw bytes -as a workaround. This allows them to use any valid Protobuf library without -the need of implementing a custom serializer that adheres to this standard (and related risks of bugs). - -## References - -- 1 _When a message is serialized, there is no guaranteed order for - how its known or unknown fields should be written. Serialization order is an - implementation detail and the details of any particular implementation may - change in the future. Therefore, protocol buffer parsers must be able to parse - fields in any order._ from - https://developers.google.com/protocol-buffers/docs/encoding#order -- 2 https://developers.google.com/protocol-buffers/docs/encoding#signed_integers -- 3 _Note that for scalar message fields, once a message is parsed - there's no way of telling whether a field was explicitly set to the default - value (for example whether a boolean was set to false) or just not set at all: - you should bear this in mind when defining your message types. For example, - don't have a boolean that switches on some behavior when set to false if you - don't want that behavior to also happen by default._ from - https://developers.google.com/protocol-buffers/docs/proto3#default -- 4 _When a message is parsed, if the encoded message does not - contain a particular singular element, the corresponding field in the parsed - object is set to the default value for that field._ from - https://developers.google.com/protocol-buffers/docs/proto3#default -- 5 _Also note that if a scalar message field is set to its default, - the value will not be serialized on the wire._ from - https://developers.google.com/protocol-buffers/docs/proto3#default -- 6 _For enums, the default value is the first defined enum value, - which must be 0._ from - https://developers.google.com/protocol-buffers/docs/proto3#default -- 7 _For message fields, the field is not set. Its exact value is - language-dependent._ from - https://developers.google.com/protocol-buffers/docs/proto3#default -- Encoding rules and parts of the reasoning taken from - [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3) diff --git a/docs/architecture/adr-028-public-key-addresses.md b/docs/architecture/adr-028-public-key-addresses.md deleted file mode 100644 index d7b3c884a5..0000000000 --- a/docs/architecture/adr-028-public-key-addresses.md +++ /dev/null @@ -1,168 +0,0 @@ -# ADR 028: Public Key Addresses - -## Changelog - -- 2020/08/18: Initial version - -## Status - -Proposed - -## Abstract - -This ADR defines a canonical 20-byte address format for new public key algorithms, multisig public keys, and module -accounts using string prefixes. - -## Context - -Issue [\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685) identified that public key -address spaces are currently overlapping. One initial proposal was extending the address length and -adding prefixes for different types of addresses. - -@ethanfrey explained an alternate approach originally used in https://github.com/iov-one/weave: - -> I spent quite a bit of time thinking about this issue while building weave... The other cosmos Sdk. - -> Basically I define a condition to be a type and format as human readable string with some binary data appended. This condition is hashed into an Address (again at 20 bytes). The use of this prefix makes it impossible to find a preimage for a given address with a different condition (eg ed25519 vs secp256k1). - -> This is explained in depth here https://weave.readthedocs.io/en/latest/design/permissions.html - -> And the code is here, look mainly at the top where we process conditions. https://github.com/iov-one/weave/blob/master/conditions.go - -And explained how this approach should be sufficiently collision resistant: -> Yeah, AFAIK, 20 bytes should be collision resistance when the preimages are unique and not malleable. A space of 2^160 would expect some collision to be likely around 2^80 elements (birthday paradox). And if you want to find a collision for some existing element in the database, it is still 2^160. 2^80 only is if all these elements are written to state. - -> The good example you brought up was eg. a public key bytes being a valid public key on two algorithms supported by the codec. Meaning if either was broken, you would break accounts even if they were secured with the safer variant. This is only as the issue when no differentiating type info is present in the preimage (before hashing into an address). - -> I would like to hear an argument if the 20 bytes space is an actual issue for security, as I would be happy to increase my address sizes in weave. I just figured cosmos and ethereum and bitcoin all use 20 bytes, it should be good enough. And the arguments above which made me feel it was secure. But I have not done a deeper analysis. - -In discussions in [\#5694](https://github.com/cosmos/cosmos-sdk/issues/5694), we agreed to go with an -approach similar to this where essentially we take the first 20 bytes of the `sha256` hash of -the key type concatenated with the key bytes, summarized as `Sha256(KeyTypePrefix || Keybytes)[:20]`. - -## Decision - -### Legacy Public Key Addresses Don't Change - -`secp256k1` and multisig public keys are currently in use in existing Cosmos SDK zones. They use the following -address formats: - -- secp256k1: `ripemd160(sha256(pk_bytes))[:20]` -- legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]` - -We don't want to change existing addresses. So the addresses for these two key types will remain the same. - -The current multisig public keys use amino serialization to generate the address. We will retain -those public keys and their address formatting, and call them "legacy amino" multisig public keys -in protobuf. We will also create multisig public keys without amino addresses to be described below. - - -### Canonical Address Format - -We have three types of accounts we would like to create addresses for in the future: -- regular public key addresses for new signature algorithms (ex. `sr25519`). -- public key addresses for multisig public keys that don't use amino encoding -- module accounts: basically any accounts which cannot sign transactions and -which are managed internally by modules - -To address all of these use cases we propose the following basic `AddressHash` function, -based on the discussions in [\#5694](https://github.com/cosmos/cosmos-sdk/issues/5694): - -```go -func AddressHash(prefix string, contents []byte) []byte { - preImage := []byte(prefix) - if len(contents) != 0 { - preImage = append(preImage, 0) - preImage = append(preImage, contents...) - } - return sha256.Sum256(preImage)[:20] -} -``` - -`AddressHash` always take a string `prefix` as a starting point which should represent the -type of public key (ex. `sr25519`) or module account being used (ex. `staking` or `group`). -For public keys, the `contents` parameter is used to specify the binary contents of the public -key. For module accounts, `contents` can be left empty (for modules which don't manage "sub-accounts"), -or can be some module-specific content to specify different pools (ex. `bonded` or `not-bonded` for `staking`) -or managed accounts (ex. different accounts managed by the `group` module). - -In the `preImage`, the byte value `0` is used as the separator between `prefix` and `contents`. This is a logical -choice given that `0` is an invalid value for a string character and is commonly used as a null terminator. - -### Canonical Public Key Address Prefixes - -All public key types will have a unique protobuf message type such as: - -```proto -package lbm.crypto.sr25519; - -message PubKey { - bytes key = 1; -} -``` - -All protobuf messages have unique fully qualified names, in this example `cosmos.crypto.sr25519.PubKey`. -These names are derived directly from .proto files in a standardized way and used -in other places such as the type URL in `Any`s. Since there is an easy and obvious -way to get this name for every protobuf type, we can use this message name as the -key type `prefix` when creating addresses. For all basic public keys, `contents` -should just be the raw unencoded public key bytes. - -Thus the canonical address for new public key types would be `AddressHash(proto.MessageName(pk), pk.Bytes)`. - -### Multisig Addresses - -For new multisig public keys, we define a custom address format not based on any encoding scheme -(amino or protobuf). This avoids issues with non-determinism in the encoding scheme. It also -ensures that multisig public keys which differ simply in the ordering of keys have the same -address by sorting child public keys first. - -First we define a proto message for multisig public keys: -```proto -package lbm.crypto.multisig; - -message PubKey { - uint32 threshold = 1; - repeated google.protobuf.Any public_keys = 2; -} -``` - -We define the following `Address()` function for this public key: - -``` -func (multisig PubKey) Address() { - // first gather all the addresses of each nested public key - var addresses [][]byte - for key := range multisig.Keys { - addresses = append(joinedAddresses, key.Address()) - } - - // then sort them in ascending order - addresses = Sort(addresses) - - // then concatenate them together - var joinedAddresses []byte - for addr := range addresses { - joinedAddresses := append(joinedAddresses, addr...) - } - - // form the string prefix from the message name (cosmos.crypto.multisig.PubKey) and the threshold joined together - prefix := fmt.Sprintf("%s/%d", proto.MessageName(multisig), multisig.Threshold) - - // use the standard AddressHash function - return AddressHash(prefix, joinedAddresses) -} -``` - -## Consequences - -### Positive -- a simple algorithm for generating addresses for new public keys and module accounts - -### Negative -- addresses do not communicate key type, a prefixed approach would have done this - -### Neutral -- protobuf message names are used as key type prefixes - -## References diff --git a/docs/architecture/adr-029-fee-grant-module.md b/docs/architecture/adr-029-fee-grant-module.md deleted file mode 100644 index 253a1dc038..0000000000 --- a/docs/architecture/adr-029-fee-grant-module.md +++ /dev/null @@ -1,162 +0,0 @@ -# ADR 029: Fee Grant Module - -## Changelog - -- 2020/08/18: Initial Draft - -## Status - -Accepted - -## Context - -In order to make blockchain transactions, the signing account must possess a sufficient balance of the right denomination -in order to pay fees. There are classes of transactions where needing to maintain a wallet with sufficient fees is a -barrier to adoption. - -For instance, when proper permissions are setup, someone may temporarily delegate the ability to vote on proposals to -a "burner" account that is stored on a mobile phone with only minimal security. - -Other use cases include workers tracking items in a supply chain or farmers submitting field data for analytics -or compliance purposes. - -For all of these use cases, UX would be significantly enhanced by obviating the need for these accounts to always -maintain the appropriate fee balance. This is especially true if we wanted to achieve enterprise adoption for something -like supply chain tracking. - -While one solution would be to have a service that fills up these accounts automatically with the appropriate fees, a better UX -would be provided by allowing these accounts to pull from a common fee pool account with proper spending limits. -A single pool would reduce the churn of making lots of small "fill up" transactions and also more effectively leverages -the resources of the organization setting up the pool. - -## Decision - -As a solution we propose a module, `x/feegrant` which allows one account, the "granter" to grant another account, the "grantee" -an allowance to spend the granter's account balance for fees within certain well-defined limits. - -Fee allowances are defined by the extensible `FeeAllowanceI` interface: - -```go -type FeeAllowanceI { - // Accept can use fee payment requested as well as timestamp/height of the current block - // to determine whether or not to process this. This is checked in - // Keeper.UseGrantedFees and the return values should match how it is handled there. - // - // If it returns an error, the fee payment is rejected, otherwise it is accepted. - // The FeeAllowance implementation is expected to update it's internal state - // and will be saved again after an acceptance. - // - // If remove is true (regardless of the error), the FeeAllowance will be deleted from storage - // (eg. when it is used up). (See call to RevokeFeeAllowance in Keeper.UseGrantedFees) - Accept(fee sdk.Coins, blockTime time.Time, blockHeight int64) (remove bool, err error) -} -``` - -Two basic fee allowance types, `BasicFeeAllowance` and `PeriodicFeeAllowance` are defined to support known use cases: - -```proto -// BasicFeeAllowance implements FeeAllowance with a one-time grant of tokens -// that optionally expires. The delegatee can use up to SpendLimit to cover fees. -message BasicFeeAllowance { - // spend_limit specifies the maximum amount of tokens that can be spent - // by this allowance and will be updated as tokens are spent. If it is - // empty, there is no spend limit and any amount of coins can be spent. - repeated cosmos_sdk.v1.Coin spend_limit = 1; - - // expires_at specifies an optional time when this allowance expires - ExpiresAt expiration = 2; -} - -// PeriodicFeeAllowance extends FeeAllowance to allow for both a maximum cap, -// as well as a limit per time period. -message PeriodicFeeAllowance { - BasicFeeAllowance basic = 1; - - // period specifies the time duration in which period_spend_limit coins can - // be spent before that allowance is reset - Duration period = 2; - - // period_spend_limit specifies the maximum number of coins that can be spent - // in the period - repeated cosmos_sdk.v1.Coin period_spend_limit = 3; - - // period_can_spend is the number of coins left to be spent before the period_reset time - repeated cosmos_sdk.v1.Coin period_can_spend = 4; - - // period_reset is the time at which this period resets and a new one begins, - // it is calculated from the start time of the first transaction after the - // last period ended - ExpiresAt period_reset = 5; -} - -// ExpiresAt is a point in time where something expires. -// It may be *either* block time or block height -message ExpiresAt { - oneof sum { - google.protobuf.Timestamp time = 1; - uint64 height = 2; - } - } - -// Duration is a repeating unit of either clock time or number of blocks. -message Duration { - oneof sum { - google.protobuf.Duration duration = 1; - uint64 blocks = 2; - } -} - -``` - -Allowances can be granted and revoked using `MsgGrantFeeAllowance` and `MsgRevokeFeeAllowance`: - -```proto -message MsgGrantFeeAllowance { - string granter = 1; - string grantee = 2; - google.protobuf.Any allowance = 3; - } - - // MsgRevokeFeeAllowance removes any existing FeeAllowance from Granter to Grantee. - message MsgRevokeFeeAllowance { - string granter = 1; - string grantee = 2; - } -``` - -In order to use allowances in transactions, we add a new field `granter` to the transaction `Fee` type: -```proto -package lbm.tx.v1beta1; - -message Fee { - repeated lbm.base.v1beta1.Coin amount = 1; - uint64 gas_limit = 2; - string payer = 3; - string granter = 4; -} -``` - -`granter` must either be left empty or must correspond to an account which has granted -a fee allowance to fee payer (either the first signer or the value of the `payer` field). - -A new `AnteDecorator` named `DeductGrantedFeeDecorator` will be created in order to process transactions with `fee_payer` -set and correctly deduct fees based on fee allowances. - -## Consequences - -### Positive - -- improved UX for use cases where it is cumbersome to maintain an account balance just for fees - -### Negative - -### Neutral - -- a new field must be added to the transaction `Fee` message and a new `AnteDecorator` must be -created to use it - -## References - -- Blog article describing initial work: https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b -- Initial public specification: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56 -- Original subkeys proposal from B-harvest which influenced this design: https://github.com/cosmos/cosmos-sdk/issues/4480 diff --git a/docs/architecture/adr-031-msg-service.md b/docs/architecture/adr-031-msg-service.md deleted file mode 100644 index be78405ed9..0000000000 --- a/docs/architecture/adr-031-msg-service.md +++ /dev/null @@ -1,246 +0,0 @@ -# ADR 031: Protobuf Msg Services - -## Changelog - -- 2020-10-05: Initial Draft - -## Status - -Accepted - -## Abstract - -We want to leverage protobuf `service` definitions for defining `Msg`s which will give us significant developer UX -improvements in terms of the code that is generated and the fact that return types will now be well defined. - -## Context - -Currently `Msg` handlers in the Cosmos SDK do have return values that are placed in the `data` field of the response. -These return values, however, are not specified anywhere except in the golang handler code. - -In early conversations [it was proposed](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc/edit) -that `Msg` return types be captured using a protobuf extension field, ex: - -```protobuf -package lbm.gov; - -message MsgSubmitProposal - option (cosmos_proto.msg_return) = “uint64”; - string delegator_address = 1; - string validator_address = 2; - repeated sdk.Coin amount = 3; -} -``` - -This was never adopted, however. - -Having a well-specified return value for `Msg`s would improve client UX. For instance, -in `x/gov`, `MsgSubmitProposal` returns the proposal ID as a big-endian `uint64`. -This isn’t really documented anywhere and clients would need to know the internals -of the SDK to parse that value and return it to users. - -Also, there may be cases where we want to use these return values programatically. -For instance, https://github.com/cosmos/cosmos-sdk/issues/7093 proposes a method for -doing inter-module Ocaps using the `Msg` router. A well-defined return type would -improve the developer UX for this approach. - -In addition, handler registration of `Msg` types tends to add a bit of -boilerplate on top of keepers and is usually done through manual type switches. -This isn't necessarily bad, but it does add overhead to creating modules. - -## Decision - -We decide to use protobuf `service` definitions for defining `Msg`s as well as -the code generated by them as a replacement for `Msg` handlers. - -Below we define how this will look for the `SubmitProposal` message from `x/gov` module. -We start with a `Msg` `service` definition: - -```proto -package lbm.gov; - -service Msg { - rpc SubmitProposal(MsgSubmitProposal) returns (MsgSubmitProposalResponse); -} - -// Note that for backwards compatibility this uses MsgSubmitProposal as the request -// type instead of the more canonical MsgSubmitProposalRequest -message MsgSubmitProposal { - google.protobuf.Any content = 1; - string proposer = 2; -} - -message MsgSubmitProposalResponse { - uint64 proposal_id; -} -``` - -While this is most commonly used for gRPC, overloading protobuf `service` definitions like this does not violate -the intent of the [protobuf spec](https://developers.google.com/protocol-buffers/docs/proto3#services) which says: -> If you don’t want to use gRPC, it’s also possible to use protocol buffers with your own RPC implementation. -With this approach, we would get an auto-generated `MsgServer` interface: - -In addition to clearly specifying return types, this has the benefit of generating client and server code. On the server -side, this is almost like an automatically generated keeper method and could maybe be used intead of keepers eventually -(see [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)): - -```go -package gov - -type MsgServer interface { - SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSubmitProposalResponse, error) -} -``` - -On the client side, developers could take advantage of this by creating RPC implementations that encapsulate transaction -logic. Protobuf libraries that use asynchronous callbacks, like [protobuf.js](https://github.com/protobufjs/protobuf.js#using-services) -could use this to register callbacks for specific messages even for transactions that include multiple `Msg`s. - -For backwards compatibility, existing `Msg` types should be used as the request parameter -for `service` definitions. Newer `Msg` types which only support `service` definitions -should use the more canonical `Msg...Request` names. - -### Encoding - -Currently, we are encoding `Msg`s as `Any` in `Tx`s which involves packing the -binary-encoded `Msg` with its type URL. - -The type URL for `MsgSubmitProposal` based on the proto3 spec is `/cosmos.gov.MsgSubmitProposal`. - -The fully-qualified name for the `SubmitProposal` service method above (also -based on the proto3 and gRPC specs) is `/cosmos.gov.Msg/SubmitProposal` which varies -by a single `/` character. The generated `.pb.go` files for protobuf `service`s -include names of this form and any compliant protobuf/gRPC code generator will -generate the same name. - -In order to encode service methods in transactions, we encode them as `Any`s in -the same `TxBody.messages` field as other `Msg`s. We simply set `Any.type_url` -to the full-qualified method name (ex. `/cosmos.gov.Msg/SubmitProposal`) and -set `Any.value` to the protobuf encoding of the request message -(`MsgSubmitProposal` in this case). - -### Decoding - -When decoding, `TxBody.UnpackInterfaces` will need a special case -to detect if `Any` type URLs match the service method format (ex. `/cosmos.gov.Msg/SubmitProposal`) -by checking for two `/` characters. Messages that are method names plus request parameters -instead of a normal `Any` messages will get unpacked into the `ServiceMsg` struct: - -```go -type ServiceMsg struct { - // MethodName is the fully-qualified service name - MethodName string - // Request is the request payload - Request MsgRequest -} -``` - -### Routing - -In the future, `service` definitions may become the primary method for defining -`Msg`s. As a starting point, we need to integrate with the SDK's existing routing -and `Msg` interface. - -To do this, `ServiceMsg` implements the `sdk.Msg` interface and its handler does the -actual method routing, allowing this feature to be added incrementally on top of -existing functionality. - -### `MsgRequest` interface - -All request messages will need to implement the `MsgRequest` interface which is a -simplified version of `Msg`, without `Route()`, `Type()` and `GetSignBytes()` which -are no longer needed: - -```go -type MsgRequest interface { - proto.Message - ValidateBasic() error - GetSigners() []AccAddress -} -``` - -`ServiceMsg` will forward its `ValidateBasic` and `GetSigners` methods to the `MsgRequest` -methods. - -### Module Configuration - -In [ADR 021](./adr-021-protobuf-query-encoding.md), we introduced a method `RegisterQueryService` -to `AppModule` which allows for modules to register gRPC queriers. - -To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` -to a more generic `RegisterServices` method: - -```go -type AppModule interface { - RegisterServices(Configurator) - ... -} - -type Configurator interface { - QueryServer() grpc.Server - MsgServer() grpc.Server -} - -// example module: -func (am AppModule) RegisterServices(cfg Configurator) { - types.RegisterQueryServer(cfg.QueryServer(), keeper) - types.RegisterMsgServer(cfg.MsgServer(), keeper) -} -``` - -The `RegisterServices` method and the `Configurator` interface are intended to -evolve to satisfy the use cases discussed in [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) -and [\#7122](https://github.com/cosmos/cosmos-sdk/issues/7421). - -When `Msg` services are registered, the framework _should_ verify that all `Msg...Request` types -implement the `MsgRequest` interface described above and throw an error during initialization rather -than later when transactions are processed. - -### `Msg` Service Implementation - -Just like query services, `Msg` service methods can retrieve the `sdk.Context` -from the `context.Context` parameter method using the `sdk.UnwrapSDKContext` -method: - -```go -package gov - -func (k Keeper) SubmitProposal(goCtx context.Context, params *types.MsgSubmitProposal) (*MsgSubmitProposalResponse, error) { - ctx := sdk.UnwrapSDKContext(goCtx) - ... -} -``` - -The `sdk.Context` should have an `EventManager` already attached by the `ServiceMsg` -router. - -Separate handler definition is no longer needed with this approach. - -## Consequences - -This design changes how a module functionality is exposed and accessed. It deprecates the existing `Handler` interface and `AppModule.Route` in favor of [Protocol Buffer Services](https://developers.google.com/protocol-buffers/docs/proto3#services) and Service Routing described above. This dramatically simplifies the code. We don't need to create handlers and keepers any more. Use of Protocol Buffer auto-generated clients clearly separates the communication interfaces between the module and a modules user. The control logic (aka handlers and keepers) is not exposed any more. A module interface can be seen as a black box accessible through a client API. It's worth to note that the client interfaces are also generated by Protocol Buffers. - -This also allows us to change how we perform functional tests. Instead of mocking AppModules and Router, we will mock a client (server will stay hidden). More specifically: we will never mock `moduleA.MsgServer` in `moduleB`, but rather `moduleA.MsgClient`. One can think about it as working with external services (eg DBs, or online servers...). We assume that the transmission between clients and servers is correctly handled by generated Protocol Buffers. - -Finally, closing a module to client API opens desirable OCAP patterns discussed in ADR-033. Since server implementation and interface is hidden, nobody can hold "keepers"/servers and will be forced to relay on the client interface, which will drive developers for correct encapsulation and software engineering patterns. - -### Pros -- communicates return type clearly -- manual handler registration and return type marshaling is no longer needed, just implement the interface and register it -- communication interface is automatically generated, the developer can now focus only on the state transition methods - this would improve the UX of [\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093) approach (1) if we chose to adopt that -- generated client code could be useful for clients and tests -- dramatically reduces and simplifies the code - -### Cons -- supporting both this and the current concrete `Msg` type approach simultaneously could be confusing -(we could choose to deprecate the current approach) -- using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec) - - -## References - -- [Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122) -- [proto 3 Language Guide: Defining Services](https://developers.google.com/protocol-buffers/docs/proto3#services) -- [Initial pre-`Any` `Msg` designs](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) -- [ADR 020](./adr-020-protobuf-transaction-encoding.md) -- [ADR 021](./adr-021-protobuf-query-encoding.md) diff --git a/docs/architecture/adr-032-typed-events.md b/docs/architecture/adr-032-typed-events.md deleted file mode 100644 index 26ce1e8c73..0000000000 --- a/docs/architecture/adr-032-typed-events.md +++ /dev/null @@ -1,319 +0,0 @@ -# ADR 032: Typed Events - -## Changelog - -- 28-Sept-2020: Initial Draft - -## Authors - -- Anil Kumar (@anilcse) -- Jack Zampolin (@jackzampolin) -- Adam Bozanich (@boz) - -## Status - -Proposed - -## Abstract - -Currently in the SDK, events are defined in the handlers for each message as well as `BeginBlock` and `EndBlock`. Each module doesn't have types defined for each event, they are implemented as `map[string]string`. Above all else this makes these events difficult to consume as it requires a great deal of raw string matching and parsing. This proposal focuses on updating the events to use **typed events** defined in each module such that emiting and subscribing to events will be much easier. This workflow comes from the experience of the Akash Network team. - -## Context - -Currently in the SDK, events are defined in the handlers for each message, meaning each module doesn't have a cannonical set of types for each event. Above all else this makes these events difficult to consume as it requires a great deal of raw string matching and parsing. This proposal focuses on updating the events to use **typed events** defined in each module such that emiting and subscribing to events will be much easier. This workflow comes from the experience of the Akash Network team. - -[Our platform](http://github.com/ovrclk/akash) requires a number of programatic on chain interactions both on the provider (datacenter - to bid on new orders and listen for leases created) and user (application developer - to send the app manifest to the provider) side. In addition the Akash team is now maintaining the IBC [`relayer`](https://github.com/ovrclk/relayer), another very event driven process. In working on these core pieces of infrastructure, and integrating lessons learned from Kubernetes developement, our team has developed a standard method for defining and consuming typed events in SDK modules. We have found that it is extremely useful in building this type of event driven application. - -As the SDK gets used more extensively for apps like `peggy`, other peg zones, IBC, DeFi, etc... there will be an exploding demand for event driven applications to support new features desired by users. We propose upstreaming our findings into the SDK to enable all SDK applications to quickly and easily build event driven apps to aid their core application. Wallets, exchanges, explorers, and defi protocols all stand to benefit from this work. - -If this proposal is accepted, users will be able to build event driven SDK apps in go by just writing `EventHandler`s for their specific event types and passing them to `EventEmitters` that are defined in the SDK. - -The end of this proposal contains a detailed example of how to consume events after this refactor. - -This proposal is specifically about how to consume these events as a client of the blockchain, not for intermodule communication. - -## Decision - -__Step-1__: Implement additional functionality in the `types` package: `EmitTypedEvent` and `ParseTypedEvent` functions - -```go -// types/events.go - -// EmitTypedEvent takes typed event and emits converting it into sdk.Event -func (em *EventManager) EmitTypedEvent(event proto.Message) error { - evtType := proto.MessageName(event) - evtJSON, err := codec.ProtoMarshalJSON(event) - if err != nil { - return err - } - - var attrMap map[string]json.RawMessage - err = json.Unmarshal(evtJSON, &attrMap) - if err != nil { - return err - } - - var attrs []abci.EventAttribute - for k, v := range attrMap { - attrs = append(attrs, abci.EventAttribute{ - Key: []byte(k), - Value: v, - }) - } - - em.EmitEvent(Event{ - Type: evtType, - Attributes: attrs, - }) - - return nil -} - -// ParseTypedEvent converts abci.Event back to typed event -func ParseTypedEvent(event abci.Event) (proto.Message, error) { - concreteGoType := proto.MessageType(event.Type) - if concreteGoType == nil { - return nil, fmt.Errorf("failed to retrieve the message of type %q", event.Type) - } - - var value reflect.Value - if concreteGoType.Kind() == reflect.Ptr { - value = reflect.New(concreteGoType.Elem()) - } else { - value = reflect.Zero(concreteGoType) - } - - protoMsg, ok := value.Interface().(proto.Message) - if !ok { - return nil, fmt.Errorf("%q does not implement proto.Message", event.Type) - } - - attrMap := make(map[string]json.RawMessage) - for _, attr := range event.Attributes { - attrMap[string(attr.Key)] = attr.Value - } - - attrBytes, err := json.Marshal(attrMap) - if err != nil { - return nil, err - } - - err = jsonpb.Unmarshal(strings.NewReader(string(attrBytes)), protoMsg) - if err != nil { - return nil, err - } - - return protoMsg, nil -} -``` - -Here, the `EmitTypedEvent` is a method on `EventManager` which takes typed event as input and apply json serialization on it. Then it maps the JSON key/value pairs to `event.Attributes` and emits it in form of `sdk.Event`. `Event.Type` will be the type URL of the proto message. - -When we subscribe to emitted events on the tendermint websocket, they are emitted in the form of an `abci.Event`. `ParseTypedEvent` parses the event back to it's original proto message. - -__Step-2__: Add proto definitions for typed events for msgs in each module: - -For example, let's take `MsgSubmitProposal` of `gov` module and implement this event's type. - -```protobuf -// proto/cosmos/gov/v1beta1/gov.proto -// Add typed event definition - -package lbm.gov.v1beta1; - -message EventSubmitProposal { - string from_address = 1; - uint64 proposal_id = 2; - TextProposal proposal = 3; -} -``` - -__Step-3__: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`: - -```go -// x/gov/handler.go -func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.MsgSubmitProposalI) (*sdk.Result, error) { - ... - types.Context.EventManager().EmitTypedEvent( - &EventSubmitProposal{ - FromAddress: fromAddress, - ProposalId: id, - Proposal: proposal, - }, - ) - ... -} -``` - -#### How to subscribe to these typed events in `Client` - -> NOTE: Full code example below - -Users will be able to subscribe using `client.Context.Client.Subscribe` and consume events which are emitted using `EventHandler`s. - -Akash Network has built a simple [`pubsub`](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/pubsub/bus.go#L20). This can be used to subscribe to `abci.Events` and [publish](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L21) them as typed events. - -Please see the below code sample for more detail on this flow looks for clients. - -## Consequences - -### Positive - -* Improves consistency of implementation for the events currently in the sdk -* Provides a much more ergonomic way to handle events and facilitates writing event driven applications -* This implementation will support a middleware ecosystem of `EventHandler`s - -### Negative - - -## Detailed code example of publishing events - -This ADR also proposes adding affordances to emit and consume these events. This way developers will only need to write -`EventHandler`s which define the actions they desire to take. - -```go -// EventEmitter is a type that describes event emitter functions -// This should be defined in `types/events.go` -type EventEmitter func(context.Context, client.Context, ...EventHandler) error - -// EventHandler is a type of function that handles events coming out of the event bus -// This should be defined in `types/events.go` -type EventHandler func(proto.Message) error - -// Sample use of the functions below -func main() { - ctx, cancel := context.WithCancel(context.Background()) - - if err := TxEmitter(ctx, client.Context{}.WithNodeURI("tcp://localhost:26657"), SubmitProposalEventHandler); err != nil { - cancel() - panic(err) - } - - return -} - -// SubmitProposalEventHandler is an example of an event handler that prints proposal details -// when any EventSubmitProposal is emitted. -func SubmitProposalEventHandler(ev proto.Message) (err error) { - switch event := ev.(type) { - // Handle governance proposal events creation events - case govtypes.EventSubmitProposal: - // Users define business logic here e.g. - fmt.Println(ev.FromAddress, ev.ProposalId, ev.Proposal) - return nil - default: - return nil - } -} - -// TxEmitter is an example of an event emitter that emits just transaction events. This can and -// should be implemented somewhere in the SDK. The SDK can include an EventEmitters for tm.event='Tx' -// and/or tm.event='NewBlock' (the new block events may contain typed events) -func TxEmitter(ctx context.Context, cliCtx client.Context, ehs ...EventHandler) (err error) { - // Instantiate and start tendermint RPC client - client, err := cliCtx.GetNode() - if err != nil { - return err - } - - if err = client.Start(); err != nil { - return err - } - - // Start the pubsub bus - bus := pubsub.NewBus() - defer bus.Close() - - // Initialize a new error group - eg, ctx := errgroup.WithContext(ctx) - - // Publish chain events to the pubsub bus - eg.Go(func() error { - return PublishChainTxEvents(ctx, client, bus, simapp.ModuleBasics) - }) - - // Subscribe to the bus events - subscriber, err := bus.Subscribe() - if err != nil { - return err - } - - // Handle all the events coming out of the bus - eg.Go(func() error { - var err error - for { - select { - case <-ctx.Done(): - return nil - case <-subscriber.Done(): - return nil - case ev := <-subscriber.Events(): - for _, eh := range ehs { - if err = eh(ev); err != nil { - break - } - } - } - } - return nil - }) - - return group.Wait() -} - -// PublishChainTxEvents events using ostclient. Waits on context shutdown signals to exit. -func PublishChainTxEvents(ctx context.Context, client ostclient.EventsClient, bus pubsub.Bus, mb module.BasicManager) (err error) { - // Subscribe to transaction events - txch, err := client.Subscribe(ctx, "txevents", "tm.event='Tx'", 100) - if err != nil { - return err - } - - // Unsubscribe from transaction events on function exit - defer func() { - err = client.UnsubscribeAll(ctx, "txevents") - }() - - // Use errgroup to manage concurrency - g, ctx := errgroup.WithContext(ctx) - - // Publish transaction events in a goroutine - g.Go(func() error { - var err error - for { - select { - case <-ctx.Done(): - break - case ed := <-ch: - switch evt := ed.Data.(type) { - case tmtypes.EventDataTx: - if !evt.Result.IsOK() { - continue - } - // range over events, parse them using the basic manager and - // send them to the pubsub bus - for _, abciEv := range events { - typedEvent, err := sdk.ParseTypedEvent(abciEv) - if err != nil { - return er - } - if err := bus.Publish(typedEvent); err != nil { - bus.Close() - return - } - continue - } - } - } - } - return err - }) - - // Exit on error or context cancelation - return g.Wait() -} -``` - -## References -- [Publish Custom Events via a bus](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58) -- [Consuming the events in `Client`](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57) diff --git a/docs/architecture/adr-034-account-rekeying.md b/docs/architecture/adr-034-account-rekeying.md deleted file mode 100644 index 22cb79e313..0000000000 --- a/docs/architecture/adr-034-account-rekeying.md +++ /dev/null @@ -1,81 +0,0 @@ -# ADR 034: Account Rekeying - -## Changelog - -- 30-09-2020: Initial Draft - -## Status - -PROPOSED - -## Abstract - -Account rekeying is a process hat allows an account to replace its authentication pubkey with a new one. - -## Context - -Currently, in the Cosmos SDK, the address of an auth `BaseAccount` is based on the hash of the public key. Once an account is created, the public key for the account is set in stone, and cannot be changed. This can be a problem for users, as key rotation is a useful security practice, but is not possible currently. Furthermore, as multisigs are a type of pubkey, once a multisig for an account is set, it can not be updated. This is problematic, as multisigs are often used by organizations or companies, who may need to change their set of multisig signers for internal reasons. - -Transferring all the assets of an account to a new account with the updated pubkey is not sufficient, because some "engagements" of an account are not easily transferable. For example, in staking, to transfer bonded Atoms, an account would have to unbond all delegations and wait the three week unbonding period. Even more significantly, for validator operators, ownership over a validator is not transferrable at all, meaning that the operator key for a validator can never be updated, leading to poor operational security for validators. - -## Decision - -We propose the addition of a new feature to `x/auth` that allows accounts to update the public key associated with their account, while keeping the address the same. - -This is possible because the Cosmos SDK `BaseAccount` stores the public key for an account in state, instead of making the assumption that the public key is included in the transaction (whether explicitly or implicitly through the signature) as in other blockchains such as Bitcoin and Ethereum. Because the public key is stored on chain, it is okay for the public key to not hash to the address of an account, as the address is not pertinent to the signature checking process. - -To build this system, we design a new Msg type as follows: - -```protobuf -service Msg { - rpc ChangePubKey(MsgChangePubKey) returns (MsgChangePubKeyResponse); -} - -message MsgChangePubKey { - string address = 1; - google.protobuf.Any pub_key = 2; -} - -message MsgChangePubKeyResponse {} -``` - -The MsgChangePubKey transaction needs to be signed by the existing pubkey in state. - -Once, approved, the handler for this message type, which takes in the AccountKeeper, will update the in-state pubkey for the account and replace it with the pubkey from the Msg. - - -An account that has had its pubkey changed cannot be automatically pruned from state. This is because if pruned, the original pubkey of the account would be needed to recreate the same address, but the owner of the address may not have the original pubkey anymore. Currently, we do not automatically prune any accounts anyways, but we would like to keep this option open the road (this is the purpose of account numbers). To resolve this, we charge an additional gas fee for this operation to compensate for this this externality (this bound gas amount is configured as parameter `PubKeyChangeCost`). The bonus gas is charged inside the handler, using the `ConsumeGas` function. Furthermore, in the future, we can allow accounts that have rekeyed manually prune themselves using a new Msg type such as `MsgDeleteAccount`. Manually pruning accounts can give a gas refund as an incentive for performing the action. - - -```go - amount := ak.GetParams(ctx).PubKeyChangeCost - ctx.GasMeter().ConsumeGas(amount, "pubkey change fee") -``` - - -Everytime a key for an address is changed, we will store a log of this change in the state of the chain, thus creating a stack of all previous keys for an address and the time intervals for which they were active. This allows dapps and clients to easily query past keys for an account which may be useful for features such as verifying timestamped off-chain signed messages. - - -## Consequences - -### Positive - -* Will allow users and validator operators to employ better operational security practices with key rotation. -* Will allow organizations or groups to easily change and add/remove multisig signers. - -### Negative - -Breaks the current assumed relationship between address and pubkeys as H(pubkey) = address. This has a couple of consequences. - -* This makes wallets that support this feature more complicated. For example, if an address on chain was updated, the corresponding key in the CLI wallet also needs to be updated. -* Cannot automatically prune accounts with 0 balance that have had their pubkey changed. - - -### Neutral - -* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner. For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens. However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accouns with Vesting tokens to use this feature. -* Will require that PubKeys for an account are included in the genesis exports. - -## References - -+ https://www.algorand.com/resources/blog/announcing-rekeying diff --git a/docs/architecture/adr-035-rosetta-api-support.md b/docs/architecture/adr-035-rosetta-api-support.md deleted file mode 100644 index 2da663f572..0000000000 --- a/docs/architecture/adr-035-rosetta-api-support.md +++ /dev/null @@ -1,274 +0,0 @@ -# ADR 035: Rosetta API Support - -## Authors - -- Jonathan Gimeno (@jgimeno) -- David Grierson (@senormonito) -- Alessio Treglia (@alessio) - -## Context - -[Rosetta API](https://www.rosetta-api.org/) is an open-source specification and set of tools developed by Coinbase to -standardise blockchain interactions. - -Through the use of a standard API for integrating blockchain applications it will - -* Be easier for a user to interact with a given blockchain -* Allow exchanges to integrate new blockchains quickly and easily -* Enable application developers to build cross-blockchain applications such as block explorers, wallets and dApps at - considerably lower cost and effort. - -## Decision - -It is clear that adding Rosetta API support to the Cosmos SDK will bring value to all the developers and -Cosmos SDK based chains in the ecosystem. How it is implemented is key. - -The driving principles of the proposed design are: - -1. **Extensibility:** it must be as riskless and painless as possible for application developers to set-up network - configurations to expose Rosetta API-compliant services. -2. **Long term support:** This proposal aims to provide support for all the supported Cosmos SDK release series. -3. **Cost-efficiency:** Backporting changes to Rosetta API specifications from `master` to the various stable - branches of Cosmos SDK is a cost that needs to be reduced. - -We will achieve these delivering on these principles by the following: - -1. There will be an external repo called [cosmos-rosetta-gateway](https://github.com/tendermint/cosmos-rosetta-gateway) - for the implementation of the core Rosetta API features, particularly: - a. The types and interfaces. This separates design from implementation detail. - b. Some core implementations: specifically, the `Service` functionality as this is independent of the Cosmos SDK version. -2. Due to differences between the Cosmos release series, each series will have its own specific API implementations of `Network` struct and `Adapter` interface. -3. There will be two options for starting an API service in applications: - a. API shares the application process - b. API-specific process. - - -## Architecture - -### The External Repo - -As section will describe the proposed external library, including the service implementation, plus the defined types and interfaces. - -#### Service - -`Service` is a simple `struct` that is started and listens to the port specified in the options. This is meant to be used across all the Cosmos SDK versions that are actively supported. - -The constructor follows: - -`func New(options Options, network Network) (*Service, error)` - -#### Types - -`Service` accepts an `Options` `struct` that holds service configuration values, such as the port the service would be listening to: - -```golang -type Options struct { - ListenAddress string -} -``` - -The `Network` type holds network-specific properties (i.e. configuration values) and adapters. Pre-configured concrete types will be available for each Cosmos SDK release. Applications can also create their own custom types. - -```golang -type Network struct { - Properties rosetta.NetworkProperties - Adapter rosetta.Adapter -} -``` - -A `NetworkProperties` `struct` comprises basic values that are required by a Rosetta API `Service`: - -```golang -type NetworkProperties struct { - // Mandatory properties - Blockchain string - Network string - SupportedOperations []string -} -``` - -Rosetta API services use `Blockchain` and `Network` as identifiers, e.g. the developers of _gaia_, the application that powers the Cosmos Hub, may want to set those to `Cosmos Hub` and `cosmos-hub-3` respectively. - -`SupportedOperations` contains the transaction types that are supported by the library. At the present time, -only `cosmos-sdk/MsgSend` is supported in Launchpad. Additional operations will be added in due time. - -For Launchpad we will map the amino type name to the operation supported, in Stargate we will use the protoc one. - -#### Interfaces - -Every SDK version uses a different format to connect (rpc, gRpc, etc), we have abstracted this in what is called the -Adapter. This is an interface that defines the methods an adapter implementation must provide in order to be used -in the `Network` interface. - -Each Cosmos SDK release series will have their own Adapter implementations. -Developers can implement their own custom adapters as required. - -```golang -type Adapter interface { - DataAPI - ConstructionAPI -} - -type DataAPI interface { - server.NetworkAPIServicer - server.AccountAPIServicer - server.MempoolAPIServicer - server.BlockAPIServicer - server.ConstructionAPIServicer -} - -type ConstructionAPI interface { - server.ConstructionAPIServicer -} -``` - -Example in pseudo-code of an Adapter interface: - -```golang -type SomeAdapter struct { - cosmosClient client - tendermintClient client -} - -func NewSomeAdapter(cosmosClient client, tendermintClient client) rosetta.Adapter { - return &SomeAdapter{cosmosClient: cosmosClient, tendermintClient: tendermintClient} -} - -func (s SomeAdapter) NetworkStatus(ctx context.Context, request *types.NetworkRequest) (*types.NetworkStatusResponse, *types.Error) { - resp := s.tendermintClient.CallStatus() - // ... Parse status Response - // build NetworkStatusResponse - return networkStatusResp, nil -} - -func (s SomeAdapter) AccountBalance(ctx context.Context, request *types.AccountBalanceRequest) (*types.AccountBalanceResponse, *types.Error) { - resp := s.cosmosClient.Account() - // ... Parse cosmos specific account response - // build AccountBalanceResponse - return AccountBalanceResponse, nil -} - -// And we repeat for all the methods defined in the interface. -``` - -For further information about the `Servicer` interfaces, please refer to the [Coinbase's rosetta-sdk-go's documentation](https://pkg.go.dev/github.com/coinbase/rosetta-sdk-go@v0.5.9/server). - -### 2. Cosmos SDK Implementation - -As described, each Cosmos SDK release series will have version specific implementations of `Network` and `Adapter`, as -well as a `NewNetwork` constructor. - -Due to separation of interface and implementation, application developers have the option to override as needed, -using this code as reference. - -```golang -// NewNetwork returns the default application configuration. -func NewNetwork(options Options) service.Network { - cosmosClient := cosmos.NewClient(fmt.Sprintf("http://%s", options.CosmosEndpoint)) - tendermintClient := tendermint.NewClient(fmt.Sprintf("http://%s", options.TendermintEndpoint)) - - return service.Network{ - Properties: rosetta.NetworkProperties{ - Blockchain: options.Blockchain, - Network: options.Network, - SupportedOperations: []string{OperationTransfer}, - }, - Adapter: newAdapter( - cosmosClient, - tendermintClient, - properties{ - Blockchain: options.Blockchain, - Network: options.Network, - OfflineMode: options.OfflineMode, - }, - ), - } -} -``` - -### 3. API service invocation - -As stated at the start, application developers will have two methods for invocation of the Rosetta API service: - -1. Shared process for both application and API -2. Standalone API service - -#### Shared Process (Only Stargate) - -Rosetta API service could run within the same execution process as the application. New configuration option and -command line flags would be provided to support this: - -```golang - if config.Rosetta.Enable { - .... - get contecxt, flags, etc - ... - - h, err := service.New( - service.Options{ListenAddress: config.Rosetta.ListenAddress}, - rosetta.NewNetwork(cdc, options), - ) - if err != nil { - } - - ... - - go func() { - if err := h.Start(config); err != nil { - errCh <- err - } - }() - } - -``` - -#### Separate API service - -Client application developers can write a new command to launch a Rosetta API server as a separate process too: - -```golang -func RosettaCommand(cdc *codec.Codec) *cobra.Command { - - ... - cmd := &cobra.Command{ - Use: "rosetta", - .... - - RunE: func(cmd *cobra.Command, args []string) error { - .... - get contecxt, flags, etc - ... - - h, err := service.New( - service.Options{Endpoint: endpoint}, - rosetta.NewNetwork(cdc, options), - ) - if err != nil { - return err - } - - ... - - h.Start() - } - } - ... - -} -``` - -## Status - -Proposed - -## Consequences - -### Positive - -- Out-of-the-box Rosetta API support within Cosmos SDK. -- Blockchain interface standardisation - -## References - -- https://www.rosetta-api.org/ -- https://github.com/tendermint/cosmos-rosetta-gateway diff --git a/docs/architecture/adr-037-gov-split-vote.md b/docs/architecture/adr-037-gov-split-vote.md deleted file mode 100644 index af9cd8d6f6..0000000000 --- a/docs/architecture/adr-037-gov-split-vote.md +++ /dev/null @@ -1,104 +0,0 @@ -# ADR 037: Governance split votes - -## Changelog - -- 2020/10/28: Intial draft - -## Status - -Proposed - -## Abstract - -This ADR defines a modification to the the governance module that would allow a staker to split their votes into several voting options. For example, it could use 70% of its voting power to vote Yes and 30% of its voting power to vote No. - -## Context - -Currently, an address can cast a vote with only one options (Yes/No/Abstain/NoWithVeto) and use their full voting power behind that choice. - -However, often times the entity owning that address might not be a single individual. For example, a company might have different stakeholders who want to vote differently, and so it makes sense to allow them to split their voting power. Another example use case is exchanges. Many centralized exchanges often stake a portion of their users' tokens in their custody. Currently, it is not possible for them to do "passthrough voting" and giving their users voting rights over their tokens. However, with this system, exchanges can poll their users for voting preferences, and then vote on-chain proportionally to the results of the poll. - -## Decision - -We modify the vote structs to be - -``` -type WeightedVoteOption struct { - Option string - Weight sdk.Dec -} - -type Vote struct { - ProposalID int64 - Voter sdk.Address - Options []WeightedVoteOption -} -``` - -And for backwards compatibility, we introduce `MsgWeightedVote` while keeping `MsgVote`. -``` -type MsgVote struct { - ProposalID int64 - Voter sdk.Address - Option Option -} - -type MsgWeightedVote struct { - ProposalID int64 - Voter sdk.Address - Options []WeightedVoteOption -} -``` - -The `ValidateBasic` of a `MsgWeightedVote` struct would require that -1. The sum of all the Rates is equal to 1.0 -2. No Option is repeated - -The governance tally function will iterate over all the options in a vote and add to the tally the result of the voter's voting power * the rate for that option. - -``` -tally() { - results := map[types.VoteOption]sdk.Dec - - for _, vote := range votes { - for i, weightedOption := range vote.Options { - results[weightedOption.Option] += getVotingPower(vote.voter) * weightedOption.Weight - } - } -} -``` - -The CLI command for creating a multi-option vote would be as such: -```sh -simd tx gov vote 1 "yes=0.6,no=0.3,abstain=0.05,no_with_veto=0.05" --from mykey -``` - -To create a single-option vote a user can do either -``` -simd tx gov vote 1 "yes=1" --from mykey -``` - -or - -```sh -simd tx gov vote 1 yes --from mykey -``` - -to maintain backwards compatibility. - - -## Consequences - -### Backwards Compatibility -- Previous VoteMsg types will remain the same and so clients will not have to update their procedure unless they want to support the WeightedVoteMsg feature. -- When querying a Vote struct from state, its structure will be different, and so clients wanting to display all voters and their respective votes will have to handle the new format and the fact that a single voter can have split votes. -- The result of querying the tally function should have the same API for clients. - -### Positive -- Can make the voting process more accurate for addresses representing multiple stakeholders, often some of the largest addresses. - -### Negative -- Is more complex than simple voting, and so may be harder to explain to users. However, this is mostly mitigated because the feature is opt-in. - -### Neutral -- Relatively minor change to governance tally function. diff --git a/docs/architecture/adr-template.md b/docs/architecture/adr-template.md deleted file mode 100644 index 5d6a342c29..0000000000 --- a/docs/architecture/adr-template.md +++ /dev/null @@ -1,69 +0,0 @@ -# ADR {ADR-NUMBER}: {TITLE} - -## Changelog - -- {date}: {changelog} - -## Status - -{DRAFT | PROPOSED} Not Implemented - -> Please have a look at the [PROCESS](./PROCESS.md#adr-status) page. -> Use DRAFT if the ADR is in a draft stage (draft PR) or PROPOSED if it's in review. - - -## Abstract - -> "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the ADR. -> A short (~200 word) description of the issue being addressed. - - -## Context - -> This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts. It should clearly explain the problem and motivation that the proposal aims to resolve. -> {context body} - - -## Decision - -> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..." -> {decision body} - - -## Consequences - -> This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future. - - -### Backwards Compatibility - -> All ADRs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ADR must explain how the author proposes to deal with these incompatibilities. ADR submissions without a sufficient backwards compatibility treatise may be rejected outright. - - -### Positive - -{positive consequences} - -### Negative - -{negative consequences} - -### Neutral - -{neutral consequences} - - -## Further Discussions - -While an ADR is in the DRAFT or PROPOSED stage, this section should contain a summary of issues to be solved in future iterations (usually referencing comments from a pull-request discussion). -Later, this section can optionally list ideas or improvements the author or reviewers found during the analysis of this ADR. - - -## Test Cases [optional] - -Test cases for an implementation are mandatory for ADRs that are affecting consensus changes. Other ADRs can choose to include links to test cases if applicable. - - -## References - -- {reference link} diff --git a/docs/architecture/readme.md~origin_master-docs b/docs/architecture/readme.md~origin_master-docs deleted file mode 100644 index f0c07cb685..0000000000 --- a/docs/architecture/readme.md~origin_master-docs +++ /dev/null @@ -1,5 +0,0 @@ ---- -order: false -parent: - order: false ---- diff --git a/docs/basics/README.md b/docs/basics/README.md deleted file mode 100644 index 03934dcd51..0000000000 --- a/docs/basics/README.md +++ /dev/null @@ -1,17 +0,0 @@ - - -# Basics - -This repository contains reference documentation on the basic concepts of the Cosmos SDK. - -1. [Anatomy of an SDK Application](./app-anatomy.md) -2. [Lifecycle of a transaction](./tx-lifecycle.md) -3. [Lifecycle of a query](./query-lifecycle.md) -4. [Accounts](./accounts.md) -5. [Gas and Fees](./gas-fees.md) - -After reading the basics, head on to the [Core Reference](../core/README.md) for more advanced material. diff --git a/docs/basics/accounts.md b/docs/basics/accounts.md deleted file mode 100644 index 2268ff5736..0000000000 --- a/docs/basics/accounts.md +++ /dev/null @@ -1,136 +0,0 @@ - - -# Accounts - -This document describes the in-built accounts system of the Cosmos SDK. {synopsis} - -### Pre-requisite Readings - -- [Anatomy of an SDK Application](./app-anatomy.md) {prereq} - -## Account Definition - -In the Cosmos SDK, an _account_ designates a pair of _public key_ `PubKey` and _private key_ `PrivKey`. The `PubKey` can be derived to generate various `Addresses`, which are used to identify users (among other parties) in the application. `Addresses` are also associated with [`message`s](../building-modules/messages-and-queries.md#messages) to identify the sender of the `message`. The `PrivKey` is used to generate [digital signatures](#signatures) to prove that an `Address` associated with the `PrivKey` approved of a given `message`. - -To derive `PubKey`s and `PrivKey`s, the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). This standard defines how to build an HD wallet, where a wallet is a set of accounts. At the core of every account, there is a seed, which takes the form of a 12 or 24-words mnemonic. From this mnemonic, it is possible to derive any number of `PrivKey`s using 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. - -``` - 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) | - | | - +-------------------+ -``` - -In the Cosmos SDK, accounts are stored and managed via an object called a [`Keyring`](#keyring). - -## Keyring - -A `Keyring` is an object that stores and manages accounts. In the Cosmos SDK, a `Keyring` implementation follows the `Keyring` interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/keyring/keyring.go#L50-L88 - -The default implementation of `Keyring` comes from the third-party [`99designs/keyring`](https://github.com/99designs/keyring) library. - -A few notes on the `Keyring` methods: - -- `Sign(uid string, payload []byte) ([]byte, ostcrypto.PubKey, error)` strictly deals with the signature of the `payload` bytes. Some preliminary work should be done beforehand to prepare and encode the transaction into a canonical `[]byte` form. Protobuf being not deterministic, it has been decided in [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) that the canonical `payload` to sign is the `SignDoc` struct, deterministically encoded using [ADR-027](adr-027-deterministic-protobuf-serialization.md). Note that signature verification is not implemented in the SDK by default, it is deferred to the [`anteHandler`](../core/baseapp.md#antehandler). - +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L47-L64 - -- `NewAccount(uid, mnemonic, bip39Passwd, hdPath string, algo SignatureAlgo) (Info, error)` creates a new account based on the [`bip44 path`](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) and persists it on disk (note that the `PrivKey` is [encrypted with a passphrase before being persisted](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/armor.go), it is **never stored unencrypted**). In the context of this method, the `account` and `address` parameters refer to the segment of the BIP44 derivation path (e.g. `0`, `1`, `2`, ...) used to derive the `PrivKey` and `PubKey` from the mnemonic (note that given the same mnemonic and `account`, the same `PrivKey` will be generated, and given the same `account` and `address`, the same `PubKey` and `Address` will be generated). Finally, note that the `NewAccount` method derives keys and addresses using the algorithm specified in the last argument `algo`. Currently, the SDK supports two public key algorithms: - - - `secp256k1`, as implemented in the [SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/keys/secp256k1/secp256k1.go), - - `ed25519`, as implemented in the [SDK's `crypto/keys/ed25519` package](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/keys/ed25519/ed25519.go). - -- `ExportPrivKeyArmor(uid, encryptPassphrase string) (armor string, err error)` exports a private key in ASCII-armored encrypted format, using the given passphrase. You can then either import it again into the keyring using the `ImportPrivKey(uid, armor, passphrase string)` function, or decrypt it into a raw private key using the `UnarmorDecryptPrivKey(armorStr string, passphrase string)` function. - -Also see the [`Addresses`](#addresses) section for more information. - -## Addresses and PubKeys - -`Addresses` and `PubKey`s are both public information that identify actors in the application. There are 3 main types of `Addresses`/`PubKeys` available by default in the Cosmos SDK: - -- Addresses and Keys for **accounts**, which identify users (e.g. the sender of a `message`). They are derived using the **`secp256k1`** curve. -- Addresses and Keys for **validator operators**, which identify the operators of validators. They are derived using the **`secp256k1`** curve. -- Addresses and Keys for **consensus nodes**, which identify the validator nodes participating in consensus. They are derived using the **`ed25519`** curve. - -| | Address bech32 Prefix | Pubkey bech32 Prefix | Curve | Address byte length | Pubkey byte length | -| ------------------ | --------------------- | -------------------- | ----------- | ------------------- | ------------------ | -| Accounts | cosmos | cosmospub | `secp256k1` | `20` | `33` | -| Validator Operator | cosmosvaloper | cosmosvaloperpub | `secp256k1` | `20` | `33` | -| Consensus Nodes | cosmosvalcons | cosmosvalconspub | `ed25519` | `20` | `32` | - -### PubKeys - -`PubKey`s used in the Cosmos SDK are Protobuf messages and have the following methods: - -+++ https://github.com/cosmos/cosmos-sdk/blob/master/crypto/types/types.go#L8-L17 - -- For `secp256k1` keys, the actual implementation can be found [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/keys/secp256k1/secp256k1.go). -- For `ed25519` keys, it can be found [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/keys/ed25519/ed25519.go). - -In both case, the actual key (as raw bytes) is the compressed form of the pubkey. The first byte is a `0x02` byte if the `y`-coordinate is the lexicographically largest of the two associated with the `x`-coordinate. Otherwise the first byte is a `0x03`. This prefix is followed with the `x`-coordinate. - -Note that in the Cosmos SDK, `Pubkeys` are not manipulated in their raw bytes form. Instead, they are encoded to string using [`Amino`](../core/encoding.md#amino) and [`bech32`](https://en.bitcoin.it/wiki/Bech32). In the SDK, it is done by first calling the `Bytes()` method on the raw `Pubkey` (which applies amino encoding), and then the `ConvertAndEncode` method of `bech32`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/address.go#L579-L729 - -### Addresses - -The Cosmos SDK comes by default with 3 types of addresses: - -- `AccAddress` for accounts. -- `ValAddress` for validator operators. -- `ConsAddress` for validator nodes. - -Each of these address types are an alias for an hex-encoded `[]byte` array of length 20. Here is the standard way to obtain an address `aa` from a `Pubkey pub`: - -```go -aa := sdk.AccAddress(pub.Address().Bytes()) -``` - -These addresses implement the `Address` interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/address.go#L73-L82 - -Of note, the `Marshal()` and `Bytes()` method both return the same raw `[]byte` form of the address, the former being needed for Protobuf compatibility. Also, the `String()` method is used to return the `bech32` encoded form of the address, which should be the only address format with which end-user interract. Here is an example: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/address.go#L232-L246 - -## Next {hide} - -Learn about [gas and fees](./gas-fees.md) {hide} diff --git a/docs/basics/app-anatomy.md b/docs/basics/app-anatomy.md deleted file mode 100644 index 55d4318823..0000000000 --- a/docs/basics/app-anatomy.md +++ /dev/null @@ -1,261 +0,0 @@ - - -# Anatomy of an SDK Application - -This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used. {synopsis} - -## Node Client - -The Daemon, or [Full-Node Client](../core/node.md), is the core process of an 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. - -``` - ^ +-------------------------------+ ^ - | | | | - | | State-machine = Application | | - | | | | Built with Cosmos SDK - | | ^ + | | - | +----------- | ABCI | ----------+ v - | | + v | ^ - | | | | -Blockchain Node | | Consensus | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Networking | | - | | | | - v +-------------------------------+ v -``` - -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`](../core/node.md#main-function) function placed in `./cmd/appd/`. This operation usually happens through the [Makefile](#dependencies-and-makefile). - -Once the main binary is built, the node can be started by running the [`start` command](../core/node.md#start-command). This command function primarily does three things: - -1. Create an instance of the state-machine defined in [`app.go`](#core-application-file). -2. Initialize the state-machine with the latest known state, extracted from the `db` stored in the `~/.appd/data` folder. At this point, the state-machine is at height `appBlockHeight`. -3. Create and start a new Tendermint instance. Among other things, the node will perform a handshake with its peers. It will get the latest `blockHeight` from them, and replay blocks to sync to this height if it is greater than the local `appBlockHeight`. If `appBlockHeight` is `0`, the node is starting from genesis and Tendermint sends an `InitChain` message via the ABCI to the `app`, which triggers the [`InitChainer`](#initchainer). - -## Core Application File - -In general, the core of the state-machine is defined in a file called `app.go`. It mainly contains the **type definition of the application** and functions to **create and initialize it**. - -### Type Definition of the Application - -The first thing defined in `app.go` is the `type` of the application. It is generally comprised of the following parts: - -- **A reference to [`baseapp`](../core/baseapp.md).** The custom application defined in `app.go` is an extension of `baseapp`. When a transaction is relayed by Tendermint to the application, `app` uses `baseapp`'s methods to route them to the appropriate module. `baseapp` implements most of the core logic for the application, including all the [ABCI methods](https://tendermint.com/docs/spec/abci/abci.html#overview) and the [routing logic](../core/baseapp.md#routing). -- **A list of store keys**. The [store](../core/store.md), which contains the entire state, is implemented as a [`multistore`](../core/store.md#multistore) (i.e. a store of stores) in the Cosmos SDK. Each module uses one or multiple stores in the multistore to persist their part of the state. These stores can be accessed with specific keys that are declared in the `app` type. These keys, along with the `keepers`, are at the heart of the [object-capabilities model](../core/ocap.md) of the Cosmos SDK. -- **A list of module's `keeper`s.** Each module defines an abstraction called [`keeper`](../building-modules/keeper.md), which handles reads and writes for this module's store(s). The `keeper`'s methods of one module can be called from other modules (if authorized), which is why they are declared in the application's type and exported as interfaces to other modules so that the latter can only access the authorized functions. -- **A reference to an [`appCodec`](../core/encoding.md).** The application's `appCodec` is used to serialize and deserialize data structures in order to store them, as stores can only persist `[]bytes`. The default codec is [Protocol Buffers](../core/encoding.md). -- **A reference to a [`legacyAmino`](../core/encoding.md) codec.** Some parts of the SDK have not been migrated to use the `appCodec` above, and are still hardcoded to use Amino. Other parts explicity use Amino for backwards compatibility. For these reasons, the application still holds a reference to the legacy Amino codec. Please note that the Amino codec will be removed from the SDK in the upcoming releases. -- **A reference to a [module manager](../building-modules/module-manager.md#manager)** and a [basic module manager](../building-modules/module-manager.md#basicmanager). The module manager is an object that contains a list of the application's module. It facilitates operations related to these modules, like registering their [`Msg` service](../core/baseapp.md#msg-services) and [gRPC `Query` service](../core/baseapp.md#grpc-query-services), or setting the order of execution between modules for various functions like [`InitChainer`](#initchainer), [`BeginBlocker` and `EndBlocker`](#beginblocker-and-endblocker). - -See an example of application type definition from `simapp`, the SDK's own app used for demo and testing purposes: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L139-L181 - -### Constructor Function - -This function constructs a new application of the type defined in the section above. It must fulfill the `AppCreator` signature in order to be used in the [`start` command](../core/node.md#start-command) of the application's daemon command. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/types/app.go#L42-L44 - -Here are the main actions performed by this function: - -- Instantiate a new [`codec`](../core/encoding.md) and initialize the `codec` of each of the application's module using the [basic manager](../building-modules/module-manager.md#basicmanager) -- Instantiate a new application with a reference to a `baseapp` instance, a codec and all the appropriate store keys. -- Instantiate all the [`keeper`s](#keeper) defined in the application's `type` using the `NewKeeper` function of each of the application's modules. Note that `keepers` must be instantiated in the correct order, as the `NewKeeper` of one module might require a reference to another module's `keeper`. -- Instantiate the application's [module manager](../building-modules/module-manager.md#manager) with the [`AppModule`](#application-module-interface) object of each of the application's modules. -- With the module manager, initialize the application's [`Msg` services](../core/baseapp.md#msg-services), [gRPC `Query` services](../core/baseapp.md#grpc-query-services), [legacy `Msg` routes](../core/baseapp.md#routing) and [legacy query routes](../core/baseapp.md#query-routing). When a transaction is relayed to the application by Tendermint via the ABCI, it is routed to the appropriate module's [`Msg` service](#msg-services) using the routes defined here. Likewise, when a gRPC query request is received by the application, it is routed to the appropriate module's [`gRPC query service`](#grpc-query-services) using the gRPC routes defined here. The SDK still supports legacy `Msg`s and legacy Tendermint queries, which are routed using respectively the legacy `Msg` routes and the legacy query routes. -- With the module manager, register the [application's modules' invariants](../building-modules/invariants.md). Invariants are variables (e.g. total supply of a token) that are evaluated at the end of each block. The process of checking invariants is done via a special module called the [`InvariantsRegistry`](../building-modules/invariants.md#invariant-registry). The value of the invariant should be equal to a predicted value defined in the module. Should the value be different than the predicted one, special logic defined in the invariant registry will be triggered (usually the chain is halted). This is useful to make sure no critical bug goes unnoticed and produces long-lasting effects that would be hard to fix. -- With the module manager, set the order of execution between the `InitGenesis`, `BegingBlocker` and `EndBlocker` functions of each of the [application's modules](#application-module-interface). Note that not all modules implement these functions. -- Set the remainer of application's parameters: - - [`InitChainer`](#initchainer): used to initialize the application when it is first started. - - [`BeginBlocker`, `EndBlocker`](#beginblocker-and-endlbocker): called at the beginning and the end of every block). - - [`anteHandler`](../core/baseapp.md#antehandler): used to handle fees and signature verification. -- Mount the stores. -- Return the application. - -Note that this function only creates an instance of the app, while the actual state is either carried over from the `~/.appd/data` folder if the node is restarted, or generated from the genesis file if the node is started for the first time. - -See an example of application constructor from `simapp`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L192-L429 - -### InitChainer - -The `InitChainer` is a function that initializes the state of the application from a genesis file (i.e. token balances of genesis accounts). It is called when the application receives the `InitChain` message from the Tendermint engine, which happens when the node is started at `appBlockHeight == 0` (i.e. on genesis). The application must set the `InitChainer` in its [constructor](#constructor-function) via the [`SetInitChainer`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) method. - -In general, the `InitChainer` is mostly composed of the [`InitGenesis`](../building-modules/genesis.md#initgenesis) function of each of the application's modules. This is done by calling the `InitGenesis` function of the module manager, which in turn will call the `InitGenesis` function of each of the modules it contains. Note that the order in which the modules' `InitGenesis` functions must be called has to be set in the module manager using the [module manager's](../building-modules/module-manager.md) `SetOrderInitGenesis` method. This is done in the [application's constructor](#application-constructor), and the `SetOrderInitGenesis` has to be called before the `SetInitChainer`. - -See an example of an `InitChainer` from `simapp`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L452-L459 - -### BeginBlocker and EndBlocker - -The SDK offers developers the possibility to implement automatic execution of code as part of their application. This is implemented through two function called `BeginBlocker` and `EndBlocker`. They are called when the application receives respectively the `BeginBlock` and `EndBlock` messages from the Tendermint engine, which happens at the beginning and at the end of each block. The application must set the `BeginBlocker` and `EndBlocker` in its [constructor](#constructor-function) via the [`SetBeginBlocker`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetBeginBlocker) and [`SetEndBlocker`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) methods. - -In general, the `BeginBlocker` and `EndBlocker` functions are mostly composed of the [`BeginBlock` and `EndBlock`](../building-modules/beginblock-endblock.md) functions of each of the application's modules. This is done by calling the `BeginBlock` and `EndBlock` functions of the module manager, which in turn will call the `BeginBLock` and `EndBlock` functions of each of the modules it contains. Note that the order in which the modules' `BegingBlock` and `EndBlock` functions must be called has to be set in the module manager using the `SetOrderBeginBlock` and `SetOrderEndBlock` methods respectively. This is done via the [module manager](../building-modules/module-manager.md) in the [application's constructor](#application-constructor), and the `SetOrderBeginBlock` and `SetOrderEndBlock` methods have to be called before the `SetBeginBlocker` and `SetEndBlocker` functions. - -As a sidenote, it is important to remember that application-specific blockchains are deterministic. Developers must be careful not to introduce non-determinism in `BeginBlocker` or `EndBlocker`, and must also be careful not to make them too computationally expensive, as [gas](./gas-fees.md) does not constrain the cost of `BeginBlocker` and `EndBlocker` execution. - -See an example of `BeginBlocker` and `EndBlocker` functions from `simapp` - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L442-L450 - -### Register Codec - -The `EncodingConfig` structure is the last important part of the `app.go` file. The goal of this structure is to define the codecs that will be used throughout the app. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/params/encoding.go#L9-L16 - -Here are descriptions of what each of the four fields means: - -- `InterfaceRegistry`: The `InterfaceRegistry` is used by the Protobuf codec to handle interfaces, which are encoded and decoded (we also say "unpacked") using [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto). `Any` could be thought as a struct which contains a `type_url` (the concrete type of the interface) and a `value` (its encoded bytes). `InterfaceRegistry` provides a mechanism for registering interfaces and implementations that can be safely unpacked from `Any`. Each of the application's modules implements the `RegisterInterfaces` method, which can be used to register the module's own interfaces and implementations. - - To go more into details, the SDK uses an implementation of the Protobuf specification called [`gogoprotobuf`](https://github.com/gogo/protobuf). By default, the [gogo protobuf implementation of `Any`](https://godoc.org/github.com/gogo/protobuf/types) uses [global type registration](https://github.com/gogo/protobuf/blob/master/proto/properties.go#L540) to decode values packed in `Any` into concrete Go types. This introduces a vulnerability where any malicious module in the dependency tree could registry a type with the global protobuf registry and cause it to be loaded and unmarshaled by a transaction that referenced it in the `type_url` field. For more information, please refer to [ADR-019](../architecture/adr-019-protobuf-state-encoding.md). -- `Marshaler`: The `Marshaler` is the default codec used throughout the SDK. It is composed of a `BinaryMarshaler` used to encode and decode state, and a `JSONMarshaler` used to output data to the users (for example in the [CLI](#cli)). By default, the SDK uses Protobuf as `Marshaler`. -- `TxConfig`: `TxConfig` defines an interface a client can utilize to generate an application-defined concrete transaction type. Currently, the SDK handles two transaction types: `SIGN_MODE_DIRECT` (which uses Protobuf binary as over-the-wire encoding) and `SIGN_MODE_LEGACY_AMINO_JSON` (which depends on Amino). Read more about transactions [here](../core/transactions.md). -- `Amino`: Some legacy parts of the SDK still use Amino for backwards-compatibility. Each module exposes a `RegisterLegacyAmino` method to register the module's specific types within Amino. This `Amino` codec should not be used by app developers anymore, and will be removed in future releases. - -The SDK exposes a `MakeTestEncodingConfig` function used to create a `EncodingConfig` for the app constructor (`NewApp`). It uses Protobuf as a default `Marshaler`, and passes it down to the app's `appCodec` field. It also instantiates a legacy `Amino` codec inside the app's `legacyAmino` field. -NOTE: this function is marked deprecated and should only be used to create an app or in tests. We are working on refactoring codec management in a post Stargate release. - -See an example of a `MakeCodecs` from `simapp`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L429-L435 - -## Modules - -[Modules](../building-modules/intro.md) are the heart and soul of SDK applications. They can be considered as state-machines within the state-machine. When a transaction is relayed from the underlying Tendermint engine via the ABCI to the application, it is routed by [`baseapp`](../core/baseapp.md) to the appropriate module in order to be processed. This paradigm enables developers to easily build complex state-machines, as most of the modules they need often already exist. For developers, most of the work involved in building an SDK application revolves around building custom modules required by their application that do not exist yet, and integrating them with modules that do already exist into one coherent application. In the application directory, the standard practice is to store modules in the `x/` folder (not to be confused with the SDK's `x/` folder, which contains already-built modules). - -### Application Module Interface - -Modules must implement [interfaces](../building-modules/module-manager.md#application-module-interfaces) defined in the Cosmos SDK, [`AppModuleBasic`](../building-modules/module-manager.md#appmodulebasic) and [`AppModule`](../building-modules/module-manager.md#appmodule). The former implements basic non-dependant elements of the module, such as the `codec`, while the latter handles the bulk of the module methods (including methods that require references to other modules' `keeper`s). Both the `AppModule` and `AppModuleBasic` types are defined in a file called `./module.go`. - -`AppModule` exposes a collection of useful methods on the module that facilitates the composition of modules into a coherent application. These methods are are called from the `module manager`(../building-modules/module-manager.md#manager), which manages the application's collection of modules. - -### `Msg` Services - -Each module defines two [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services): one `Msg` service to handle messages, and one gRPC `Query` service to handle queries. If we consider the module as a state-machine, then a `Msg` is a state transition. A `Msg` service is a Protobuf service defining all possible `Msg`s a module exposes. Note that `Msg`s are bundled in [`transactions`](../core/transactions.md), and each transaction contains one or multiple `messages`. - -When a valid block of transactions is received by the full-node, Tendermint relays each one to the application via [`DeliverTx`](https://tendermint.com/docs/app-dev/abci-spec.html#delivertx). Then, the application handles the transaction: - -1. Upon receiving the transaction, the application first unmarshalls it from `[]bytes`. -2. Then, it verifies a few things about the transaction like [fee payment and signatures](#gas-fees.md#antehandler) before extracting the `Msg`(s) contained in the transaction. -3. `Msg`s are encoded as Protobuf [`Any`s](#register-codec) via the `sdk.ServiceMsg` struct. By analyzing each `Any`'s `type_url`, baseapp's `msgServiceRouter` routes the `Msg` to the corresponding module's `Msg` service. -4. If the message is successfully processed, the state is updated. - -For a more detailed look at a transaction lifecycle, click [here](./tx-lifecycle.md). - -Module developers create custom `Msg`s when they build their own module. The general practice is to define all `Msg`s in a Protobuf service called `service Msg {}`, and define each `Msg` as a Protobuf service method, using the `rpc` keyword. These definitions usually reside in a `tx.proto` file. For example, the `x/bank` module defines two `Msg`s to allows users to transfer tokens: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/bank/v1beta1/tx.proto#L10-L17 - -These two `Msg`s are processed by the `Msg` service of the `x/bank` module, which ultimately calls the `keeper` of the `x/auth` module in order to update the state. - -Each module should also implement the `RegisterServices` method as part of the [`AppModule` interface](#application-module-interface). This method should call the `RegisterMsgServer` function provided by the generated Protobuf code. - -### gRPC `Query` Services - -gRPC `Query` services are introduced in the v0.40 Stargate release. They allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configued under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). - -gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service. - -Protobuf generates a `QueryServer` interface for each module, containing all the service methods. A module's [`keeper`](#keeper) then needs to implement this `QueryServer` interface, by providing the concrete implementation of each service method. This concrete implementation is the handler of the corresponding gRPC query endpoint. - -Finally, each module should also implement the `RegisterServices` method as part of the [`AppModule` interface](#application-module-interface). This method should call the `RegisterQueryServer` function provided by the generated Protobuf code. - -### Keeper - -[`Keepers`](../building-modules/keeper.md) are the gatekeepers of their module's store(s). To read or write in a module's store, it is mandatory to go through one of its `keeper`'s methods. This is ensured by the [object-capabilities](../core/ocap.md) model of the Cosmos SDK. Only objects that hold the key to a store can access it, and only the module's `keeper` should hold the key(s) to the module's store(s). - -`Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. - -The `keeper` type definition generally consists of: - -- **Key(s)** to the module's store(s) in the multistore. -- Reference to **other module's `keepers`**. Only needed if the `keeper` needs to access other module's store(s) (either to read or write from them). -- A reference to the application's **codec**. The `keeper` needs it to marshal structs before storing them, or to unmarshal them when it retrieves them, because stores only accept `[]bytes` as value. - -Along with the type definition, the next important component of the `keeper.go` file is the `keeper`'s constructor function, `NewKeeper`. This function instantiates a new `keeper` of the type defined above, with a `codec`, store `keys` and potentially references to other modules' `keeper`s as parameters. The `NewKeeper` function is called from the [application's constructor](#constructor-function). The rest of the file defines the `keeper`'s methods, primarily getters and setters. - -### Command-Line, gRPC Services and REST Interfaces - -Each module defines command-line commands, gRPC services and REST routes to be exposed to end-user via the [application's interfaces](#application-interfaces). This enables end-users to create messages of the types defined in the module, or to query the subset of the state managed by the module. - -#### CLI - -Generally, the [commands related to a module](../building-modules/module-interfaces.md#cli) are defined in a folder called `client/cli` in the module's folder. The CLI divides commands in two category, transactions and queries, defined in `client/cli/tx.go` and `client/cli/query.go` respectively. Both commands are built on top of the [Cobra Library](https://github.com/spf13/cobra): - -- Transactions commands let users generate new transactions so that they can be included in a block and eventually update the state. One command should be created for each [message type](#message-types) defined in the module. The command calls the constructor of the message with the parameters provided by the end-user, and wraps it into a transaction. The SDK handles signing and the addition of other transaction metadata. -- Queries let users query the subset of the state defined by the module. Query commands forward queries to the [application's query router](../core/baseapp.md#query-routing), which routes them to the appropriate [querier](#querier) the `queryRoute` parameter supplied. - -#### gRPC - -[gRPC](https://grpc.io) is a modern open source high performance RPC framework that has support in multiple languages. It is the recommended way for external clients (such as wallets, browsers and other backend services) to interact with a node. - -Each module can expose gRPC endpoints, called [service methods](https://grpc.io/docs/what-is-grpc/core-concepts/#service-definition) and are defined in the [module's Protobuf `query.proto` file](#grpc-query-services). A service method is defined by its name, input arguments and output response. The module then needs to: - -- define a `RegisterGRPCGatewayRoutes` method on `AppModuleBasic` to wire the client gRPC requests to the correct handler inside the module. -- for each service method, define a corresponding handler. The handler implements the core logic necessary to serve the gRPC request, and is located in the `keeper/grpc_query.go` file. - -#### gRPC-gateway REST Endpoints - -Some external clients may not wish to use gRPC. The SDK provides in this case a gRPC gateway service, which exposes each gRPC service as a correspoding REST endpoint. Please refer to the [grpc-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) documentation to learn more. - -The REST endpoints are defined in the Protobuf files, along with the gRPC services, using Protobuf annotations. Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods. By default, all REST endpoints defined in the SDK have an URL starting with the `/cosmos/` prefix. - -The SDK also provides a development endpoint to generate [Swagger](https://swagger.io/) definition files for these REST endpoints. This endpoint can be enabled inside the [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) config file, under the `api.swagger` key. - -#### Legacy API REST Endpoints - -The [module's Legacy REST interface](../building-modules/module-interfaces.md#legacy-rest) lets users generate transactions and query the state through REST calls to the application's Legacy API Service. REST routes are defined in a file `client/rest/rest.go`, which is composed of: - -- A `RegisterRoutes` function, which registers each route defined in the file. This function is called from the [main application's interface](#application-interfaces) for each module used within the application. The router used in the SDK is [Gorilla's mux](https://github.com/gorilla/mux). -- Custom request type definitions for each query or transaction creation function that needs to be exposed. These custom request types build on the base `request` type of the Cosmos SDK: - +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/rest/rest.go#L62-L76 -- One handler function for each request that can be routed to the given module. These functions implement the core logic necessary to serve the request. - -These Legacy API endpoints are present in the SDK for backward compatibility purposes and will be removed in the next release. - -## Application Interface - -[Interfaces](../interfaces/interfaces-intro.md) let end-users interact with full-node clients. This means querying data from the full-node or creating and sending new transactions to be relayed by the full-node and eventually included in a block. - -The main interface is the [Command-Line Interface](../interfaces/cli.md). The CLI of an SDK application is built by aggregating [CLI commands](#cli) defined in each of the modules used by the application. The CLI of an application is the same as the daemon (e.g. `appd`), and defined in a file called `appd/main.go`. The file contains: - -- **A `main()` function**, which is executed to build the `appd` interface client. This function prepares each command and adds them to the `rootCmd` before building them. At the root of `appd`, the function adds generic commands like `status`, `keys` and `config`, query commands, tx commands and `rest-server`. -- **Query commands** are added by calling the `queryCmd` function. This function returns a Cobra command that contains the query commands defined in each of the application's modules (passed as an array of `sdk.ModuleClients` from the `main()` function), as well as some other lower level query commands such as block or validator queries. Query command are called by using the command `appd query [query]` of the CLI. -- **Transaction commands** are added by calling the `txCmd` function. Similar to `queryCmd`, the function returns a Cobra command that contains the tx commands defined in each of the application's modules, as well as lower level tx commands like transaction signing or broadcasting. Tx commands are called by using the command `appd tx [tx]` of the CLI. - -See an example of an application's main command-line file from the [nameservice tutorial](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice) - -+++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/cmd/nscli/main.go - -## Dependencies and Makefile - -::: warning -A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. - -To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: - -``` -replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 -``` - -Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. -::: - -This section is optional, as developers are free to choose their dependency manager and project building method. That said, the current most used framework for versioning control is [`go.mod`](https://github.com/golang/go/wiki/Modules). It ensures each of the libraries used throughout the application are imported with the correct version. See an example from the [nameservice tutorial](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice): - -+++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/go.mod#L1-L18 - -For building the application, a [Makefile](https://en.wikipedia.org/wiki/Makefile) is generally used. The Makefile primarily ensures that the `go.mod` is run before building the two entrypoints to the application, [`appd`](#node-client) and [`appd`](#application-interface). See an example of Makefile from the [nameservice tutorial]() - -+++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/Makefile - -## Next {hide} - -Learn more about the [Lifecycle of a transaction](./tx-lifecycle.md) {hide} diff --git a/docs/basics/gas-fees.md b/docs/basics/gas-fees.md deleted file mode 100644 index 2ab586497c..0000000000 --- a/docs/basics/gas-fees.md +++ /dev/null @@ -1,89 +0,0 @@ - - -# Gas and Fees - -This document describes the default strategies to handle gas and fees within a Cosmos SDK application. {synopsis} - -### Pre-requisite Readings - -- [Anatomy of an SDK Application](./app-anatomy.md) {prereq} - -## Introduction to `Gas` and `Fees` - -In the Cosmos SDK, `gas` is a special unit that is used to track the consumption of resources during execution. `gas` is typically consumed whenever read and writes are made to the store, but it can also be consumed if expensive computation needs to be done. It serves two main purposes: - -- Make sure blocks are not consuming too many resources and will be finalized. This is implemented by default in the SDK via the [block gas meter](#block-gas-meter). -- Prevent spam and abuse from end-user. To this end, `gas` consumed during [`message`](../building-modules/messages-and-queries.md#messages) execution is typically priced, resulting in a `fee` (`fees = gas * gas-prices`). `fees` generally have to be paid by the sender of the `message`. Note that the SDK does not enforce `gas` pricing by default, as there may be other ways to prevent spam (e.g. bandwidth schemes). Still, most applications will implement `fee` mechanisms to prevent spam. This is done via the [`AnteHandler`](#antehandler). - -## Gas Meter - -In the Cosmos SDK, `gas` is a simple alias for `uint64`, and is managed by an object called a _gas meter_. Gas meters implement the `GasMeter` interface - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/store/types/gas.go#L34-L43 - -where: - -- `GasConsumed()` returns the amount of gas that was consumed by the gas meter instance. -- `GasConsumedToLimit()` returns the amount of gas that was consumed by gas meter instance, or the limit if it is reached. -- `Limit()` returns the limit of the gas meter instance. `0` if the gas meter is infinite. -- `ConsumeGas(amount Gas, descriptor string)` consumes the amount of `gas` provided. If the `gas` overflows, it panics with the `descriptor` message. If the gas meter is not infinite, it panics if `gas` consumed goes above the limit. -- `IsPastLimit()` returns `true` if the amount of gas consumed by the gas meter instance is strictly above the limit, `false` otherwise. -- `IsOutOfGas()` returns `true` if the amount of gas consumed by the gas meter instance is above or equal to the limit, `false` otherwise. - -The gas meter is generally held in [`ctx`](../core/context.md), and consuming gas is done with the following pattern: - -```go -ctx.GasMeter().ConsumeGas(amount, "description") -``` - -By default, the Cosmos SDK makes use of two different gas meters, the [main gas meter](#main-gas-metter[) and the [block gas meter](#block-gas-meter). - -### Main Gas Meter - -`ctx.GasMeter()` is the main gas meter of the application. The main gas meter is initialized in `BeginBlock` via `setDeliverState`, and then tracks gas consumption during execution sequences that lead to state-transitions, i.e. those originally triggered by [`BeginBlock`](../core/baseapp.md#beginblock), [`DeliverTx`](../core/baseapp.md#delivertx) and [`EndBlock`](../core/baseapp.md#endblock). At the beginning of each `DeliverTx`, the main gas meter **must be set to 0** in the [`AnteHandler`](#antehandler), so that it can track gas consumption per-transaction. - -Gas consumption can be done manually, generally by the module developer in the [`BeginBlocker`, `EndBlocker`](../building-modules/beginblock-endblock.md) or [`Msg` service](../building-modules/msg-services.md), but most of the time it is done automatically whenever there is a read or write to the store. This automatic gas consumption logic is implemented in a special store called [`GasKv`](../core/store.md#gaskv-store). - -### Block Gas Meter - -`ctx.BlockGasMeter()` is the gas meter used to track gas consumption per block and make sure it does not go above a certain limit. A new instance of the `BlockGasMeter` is created each time [`BeginBlock`](../core/baseapp.md#beginblock) is called. The `BlockGasMeter` is finite, and the limit of gas per block is defined in the application's consensus parameters. By default Cosmos SDK applications use the default consensus parameters provided by Tendermint: - -+++ https://github.com/tendermint/tendermint/blob/v0.34.0-rc6/types/params.go#L34-L41 - -When a new [transaction](../core/transactions.md) is being processed via `DeliverTx`, the current value of `BlockGasMeter` is checked to see if it is above the limit. If it is, `DeliverTx` returns immediately. This can happen even with the first transaction in a block, as `BeginBlock` itself can consume gas. If not, the transaction is processed normally. At the end of `DeliverTx`, the gas tracked by `ctx.BlockGasMeter()` is increased by the amount consumed to process the transaction: - -```go -ctx.BlockGasMeter().ConsumeGas( - ctx.GasMeter().GasConsumedToLimit(), - "block gas meter", -) -``` - -## AnteHandler - -The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`, before the `Msg` service of each `Msg` in the transaction. `AnteHandler`s have the following signature: - -```go -// AnteHandler authenticates transactions, before their internal messages are handled. -// If newCtx.IsZero(), ctx is used instead. -type AnteHandler func(ctx Context, tx Tx, simulate bool) (newCtx Context, result Result, abort bool) -``` - -The `anteHandler` is not implemented in the core SDK but in a module. This gives the possibility to developers to choose which version of `AnteHandler` fits their application's needs. That said, most applications today use the default implementation defined in the [`auth` module](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth). Here is what the `anteHandler` is intended to do in a normal Cosmos SDK application: - -- Verify that the transaction are of the correct type. Transaction types are defined in the module that implements the `anteHandler`, and they follow the transaction interface: - +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/tx_msg.go#L49-L57 - This enables developers to play with various types for the transaction of their application. In the default `auth` module, the default transaction type is `Tx`: - +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L12-L25 -- Verify signatures for each [`message`](../building-modules/messages-and-queries.md#messages) contained in the transaction. Each `message` should be signed by one or multiple sender(s), and these signatures must be verified in the `anteHandler`. -- During `CheckTx`, verify that the gas prices provided with the transaction is greater than the local `min-gas-prices` (as a reminder, gas-prices can be deducted from the following equation: `fees = gas * gas-prices`). `min-gas-prices` is a parameter local to each full-node and used during `CheckTx` to discard transactions that do not provide a minimum amount of fees. This ensure that the mempool cannot be spammed with garbage transactions. -- Verify that the sender of the transaction has enough funds to cover for the `fees`. When the end-user generates a transaction, they must indicate 2 of the 3 following parameters (the third one being implicit): `fees`, `gas` and `gas-prices`. This signals how much they are willing to pay for nodes to execute their transaction. The provided `gas` value is stored in a parameter called `GasWanted` for later use. -- Set `newCtx.GasMeter` to 0, with a limit of `GasWanted`. **This step is extremely important**, as it not only makes sure the transaction cannot consume infinite gas, but also that `ctx.GasMeter` is reset in-between each `DeliverTx` (`ctx` is set to `newCtx` after `anteHandler` is run, and the `anteHandler` is run each time `DeliverTx` is called). - -As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed =< GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`DeliverTx`](../core/baseapp.md#delivertx) returns. - -## Next {hide} - -Learn about [baseapp](../core/baseapp.md) {hide} diff --git a/docs/basics/query-lifecycle.md b/docs/basics/query-lifecycle.md deleted file mode 100644 index 55902e698d..0000000000 --- a/docs/basics/query-lifecycle.md +++ /dev/null @@ -1,152 +0,0 @@ - - -# Query Lifecycle - -This document describes the lifecycle of a query in a SDK application, from the user interface to application stores and back. {synopsis} - -## Pre-requisite Readings - -- [Transaction Lifecycle](./tx-lifecycle.md) {prereq} - -## Query Creation - -A [**query**](../building-modules/messages-and-queries.md#queries) is a request for information made by end-users of applications through an interface and processed by a full-node. Users can query information about the network, the application itself, and application state directly from the application's stores or modules. Note that queries are different from [transactions](../core/transactions.md) (view the lifecycle [here](./tx-lifecycle.md)), particularly in that they do not require consensus to be processed (as they do not trigger state-transitions); they can be fully handled by one full-node. - -For the purpose of explaining the query lifecycle, let's say `MyQuery` is requesting a list of delegations made by a certain delegator address in the application called `simapp`. As to be expected, the [`staking`](../../x/staking/spec/README.md) module handles this query. But first, there are a few ways `MyQuery` can be created by users. - -### CLI - -The main interface for an application is the command-line interface. Users connect to a full-node and run the CLI directly from their machines - the CLI interacts directly with the full-node. To create `MyQuery` from their terminal, users type the following command: - -```bash -simd query staking delegations -``` - -This query command was defined by the [`staking`](../../x/staking/spec/README.md) module developer and added to the list of subcommands by the application developer when creating the CLI. - -Note that the general format is as follows: - -```bash -simd query [moduleName] [command] --flag -``` - -To provide values such as `--node` (the full-node the CLI connects to), the user can use the [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) config file to set them or provide them as flags. - -The CLI understands a specific set of commands, defined in a hierarchical structure by the application developer: from the [root command](../core/cli.md#root-command) (`simd`), the type of command (`Myquery`), the module that contains the command (`staking`), and command itself (`delegations`). Thus, the CLI knows exactly which module handles this command and directly passes the call there. - -### gRPC - -::: warning -A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. - -To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: - -``` -replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 -``` - -Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. -::: - -Another interface through which users can make queries, introduced in Cosmos SDK v0.40, is [gRPC](https://grpc.io) requests to a [gRPC server](../core/grpc_rest.md#grpc-server). The endpoints are defined as [Protocol Buffers](https://developers.google.com/protocol-buffers) service methods inside `.proto` files, written in Protobuf's own language-agnostic interface definition language (IDL). The Protobuf ecosystem developed tools for code-generation from `*.proto` files into various languages. These tools allow to build gRPC clients easily. - -One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC request for `MyQuery` using this client looks like: - -```bash -grpcurl \ - -plaintext # We want results in plain test - -import-path ./proto \ # Import these .proto files - -proto ./proto/cosmos/staking/v1beta1/query.proto \ # Look into this .proto file for the Query protobuf service - -d '{"address":"$MY_DELEGATOR"}' \ # Query arguments - localhost:9090 \ # gRPC server endpoint - cosmos.staking.v1beta1.Query/Delegations # Fully-qualified service method name -``` - -### REST - -Another interface through which users can make queries is through HTTP Requests to a [REST server](../core/grpc_rest.md#rest-server). The REST server is fully auto-generated from Protobuf services, using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). - -An example HTTP request for `MyQuery` looks like: - -```bash -GET http://localhost:1317/cosmos/staking/v1beta1/delegators/{delegatorAddr}/delegations -``` - -## How Queries are Handled by the CLI - -The examples above show how an external user can interact with a node by querying its state. To understand more in details the exact lifecycle of a query, let's dig into how the CLI prepares the query, and how the node handles it. The interactions from the users' perspective are a bit different, but the underlying functions are almost identical because they are implementations of the same command defined by the module developer. This step of processing happens within the CLI, gRPC or REST server and heavily involves a `client.Context`. - -### Context - -The first thing that is created in the execution of a CLI command is a `client.Context`. A `client.Context` is an object that stores all the data needed to process a request on the user side. In particular, a `client.Context` stores the following: - -- **Codec**: The [encoder/decoder](../core/encoding.md) used by the application, used to marshal the parameters and query before making the Tendermint RPC request and unmarshal the returned response into a JSON object. The default codec used by the CLI is Protobuf. -- **Account Decoder**: The account decoder from the [`auth`](../..//x/auth/spec/README.md) module, which translates `[]byte`s into accounts. -- **RPC Client**: The Tendermint RPC Client, or node, to which the request will be relayed to. -- **Keyring**: A [Key Manager](../basics/accounts.md#keyring) used to sign transactions and handle other operations with keys. -- **Output Writer**: A [Writer](https://golang.org/pkg/io/#Writer) used to output the response. -- **Configurations**: The flags configured by the user for this command, including `--height`, specifying the height of the blockchain to query and `--indent`, which indicates to add an indent to the JSON response. - -The `client.Context` also contains various functions such as `Query()` which retrieves the RPC Client and makes an ABCI call to relay a query to a full-node. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/context.go#L20-L50 - -The `client.Context`'s primary role is to store data used during interactions with the end-user and provide methods to interact with this data - it is used before and after the query is processed by the full-node. Specifically, in handling `MyQuery`, the `client.Context` is utilized to encode the query parameters, retrieve the full-node, and write the output. Prior to being relayed to a full-node, the query needs to be encoded into a `[]byte` form, as full-nodes are application-agnostic and do not understand specific types. The full-node (RPC Client) itself is retrieved using the `client.Context`, which knows which node the user CLI is connected to. The query is relayed to this full-node to be processed. Finally, the `client.Context` contains a `Writer` to write output when the response is returned. These steps are further described in later sections. - -### Arguments and Route Creation - -At this point in the lifecycle, the user has created a CLI command with all of the data they wish to include in their query. A `client.Context` exists to assist in the rest of the `MyQuery`'s journey. Now, the next step is to parse the command or request, extract the arguments, and encode everything. These steps all happen on the user side within the interface they are interacting with. - -#### Encoding - -In our case (querying an address's delegations), `MyQuery` contains an [address](./accounts.md#addresses) `delegatorAddress` as its only argument. However, the request can only contain `[]byte`s, as it will be relayed to a consensus engine (e.g. Tendermint Core) of a full-node that has no inherent knowledge of the application types. Thus, the `codec` of `client.Context` is used to marshal the address. - -Here is what the code looks like for the CLI command: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/client/cli/query.go#L324-L327 - -#### gRPC Query Client Creation - -The SDK leverages code generated from Protobuf services to make queries. The `staking` module's `MyQuery` service generates a `queryClient`, which the CLI will use to make queries. Here is the relevant code: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/client/cli/query.go#L318-L342 - -Under the hood, the `client.Context` has a `Query()` function used to retrieve the pre-configured node and relay a query to it; the function takes the query fully-qualified service method name as path (in our case: `/cosmos.staking.v1beta1.Query/Delegations`), and arguments as parameters. It first retrieves the RPC Client (called the [**node**](../core/node.md)) configured by the user to relay this query to, and creates the `ABCIQueryOptions` (parameters formatted for the ABCI call). The node is then used to make the ABCI call, `ABCIQueryWithOptions()`. - -Here is what the code looks like: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/query.go#L65-L91 - -## RPC - -With a call to `ABCIQueryWithOptions()`, `MyQuery` is received by a [full-node](../core/encoding.md) which will then process the request. Note that, while the RPC is made to the consensus engine (e.g. Tendermint Core) of a full-node, queries are not part of consensus and will not be broadcasted to the rest of the network, as they do not require anything the network needs to agree upon. - -Read more about ABCI Clients and Tendermint RPC in the Tendermint documentation [here](https://tendermint.com/rpc). - -## Application Query Handling - -When a query is received by the full-node after it has been relayed from the underlying consensus engine, it is now being handled within an environment that understands application-specific types and has a copy of the state. [`baseapp`](../core/baseapp.md) implements the ABCI [`Query()`](../core/baseapp.md#query) function and handles gRPC queries. The query route is parsed, and it it matches the fully-qualified service method name of an existing service method (most likely in one of the modules), then `baseapp` will relay the request to the relevant module. - -Apart from gRPC routes, `baseapp` also handles four different types of queries: `app`, `store`, `p2p`, and `custom`. The first three types (`app`, `store`, `p2p`) are purely application-level and thus directly handled by `baseapp` or the stores, but the `custom` query type requires `baseapp` to route the query to a module's [legacy queriers](../building-modules/query-services.md#legacy-queriers). To learn more about these queries, please refer to [this guide](../core/grpc_rest.md#tendermint-rpc). - -Since `MyQuery` has a Protobuf fully-qualified service method name from the `staking` module (recall `/cosmos.staking.v1beta1.Query/Delegations`), `baseapp` first parses the path, then uses its own internal `GRPCQueryRouter` to retrieve the corresponding gRPC handler, and routes the query to the module. The gRPC handler is responsible for recognizing this query, retrieving the appropriate values from the application's stores, and returning a response. Read more about query services [here](../building-modules/query-services.md). - -Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. - -## Response - -Since `Query()` is an ABCI function, `baseapp` returns the response as an [`abci.ResponseQuery`](https://tendermint.com/docs/spec/abci/abci.html#messages) type. The `client.Context` `Query()` routine receives the response and. - -### CLI Response - -The application [`codec`](../core/encoding.md) is used to unmarshal the response to a JSON and the `client.Context` prints the output to the command line, applying any configurations such as the output type (text, JSON or YAML). - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/context.go#L248-L283 - -And that's a wrap! The result of the query is outputted to the console by the CLI. - -## Next {hide} - -Read more about [accounts](./accounts.md). {hide} diff --git a/docs/basics/tx-lifecycle.md b/docs/basics/tx-lifecycle.md deleted file mode 100644 index daed33f823..0000000000 --- a/docs/basics/tx-lifecycle.md +++ /dev/null @@ -1,246 +0,0 @@ - - -# Transaction Lifecycle - -This document describes the lifecycle of a transaction from creation to committed state changes. Transaction definition is described in a [different doc](../core/transactions.md). The transaction will be referred to as `Tx`. {synopsis} - -### Pre-requisite Readings - -- [Anatomy of an SDK Application](./app-anatomy.md) {prereq} - -## Creation - -### Transaction Creation - -One of the main application interfaces is the command-line interface. The transaction `Tx` can be created by the user inputting a command in the following format from the [command-line](../interfaces/cli.md), providing the type of transaction in `[command]`, arguments in `[args]`, and configurations such as gas prices in `[flags]`: - -```bash -[appname] tx [command] [args] [flags] -``` - -This command will automatically **create** the transaction, **sign** it using the account's private key, and **broadcast** it to the specified peer node. - -There are several required and optional flags for transaction creation. The `--from` flag specifies which [account](./accounts.md) the transaction is originating from. For example, if the transaction is sending coins, the funds will be drawn from the specified `from` address. - -#### Gas and Fees - -Additionally, there are several [flags](../interfaces/cli.md) users can use to indicate how much they are willing to pay in [fees](./gas-fees.md): - -- `--gas` refers to how much [gas](./gas-fees.md), which represents computational resources, `Tx` consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing `auto` as the value for `--gas`. -- `--gas-adjustment` (optional) can be used to scale `gas` up in order to avoid underestimating. For example, users can specify their gas adjustment as 1.5 to use 1.5 times the estimated gas. -- `--gas-prices` specifies how much the user is willing pay per unit of gas, which can be one or multiple denominations of tokens. For example, `--gas-prices=0.025uatom, 0.025upho` means the user is willing to pay 0.025uatom AND 0.025upho per unit of gas. -- `--fees` specifies how much in fees the user is willing to pay in total. -- `--timeout-height` specifies a block timeout height to prevent the tx from being committed past a certain height. - -The ultimate value of the fees paid is equal to the gas multiplied by the gas prices. In other words, `fees = ceil(gas * gasPrices)`. Thus, since fees can be calculated using gas prices and vice versa, the users specify only one of the two. - -Later, validators decide whether or not to include the transaction in their block by comparing the given or calculated `gas-prices` to their local `min-gas-prices`. `Tx` will be rejected if its `gas-prices` is not high enough, so users are incentivized to pay more. - -#### CLI Example - -Users of application `app` can enter the following command into their CLI to generate a transaction to send 1000uatom from a `senderAddress` to a `recipientAddress`. It specifies how much gas they are willing to pay: an automatic estimate scaled up by 1.5 times, with a gas price of 0.025uatom per unit gas. - -```bash -appd tx send 1000uatom --from --gas auto --gas-adjustment 1.5 --gas-prices 0.025uatom -``` - -#### Other Transaction Creation Methods - -The command-line is an easy way to interact with an application, but `Tx` can also be created using a [REST interface](../interfaces/rest.md) or some other entrypoint defined by the application developer. From the user's perspective, the interaction depends on the web interface or wallet they are using (e.g. creating `Tx` using [Lunie.io](https://lunie.io/#/) and signing it with a Ledger Nano S). - -## Addition to Mempool - -Each full-node (running Tendermint) that receives a `Tx` sends an [ABCI message](https://tendermint.com/docs/spec/abci/abci.html#messages), -`CheckTx`, to the application layer to check for validity, and receives an `abci.ResponseCheckTx`. If the `Tx` passes the checks, it is held in the nodes' -[**Mempool**](https://tendermint.com/docs/tendermint-core/mempool.html#mempool), an in-memory pool of transactions unique to each node) pending inclusion in a block - honest nodes will discard `Tx` if it is found to be invalid. Prior to consensus, nodes continuously check incoming transactions and gossip them to their peers. - -### Types of Checks - -The full-nodes perform stateless, then stateful checks on `Tx` during `CheckTx`, with the goal to -identify and reject an invalid transaction as early on as possible to avoid wasted computation. - -**_Stateless_** checks do not require nodes to access state - light clients or offline nodes can do -them - and are thus less computationally expensive. Stateless checks include making sure addresses -are not empty, enforcing nonnegative numbers, and other logic specified in the definitions. - -**_Stateful_** checks validate transactions and messages based on a committed state. Examples -include checking that the relevant values exist and are able to be transacted with, the address -has sufficient funds, and the sender is authorized or has the correct ownership to transact. -At any given moment, full-nodes typically have [multiple versions](../core/baseapp.md#volatile-states) -of the application's internal state for different purposes. For example, nodes will execute state -changes while in the process of verifying transactions, but still need a copy of the last committed -state in order to answer queries - they should not respond using state with uncommitted changes. - -In order to verify a `Tx`, full-nodes call `CheckTx`, which includes both _stateless_ and _stateful_ -checks. Further validation happens later in the [`DeliverTx`](#delivertx) stage. `CheckTx` goes -through several steps, beginning with decoding `Tx`. - -### Decoding - -When `Tx` is received by the application from the underlying consensus engine (e.g. Tendermint), it is still in its [encoded](../core/encoding.md) `[]byte` form and needs to be unmarshaled in order to be processed. Then, the [`runTx`](../core/baseapp.md#runtx-and-runmsgs) function is called to run in `runTxModeCheck` mode, meaning the function will run all checks but exit before executing messages and writing state changes. - -### ValidateBasic - -[`Msg`s](../core/transactions.md#messages) are extracted from `Tx` and `ValidateBasic`, a method of the `Msg` interface implemented by the module developer, is run for each one. It should include basic **stateless** sanity checks. For example, if the message is to send coins from one address to another, `ValidateBasic` likely checks for nonempty addresses and a nonnegative coin amount, but does not require knowledge of state such as account balance of an address. - -### AnteHandler - -After the ValidateBasic checks, the `AnteHandler`s are run. Technically, they are optional, but in practice, they are very often present to perform signature verification, gas calculation, fee deduction and other core operations related to blockchain transactions. - -A copy of the cached context is provided to the `AnteHandler`, which performs limited checks specified for the transaction type. Using a copy allows the AnteHandler to do stateful checks for `Tx` without modifying the last committed state, and revert back to the original if the execution fails. - -For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec) module `AnteHandler` checks and increments sequence numbers, checks signatures and account numbers, and deducts fees from the first signer of the transaction - all state changes are made using the `checkState`. - -### Gas - -The [`Context`](../core/context.md), which keeps a `GasMeter` that will track how much gas has been used during the execution of `Tx`, is initialized. The user-provided amount of gas for `Tx` is known as `GasWanted`. If `GasConsumed`, the amount of gas consumed so during execution, ever exceeds `GasWanted`, the execution will stop and the changes made to the cached copy of the state won't be committed. Otherwise, `CheckTx` sets `GasUsed` equal to `GasConsumed` and returns it in the result. After calculating the gas and fee values, validator-nodes check that the user-specified `gas-prices` is less than their locally defined `min-gas-prices`. - -### Discard or Addition to Mempool - -If at any point during `CheckTx` the `Tx` fails, it is discarded and the transaction lifecycle ends -there. Otherwise, if it passes `CheckTx` successfully, the default protocol is to relay it to peer -nodes and add it to the Mempool so that the `Tx` becomes a candidate to be included in the next block. - -The **mempool** serves the purpose of keeping track of transactions seen by all full-nodes. -Full-nodes keep a **mempool cache** of the last `mempool.cache_size` transactions they have seen, as a first line of -defense to prevent replay attacks. Ideally, `mempool.cache_size` is large enough to encompass all -of the transactions in the full mempool. If the the mempool cache is too small to keep track of all -the transactions, `CheckTx` is responsible for identifying and rejecting replayed transactions. - -Currently existing preventative measures include fees and a `sequence` (nonce) counter to distinguish -replayed transactions from identical but valid ones. If an attacker tries to spam nodes with many -copies of a `Tx`, full-nodes keeping a mempool cache will reject identical copies instead of running -`CheckTx` on all of them. Even if the copies have incremented `sequence` numbers, attackers are -disincentivized by the need to pay fees. - -Validator nodes keep a mempool to prevent replay attacks, just as full-nodes do, but also use it as -a pool of unconfirmed transactions in preparation of block inclusion. Note that even if a `Tx` -passes all checks at this stage, it is still possible to be found invalid later on, because -`CheckTx` does not fully validate the transaction (i.e. it does not actually execute the messages). - -## Inclusion in a Block - -Consensus, the process through which validator nodes come to agreement on which transactions to -accept, happens in **rounds**. Each round begins with a proposer creating a block of the most -recent transactions and ends with **validators**, special full-nodes with voting power responsible -for consensus, agreeing to accept the block or go with a `nil` block instead. Validator nodes -execute the consensus algorithm, such as [Tendermint BFT](https://tendermint.com/docs/spec/consensus/consensus.html#terms), -confirming the transactions using ABCI requests to the application, in order to come to this agreement. - -The first step of consensus is the **block proposal**. One proposer amongst the validators is chosen -by the consensus algorithm to create and propose a block - in order for a `Tx` to be included, it -must be in this proposer's mempool. - -## State Changes - -The next step of consensus is to execute the transactions to fully validate them. All full-nodes -that receive a block proposal from the correct proposer execute the transactions by calling the ABCI functions -[`BeginBlock`](./app-anatomy.md#beginblocker-and-endblocker), `DeliverTx` for each transaction, -and [`EndBlock`](./app-anatomy.md#beginblocker-and-endblocker). While each full-node runs everything -locally, this process yields a single, unambiguous result, since the messages' state transitions are deterministic and transactions are -explicitly ordered in the block proposal. - -``` - ----------------------- - |Receive Block Proposal| - ----------------------- - | - v - ----------------------- - | BeginBlock | - ----------------------- - | - v - ----------------------- - | DeliverTx(tx0) | - | DeliverTx(tx1) | - | DeliverTx(tx2) | - | DeliverTx(tx3) | - | . | - | . | - | . | - ----------------------- - | - v - ----------------------- - | EndBlock | - ----------------------- - | - v - ----------------------- - | Consensus | - ----------------------- - | - v - ----------------------- - | Commit | - ----------------------- -``` - -### DeliverTx - -The `DeliverTx` ABCI function defined in [`BaseApp`](../core/baseapp.md) does the bulk of the -state transitions: it is run for each transaction in the block in sequential order as committed -to during consensus. Under the hood, `DeliverTx` is almost identical to `CheckTx` but calls the -[`runTx`](../core/baseapp.md#runtx) function in deliver mode instead of check mode. -Instead of using their `checkState`, full-nodes use `deliverState`: - -- **Decoding:** Since `DeliverTx` is an ABCI call, `Tx` is received in the encoded `[]byte` form. - Nodes first unmarshal the transaction, using the [`TxConfig`](./app-anatomy#register-codec) defined in the app, then call `runTx` in `runTxModeDeliver`, which is very similar to `CheckTx` but also executes and writes state changes. - -- **Checks:** Full-nodes call `validateBasicMsgs` and the `AnteHandler` again. This second check - happens because they may not have seen the same transactions during the addition to Mempool stage\ - and a malicious proposer may have included invalid ones. One difference here is that the - `AnteHandler` will not compare `gas-prices` to the node's `min-gas-prices` since that value is local - to each node - differing values across nodes would yield nondeterministic results. - -- **`MsgServiceRouter`:** While `CheckTx` would have exited, `DeliverTx` continues to run - [`runMsgs`](../core/baseapp.md#runtx-and-runmsgs) to fully execute each `Msg` within the transaction. - Since the transaction may have messages from different modules, `BaseApp` needs to know which module - to find the appropriate handler. This is achieved using `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](../building-modules/msg-services.md). - For legacy `Msg` routing, the `Route` function is called via the [module manager](../building-modules/module-manager.md) to retrieve the route name and find the legacy [`Handler`](../building-modules/msg-services.md#handler-type) within the module. - -- **`Msg` service:** The `Msg` service, a step up from `AnteHandler`, is responsible for executing each - message in the `Tx` and causes state transitions to persist in `deliverTxState`. It is defined - within a module `Msg` protobuf service and writes to the appropriate stores within the module. - -- **Gas:** While a `Tx` is being delivered, a `GasMeter` is used to keep track of how much - gas is being used; if execution completes, `GasUsed` is set and returned in the - `abci.ResponseDeliverTx`. If execution halts because `BlockGasMeter` or `GasMeter` has run out or something else goes - wrong, a deferred function at the end appropriately errors or panics. - -If there are any failed state changes resulting from a `Tx` being invalid or `GasMeter` running out, -the transaction processing terminates and any state changes are reverted. Invalid transactions in a -block proposal cause validator nodes to reject the block and vote for a `nil` block instead. - -### Commit - -The final step is for nodes to commit the block and state changes. Validator nodes -perform the previous step of executing state transitions in order to validate the transactions, -then sign the block to confirm it. Full nodes that are not validators do not -participate in consensus - i.e. they cannot vote - but listen for votes to understand whether or -not they should commit the state changes. - -When they receive enough validator votes (2/3+ _precommits_ weighted by voting power), full nodes commit to a new block to be added to the blockchain and -finalize the state transitions in the application layer. A new state root is generated to serve as -a merkle proof for the state transitions. Applications use the [`Commit`](../core/baseapp.md#commit) -ABCI method inherited from [Baseapp](../core/baseapp.md); it syncs all the state transitions by -writing the `deliverState` into the application's internal state. As soon as the state changes are -committed, `checkState` start afresh from the most recently committed state and `deliverState` -resets to `nil` in order to be consistent and reflect the changes. - -Note that not all blocks have the same number of transactions and it is possible for consensus to -result in a `nil` block or one with none at all. In a public blockchain network, it is also possible -for validators to be **byzantine**, or malicious, which may prevent a `Tx` from being committed in -the blockchain. Possible malicious behaviors include the proposer deciding to censor a `Tx` by -excluding it from the block or a validator voting against the block. - -At this point, the transaction lifecycle of a `Tx` is over: nodes have verified its validity, -delivered it by executing its state changes, and committed those changes. The `Tx` itself, -in `[]byte` form, is stored in a block and appended to the blockchain. - -## Next {hide} - -Learn about [accounts](./accounts.md) {hide} diff --git a/docs/building-modules/README.md b/docs/building-modules/README.md deleted file mode 100644 index 22f3ffb75e..0000000000 --- a/docs/building-modules/README.md +++ /dev/null @@ -1,22 +0,0 @@ - - -# Building Modules - -This repository contains documentation on concepts developers need to know in order to build modules for Cosmos SDK applications. - -1. [Introduction to Cosmos SDK Modules](./intro.md) -2. [`AppModule` Interface and Module Manager](./module-manager.md) -3. [Messages and Queries](./messages-and-queries.md) -4. [`Msg` services - Processing Messages](./msg-services.md) -5. [Query Services - Processing Queries](./query-services.md) -6. [BeginBlocker and EndBlocker](./beginblock-endblock.md) -7. [`Keeper`s](./keeper.md) -8. [Invariants](./invariants.md) -9. [Genesis](./genesis.md) -10. [Module Interfaces](./module-interfaces.md) -11. [Standard Module Structure](./structure.md) -12. [Errors](./errors.md) diff --git a/docs/building-modules/beginblock-endblock.md b/docs/building-modules/beginblock-endblock.md deleted file mode 100644 index cb8dbba1dd..0000000000 --- a/docs/building-modules/beginblock-endblock.md +++ /dev/null @@ -1,39 +0,0 @@ - - -# BeginBlocker and EndBlocker - -`BeginBlocker` and `EndBlocker` are optional methods module developers can implement in their module. They will be triggered at the beginning and at the end of each block respectively, when the [`BeginBlock`](../core/baseapp.md#beginblock) and [`EndBlock`](../core/baseapp.md#endblock) ABCI messages are received from the underlying consensus engine. {synopsis} - -## Pre-requisite Readings - -- [Module Manager](./module-manager.md) {prereq} - -## BeginBlocker and EndBlocker - -`BeginBlocker` and `EndBlocker` are a way for module developers to add automatic execution of logic to their module. This is a powerful tool that should be used carefully, as complex automatic functions can slow down or even halt the chain. - -When needed, `BeginBlocker` and `EndBlocker` are implemented as part of the [`AppModule` interface](./module-manager.md#appmodule). The `BeginBlock` and `EndBlock` methods of the interface implemented in `module.go` generally defer to `BeginBlocker` and `EndBlocker` methods respectively, which are usually implemented in a **`abci.go`** file. - -The actual implementation of `BeginBlocker` and `EndBlocker` in `./abci.go` are very similar to that of a [`Msg` service](./msg-services.md): - -- They generally use the [`keeper`](./keeper.md) and [`ctx`](../core/context.md) to retrieve information about the latest state. -- If needed, they use the `keeper` and `ctx` to trigger state-transitions. -- If needed, they can emit [`events`](../core/events.md) via the `ctx`'s `EventManager`. - -A specificity of the `EndBlocker` is that it can return validator updates to the underlying consensus engine in the form of an [`[]abci.ValidatorUpdates`](https://tendermint.com/docs/app-dev/abci-spec.html#validatorupdate). This is the preferred way to implement custom validator changes. - -It is possible for developers to define the order of execution between the `BeginBlocker`/`EndBlocker` functions of each of their application's modules via the module's manager `SetOrderBeginBlocker`/`SetOrderEndBlocker` methods. For more on the module manager, click [here](./module-manager.md#manager). - -See an example implementation of `BeginBlocker` from the `distr` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/f33749263f4ecc796115ad6e789cb0f7cddf9148/x/distribution/abci.go#L14-L38 - -and an example implementation of `EndBlocker` from the `staking` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/f33749263f4ecc796115ad6e789cb0f7cddf9148/x/staking/abci.go#L22-L27 - -## Next {hide} - -Learn about [`keeper`s](./keeper.md) {hide} diff --git a/docs/building-modules/errors.md b/docs/building-modules/errors.md deleted file mode 100644 index 3b6d90535e..0000000000 --- a/docs/building-modules/errors.md +++ /dev/null @@ -1,54 +0,0 @@ - - -# Errors - -This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. {synopsis} - -Modules are encouraged to define and register their own errors to provide better -context on failed message or handler execution. Typically, these errors should be -common or general errors which can be further wrapped to provide additional specific -execution context. - -## Registration - -Modules should define and register their custom errors in `x/{module}/types/errors.go`. Registration -of errors is handled via the `types/errors` package. - -Example: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.38.1/x/distribution/types/errors.go#L1-L21 - -Each custom module error must provide the codespace, which is typically the module name -(e.g. "distribution") and is unique per module, and a uint32 code. Together, the codespace and code -provide a globally unique SDK error. Typically, the code is monotonically increasing but does not -necessarily have to be. The only restrictions on error codes are the following: - -* Must be greater than one, as a code value of one is reserved for internal errors. -* Must be unique within the module. - -Note, the SDK provides a core set of *common* errors. These errors are defined in `types/errors/errors.go`. - -## Wrapping - -The custom module errors can be returned as their concrete type as they already fulfill the `error` -interface. However, module errors can be wrapped to provide further context and meaning to failed -execution. - -Example: - -+++ https://github.com/cosmos/cosmos-sdk/blob/b2d48a9e815fe534a7faeec6ca2adb0874252b81/x/bank/keeper/keeper.go#L85-L122 - -Regardless if an error is wrapped or not, the SDK's `errors` package provides an API to determine if -an error is of a particular kind via `Is`. - -## ABCI - -If a module error is registered, the SDK `errors` package allows ABCI information to be extracted -through the `ABCIInfo` API. The package also provides `ResponseCheckTx` and `ResponseDeliverTx` as -auxiliary APIs to automatically get `CheckTx` and `DeliverTx` responses from an error. - -## Next {hide} - -Learn about [interfaces](../interfaces/interfaces-intro.md) {hide} diff --git a/docs/building-modules/genesis.md b/docs/building-modules/genesis.md deleted file mode 100644 index 7314442969..0000000000 --- a/docs/building-modules/genesis.md +++ /dev/null @@ -1,60 +0,0 @@ - - -# Module Genesis - -Modules generally handle a subset of the state and, as such, they need to define the related subset of the genesis file as well as methods to initialize, verify and export it. {synopsis} - -## Pre-requisite Readings - -- [Module Manager](./module-manager.md) {prereq} -- [Keepers](./keeper.md) {prereq} - -## Type Definition - -The subset of the genesis state defined from a given module is generally defined in a `genesis.proto` file ([more info](../core/encoding.md#gogoproto) on how to define protobuf messages). The struct defining the module's subset of the genesis state is usually called `GenesisState` and contains all the module-related values that need to be initialized during the genesis process. - -See an example of `GenesisState` protobuf message definition from the `auth` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/a9547b54ffac9729fe1393651126ddfc0d236cff/proto/cosmos/auth/v1beta1/genesis.proto - -Next we present the main genesis-related methods that need to be implemented by module developers in order for their module to be used in Cosmos SDK applications. - -### `DefaultGenesis` - -The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/module.go#L48-L52 - -### `ValidateGenesis` - -The `ValidateGenesis(genesisState GenesisState)` method is called to verify that the provided `genesisState` is correct. It should perform validity checks on each of the parameter listed in `GenesisState`. See an example from the `auth` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/types/genesis.go#L57-L70 - -## Other Genesis Methods - -Other than the methods related directly to `GenesisState`, module developers are expected to implement two other methods as part of the [`AppModuleGenesis` interface](./module-manager.md#appmodulegenesis) (only if the module needs to initialize a subset of state in genesis). These methods are [`InitGenesis`](#initgenesis) and [`ExportGenesis`](#exportgenesis). - -### `InitGenesis` - -The `InitGenesis` method is executed during [`InitChain`](../core/baseapp.md#initchain) when the application is first started. Given a `GenesisState`, it initializes the subset of the state managed by the module by using the module's [`keeper`](./keeper.md) setter function on each parameter within the `GenesisState`. - -The [module manager](./module-manager.md#manager) of the application is responsible for calling the `InitGenesis` method of each of the application's modules, in order. This order is set by the application developer via the manager's `SetOrderGenesisMethod`, which is called in the [application's constructor function](../basics/app-anatomy.md#constructor-function) - -See an example of `InitGenesis` from the `auth` module - -+++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/genesis.go#L13-L28 - -### `ExportGenesis` - -The `ExportGenesis` method is executed whenever an export of the state is made. It takes the latest known version of the subset of the state managed by the module and creates a new `GenesisState` out of it. This is mainly used when the chain needs to be upgraded via a hard fork. - -See an example of `ExportGenesis` from the `auth` module. - -+++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/genesis.go#L31-L42 - -## Next {hide} - -Learn about [modules interfaces](module-interfaces.md) {hide} \ No newline at end of file diff --git a/docs/building-modules/intro.md b/docs/building-modules/intro.md deleted file mode 100644 index 95d45fa7b6..0000000000 --- a/docs/building-modules/intro.md +++ /dev/null @@ -1,92 +0,0 @@ - - -# Introduction to SDK Modules - -Modules define most of the logic of SDK applications. Developers compose module together using the Cosmos SDK to build their custom application-specific blockchains. This document outlines the basic concepts behind SDK modules and how to approach module management. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} -- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq} - -## Role of Modules in an SDK Application - -The Cosmos SDK can be thought as the Ruby-on-Rails of blockchain development. It comes with a core that provides the basic functionalities every blockchain application needs, like a [boilerplate implementation of the ABCI](../core/baseapp.md) to communicate with the underlying consensus engine, a [`multistore`](../core/store.md#multistore) to persist state, a [server](../core/node.md) to form a full-node and [interfaces](../interfaces/interfaces-intro.md) to handle queries. - -On top of this core, the Cosmos SDK enables developers to build modules that implement the business logic of their application. In other words, SDK modules implement the bulk of the logic of applications, while the core does the wiring and enables modules to be composed together. The end goal is to build a robust ecosystem of open-source SDK modules, making it increasingly easier to build complex blockchain applications. - -SDK Modules can be seen as little state-machines within the state-machine. They generally define a subset of the state using one or more `KVStore`s in the [main multistore](../core/store.md), as well as a subset of [message types](./messages-and-queries.md#messages). These messages are routed by one of the main component of SDK core, [`BaseApp`](../core/baseapp.md), to the [`Msg` service](./msg-services.md) of the module that define them. - -``` - + - | - | Transaction relayed from the full-node's consensus engine - | to the node's application via DeliverTx - | - | - | - +---------------------v--------------------------+ - | APPLICATION | - | | - | Using baseapp's methods: Decode the Tx, | - | extract and route the message(s) | - | | - +---------------------+--------------------------+ - | - | - | - +---------------------------+ - | - | - | - | Message routed to the correct - | module to be processed - | - | -+----------------+ +---------------+ +----------------+ +------v----------+ -| | | | | | | | -| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | -| | | | | | | | -| | | | | | | Handles message,| -| | | | | | | Updates state | -| | | | | | | | -+----------------+ +---------------+ +----------------+ +------+----------+ - | - | - | - | - +--------------------------+ - | - | Return result to the underlying consensus engine (e.g. Tendermint) - | (0=Ok, 1=Err) - v -``` - -As a result of this architecture, building an 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. - -## How to Approach Building Modules as a Developer - -While there is no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them: - -- **Composability**: SDK applications are almost always composed of multiple modules. This means developers need to carefully consider the integration of their module not only with the core of the Cosmos SDK, but also with other modules. The former is achieved by following standard design patterns outlined [here](#main-components-of-sdk-modules), while the latter is achieved by properly exposing the store(s) of the module via the [`keeper`](./keeper.md). -- **Specialization**: A direct consequence of the **composability** feature is that modules should be **specialized**. Developers should carefully establish the scope of their module and not batch multiple functionalities into the same module. This separation of concern enables modules to be re-used in other projects and improves the upgradability of the application. **Specialization** also plays an important role in the [object-capabilities model](../core/ocap.md) of the Cosmos SDK. -- **Capabilities**: Most modules need to read and/or write to the store(s) of other modules. However, in an open-source environment, it is possible for some module to be malicious. That is why module developers need to carefully think not only about how their module interracts with other modules, but also about how to give access to the module's store(s). The Cosmos SDK takes a capabilities-oriented approach to inter-module security. This means that each store defined by a module is accessed by a `key`, which is held by the module's [`keeper`](./keeper.md). This `keeper` defines how to access the store(s) and under what conditions. Access to the module's store(s) is done by passing a reference to the module's `keeper`. - -## Main Components of SDK Modules - -Modules are by convention defined in the `./x/` subfolder (e.g. the `bank` module will be defined in the `./x/bank` folder). They generally share the same core components: - -- A [`keeper`](./keeper.md), used to access the module's store(s) and update the state. -- A [`Msg` service](./messages-and-queries.md#messages) used to process messages when they are routed to the module by [`BaseApp`](../core/baseapp.md#message-routing) and trigger state-transitions. -- A [query service](./query-services.md), used to process user queries when they are routed to the module by [`BaseApp`](../core/baseapp.md#query-routing). -- Interfaces, for end users to query the subset of the state defined by the module and create `message`s of the custom types defined in the module. - -In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](./module-manager.md). - -Please refer to the [structure document](./structure.md) to learn about the recommended structure of a module's directory. - -## Next {hide} - -Read more on the [`AppModule` interface and the `module manager`](./module-manager.md) {hide} diff --git a/docs/building-modules/invariants.md b/docs/building-modules/invariants.md deleted file mode 100644 index d21100cb24..0000000000 --- a/docs/building-modules/invariants.md +++ /dev/null @@ -1,89 +0,0 @@ - - -# Invariants - -An invariant is a property of the application that should always be true. In the context of the Cosmos SDK, an `Invariant` is a function that checks for a particular invariant. These functions are useful to detect bugs early on and act upon them to limit their potential consequences (e.g. by halting the chain). They are also useful in the development process of the application to detect bugs via simulations. {synopsis} - -## Pre-requisite Readings - -- [Keepers](./keeper.md) {prereq} - -## Implementing `Invariant`s - -An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant`s type: - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/invariant.go#L9 - -where the `string` return value is the invariant message, which can be used when printing logs, and the `bool` return value is the actual result of the invariant check. - -In practice, each module implements `Invariant`s in a `./keeper/invariants.go` file within the module's folder. The standard is to implement one `Invariant` function per logical grouping of invariants with the following model: - -```go -// Example for an Invariant that checks balance-related invariants - -func BalanceInvariants(k Keeper) sdk.Invariant { - return func(ctx sdk.Context) (string, bool) { - // Implement checks for balance-related invariants - } -} -``` - -Additionally, module developers should generally implement an `AllInvariants` function that runs all the `Invariant`s functions of the module: - -```go -// AllInvariants runs all invariants of the module. -// In this example, the module implements two Invariants: BalanceInvariants and DepositsInvariants - -func AllInvariants(k Keeper) sdk.Invariant { - - return func(ctx sdk.Context) (string, bool) { - res, stop := BalanceInvariants(k)(ctx) - if stop { - return res, stop - } - - return DepositsInvariant(k)(ctx) - } -} -``` - -Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](./module-manager.md#appmodule). Indeed, the `RegisterInvariants` method of the module, implemented in the `module.go` file, typically only defers the call to a `RegisterInvariants` method implemented in `internal/keeper/invariants.go`. The `RegisterInvariants` method registers a route for each `Invariant` function in the [`InvariantRegistry`](#invariant-registry): - - -```go -// RegisterInvariants registers all staking invariants -func RegisterInvariants(ir sdk.InvariantRegistry, k Keeper) { - ir.RegisterRoute(types.ModuleName, "module-accounts", - BalanceInvariants(k)) - ir.RegisterRoute(types.ModuleName, "nonnegative-power", - DepositsInvariant(k)) -} -``` - -For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/staking/keeper/invariants.go). - -## Invariant Registry - -The `InvariantRegistry` is a registry where the `Invariant`s of all the modules of an application are registered. There is only one `InvariantRegistry` per **application**, meaning module developers need not implement their own `InvariantRegistry` when building a module. **All module developers need to do is to register their modules' invariants in the `InvariantRegistry`, as explained in the section above**. The rest of this section gives more information on the `InvariantRegistry` itself, and does not contain anything directly relevant to module developers. - -At its core, the `InvariantRegistry` is defined in the SDK as an interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/invariant.go#L14-L17 - -Typically, this interface is implemented in the `keeper` of a specific module. The most used implementation of an `InvariantRegistry` can be found in the `crisis` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/master/x/crisis/keeper/keeper.go#L50-L54 - - The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](../basics/app-anatomy.md#constructor-function). - -`Invariant`s can be checked manually via [`message`s](./messages-and-queries.md), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/crisis/abci.go#L7-L14 - -In both cases, if one of the `Invariant`s returns false, the `InvariantRegistry` can trigger special logic (e.g. have the application panic and print the `Invariant`s message in the log). - -## Next {hide} - -Learn about [genesis functionalities](./genesis.md) {hide} diff --git a/docs/building-modules/keeper.md b/docs/building-modules/keeper.md deleted file mode 100644 index e84abfb01f..0000000000 --- a/docs/building-modules/keeper.md +++ /dev/null @@ -1,85 +0,0 @@ - - -# Keepers - -`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage access to the subset of the state defined by various modules. `Keeper`s are module-specific, i.e. the subset of state defined by a module can only be accessed by a `keeper` defined in said module. If a module needs to access the subset of state defined by another module, a reference to the second module's internal `keeper` needs to be passed to the first one. This is done in `app.go` during the instantiation of module keepers. {synopsis} - -## Pre-requisite Readings - -- [Introduction to SDK Modules](./intro.md) {prereq} - -## Motivation - -The Cosmos SDK is a framework that makes it easy for developers to build complex decentralised applications from scratch, mainly by composing modules together. As the ecosystem of open source modules for the Cosmos SDK expands, it will become increasingly likely that some of these modules contain vulnerabilities, as a result of the negligence or malice of their developer. - -The Cosmos SDK adopts an [object-capabilities-based approach](../core/ocap.md) to help developers better protect their application from unwanted inter-module interactions, and `keeper`s are at the core of this approach. A `keeper` can be thought of quite literally as the gatekeeper of a module's store(s). Each store (typically an [`IAVL` Store](../core/store.md#iavl-store)) defined within a module comes with a `storeKey`, which grants unlimited access to it. The module's `keeper` holds this `storeKey` (which should otherwise remain unexposed), and defines [methods](#implementing-methods) for reading and writing to the store(s). - -The core idea behind the object-capabilities approach is to only reveal what is necessary to get the work done. In practice, this means that instead of handling permissions of modules through access-control lists, module `keeper`s are passed a reference to the specific instance of the other modules' `keeper`s that they need to access (this is done in the [application's constructor function](../basics/app-anatomy.md#constructor-function)). As a consequence, a module can only interact with the subset of state defined in another module via the methods exposed by the instance of the other module's `keeper`. This is a great way for developers to control the interactions that their own module can have with modules developed by external developers. - -## Type Definition - -`keeper`s are generally implemented in a `/keeper/keeper.go` file located in the module's folder. By convention, the type `keeper` of a module is simply named `Keeper` and usually follows the following structure: - -```go -type Keeper struct { - // External keepers, if any - - // Store key(s) - - // codec -} -``` - -For example, here is the type definition of the `keeper` from the `staking` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/3bafd8255a502e5a9cee07391cf8261538245dfd/x/staking/keeper/keeper.go#L23-L33 - -Let us go through the different parameters: - -- An expected `keeper` is a `keeper` external to a module that is required by the internal `keeper` of said module. External `keeper`s are listed in the internal `keeper`'s type definition as interfaces. These interfaces are themselves defined in a `types/expected_keepers.go` file within the module's folder. In this context, interfaces are used to reduce the number of dependencies, as well as to facilitate the maintenance of the module itself. -- `storeKey`s grant access to the store(s) of the [multistore](../core/store.md) managed by the module. They should always remain unexposed to external modules. -- A [codec `cdc`](../core/encoding.md), used to marshall and unmarshall struct to/from `[]byte`, that can be any of `codec.BinaryMarshaler`,`codec.JSONMarshaler` or `codec.Marshaler` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. - -Of course, it is possible to define different types of internal `keeper`s for the same module (e.g. a read-only `keeper`). Each type of `keeper` comes with its own constructor function, which is called from the [application's constructor function](../basics/app-anatomy.md). This is where `keeper`s are instantiated, and where developers make sure to pass correct instances of modules' `keeper`s to other modules that require it. - -## Implementing Methods - -`Keeper`s primarily expose getter and setter methods for the store(s) managed by their module. These methods should remain as simple as possible and strictly be limited to getting or setting the requested value, as validity checks should have already been performed via the `ValidateBasic()` method of the [`message`](./messages-and-queries.md#messages) and the [`Msg` server](./msg-services.md) when `keeper`s' methods are called. - -Typically, a *getter* method will present with the following signature - -```go -func (k Keeper) Get(ctx sdk.Context, key string) returnType -``` - -and go through the following steps: - -1. Retrieve the appropriate store from the `ctx` using the `storeKey`. This is done through the `KVStore(storeKey sdk.StoreKey)` method of the `ctx`. Then it's prefered to use the `prefix.Store` to access only the desired limited subset of the store for convenience and safety. -2. If it exists, get the `[]byte` value stored at location `[]byte(key)` using the `Get(key []byte)` method of the store. -3. Unmarshall the retrieved value from `[]byte` to `returnType` using the codec `cdc`. Return the value. - -Similarly, a *setter* method will present with the following signature - -```go -func (k Keeper) Set(ctx sdk.Context, key string, value valueType) -``` - -and go through the following steps: - -1. Retrieve the appropriate store from the `ctx` using the `storeKey`. This is done through the `KVStore(storeKey sdk.StoreKey)` method of the `ctx`. Then it's prefered to use the `prefix.Store` to access only the desired limited subset of the store for convenience and safety. -2. Marshal `value` to `[]byte` using the codec `cdc`. -3. Set the encoded value in the store at location `key` using the `Set(key []byte, value []byte)` method of the store. - -For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/3bafd8255a502e5a9cee07391cf8261538245dfd/x/staking/keeper/keeper.go). - -The [module `KVStore`](../core/store.md#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys. - -This is an example from the `auth` module to iterate accounts: - -+++ https://github.com/cosmos/cosmos-sdk/blob/bf8809ef9840b4f5369887a38d8345e2380a567f/x/auth/keeper/account.go#L70-L83 - -## Next {hide} - -Learn about [invariants](./invariants.md) {hide} diff --git a/docs/building-modules/messages-and-queries.md b/docs/building-modules/messages-and-queries.md deleted file mode 100644 index 33afa51dbb..0000000000 --- a/docs/building-modules/messages-and-queries.md +++ /dev/null @@ -1,111 +0,0 @@ - - -# Messages and Queries - -`Msg`s and `Queries` are the two primary objects handled by modules. Most of the core components defined in a module, like `Msg` services, `keeper`s and `Query` services, exist to process `message`s and `queries`. {synopsis} - -## Pre-requisite Readings - -- [Introduction to SDK Modules](./intro.md) {prereq} - -## Messages - -`Msg`s are objects whose end-goal is to trigger state-transitions. They are wrapped in [transactions](../core/transactions.md), which may contain one or more of them. - -When a transaction is relayed from the underlying consensus engine to the SDK application, it is first decoded by [`BaseApp`](../core/baseapp.md). Then, each message contained in the transaction is extracted and routed to the appropriate module via `BaseApp`'s `MsgServiceRouter` so that it can be processed by the module's [`Msg` service](./msg-services.md). For a more detailed explanation of the lifecycle of a transaction, click [here](../basics/tx-lifecycle.md). - -### `Msg` Services - -Starting from v0.40, defining Protobuf `Msg` services is the recommended way to handle messages. A `Msg` protobuf service should be created per module, typically in `tx.proto` (see more info about [conventions and naming](../core/encoding.md#faq)). It must have an RPC service method defined for each message in the module. - -See an example of a `Msg` service definition from `x/bank` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L10-L17 - -For backwards compatibility with [legacy Amino `Msg`s](#legacy-amino-msgs), existing `Msg` types should be used as the request parameter for `service` definitions. Newer `Msg` types which only support `service` definitions should use the more canonical `Msg...Request` names. - -`Msg` request types need to implement the `MsgRequest` interface which is a simplified version of the `Msg` interface described [below](#legacy-amino-msgs) with only `ValidateBasic()` and `GetSigners()` methods. - -Defining such `Msg` services allow to specify return types as part of `Msg` response using the canonical `Msg...Response` names. - -In addition, this generates client and server code. -The generated `MsgServer` interface defines the server API for the `Msg` service and its implementation is described as part of the [`Msg` services](./msg-services.md) documentation. - -A `RegisterMsgServer` method is also generated and should be used to register the module's `MsgServer` implementation in `RegisterServices` method from the [`AppModule` interface](./module-manager.md#appmodule). - -In order for clients (CLI and grpc-gateway) to have these URLs registered, the SDK provides the function `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)` that should be called inside module's [`RegisterInterfaces`](module-manager.md#appmodulebasic) method, using the proto-generated `&_Msg_serviceDesc` as `*grpc.ServiceDesc` argument. - -### Legacy Amino `Msg`s - -This way of defining messages is deprecated and using [`Msg` services](#msg-services) is preferred. - -Legacy `Msg`s can be defined as protobuf messages. The messages definition usually includes a list of parameters needed to process the message that will be provided by end-users when they want to create a new transaction containing said message. - -The `Msg` is typically accompanied by a standard constructor function, that is called from one of the [module's interface](./module-interfaces.md). `message`s also need to implement the [`Msg`] interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/4a1b2fba43b1052ca162b3a1e0b6db6db9c26656/types/tx_msg.go#L10-L33 - -It extends `proto.Message` and contains the following methods: - -- `Route() string`: Name of the route for this message. Typically all `message`s in a module have the same route, which is most often the module's name. -- `Type() string`: Type of the message, used primarly in [events](../core/events.md). This should return a message-specific `string`, typically the denomination of the message itself. -- `ValidateBasic() error`: This method is called by `BaseApp` very early in the processing of the `message` (in both [`CheckTx`](../core/baseapp.md#checktx) and [`DeliverTx`](../core/baseapp.md#delivertx)), in order to discard obviously invalid messages. `ValidateBasic` should only include *stateless* checks, i.e. checks that do not require access to the state. This usually consists in checking that the message's parameters are correctly formatted and valid (i.e. that the `amount` is strictly positive for a transfer). -- `GetSignBytes() []byte`: Return the canonical byte representation of the message. Used to generate a signature. -- `GetSigners() []AccAddress`: Return the list of signers. The SDK will make sure that each `message` contained in a transaction is signed by all the signers listed in the list returned by this method. - -See an example implementation of a `message` from the `gov` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/gov/types/msgs.go#L77-L125 - -## Queries - -A `query` is a request for information made by end-users of applications through an interface and processed by a full-node. A `query` is received by a full-node through its consensus engine and relayed to the application via the ABCI. It is then routed to the appropriate module via `BaseApp`'s `queryrouter` so that it can be processed by the module's query service (./query-services.md). For a deeper look at the lifecycle of a `query`, click [here](../interfaces/query-lifecycle.md). - -### gRPC Queries - -Starting from v0.40, the prefered way to define queries is by using [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services). A `Query` service should be created per module in `query.proto`. This service lists endpoints starting with `rpc`. - -Here's an example of such a `Query` service definition: - -+++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/proto/cosmos/auth/v1beta1/query.proto#L12-L23 - -As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer). - -A `RegisterQueryServer` method is also generated and should be used to register the module's query server in the `RegisterServices` method from the [`AppModule` interface](./module-manager.md#appmodule). - -### Legacy Queries - -Before the introduction of Protobuf and gRPC in the SDK, there was usually no specific `query` object defined by module developers, contrary to `message`s. Instead, the SDK took the simpler approach of using a simple `path` to define each `query`. The `path` contains the `query` type and all the arguments needed in order to process it. For most module queries, the `path` should look like the following: - -``` -queryCategory/queryRoute/queryType/arg1/arg2/... -``` - -where: - -- `queryCategory` is the category of the `query`, typically `custom` for module queries. It is used to differentiate between different kinds of queries within `BaseApp`'s [`Query` method](../core/baseapp.md#query). -- `queryRoute` is used by `BaseApp`'s [`queryRouter`](../core/baseapp.md#query-routing) to map the `query` to its module. Usually, `queryRoute` should be the name of the module. -- `queryType` is used by the module's [`querier`](./query-services.md#legacy-queriers) to map the `query` to the appropriate `querier function` within the module. -- `args` are the actual arguments needed to process the `query`. They are filled out by the end-user. Note that for bigger queries, you might prefer passing arguments in the `Data` field of the request `req` instead of the `path`. - -The `path` for each `query` must be defined by the module developer in the module's [command-line interface file](./module-interfaces.md#query-commands).Overall, there are 3 mains components module developers need to implement in order to make the subset of the state defined by their module queryable: - -- A [`querier`](./query-services.md#legacy-queriers), to process the `query` once it has been [routed to the module](../core/baseapp.md#query-routing). -- [Query commands](./module-interfaces.md#query-commands) in the module's CLI file, where the `path` for each `query` is specified. -- `query` return types. Typically defined in a file `types/querier.go`, they specify the result type of each of the module's `queries`. These custom types must implement the `String()` method of [`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer). - -### Store Queries - -Store queries query directly for store keys. They use `clientCtx.QueryABCI(req abci.RequestQuery)` to return the full `abci.ResponseQuery` with inclusion Merkle proofs. - -See following examples: - -+++ https://github.com/cosmos/cosmos-sdk/blob/080fcf1df25ccdf97f3029b6b6f83caaf5a235e4/x/ibc/core/client/query.go#L36-L46 - -+++ https://github.com/cosmos/cosmos-sdk/blob/080fcf1df25ccdf97f3029b6b6f83caaf5a235e4/baseapp/abci.go#L722-L749 - -## Next {hide} - -Learn about [`Msg` services](./msg-services.md) {hide} diff --git a/docs/building-modules/module-interfaces.md b/docs/building-modules/module-interfaces.md deleted file mode 100644 index c9d65632cf..0000000000 --- a/docs/building-modules/module-interfaces.md +++ /dev/null @@ -1,207 +0,0 @@ - - -# Module Interfaces - -This document details how to build CLI and REST interfaces for a module. Examples from various SDK modules are included. {synopsis} - -## Pre-requisite Readings - -- [Building Modules Intro](./intro.md) {prereq} - -## CLI - -One of the main interfaces for an application is the [command-line interface](../interfaces/cli.md). This entrypoint adds commands from the application's modules to let end-users create [**messages**](./messages-and-queries.md#messages) and [**queries**](./messages-and-queries.md#queries). The CLI files are typically found in the `./x/moduleName/client/cli` folder. - -### Transaction Commands - -[Transactions](../core/transactions.md) are created by users to wrap messages that trigger state changes when they get included in a valid block. Transaction commands typically have their own `tx.go` file in the module `./x/moduleName/client/cli` folder. The commands are specified in getter functions and include the name of the command. - -Here is an example from the `auth` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/client/cli/tx_sign.go#L160-L194 - -This getter function creates the command for the `Sign` transaction. It does the following: - -- **Construct the command:** Read the [Cobra Documentation](https://godoc.org/github.com/spf13/cobra) for details on how to create commands. - - **Use:** Specifies the format of a command-line entry users should type in order to invoke this command. In this case, the user uses `buy-name` as the name of the transaction command and provides the `name` the user wishes to buy and the `amount` the user is willing to pay. - - **Args:** The number of arguments the user provides, in this case exactly two: `name` and `amount`. - - **Short and Long:** A description for the function is provided here. A `Short` description is expected, and `Long` can be used to provide a more detailed description when a user uses the `--help` flag to ask for more information. - - **RunE:** Defines a function that can return an error, called when the command is executed. Using `Run` would do the same thing, but would not allow for errors to be returned. -- **`RunE` Function Body:** The function should be specified as a `RunE` to allow for errors to be returned. This function encapsulates all of the logic to create a new transaction that is ready to be relayed to nodes. - - The function should first get the `clientCtx` with `client.GetClientContextFromCmd(cmd)` and `client.ReadTxCommandFlags(clientCtx, cmd.Flags())`. This context contains all the information provided by the user and will be used to transfer this user-specific information between processes. To learn more about how contexts are used in a transaction, click [here](../core/transactions.md#transaction-generation). - - If applicable, the command's arguments are parsed. - - If applicable, the `Context` is used to retrieve any parameters such as the transaction originator's address to be used in the transaction. Here, the `from` address is retrieved by calling `clientCtx.GetFromAddress()`. - - A [message](./messages-and-queries.md) is created using all parameters parsed from the command arguments and `Context`. The constructor function of the specific message type is called directly. It is good practice to call `ValidateBasic()` on the newly created message to run a sanity check and check for invalid arguments. - - Depending on what the user wants, the transaction is either generated offline or signed and broadcasted to the preconfigured node using `GenerateOrBroadcastMsgs()`. -- **Flags.** Add any [flags](#flags) to the command. All transaction commands have flags to provide additional information from the user (e.g. amount of fees they are willing to pay). These _persistent_ [transaction flags](../interfaces/cli.md#flags) can be added to a higher-level command so that they apply to all transaction commands. - -Finally, the module needs to have a `GetTxCmd()`, which aggregates all of the transaction commands of the module. Often, each command getter function has its own file in the module's `cli` folder, and a separate `tx.go` file contains `GetTxCmd()`. Application developers wishing to include the module's transactions will call this function to add them as subcommands in their CLI. Here is the `auth` `GetTxCmd()` function, which adds the `Sign`, `MultiSign`, `ValidateSignatures` and `SignBatch` commands. - -+++ https://github.com/cosmos/cosmos-sdk/blob/351192aa0b52a42b66ff06e81cfa7a9e26667a7f/x/auth/client/cli/tx.go#L10-L26 - -An application using this module likely adds `auth` module commands to its root `TxCmd` command by calling `txCmd.AddCommand(authModuleClient.GetTxCmd())`. - -### Query Commands - -[Queries](./messages-and-queries.md#queries) allow users to gather information about the application or network state; they are routed by the application and processed by the module in which they are defined. Query commands typically have their own `query.go` file in the module `x/moduleName/client/cli` folder. Like transaction commands, they are specified in getter functions. Here is an example of a query command from the `auth` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/x/auth/client/cli/query.go#L76-L108 - -This query returns the account at a given address. The getter function does the following: - -- **Construct the command.** Read the [Cobra Documentation](https://godoc.org/github.com/spf13/cobra) and the [transaction command](#transaction-commands) example above for more information. The user must type `account` and provide the `address` they are querying for as the only argument. -- **`RunE`.** The function should be specified as a `RunE` to allow for errors to be returned. This function encapsulates all of the logic to create a new query that is ready to be relayed to nodes. - - The function should first initialize a new client [`Context`](../interfaces/query-lifecycle.md#context) as described in the [previous section](#transaction-commands) - - If applicable, the `Context` is used to retrieve any parameters (e.g. the query originator's address to be used in the query) and marshal them with the query parameter type, in preparation to be relayed to a node. There are no `Context` parameters in this case because the query does not involve any information about the user. - - A new `queryClient` should be initialized using `NewQueryClient(clientCtx)`, this method being generated from `query.proto`. Then it can be used to call the appropriate [query](./messages-and-queries.md#grpc-queries). - - The `clientCtx.PrintProto` method is used to format a `proto.Message` object and print it back to the user. -- **Flags.** Add any [flags](#flags) to the command. - -Finally, the module also needs a `GetQueryCmd`, which aggregates all of the query commands of the module. Application developers wishing to include the module's queries will call this function to add them as subcommands in their CLI. Its structure is identical to the `GetTxCmd` command shown above. - -### Flags - -[Flags](../interfaces/cli.md#flags) are entered by the user and allow for command customizations. Examples include the [fees](../basics/gas-fees.md) or gas prices users are willing to pay for their transactions. - -The flags for a module are typically found in a `flags.go` file in the `./x/moduleName/client/cli` folder. Module developers can create a list of possible flags including the value type, default value, and a description displayed if the user uses a `help` command. In each transaction getter function, they can add flags to the commands and, optionally, mark flags as _required_ so that an error is thrown if the user does not provide values for them. - -For full details on flags, visit the [Cobra Documentation](https://github.com/spf13/cobra). - -For example, the SDK `./client/flags` package includes a `AddTxFlagsToCmd(cmd *cobra.Command)` function that adds necessary flags to a transaction command, such as the `from` flag to indicate which address the transaction originates from. - -+++ https://github.com/cosmos/cosmos-sdk/blob/cfb5fc03e5092395403d10156c0ee96e6ff1ddbe/client/flags/flags.go#L85-L112 - -Here is an example of how to add a flag using the `from` flag from this function. - -```go -cmd.Flags().String(FlagFrom, "", "Name or address of private key with which to sign") -``` - -The input provided for this flag - called `FlagFrom` is a string with the default value of `""` if none is provided. If the user asks for a description of this flag, the description will be printed. - -A flag can be marked as _required_ so that an error is automatically thrown if the user does not provide a value: - -```go -cmd.MarkFlagRequired(FlagFrom) -``` - -Since `AddTxFlagsToCmd(cmd *cobra.Command)` includes all of the basic flags required for a transaction command, module developers may choose not to add any of their own (specifying arguments instead may often be more appropriate). - -Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command. - -## gRPC - -[gRPC](https://grpc.io/) is the prefered way for external clients like wallets and exchanges to interact with a node. - -In addition to providing an ABCI query pathway, modules [custom queries](./messages-and-queries.md#grpc-queries) can provide a GRPC proxy server that routes requests in the GRPC protocol to ABCI query requests under the hood. - -In order to do that, module should implement `RegisterGRPCGatewayRoutes(clientCtx client.Context, mux *runtime.ServeMux)` on `AppModuleBasic` to wire the client gRPC requests to the correct handler inside the module. - -Here's an example from the `auth` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/module.go#L69-L72 - -## gRPC-gateway REST - -Applications typically support web services that use HTTP requests (e.g. a web wallet like [Lunie.io](https://lunie.io). Thus, application developers can also use REST Routes to route HTTP requests to the application's modules; these routes will be used by service providers. - -[grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) translates REST calls into gRPC calls, which might be useful for clients that do not use gRPC. - -Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods, such as in the example below from the `auth` module: - -```proto -// Query defines the gRPC querier service. -service Query{ - // Account returns account details based on address. - rpc Account (QueryAccountRequest) returns (QueryAccountResponse) { - option (google.api.http).get = "/lbm/auth/v1beta1/accounts/{address}"; - } - - // Params queries all parameters. - rpc Params (QueryParamsRequest) returns (QueryParamsResponse) { - option (google.api.http).get = "/lbm/auth/v1beta1/params"; - } -} -``` - -gRPC gateway is started in-process along with the application and Tendermint. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). - -The SDK provides a command for generating [Swagger](https://swagger.io/) documentation (`protoc-gen-swagger`). Setting `swagger` in [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) defines if swagger documentation should be automatically registered. - -## Legacy REST - -Legacy REST endpoints will be deprecated. But developers may choose to keep using legacy REST endpoints for backward compatibility, although the recommended way is to use [gRPC](#grpc) and [gRPC-gateway](#grpc-gateway-rest). - -With this implementation, module developers need to define the REST client by defining [routes](#register-routes) for all possible [requests](#request-types) and [handlers](#request-handlers) for each of them. It's up to the module developer how to organize the REST interface files; there is typically a `rest.go` file found in the module's `./x/moduleName/client/rest` folder. - -To support HTTP requests, the module developer needs to define possible request types, how to handle them, and provide a way to register them with a provided router. - -### Request Types - -Request types, which define structured interactions from users, must be defined for all _transaction_ requests. Users using this method to interact with an application will send HTTP Requests with the required fields in order to trigger state changes in the application. Conventionally, each request is named with the suffix `Req`, e.g. `SendReq` for a Send transaction. Each struct should include a base request [`baseReq`](../interfaces/rest.md#basereq), the name of the transaction, and all the arguments the user must provide for the transaction. - -Here is an example of a request to send coins from the `bank` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/7f59723d889b69ca19966167f0b3a7fec7a39e53/x/bank/client/rest/tx.go#L15-L19 - -The `BaseReq` includes basic information that every request needs to have, similar to required flags in a CLI. All of these values, including `GasPrices` and `AccountNumber`, will be provided in the request body. The user will also need to specify the argument `Amount` fields in the body. - -#### BaseReq - -`BaseReq` is a type defined in the SDK that encapsulates much of the transaction configurations similar to CLI command flags. Users must provide the information in the body of their requests. - -- `From` indicates which [account](../basics/accounts.md) the transaction originates from. This account is used to sign the transaction. -- `Memo` sends a memo along with the transaction. -- `ChainID` specifies the unique identifier of the blockchain the transaction pertains to. -- `AccountNumber` is an identifier for the account. -- `Sequence`is the value of a counter measuring how many transactions have been sent from the account. It is used to prevent replay attacks. -- `TimeoutHeight` allows a transaction to be rejected if it's committed at a height greater than the timeout. -- `Gas` refers to how much [gas](../basics/gas-fees.md), which represents computational resources, Tx consumes. Gas is dependent on the transaction and is not precisely calculated until execution, but can be estimated by providing auto as the value for `Gas`. -- `GasAdjustment` can be used to scale gas up in order to avoid underestimating. For example, users can specify their gas adjustment as 1.5 to use 1.5 times the estimated gas. -- `GasPrices` specifies how much the user is willing pay per unit of gas, which can be one or multiple denominations of tokens. For example, --gas-prices=0.025uatom, 0.025upho means the user is willing to pay 0.025uatom AND 0.025upho per unit of gas. -- `Fees` specifies how much in [fees](../basics/gas-fees.md) the user is willing to pay in total. Note that the user only needs to provide either `gas-prices` or `fees`, but not both, because they can be derived from each other. -- `Simulate` instructs the application to ignore gas and simulate the transaction running without broadcasting. - -### Request Handlers - -Request handlers must be defined for both transaction and query requests. Handlers' arguments include a reference to the [client `Context`](../interfaces/query-lifecycle.md#context). - -Here is an example of a request handler for the `bank` module `SendReq` request (the same one shown above): - -+++ https://github.com/cosmos/cosmos-sdk/blob/7f59723d889b69ca19966167f0b3a7fec7a39e53/x/bank/client/rest/tx.go#L21-L51 - -The request handler can be broken down as follows: - -- **Parse Request:** First, it tries to parse the argument `address` into a `AccountAddress`. Then, the request handler attempts to parse the request, and then run `Sanitize` and `ValidateBasic` on the underlying `BaseReq` to check the validity of the request. Finally, it attempts to parse `BaseReq.From` to the type `AccountAddress`. -- **Message:** Then, a [message](./messages-and-queries.md#messages) of the type `MsgSend` (defined by the module developer to trigger the state changes for this transaction) is created from the values. -- **Generate Transaction:** Finally, the HTTP `ResponseWriter`, client `Context`, request [`BaseReq`](../interfaces/rest.md#basereq), and message is passed to `WriteGeneratedTxResponse` to further process the request. - -To read more about how a transaction is generated, visit the transactions documentation [here](../core/transactions.md#transaction-generation). - -### Register Routes - -The application CLI entrypoint will have a `RegisterRoutes` function in its `main.go` file, which calls the `registerRoutes` functions of each module utilized by the application. Module developers need to implement `registerRoutes` for their modules so that applications are able to route messages and queries to their corresponding handlers and queriers. - -The router used by the SDK is [Gorilla Mux](https://github.com/gorilla/mux). The router is initialized with the Gorilla Mux `NewRouter()` function. Then, the router's `HandleFunc` function can then be used to route urls with the defined request handlers and the HTTP method (e.g. "POST", "GET") as a route matcher. It is recommended to prefix every route with the name of the module to avoid collisions with other modules that have the same query or transaction names. - -Here is a `registerRoutes` function with one query route example from the [nameservice tutorial](https://cosmos.network/docs/tutorial/rest.html): - -```go -func RegisterRoutes(cliCtx client.Context, r *mux.Router, cdc *codec.LegacyAmino, storeName string) { - // ResolveName Query - r.HandleFunc(fmt.Sprintf("/%s/names/{%s}", storeName, restName), resolveNameHandler(cdc, cliCtx, storeName)).Methods("GET") -} -``` - -A few things to note: - -- The router `r` has already been initialized by the application and is passed in here as an argument - this function is able to add on the nameservice module's routes onto any application's router. The application must also provide a [`Context`](../interfaces/query-lifecycle.md#context) that the querier will need to process user requests and the application [`codec`](../core/encoding.md) for encoding and decoding application-specific types. -- `"/%s/names/{%s}", storeName, restName` is the url for the HTTP request. `storeName` is the name of the module, `restName` is a variable provided by the user to specify what kind of query they are making. -- `resolveNameHandler` is the query request handler defined by the module developer. It also takes the application `codec` and `Context` passed in from the user side, as well as the `storeName`. -- `"GET"` is the HTTP Request method. As to be expected, queries are typically GET requests. Transactions are typically POST and PUT requests. - -## Next {hide} - -Read about the recommended [module structure](./structure.md) {hide} diff --git a/docs/building-modules/module-manager.md b/docs/building-modules/module-manager.md deleted file mode 100644 index 919ec1425c..0000000000 --- a/docs/building-modules/module-manager.md +++ /dev/null @@ -1,151 +0,0 @@ - - -# Module Manager - -Cosmos SDK modules need to implement the [`AppModule` interfaces](#application-module-interfaces), in order to be managed by the application's [module manager](#module-manager). The module manager plays an important role in [`message` and `query` routing](../core/baseapp.md#routing), and allows application developers to set the order of execution of a variety of functions like [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker). {synopsis} - -## Pre-requisite Readings - -- [Introduction to SDK Modules](./intro.md) {prereq} - -## Application Module Interfaces - -Application module interfaces exist to facilitate the composition of modules together to form a functional SDK application. There are 3 main application module interfaces: - -- [`AppModuleBasic`](#appmodulebasic) for independent module functionalities. -- [`AppModule`](#appmodule) for inter-dependent module functionalities (except genesis-related functionalities). -- [`AppModuleGenesis`](#appmodulegenesis) for inter-dependent genesis-related module functionalities. - -The `AppModuleBasic` interface exists to define independent methods of the module, i.e. those that do not depend on other modules in the application. This allows for the construction of the basic application structure early in the application definition, generally in the `init()` function of the [main application file](../basics/app-anatomy.md#core-application-file). - -The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interract with other modules, typically through [`keeper`s](./keeper.md), which means there is a need for an interface where modules list their `keeper`s and other methods that require a reference to another module's object. `AppModule` interface also enables the module manager to set the order of execution between module's methods like `BeginBlock` and `EndBlock`, which is important in cases where the order of execution between modules matters in the context of the application. - -Lastly the interface for genesis functionality `AppModuleGenesis` is separated out from full module functionality `AppModule` so that modules which -are only used for genesis can take advantage of the `Module` patterns without having to define many placeholder functions. - -### `AppModuleBasic` - -The `AppModuleBasic` interface defines the independent methods modules need to implement. - -+++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L49-L63 - -Let us go through the methods: - -- `Name()`: Returns the name of the module as a `string`. -- `RegisterLegacyAminoCodec(*codec.LegacyAmino)`: Registers the `amino` codec for the module, which is used to marshal and unmarshal structs to/from `[]byte` in order to persist them in the module's `KVStore`. -- `RegisterInterfaces(codectypes.InterfaceRegistry)`: Registers a module's interface types and their concrete implementations as `proto.Message`. -- `DefaultGenesis(codec.JSONMarshaler)`: Returns a default [`GenesisState`](./genesis.md#genesisstate) for the module, marshalled to `json.RawMessage`. The default `GenesisState` need to be defined by the module developer and is primarily used for testing. -- `ValidateGenesis(codec.JSONMarshaler, client.TxEncodingConfig, json.RawMessage)`: Used to validate the `GenesisState` defined by a module, given in its `json.RawMessage` form. It will usually unmarshall the `json` before running a custom [`ValidateGenesis`](./genesis.md#validategenesis) function defined by the module developer. -- `RegisterRESTRoutes(client.Context, *mux.Router)`: Registers the REST routes for the module. These routes will be used to map REST request to the module in order to process them. See [../interfaces/rest.md] for more. -- `RegisterGRPCGatewayRoutes(client.Context, *runtime.ServeMux)`: Registers gRPC routes for the module. -- `GetTxCmd()`: Returns the root [`Tx` command](./module-interfaces.md#tx) for the module. The subcommands of this root command are used by end-users to generate new transactions containing [`message`s](./messages-and-queries.md#queries) defined in the module. -- `GetQueryCmd()`: Return the root [`query` command](./module-interfaces.md#query) for the module. The subcommands of this root command are used by end-users to generate new queries to the subset of the state defined by the module. - -All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#basicmanager). - -### `AppModuleGenesis` - -The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` interface with two added methods. - -+++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L152-L158 - -Let us go through the two added methods: - -- `InitGenesis(sdk.Context, codec.JSONMarshaler, json.RawMessage)`: Initializes the subset of the state managed by the module. It is called at genesis (i.e. when the chain is first started). -- `ExportGenesis(sdk.Context, codec.JSONMarshaler)`: Exports the latest subset of the state managed by the module to be used in a new genesis file. `ExportGenesis` is called for each module when a new chain is started from the state of an existing chain. - -It does not have its own manager, and exists separately from [`AppModule`](#appmodule) only for modules that exist only to implement genesis functionalities, so that they can be managed without having to implement all of `AppModule`'s methods. If the module is not only used during genesis, `InitGenesis(sdk.Context, codec.JSONMarshaler, json.RawMessage)` and `ExportGenesis(sdk.Context, codec.JSONMarshaler)` will generally be defined as methods of the concrete type implementing hte `AppModule` interface. - -### `AppModule` - -The `AppModule` interface defines the inter-dependent methods modules need to implement. - -+++ https://github.com/cosmos/cosmos-sdk/blob/b4cce159bcc6a32ac78245c6866dd87c73f3720d/types/module/module.go#L160-L182 - -`AppModule`s are managed by the [module manager](#manager). This interface embeds the `AppModuleGenesis` interface so that the manager can access all the independent and genesis inter-dependent methods of the module. This means that a concrete type implementing the `AppModule` interface must either implement all the methods of `AppModuleGenesis` (and by extension `AppModuleBasic`), or include a concrete type that does as parameter. - -Let us go through the methods of `AppModule`: - -- `RegisterInvariants(sdk.InvariantRegistry)`: Registers the [`invariants`](./invariants.md) of the module. If the invariants deviates from its predicted value, the [`InvariantRegistry`](./invariants.md#registry) triggers appropriate logic (most often the chain will be halted). -- `Route()`: Returns the route for [`message`s](./messages-and-queries.md#messages) to be routed to the module by [`BaseApp`](../core/baseapp.md#message-routing). -- `QuerierRoute()` (deprecated): Returns the name of the module's query route, for [`queries`](./messages-and-queries.md#queries) to be routes to the module by [`BaseApp`](../core/baseapp.md#query-routing). -- `LegacyQuerierHandler(*codec.LegacyAmino)` (deprecated): Returns a [`querier`](./query-services.md#legacy-queriers) given the query `path`, in order to process the `query`. -- `RegisterServices(Configurator)`: Allows a module to register services. -- `BeginBlock(sdk.Context, abci.RequestBeginBlock)`: This method gives module developers the option to implement logic that is automatically triggered at the beginning of each block. Implement empty if no logic needs to be triggered at the beginning of each block for this module. -- `EndBlock(sdk.Context, abci.RequestEndBlock)`: This method gives module developers the option to implement logic that is automatically triggered at the end of each block. This is also where the module can inform the underlying consensus engine of validator set changes (e.g. the `staking` module). Implement empty if no logic needs to be triggered at the end of each block for this module. - - -### Implementing the Application Module Interfaces - -Typically, the various application module interfaces are implemented in a file called `module.go`, located in the module's folder (e.g. `./x/module/module.go`). - -Almost every module needs to implement the `AppModuleBasic` and `AppModule` interfaces. If the module is only used for genesis, it will implement `AppModuleGenesis` instead of `AppModule`. The concrete type that implements the interface can add parameters that are required for the implementation of the various methods of the interface. For example, the `Route()` function often calls a `NewHandler(k keeper)` function defined in [`handler.go`](./msg-services.md#handler-type) and therefore needs to pass the module's [`keeper`](./keeper.md) as a parameter. - -```go -// example -type AppModule struct { - AppModuleBasic - keeper Keeper -} -``` - -In the example above, you can see that the `AppModule` concrete type references an `AppModuleBasic`, and not an `AppModuleGenesis`. That is because `AppModuleGenesis` only needs to be implemented in modules that focus on genesis-related functionalities. In most modules, the concrete `AppModule` type will have a reference to an `AppModuleBasic` and implement the two added methods of `AppModuleGenesis` directly in the `AppModule` type. - -If no parameter is required (which is often the case for `AppModuleBasic`), just declare an empty concrete type like so: - -```go -type AppModuleBasic struct{} -``` - -## Module Managers - -Module managers are used to manage collections of `AppModuleBasic` and `AppModule`. - -### `BasicManager` - -The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application: - -+++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L65-L66 - -It implements the following methods: - -- `NewBasicManager(modules ...AppModuleBasic)`: Constructor function. It takes a list of the application's `AppModuleBasic` and builds a new `BasicManager`. This function is generally called in the `init()` function of [`app.go`](../basics/app-anatomy.md#core-application-file) to quickly initialize the independent elements of the application's modules (click [here](https://github.com/cosmos/gaia/blob/master/app/app.go#L59-L74) to see an example). -- `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`: Registers the [`codec.LegacyAmino`s](../core/encoding.md#amino) of each of the application's `AppModuleBasic`. This function is usually called early on in the [application's construction](../basics/app-anatomy.md#constructor). -- `RegisterInterfaces(registry codectypes.InterfaceRegistry)`: Registers interface types and implementations of each of the application's `AppModuleBasic`. -- `DefaultGenesis(cdc codec.JSONMarshaler)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONMarshaler)`](./genesis.md#defaultgenesis) function of each module. It is used to construct a default genesis file for the application. -- `ValidateGenesis(cdc codec.JSONMarshaler, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONMarshaler, client.TxEncodingConfig, json.RawMessage)`](./genesis.md#validategenesis) function of each module. -- `RegisterRESTRoutes(ctx client.Context, rtr *mux.Router)`: Registers REST routes for modules by calling the [`RegisterRESTRoutes`](./module-interfaces.md#register-routes) function of each module. This function is usually called function from the `main.go` function of the [application's command-line interface](../interfaces/cli.md). -- `RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux)`: Registers gRPC routes for modules. -- `AddTxCommands(rootTxCmd *cobra.Command)`: Adds modules' transaction commands to the application's [`rootTxCommand`](../interfaces/cli.md#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](../interfaces/cli.md). -- `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands to the application's [`rootQueryCommand`](../interfaces/cli.md#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](../interfaces/cli.md). - -### `Manager` - -The `Manager` is a structure that holds all the `AppModule` of an application, and defines the order of execution between several key components of these modules: - -+++ https://github.com/cosmos/cosmos-sdk/blob/325be6ff215db457c6fc7668109640cd7fdac461/types/module/module.go#L223-L231 - -The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods: - -- `NewManager(modules ...AppModule)`: Constructor function. It takes a list of the application's `AppModule`s and builds a new `Manager`. It is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). -- `SetOrderInitGenesis(moduleNames ...string)`: Sets the order in which the [`InitGenesis`](./genesis.md#initgenesis) function of each module will be called when the application is first started. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). -- `SetOrderExportGenesis(moduleNames ...string)`: Sets the order in which the [`ExportGenesis`](./genesis.md#exportgenesis) function of each module will be called in case of an export. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). -- `SetOrderBeginBlockers(moduleNames ...string)`: Sets the order in which the `BeginBlock()` function of each module will be called at the beginning of each block. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). -- `SetOrderEndBlockers(moduleNames ...string)`: Sets the order in which the `EndBlock()` function of each module will be called at the end of each block. This function is generally called from the application's main [constructor function](../basics/app-anatomy.md#constructor-function). -- `RegisterInvariants(ir sdk.InvariantRegistry)`: Registers the [invariants](./invariants.md) of each module. -- `RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino)`: Registers legacy [`Msg`](./messages-and-queries.md#messages) and [`querier`](./query-services.md#legacy-queriers) routes. -- `RegisterServices(cfg Configurator)`: Registers all module services. -- `InitGenesis(ctx sdk.Context, cdc codec.JSONMarshaler, genesisData map[string]json.RawMessage)`: Calls the [`InitGenesis`](./genesis.md#initgenesis) function of each module when the application is first started, in the order defined in `OrderInitGenesis`. Returns an `abci.ResponseInitChain` to the underlying consensus engine, which can contain validator updates. -- `ExportGenesis(ctx sdk.Context, cdc codec.JSONMarshaler)`: Calls the [`ExportGenesis`](./genesis.md#exportgenesis) function of each module, in the order defined in `OrderExportGenesis`. The export constructs a genesis file from a previously existing state, and is mainly used when a hard-fork upgrade of the chain is required. -- `BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock)`: At the beginning of each block, this function is called from [`BaseApp`](../core/baseapp.md#beginblock) and, in turn, calls the [`BeginBlock`](./beginblock-endblock.md) function of each module, in the order defined in `OrderBeginBlockers`. It creates a child [context](../core/context.md) with an event manager to aggregate [events](../core/events.md) emitted from all modules. The function returns an `abci.ResponseBeginBlock` which contains the aforementioned events. -- `EndBlock(ctx sdk.Context, req abci.RequestEndBlock)`: At the end of each block, this function is called from [`BaseApp`](../core/baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./beginblock-endblock.md) function of each module, in the order defined in `OrderEndBlockers`. It creates a child [context](../core/context.md) with an event manager to aggregate [events](../core/events.md) emitted from all modules. The function returns an `abci.ResponseEndBlock` which contains the aforementioned events, as well as validator set updates (if any). - -Here's an example of a concrete integration within an application: - -+++ https://github.com/cosmos/cosmos-sdk/blob/2323f1ac0e9a69a0da6b43693061036134193464/simapp/app.go#L315-L362 - -## Next {hide} - -Learn more about [`message`s and `queries`](./messages-and-queries.md) {hide} diff --git a/docs/building-modules/msg-services.md b/docs/building-modules/msg-services.md deleted file mode 100644 index 868d74b4a2..0000000000 --- a/docs/building-modules/msg-services.md +++ /dev/null @@ -1,101 +0,0 @@ - -# `Msg` Services - -A `Msg` Service processes [messages](./messages-and-queries.md#messages). `Msg` Services are specific to the module in which they are defined, and only process messages defined within the said module. They are called from `BaseApp` during [`DeliverTx`](../core/baseapp.md#delivertx). {synopsis} - -## Pre-requisite Readings - -- [Module Manager](./module-manager.md) {prereq} -- [Messages and Queries](./messages-and-queries.md) {prereq} - -## Implementation of a module `Msg` service - -All `Msg` processing is done by a [`Msg`](messages-and-queries.md#msg-services) protobuf service. Each module should define a `Msg` service, which will be responsible for request and response serialization. - -As further described in [ADR 031](../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code. - -Based on the definition of the `Msg` service, Protobuf generates a `MsgServer` interface. It is the role of the module developer to implement this interface, by implementing the state transition logic that should happen upon receival of each `Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `Msg`s: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/bank/types/tx.pb.go#L285-L291 - -When possible, the existing module's [`Keeper`](keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/bank/keeper/msg_server.go#L14-L16 - -`msgServer` methods can retrieve the `sdk.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/bank/keeper/msg_server.go#L27 - -`Msg` processing usually follows these 2 steps: - -- First, they perform *stateful* checks to make sure the `message` is valid. At this stage, the `message`'s `ValidateBasic()` method has already been called, meaning *stateless* checks on the message (like making sure parameters are correctly formatted) have already been performed. Checks performed in the `msgServer` method can be more expensive and require access to the state. For example, a `msgServer` method for a `transfer` message might check that the sending account has enough funds to actually perform the transfer. To access the state, the `msgServer` method needs to call the [`keeper`'s](./keeper.md) getter functions. -- Then, if the checks are successful, the `msgServer` method calls the [`keeper`'s](./keeper.md) setter functions to actually perform the state transition. - -Before returning, `msgServer` methods generally emit one or more [events](../core/events.md) via the `EventManager` held in the `ctx`: - -```go -ctx.EventManager().EmitEvent( - sdk.NewEvent( - eventType, // e.g. sdk.EventTypeMessage for a message, types.CustomEventType for a custom event defined in the module - sdk.NewAttribute(attributeKey, attributeValue), - ), - ) -``` - -These events are relayed back to the underlying consensus engine and can be used by service providers to implement services around the application. Click [here](../core/events.md) to learn more about events. - -The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error` using `sdk.WrapServiceResult(ctx sdk.Context, res proto.Message, err error)`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc2/baseapp/msg_service_router.go#L104 - -This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/proto/cosmos/base/abci/v1beta1/abci.proto#L81-L95 - -## Legacy Amino `Msg`s - -### `handler` type - -The `handler` type defined in the Cosmos SDK will be deprecated in favor of [`Msg` Services](#implementation-of-a-module-msg-service). - -Here is the typical structure of a `handler` function: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc2/types/handler.go#L4 - -Let us break it down: - -- The [`Msg`](./messages-and-queries.md#messages) is the actual object being processed. -- The [`Context`](../core/context.md) contains all the necessary information needed to process the `msg`, as well as a branch of the latest state. If the `msg` is successfully processed, the branched version of the state contained in the `ctx` will be written to the main state (branch). -- The [`*Result`] returned to `BaseApp` contains (among other things) information on the execution of the `handler` and [events](../core/events.md). - -Module `handler`s are typically implemented in a `./handler.go` file inside the module's folder. The [module manager](./module-manager.md) is used to add the module's `handler`s to the -[application's `router`](../core/baseapp.md#message-routing) via the `Route()` method. Typically, -the manager's `Route()` method simply constructs a Route that calls a `NewHandler()` method defined in `handler.go`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/228728cce2af8d494c8b4e996d011492139b04ab/x/gov/module.go#L143-L146 - -### Implementation - -`NewHandler` function dispatches a `Msg` to appropriate handler function, usually by using a switch statement: - -+++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/x/bank/handler.go#L13-L29 - -First, `NewHandler` function sets a new `EventManager` to the context to isolate events per `msg`. -Then, a simple switch calls the appropriate `handler` based on the `Msg` type. - -In this regard, `handler`s functions need to be implemented for each module `Msg`. This will also involve manual handler registration of `Msg` types. -`handler`s functions should return a `*Result` and an `error`. - -## Telemetry - -New [telemetry metrics](../core/telemetry.md) can be created from `msgServer` methods when handling messages. - -This is an example from the `x/auth/vesting` module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/auth/vesting/msg_server.go#L73-L85 - -## Next {hide} - -Learn about [query services](./query-services.md) {hide} diff --git a/docs/building-modules/query-services.md b/docs/building-modules/query-services.md deleted file mode 100644 index e9f7f8c77d..0000000000 --- a/docs/building-modules/query-services.md +++ /dev/null @@ -1,77 +0,0 @@ - - -# Query Services - -A query service processes [`queries`](./messages-and-queries.md#queries). Query services are specific to the module in which they are defined, and only process `queries` defined within said module. They are called from `BaseApp`'s [`Query` method](../core/baseapp.md#query). {synopsis} - -## Pre-requisite Readings - -- [Module Manager](./module-manager.md) {prereq} -- [Messages and Queries](./messages-and-queries.md) {prereq} - -## `Querier` type - -The `querier` type defined in the Cosmos SDK will be deprecated in favor of [gRPC Services](#grpc-service). It specifies the typical structure of a `querier` function: - -+++ https://github.com/cosmos/cosmos-sdk/blob/9a183ffbcc0163c8deb71c7fd5f8089a83e58f05/types/queryable.go#L9 - -Let us break it down: - -- The `path` is an array of `string`s that contains the type of the query, and that can also contain `query` arguments. See [`queries`](./messages-and-queries.md#queries) for more information. -- The `req` itself is primarily used to retrieve arguments if they are too large to fit in the `path`. This is done using the `Data` field of `req`. -- The [`Context`](../core/context.md) contains all the necessary information needed to process the `query`, as well as a branch of the latest state. It is primarily used by the [`keeper`](./keeper.md) to access the state. -- The result `res` returned to `BaseApp`, marshalled using the application's [`codec`](../core/encoding.md). - -## Implementation of a module query service - -### gRPC Service - -When defining a Protobuf `Query` service, a `QueryServer` interface is generated for each module with all the service methods: - -```go -type QueryServer interface { - QueryBalance(context.Context, *QueryBalanceParams) (*types.Coin, error) - QueryAllBalances(context.Context, *QueryAllBalancesParams) (*QueryAllBalancesResponse, error) -} -``` - -These custom queries methods should be implemented by a module's keeper, typically in `./keeper/grpc_query.go`. The first parameter of these methods is a generic `context.Context`, whereas querier methods generally need an instance of `sdk.Context` to read -from the store. Therefore, the SDK provides a function `sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided -`context.Context`. - -Here's an example implementation for the bank module: - -+++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/x/bank/keeper/grpc_query.go - -### Legacy Queriers - -Module legacy `querier`s are typically implemented in a `./keeper/querier.go` file inside the module's folder. The [module manager](./module-manager.md) is used to add the module's `querier`s to the [application's `queryRouter`](../core/baseapp.md#query-routing) via the `NewQuerier()` method. Typically, the manager's `NewQuerier()` method simply calls a `NewQuerier()` method defined in `keeper/querier.go`, which looks like the following: - -```go -func NewQuerier(keeper Keeper) sdk.Querier { - return func(ctx sdk.Context, path []string, req abci.RequestQuery) ([]byte, error) { - switch path[0] { - case QueryType1: - return queryType1(ctx, path[1:], req, keeper) - - case QueryType2: - return queryType2(ctx, path[1:], req, keeper) - - default: - return nil, sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "unknown %s query endpoint: %s", types.ModuleName, path[0]) - } - } -} -``` - -This simple switch returns a `querier` function specific to the type of the received `query`. At this point of the [query lifecycle](../interfaces/query-lifecycle.md), the first element of the `path` (`path[0]`) contains the type of the query. The following elements are either empty or contain arguments needed to process the query. - -The `querier` functions themselves are pretty straighforward. They generally fetch a value or values from the state using the [`keeper`](./keeper.md). Then, they marshall the value(s) using the [`codec`](../core/encoding.md) and return the `[]byte` obtained as result. - -For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/7f59723d889b69ca19966167f0b3a7fec7a39e53/x/gov/keeper/querier.go) from the bank module. - -## Next {hide} - -Learn about [`BeginBlocker` and `EndBlocker`](./beginblock-endblock.md) {hide} diff --git a/docs/building-modules/simulator.md b/docs/building-modules/simulator.md deleted file mode 100644 index bd53017256..0000000000 --- a/docs/building-modules/simulator.md +++ /dev/null @@ -1,123 +0,0 @@ -# Module Simulation - -## Prerequisites - -* [Cosmos Blockchain Simulator](./../using-the-sdk/simulation.md) - -## Synopsis - -This document details how to define each module simulation functions to be -integrated with the application `SimulationManager`. - -* [Simulation package](#simulation-package) - * [Store decoders](#store-decoders) - * [Randomized genesis](#randomized-genesis) - * [Randomized parameters](#randomized-parameters) - * [Random weighted operations](#random-weighted-operations) - * [Random proposal contents](#random-proposal-contents) -* [Registering the module simulation functions](#registering-simulation-functions) -* [App simulator manager](#app-simulator-manager) -* [Simulation tests](#simulation-tests) - -## Simulation package - -Every module that implements the SDK simulator needs to have a `x//simulation` -package which contains the primary functions required by the fuzz tests: store -decoders, randomized genesis state and parameters, weighted operations and proposal -contents. - -### Store decoders - -Registering the store decoders is required for the `AppImportExport`. This allows -for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled) -to their corresponding types. In particular, it matches the key to a concrete type -and then unmarshals the value from the `KVPair` to the type provided. - -You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/release%2Fv0.38.0/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. - -### Randomized genesis - -The simulator tests different scenarios and values for genesis parameters -in order to fully test the edge cases of specific modules. The `simulator` package from each module must expose a `RandomizedGenState` function to generate the initial random `GenesisState` from a given seed. - -Once the module genesis parameter are generated randomly (or with the key and -values defined in a `params` file), they are marshaled to JSON format and added -to the app genesis JSON to use it on the simulations. - -You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/release%2Fv0.38.0/x/staking/simulation/genesis.go). - -### Randomized parameter changes - -The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan. - -You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/release%2Fv0.38.0/x/staking/simulation/params.go) - -### Random weighted operations - -Operations are one of the crucial parts of the SDK simulation. They are the transactions -(`Msg`) that are simulated with random field values. The sender of the operation -is also assigned randomly. - -Operations on the simulation are simulated using the full [transaction cycle](../core/transactions.md) of a -`ABCI` application that exposes the `BaseApp`. - -Shown below is how weights are set: - -+++ https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/simulation/operations.go#L18 - -As you can see the weights are predefined in this case but there are options on how to override this behavior with different weights. One is allowing `*rand.Rand` to define a random weight for the operation, or you can inject your own predefined weights. - -Here is how one can override the above package `simappparams`. - -+++ https://github.com/cosmos/gaia/blob/master/sims.mk#L9-L22 - -For the last test a tool called runsim is used, this is used to parallelize go test instances, provide info to Github and slack integrations to provide information to your team on how the simulations are running. - -### Random proposal contents - -Randomized governance proposals are also supported on the SDK simulator. Each -module must define the governance proposal `Content`s that they expose and register -them to be used on the parameters. - -## Registering simulation functions - -Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/master/x/distribution/module.go - -## App Simulator manager - -The following step is setting up the `SimulatorManager` at the app level. This -is required for the simulation test files on the next step. - -```go -type CustomApp struct { - ... - sm *module.SimulationManager -} -``` - -Then at the instantiation of the application, we create the `SimulationManager` -instance in the same way we create the `ModuleManager` but this time we only pass -the modules that implement the simulation functions from the `AppModuleSimulation` -interface described above. - -```go -func NewCustomApp(...) { - // create the simulation manager and define the order of the modules for deterministic simulations - app.sm = module.NewSimulationManager( - auth.NewAppModule(app.accountKeeper), - bank.NewAppModule(app.bankKeeper, app.accountKeeper), - supply.NewAppModule(app.supplyKeeper, app.accountKeeper), - ov.NewAppModule(app.govKeeper, app.accountKeeper, app.supplyKeeper), - mint.NewAppModule(app.mintKeeper), - distr.NewAppModule(app.distrKeeper, app.accountKeeper, app.supplyKeeper, app.stakingKeeper), - staking.NewAppModule(app.stakingKeeper, app.accountKeeper, app.supplyKeeper), - slashing.NewAppModule(app.slashingKeeper, app.accountKeeper, app.stakingKeeper), - ) - - // register the store decoders for simulation tests - app.sm.RegisterStoreDecoders() - ... -} -``` diff --git a/docs/building-modules/structure.md b/docs/building-modules/structure.md deleted file mode 100644 index 79c353a2ce..0000000000 --- a/docs/building-modules/structure.md +++ /dev/null @@ -1,84 +0,0 @@ - - -# Recommended Folder Structure - -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. {synopsis} - -## Structure - -A typical Cosmos SDK module can be structured as follows: - -```shell -x/{module} -├── client -│   ├── cli -│   │ ├── query.go -│   │   └── tx.go -│   └── rest -│   ├── query.go -│   └── tx.go -├── exported -│   └── exported.go -├── keeper -│   ├── invariants.go -│   ├── genesis.go -│   ├── keeper.go -│   ├── msg_server.go -│   ├── ... -│   └── querier.go -│   └── grpc_query.go -├── types -│ ├── codec.go -│ ├── errors.go -│ ├── events.go -│ ├── expected_keepers.go -│ ├── genesis.go -│ ├── keys.go -│ ├── msgs.go -│ ├── params.go -│ ├── types.proto -│ ├── ... -│ └── querier.go -│ └── {module_name}.pb.go -│ └── query.pb.go -│ └── genesis.pb.go -├── simulation -│   ├── decoder.go -│   ├── genesis.go -│   ├── operations.go -│   ├── params.go -│   └── proposals.go -├── abci.go -├── handler.go -├── ... -└── module.go -``` - -- `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (if any). -- `client/`: The module's CLI and REST client functionality implementation and -testing. -- `exported/`: The module's exported types -- typically type interfaces. If a module -relies on other module keepers, it is expected to receive them as interface -contracts through the `expected_keepers.go` (which are detailed below) design to -avoid having a direct dependency on the implementing module. However, these -contracts can define methods that operate on and/or return types that are specific -to the contract's implementing module and this is where `exported/` comes into play. -Types defined here allow for `expected_keepers.go` in other modules to define -contracts that use single canonical types. This pattern allows for code to remain -DRY and also alleviates import cycle chaos. -- `handler.go`: The module's message handlers. -- `keeper/`: The module's keeper implementation along with any auxiliary -implementations such as the querier and invariants. -- `types/`: The module's type definitions such as messages, `KVStore` keys, -parameter types, Protocol Buffer definitions, and `expected_keepers.go` contracts. -- `module.go`: The module's implementation of the `AppModule` and `AppModuleBasic` -interfaces. -- `simulation/`: The module's simulation package defines all the required functions -used on the blockchain simulator: randomized genesis state, parameters, weighted -operations, proposal contents and types decoders. - -## Next {hide} - -Learn about [Errors](./errors.md) {hide} diff --git a/docs/cn/README.md b/docs/cn/README.md deleted file mode 100644 index dd30ed000a..0000000000 --- a/docs/cn/README.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -parent: - order: false ---- - -# Cosmos SDK 文档 - -## 开始 - -- **[SDK 介绍](./intro/README.md)**：Cosmos SDK 的总体概览 -- **[快速开始](./using-the-sdk/quick-start.md)**：构建一个标准的基于 cosmos sdk 的 app 并启动节点 -- **[SDK 开发教程](https://github.com/cosmos/sdk-application-tutorial)**: 一个学习 SDK 的教程。它展示了如何从头开始基于 sdk 构建区块链, 并在此过程中解释了 SDK 的基本原理。 - -## 索引 - -- **[基础文档](./basics/)**：cosmos sdk 的基础概念文档，例如应用结构、交易的生命周期、账户管理等 -- **[核心文档](./core/)**: cosmos sdk 的核心文档，例如`baseapp`，`store`，`server`等 -- **[构建模块](./building-modules/)**: 对于模块开发者来说的一些重要概念，例如`message`，`keeper`，`handler`，`querier` -- **[接口](./interfaces/)**: 为 cosmos 应用设计接口的文档 - -## 开发资源 - -- **[模块目录](../../x/)**：模块的实现和文档 -- **[规范](./spec/):** Cosmos SDK 的模块及其他规范。 -- **[SDK API 参考](https://godoc.org/github.com/cosmos/cosmos-sdk):** Cosmos SDK Godocs 文档 。 -- **[REST API 规范](https://cosmos.network/rpc/):** 通过 REST 与 `gaia` 全节点交互的 API 列表。 - -## Cosmos Hub - -Cosmos Hub (名为 `gaia`) 文档已经迁移到[这里](https://github.com/cosmos/gaia/tree/master/docs). - -## 开发语言 - -Cosmos-SDK 目前是用 [Golang](https://golang.org/)编写的, 尽管该框架同样可以在其他语言中实现。请联系我们获取有关资助其他语言实现的信息。 - -## 贡献 - -参考 [文档说明](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md) 了解构建细节及更新时注意事项。 diff --git a/docs/cn/basics/README.md b/docs/cn/basics/README.md deleted file mode 100644 index 5e1ea98ed4..0000000000 --- a/docs/cn/basics/README.md +++ /dev/null @@ -1,10 +0,0 @@ -# 基础文档 - -此目录包含对 cosmos sdk 的基础概念介绍 - -1. [SDK 应用解析](./app-anatomy.md) -2. [交易的生命周期](./tx-lifecycle.md) -3. [账户系统](./accounts.md) -4. [Gas 和 Fees](./gas-fees.md) - -阅读完基础文档后，可以阅读 [核心文档](../core/README.md) 进一步加深对 cosmos 的理解。 diff --git a/docs/cn/basics/accounts.md b/docs/cn/basics/accounts.md deleted file mode 100644 index c37e45aa69..0000000000 --- a/docs/cn/basics/accounts.md +++ /dev/null @@ -1,132 +0,0 @@ -**原文路径:https://github.com/cosmos/cosmos-sdk/blob/master/docs/basics/accounts.md** - -# 账户系统 - -# 必备阅读 {hide} - -- [一个 SDK 程序的剖析](./app-anatomy.md) {prereq} - -## 账户定义 - -在 Cosmos SDK 中，一个账户是指定的一个公私钥对。公钥可以用于派生出 `Addresses`，`Addresses` 可以在程序里面的各个模块间区分不同的用户。`Addresses` 同样可以和[消息](../building-modules/messages-and-queries.md#messages)进行关联用于确定发消息的账户。私钥一般用于生成签名来证明一个消息是被一个 `Addresses`(和私钥关联的`Addresses`) 所发送。 - -Cosmos SDK 使用一套称之为 [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 的标准来生成公私钥。这个标准定义了怎么去创建一个 HD 钱包(钱包就是一批账户的集合)。每一个账户的核心，都有一个种子，每一个种子都有一个 12 或 24 个字的助记符。使用这个助记符，使用一种单向的加密方法可以派生出任意数量的私钥。公钥可以通过私钥推导出来。当然，助记符是最敏感的信息，因为可以不停通过助记符来重新生成私钥。 - -```md - 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) | - | | - +-------------------+ -``` - -在 Cosmos SDK 中，账户可以在 [`Keybase`](#keybase) 中作为一个对象来储存和管理。 - -## Keybase - -`Keybase` 是储存和管理账户的对象，在 Cosmos SDK 中，`Keybase` 要实现以下接口 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/crypto/keys/types.go#L13-L86 - -在 Cosmos SDK 中，`Keybase` 接口的默认实现对象是 `dbKeybase`。 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/crypto/keys/keybase.go - -`dbKeybase` 上面对 `Keybase` 接口中方法实现的笔记: - -- `Sign(name, passphrase string, msg []byte) ([]byte, crypto.PubKey, error)` 对 `message` 字节进行签名。需要做一些准备工作将 `message` 编码成 []byte 类型，可以参考 `auth` 模块 `message` 准备的例子。注意，SDK 上面没有实现签名的验证，签名验证被推迟到[`anteHandler`](#antehandler)中进行 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/auth/types/txbuilder.go#L176-L209 - -- `CreateMnemonic(name string, language Language, passwd string, algo SigningAlgo) (info Info, seed string, err error)`创建一个新的助记符并打印在日志里，但是**并不保存在磁盘上** -- `CreateAccount(name, mnemonic, bip39Passwd, encryptPasswd string, account uint32, index uint32) (Info, error)` 基于[`bip44 path`](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)创建一个新的账户并将其保存在磁盘上。注意私钥在[保存前用密码加密](https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/crypto/keys/mintkey/mintkey.go),**永远不会储存未加密的私钥**.在这个方法的上下文中, `account`和 `address` 参数指的是 BIP44 派生路径的段(例如`0`, `1`, `2`, ...)用于从助记符派生出私钥和公钥(注意：给相同的助记符和 `account` 将派生出相同的私钥，给相同的 `account` 和 `address` 也会派生出相同的公钥和 `Address`)。最后注意 `CreateAccount` 方法使用在 [Tendermint library](https://github.com/tendermint/tendermint/tree/bc572217c07b90ad9cee851f193aaa8e9557cbc7/crypto/secp256k1) 中的 `secp256k1` 派生出公私钥和 `Address`。总之，这个方法是用来创建用户的钥匙和地址的，并不是共识秘钥，参见[`Addresses`](#addresses) 获取更多信息 - -`dbKeybase` 的实现是最基本的，并没有根据需求提供锁定功能。锁定功能指如果一个`dbKeybase`实例被创建，底层的`db`就被锁定意味着除了实例化它的程序其他程序无法访问它。这就是 SDK 程序使用另外一套 `Keybase` 接口的实现 `lazyKeybase` 的原因 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/crypto/keys/lazy_keybase.go - -`lazyKeybase` 是 `dbKeybase` 的一个简单包装，它仅在要执行操作时锁定数据库，并在之后立即将其解锁。使用 `lazyKeybase`[命令行界面](../interfaces/cli.md) 可以在 [rest server](../interfaces/rest.md)运行时创建新的账户，它也可以同时传递多个 CLI 命令 - -## 地址和公钥 - -`Addresses` 和 `PubKey` 在程序里面都是标识一个参与者的公共信息。Cosmos SDK 默认提供 3 种类型的 `Addresses`和 `PubKey` - -- 基于用户的 `Addresses` 和 `PubKey`，用于指定用户(例如 `message` 的发送者)。它们通过 **`secp256k1`** 曲线推导出来 -- 基于验证节点的 `Addresses` 和 `PubKey` 用于指定验证者的操作员，它们通过 **`secp256k1`** 曲线推导出来 -- 基于共识节点的 `Addresses` 和 `PubKey` 用于指定参与共识的验证着节点，它们通过 **`ed25519`** 曲线推导出来 - -| | Address bech32 Prefix | Pubkey bech32 Prefix | Curve | Address byte length | Pubkey byte length | -| ------------------ | --------------------- | -------------------- | ----------- | ------------------- | ------------------ | -| Accounts | cosmos | cosmospub | `secp256k1` | `20` | `33` | -| Validator Operator | cosmosvaloper | cosmosvaloperpub | `secp256k1` | `20` | `33` | -| Consensus Nodes | cosmosvalcons | cosmosvalconspub | `ed25519` | `20` | `32` | - -### 公钥 - -在 Cosmos SDK 里面 `PubKey` 遵循在 tendermint 的 `crypto` 包中定义的 `Pubkey` 接口 - -+++ https://github.com/tendermint/tendermint/blob/bc572217c07b90ad9cee851f193aaa8e9557cbc7/crypto/crypto.go#L22-L27 - -对于 `secp256k1` 类型的秘钥，具体的实现可以在[这里](https://github.com/tendermint/tendermint/blob/bc572217c07b90ad9cee851f193aaa8e9557cbc7/crypto/secp256k1/secp256k1.go#L140)找到。对于`ed25519`类型的密钥，具体实现可以在[这里](https://github.com/tendermint/tendermint/blob/bc572217c07b90ad9cee851f193aaa8e9557cbc7/crypto/ed25519/ed25519.go#L135)找到。 - -请注意，在 Cosmos SDK 中，`Pubkeys` 并非以其原始格式进行操作。它使用 [`Amino`](../core/encoding.md#amino) 和 [`bech32`](https://en.bitcoin.it/wiki/Bech32) 进行 2 次编码。在 SDK 里面，`Pubkeys` 首先调用 `Bytes()` 方法在原始的 `Pubkey` 中(这里面提供 amino 编码)，然后使用 `bech32` 的 `ConvertAndEncode` 方法 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/address.go#L579-L729 - -### 地址 - -在 Cosmos SDK 默认提送 3 种类型的地址 - -- `AccAddress` 用于账户 -- `ValAddress` 用于验证者操作员 -- `ConsAddress` 用于验证者节点 - -这些地址类型都是一种长度为 20 的十六进制编码的 `[]byte` 数组的别名，这里有一种标准方法从`Pubkey pub`中获取到地址`aa`. - -```go -aa := sdk.AccAddress(pub.Address().Bytes()) -``` - -这些地址实现了 `Address` 接口 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/address.go#L71-L80 - -值得注意的是，`Marhsal()` 和 `Bytes()` 方法都返回相同的 `[]byte` 类型的地址，根据 protobuf 的兼容性要求我们需要前者。同样，`String()` 也被用来返回 `bech32` 编码类型的地址，这个应该是用户看到的最终编码形式。下面是一个例子: - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/address.go#L229-L243 - -## 接下来 {hide} - -学习[gas and fees](./gas-fees.md) {hide} diff --git a/docs/cn/basics/app-anatomy.md b/docs/cn/basics/app-anatomy.md deleted file mode 100644 index 813e9c6c44..0000000000 --- a/docs/cn/basics/app-anatomy.md +++ /dev/null @@ -1,235 +0,0 @@ -# SDK 应用程序剖析 - -## Node Client - -全节点的核心进程是基于 SDK 包的。网络中的参与者运行此过程以初始化其状态机，与其他全节点连接并在新块进入时更新其状态机。 - -``` - ^ +-------------------------------+ ^ - | | | | - | | State-machine = Application | | - | | | | Built with Cosmos SDK - | | ^ + | | - | +----------- | ABCI | ----------+ v - | | + v | ^ - | | | | -Blockchain Node | | Consensus | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Networking | | - | | | | - v +-------------------------------+ v -``` - -区块链全节点以二进制形式表示，通常以 `-d` 后缀表示`守护程序`（例如，`appd` 表示 `app` 或 `gaiad` 表示 `gaia`）。这个二进制文件是通过编译一个简单的代码文件 main.go 构建的，`main.go` 通常位于`./cmd/appd/`中。 此操作通常通过用 Makefile 编译。 - -编译了二进制文件，就可以通过运行[`start`命令](https://docs.cosmos.network/master/core/node.html#start-command) 来启动节点。 此命令功能主要执行三件事： - -1. [`app.go`] 创建了一个状态机实例。 - -2. 用最新的已知状态初始化状态机，该状态机是从存储在 `~/.appd/data` 文件夹中的 db 中提取的。 此时，状态机的高度为：`appBlockHeight`。 - -3. 创建并启动一个新的 Tendermint 实例。 该节点将与对等节点进行连接交换信息。 它将从他们那里获取最新的 `blockHeight`，如果它大于本地的 `appBlockHeight`，则重播块以同步到该高度。 如果 `appBlockHeight` 为 `0`，则该节点从创世开始，并且 Tendermint 通过 ABCI 接口向 `app` 发送 `InitChain` 初始化链命令，从而触发 [`InitChainer`](https://docs.cosmos.network/master/basics/app-anatomy.html#initchainer)。 - -## Core Application File - -通常，状态机的核心是在名为 `app.go` 的文件中定义的。 它主要包含“应用程序的类型定义”和“创建和初始化它”的功能。 - -### Type Definition of the Application - -在 app.go 中重要的一个是应用程序的 type。 它通常由以下部分组成： - -- 在 `app.go` 中定义的自定义应用程序是 `baseapp` 的扩展。 当事务由 Tendermint 发送到应用程序时，`app` 使用 `baseapp` 的方法将它们转送到对应的模块。 baseapp 为应用程序实现了大多数核心逻辑，包括所有的 [ABCI 方法](https://tendermint.com/docs/spec/abci/abci.html#overview)和转送消息逻辑。 - -- 一条 key 链包含整个状态，他是基于 Cosmos SDK 的 multistore 实现的。 每个模块使用 multistore 的一个或多个存储来存储其状态。可以使用在 `app` 类型中声明的特定键来访问这些存储。这些密钥以及 `keepers` 是 Cosmos SDK 的对象功能模型的核心。 -- 模块 `keeper` 的列表。 每个模块都会抽象定义一个 keeper，该 keeper 实现模块存储的读写。 一个模块的 `keeper` 方法可以从其他模块（如果已授权）中调用，这就是为什么它们在应用程序的类型中声明并作为接口导出到其他模块的原因，以便后者只能访问授权的功能。 -- 应用程序的 `codec` 用于序列化和反序列化数据结构以便存储它们，因为存储只能持久化 `[]bytes`。 `编解码器`必须是确定性的。 默认编解码器为 amino -- 模块管理器是一个对象，其中包含应用程序模块的列表。 它简化了与这些模块相关的操作，例如注册 routes 操作，query route 操作或设置各种功能的模块之间顺序执行情况，例如 InitChainer 操作，BeginBlocke 操作和 EndBlocker 操作 -- 请参阅 [gaia](https://github.com/cosmos/gaia) 中的应用程序类型定义示例 - -+++ https://github.com/cosmos/gaia/blob/5bc422e6868d04747e50b467e8eeb31ae2fe98a3/app/app.go#L87-L115 - -### Constructor Function - -此函数构造了以上部分中定义的类型的新应用程序。在应用程的 start 命令中使用，它必须具有 AppCreator 签名。 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/server/constructors.go#L20 - -以下是此功能执行的主要操作： - -- 创建初始化一个新的 codec 实例，并使用基础模块管理器初始化每个应用程序模块的 `codec`。 -- 使用 baseapp 实例，编解码器和所有适当的存储键的引用实例化一个新应用程序。 -- 使用每个应用程序模块的 `NewKeeper` 功能实例化在应用程序的`类型`中定义的所有 keeper。 注意，所有 keeper 必须以正确的顺序实例化，因为一个模块的 NewKeeper 可能需要引用另一个模块的 `keeper`。 -- 使用每个应用模块的 AppModule 来实例化应用程序的模块管理器 -- 使用模块管理器，初始化应用程序的 routes 和 query route。 当事务由 Tendermint 通过 ABCI 中继到应用程序时，它使用此处定义的路由被路由到相应模块的回调 handler。 同样，当应用程序收到查询时，使用此处定义的查询路由将其路由到适当的模块的 querier。 -- 使用模块管理器，注册应用程序的模块的 invariants。 invariants 是在每个块末尾评估的变量（例如 token 的总供应量）。 检查不变式的过程是通过 InvariantsRegistry 的特殊模块完成的。 invariants 应等于模块中定义的预测值。 如果该值与预测的值不同，则将触发不变注册表中定义的特殊逻辑（通常会中断链）。这对于确保不会发现任何严重错误并产生难以修复的长期影响非常有用。 -- 使用模块管理器，在每个应用程序的模块 的 InitGenesis，BegingBlocker 和 EndBlocker 函数之间设置执行顺序。 请注意，并非所有模块都实现这些功能。 -- 模块实现这些功能。 -- 设置其余的应用程序参数： - - `InitChainer` 于在应用程序首次启动时对其进行初始化。 - - `BeginBlocker`，`EndBlocker`：在每个块的开始和结尾处调用。 - - `anteHandler`：用于处理费用和签名验证。 -- 挂载存储. -- 返回应用实例. - -请注意，此函数仅创建该应用的一个实例，而如果重新启动节点，则状态将从 `〜/.appd/data` 文件夹中保留下来状态加载，如果节点是第一次启动，则从创世文件生成。See an example of application constructor from [`gaia`](https://github.com/cosmos/gaia): - -+++ https://github.com/cosmos/gaia/blob/f41a660cdd5bea173139965ade55bd25d1ee3429/app/app.go#L110-L222 - -### InitChainer - -InitChainer 用于根据创始文件（即创始账户的代币余额）初始化应用程序的状态。 当应用程序从 Tendermint 引擎收到`InitChain`消息时调用该消息，该消息是在节点以`appBlockHeight == 0`（即创世）启动。 应用程序必须通过[`SetInitChainer`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer)方法设置其[constructor](https://docs.cosmos.network/master/basics/app-anatomy.html#constructor-function)中的`Initchainer`。 - -通常，`InitChainer`主要由每个应用程序模块的 InitGenesis 函数组成。 这是通过调用模块管理器的 InitGenesis 函数来完成的，而模块管理器的 InitGenesis 函数将依次调用其包含的每个模块的 InitGenesis 函数。 请注意，必须使用模块管理器的 SetOrderInitGenesis 方法设置模块的 InitGenesis 函数的顺序。 这是在 应用程序的构造函数 application-constructor 中完成的，必须在 SetInitChainer 之前调用 SetOrderInitGenesis。 - -查看来自[gaia](https://github.com/cosmos/gaia)的 InitChainer 的示例： - -See an example of an `InitChainer` from [`gaia`](https://github.com/cosmos/gaia): - -查看来自 [`gaia`](https://github.com/cosmos/gaia)的 `InitChainer` 的示例： -+++ https://github.com/cosmos/gaia/blob/f41a660cdd5bea173139965ade55bd25d1ee3429/app/app.go#L235-L239 - -### BeginBlocker and EndBlocker - -该 SDK 为开发人员提供了在其应用程序中实现自定义代码可能性。 这是通过两个名为 `BeginBlocker` 和 `EndBlocker` 的函数实现的。当应用程序分别从 Tendermint 引擎接收到 `BeginBlock` 和 `EndBlock` 消息时，将调用它们，它们分别在每个块的开始和结尾处发生。应用程序必须通过 [SetBeginBlocker](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp) 和 [SetEndBlocker](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) 方法在其 constructor 中设置 `BeginBlocker` 和 `EndBlocker`。 - -通常，`BeginBlocker` 和 `EndBlocker` 函数主要由每个应用程序模块的 `BeginBlock` 和 `EndBlock` 函数组成。 这是通过调用模块管理器的 BeginBlock 和 EndBlock 函数来完成的，而后者又会调用其包含的每个模块的 BeginBLock 和 EndBlock 函数。 请注意，必须分别在模块管理器中使用 SetOrderBeginBlock 和 SetOrderEndBlock 方法来设置模块的 BegingBlock 和 EndBlock 函数必须调用的顺序。这是通过应用程序的构造函数中的模块管理器完成的，必须调用 SetOrderBeginBlock 和 SetOrderEndBlock 方法。 在 SetBeginBlocker 和 SetEndBlocker 函数之前。 - -附带说明，请记住特定于应用程序的区块链是确定性的，这一点很重要。开发人员必须注意不要在 BeginBlocker 或 EndBlocker 中引入不确定性，还必须注意不要使它们在计算上过于昂贵，因为[gas]不会限制计算代价当调用 BeginBlocker 和 EndBlocker 执行。 - -请参阅 [gaia](https://github.com/cosmos/gaia)中的 `BeginBlocker` 和 `EndBlocker` 函数的示例。 - -+++ https://github.com/cosmos/gaia/blob/f41a660cdd5bea173139965ade55bd25d1ee3429/app/app.go#L224-L232 - -### Register Codec - -MakeCodec 函数是 app.go 文件的最后一个重要功能。 此函数的目的是使用 RegisterLegacyAminoCodec 函数实例化 codec`cdc`，例如 amino 初始化 SDK 的编解码器以及每个应用程序的模块。 - -为了注册应用程序的模块，`MakeCodec` 函数在 `ModuleBasics` 上调用 `RegisterLegacyAminoCodec`。`ModuleBasics` 是一个基本管理器，其中列出了应用程序的所有模块。 它在`init()`函数中得到实例化，仅用于注册应用程序模块的非依赖元素（例如编解码器）。 要了解有关基本模块管理器的更多信息，请点击[这里](https://docs.cosmos.network/master/building-modules/module-manager.html#basicmanager)。 - -请参阅 [gaia](https://github.com/cosmos/gaia) 中的 `MakeCodec` 示例： - -+++ https://github.com/cosmos/gaia/blob/f41a660cdd5bea173139965ade55bd25d1ee3429/app/app.go#L64-L70 - -## Modules - -Modules 是 SDK 应用程序的灵魂。它们可以被视为状态机中的状态机。当交易通过 ABCI 从底层的 Tendermint 引擎中继到应用程序时，它由 baseapp 找到对应的模块以便进行处理。这种范例使开发人员可以轻松构建复杂的状态机，因为他们所需的大多数模块通常已经存在。对于开发人员而言，构建 SDK 应用程序所涉及的大部分工作都围绕构建其应用程序尚不存在的自定义模块，并将它们与已经存在的模块集成到一个统一的应用程序中。在应用程序目录中，标准做法是将模块存储在 `x/` 文件夹中（不要与 SDK 的`x/`文件夹混淆，该文件夹包含已构建的模块）。 - -### Application Module Interface - -模块必须实现 Cosmos SDK AppModuleBasic 中的 [interfaces](https://docs.cosmos.network/master/building-modules/module-manager.html#application-module-interfaces) 和 AppModule。 前者实现了模块的基本非依赖性元素，例如`编解码器`，而后者则处理了大部分模块方法（包括需要引用其他模块的`keeper`的方法）。`AppModule` 和 `AppModuleBasic` 类型都在名为 `module.go` 的文件中定义。 - -AppModule 在模块上公开了一组有用的方法，这些方法有助于将模块组合成一个一致的应用程序。 这些方法是从模块管理器中调用的，该模块管理应用程序的模块集合。 - -### Message Types - -每个 `module` 定义 [messages](https://docs.cosmos.network/master/building-modules/messages-and-queries.html#messages) 接口。 每个 `transaction` 包含一个或多个 `messages`。 - -当全节点接收到有效的交易块时，Tendermint 通过 [`DeliverTx`](https://tendermint.com/docs/app-dev/abci-spec.html#delivertx) 将每个交易发到应用程序。然后，应用程序处理事务： - -- 收到交易后，应用程序首先从 `[]bytes` 反序列化得到。 -- 然后，在提取交易中包含的消息之前，它会验证有关交易的一些信息，例如费用支付和签名。 -- 使用 message 的 Type()方法，baseapp 可以将其发到对应模块的回调 handler 以便对其进行处理。 -- 如果消息已成功处理，则状态将更新。 - -有关事务生命周期的更多详细信息，请看[这里](./ tx-lifecycle.md)。 - -模块开发人员在构建自己的模块时会创建自定义消息类型。 通常的做法是在消息的类型声明前加上 `Msg`。 例如，消息类型 `MsgSend` 允许用户传输 tokens： - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/bank/internal/types/msgs.go#L10-L15 - -它由 `bank` 模块的回调 `handler` 处理，最终会调用 `auth` 模块来写 `keeper` 以更新状态。 - -### Handler - -回调 `handler` 是指模块的一部分，负责处理 `baseapp` 传递的 `message` 消息。 仅当通过 ABCI 接口的 DeliverTx 消息从 Tendermint 收到事务时，才执行模块的`处理程序`功能。 如果通过 CheckTx，仅执行无状态检查和与费用相关的有状态检查。为了更好地理解 `DeliverTx` 和 `CheckTx` 之间的区别以及有状态和无状态检查之间的区别，请看[这里](./tx-lifecycle.md)。 - -模块的`处理程序`通常在名为 `handler.go` 的文件中定义，并包括： - -- NewHandler 将消息发到对应的回调 `handler`。 该函数返回一个 `handler` 函数，此前这个函数在 `AppModule` 中注册，以在应用程序的模块管理器中用于初始化应用程序的路由器。接下来是 [nameservice tutorial](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice) 的一个例子。 - -+++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/x/nameservice/internal/keeper/querier.go#L19-L32 - -- 模块定义的每种消息类型的处理函数。开发人员在这些函数中编写消息处理逻辑。这通常包括进行状态检查以确保消息有效，并调用 [`keeper`](https://docs.cosmos.network/master/basics/app-anatomy.html#keeper) 的方法来更新状态。 - -处理程序函数返回结果类型为 sdk.Result，该结果通知应用程序消息是否已成功处理： - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/result.go#L15-L40 - -### Querier - -`Queriers` 与 `handlers` 非常相似，除了它们向状态查询用户而不是处理事务。 最终用户从 interface 发起 query，最终用户会提供 `queryRoute` 和一些 `data`。 然后使用 `queryRoute` 通过 `baseapp` 的 `handleQueryCustom` 方法查询到正确的应用程序的 `querier` 函数 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/baseapp/abci.go#L395-L453 - -模块的 Querier 是在名为 querier.go 的文件中定义的，包括： - -- NewQuerier 将查找到对应 query 函数。 此函数返回一个 `querier` 函数，此前它在 AppModule 中注册，以在应用程序的模块管理器中用于初始化应用程序的查询路由器。请参阅 [nameservice demo]（https://github.com/cosmos/sdk-tutorials/tree/master/nameservice）中的此类切换示例： - +++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/x/nameservice/internal/keeper/querier.go#L19-L32 - -- 对于模块定义的每种需要查询的数据类型，都具有一个查询器功能。开发人员在这些函数中编写查询处理逻辑。这通常涉及调用 `keeper` 的方法来查询状态并将其序列化为 JSON。 - -### Keeper - -[`Keepers`](https://docs.cosmos.network/master/building-modules/keeper.html)是其模块存储器件。要在模块的存储区中进行读取或写入，必须使用其 `keeper` 方法之一。这是由 Cosmos SDK 的 object-capabilities 模型确保的。 只有持有存储密钥的对象才能访问它，只有模块的 `keeper` 才应持有该模块存储的密钥。 - -`Keepers` 通常在名为 `keeper.go` 的文件中定义。 它包含 `keeper` 的类型定义和方法。 - -`keeper` 类型定义通常包括： - -- 多重存储中模块存储的`密钥`。 - - 参考**其他模块的`keepers`**。 仅当 `keeper` 需要访问其他模块的存储（从它们读取或写入）时才需要。 -- 对应用程序的`编解码器`的引用。 `keeper` 需要它在存储结构之前序列化处理，或在检索它们时将反序列化处理，因为存储仅接受 `[]bytes` 作为值。 - -与类型定义一起，keeper.go 文件的一个重要组成部分是 Keeper 的构造函数 NewKeeper。 该函数实例化上面定义的类型的新 `keeper`，并带有 `codec`，存储 `keys` 以及可能引用其他模块的 `keeper` 作为参数。从应用程序的构造函数中调用 `NewKeeper` 函数。文件的其余部分定义了 `keeper` 的方法，主要是 getter 和 setter。 - -### Command-Line and REST Interfaces - -每个模块都定义了 application-interfaces 向用户公开的命令行命令和 REST routes。 用户可以创建模块中定义的类型的消息，或查询模块管理的状态的子集。 - -#### CLI - -通常，与模块有关的命令在模块文件夹中名为 `client/cli` 的文件夹中定义。CLI 将命令分为交易和查询两类，分别在 `client/cli/tx.go` 和 `client/cli/query.go` 中定义。这两个命令基于 [Cobra Library](https://github.com/spf13/cobra)之上： - -- Transactions 命令使用户可以生成新的事务，以便可以将它们包含在块中并更新状态。应该为模块中定义的每个消息类型 message-types 创建一个命令。该命令使用户提供的参数调用消息的构造函数，并将其包装到事务中。SDK 处理签名和其他事务元数据的添加。 -- 用户可以查询模块定义的状态子集。查询命令将查询转发到应用程序的查询路由器，然后将查询路由到提供的`queryRoute`参数的相应 querier。 - -#### REST - -模块的 REST 接口允许用户生成事务并通过对应用程序的 light client daemon（LCD） 查询状态。 REST 路由在 `client/rest/rest.go` 文件中定义，该文件包括： - -- `RegisterRoutes` 函数，用于注册路由。从主应用程序的接口 application-interfaces 中为应用程序内使用的每个模块调用此函数。SDK 中使用的路由器是 [Gorilla's mux](https://github.com/gorilla/mux)。 -- 需要公开的每个查询或事务创建功能的自定义请求类型定义。这些自定义请求类型基于 Cosmos SDK 的基本`请求`类型构建： - +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/rest/rest.go#L47-L60 - -- 每个请求的一个处理函数可以找到给定的模块。 这些功能实现了服务请求所需的核心逻辑。 - -## Application Interface - -Interfaces 允许用户与全节点客户端进行交互。 这意味着从全节点查询数据，或者接受全节点中包含在块中的新事务。 - -通过汇总在应用程序使用的每个模块中定义的 CLI 命令构建 SDK 应用程序的 CLI。 应用程序的 CLI 通常具有后缀-cli（例如 appcli），并在名为`cmd / appcli / main.go`的文件中定义。 该文件包含： - -- main()函数，用于构建 appcli 接口客户端。这个函数准备每个命令，并在构建它们之前将它们添加到`rootCmd`中。在 appCli 的根部，该函数添加了通用命令，例如 status，keys 和 config，查询命令，tx 命令和 rest-server。 -- 查询命令是通过调用`queryCmd`函数添加的，该函数也在 appcli / main.go 中定义。此函数返回一个 Cobra 命令，其中包含在每个应用程序模块中定义的查询命令（从`main()`函数作为`sdk.ModuleClients`数组传递），以及一些其他较低级别的查询命令，例如阻止或验证器查询。查询命令通过使用 CLI 的命令“ appcli query [query]”来调用。 -- 通过调用`txCmd`函数来添加**交易命令**。与`queryCmd`类似，该函数返回一个 Cobra 命令，其中包含在每个应用程序模块中定义的 tx 命令，以及较低级别的 tx 命令，例如事务签名或广播。使用 CLI 的命令`appcli tx [tx]`调用 Tx 命令。 -- registerRoutes 函数，在初始化 轻客户端（LCD）时从 main()函数调用。 “ registerRoutes”调用应用程序每个模块的“ RegisterRoutes”功能，从而注册该模块 routes 到 LCD 的查询路由。可以通过运行以下命令“ appcli rest-server”来启动 LCD。 - -从[nameservice demo](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice)中查看应用程序的主要命令行文件的示例。 - -+++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/cmd/nscli/main.go - -## Dependencies and Makefile - -因为开发人员可以自由选择其依赖项管理器和项目构建方法。 也就是说，当前最常用的版本控制框架是[`go.mod`](https://github.com/golang/go/wiki/Modules)。 它确保在整个应用程序中使用的每个库都以正确的版本导入。 请参阅[demo](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice)中的示例： - -+++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/go.mod#L1-L18 - -为了构建应用程序，通常使用[Makefile](https://en.wikipedia.org/wiki/Makefile)。 Makefile 主要确保在构建应用程序的两个入口点 [`appd`](https://docs.cosmos.network/master/basics/app-anatomy.html#node-client) 和 [`appcli`](https://docs.cosmos.network/master/basics/app-anatomy.html#application-interface) 之前运行 `go.mod`。 请参阅 nameservice demo 中的 Makefile 示例 - -+++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/Makefile - -## Next - -了解有关[交易生命周期](./ tx-lifecycle.md)的更多信息 diff --git a/docs/cn/basics/gas-fees.md b/docs/cn/basics/gas-fees.md deleted file mode 100644 index 8c8441a760..0000000000 --- a/docs/cn/basics/gas-fees.md +++ /dev/null @@ -1,84 +0,0 @@ -**原文路径:https://github.com/cosmos/cosmos-sdk/blob/master/docs/basics/gas-fees.md** - -# Gas and Fees - -## 必备阅读 {hide} - -- [一个 SDK 程序的剖析](./app-anatomy.md) {prereq} - -## `Gas` and `Fees`的介绍 - -在 Cosmos SDK 中,`gas`是一种特殊的单位，用于跟踪执行期间的资源消耗。每当对储存进行读写操作的时候会消耗`gas`，如果要进行比较复杂的计算的话也会消耗`gas`。它主要有两个目的: - -- 确保区块不会消耗太多资源而且能顺利完成。这个默认在 SDK 的 [block gas meter](#block-gas-meter) 中保证 -- 防止来自终端用户的垃圾消息和滥用。为此，通常会为 [`message`](../building-modules/messages-and-queries.md#messages) 执行期间的消耗进行定价，并产生 `fee`(`fees = gas * gas-prices`)。`fees` 通常必须由 `message` 的发送者来支付。请注意，SDK 并没有强制执行对 `gas` 定价，因为可能会有其他的方法来防止垃圾消息(例如带宽方案)。尽管如此，大多数应用程序仍然会使用`fee` 方式来防止垃圾消息。这个机制通过 [`AnteHandler`](#antehandler) 来完成. - -## Gas Meter - -在 Cosmos SDK 中 `gas` 是一种简单的 `uint64` 类型，被称之为 `gas meter` 的对象进行管理，Gas meters 实现了 `GasMeter` 接口 - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/store/types/gas.go#L31-L39 - -这里: - -- `GasConsumed()` 返回 `GasMeter` 实例中消耗的 `gas` 的数量 -- `GasConsumedToLimit()` 返回 `GasMeter` 实例消耗的 gas 数量，如果达到上限的话就返回上限 -- `Limit()` 返回 `GasMeter` 实例的上限，如果是 0 则表示对 `gas` 的数量没有限制 -- `ConsumeGas(amount Gas, descriptor string)` 消耗提供的 `gas`，如果 `gas` 溢出了，使用 `descriptor` 内容进行报错，如果 `gas` 并不是无限的，则超过限制就会报错。 -- `IsPastLimit()` 如果 `gas` 消耗超过了 `GasMeter` 的限制则返回 `true`，其它返回 `false` -- `IsOutOfGas()` 如果 `gas` 消耗大于或等于了 `GasMeter` 的限制则返回 `true`，其它返回 `false` - - `GasMeter` 通常保存在 [`ctx`](../core/context.md) 中，`gas` 消耗的方式如下: - -```go -ctx.GasMeter().ConsumeGas(amount, "description") -``` - -通常，Cosmos SDK 使用两种不同的 `GasMeter`，[main gas meter](#main-gas-metter[) 和 [block gas meter](#block-gas-meter)。 - -### 主 Gas Meter - -`ctx.GasMeter()` 是应用程序的主 `GasMeter`，主 `GasMeter` 通过 `BeginBlock` 中的 `setDeliverState` 进行初始化，然后跟踪导致状态转换的执行序列中的 `gas` 消耗。也即是说它的更新由 [`BeginBlock`](../core/baseapp.md#beginblock)，[`DeliverTx`](../core/baseapp.md#delivertx) 和 [`EndBlock`](../core/baseapp.md#endblock) 进行操作。主 `GasMeter` 必须在 [`AnteHandler`](#antehandler)中 **设置为 0**，以便它能获取每个 transaction 的 Gas 消耗 - -`gas`消耗可以手工完成，模块开发者通常在 [`BeginBlocker`,`EndBlocker`](../building-modules/beginblock-endblock.md) 或者 [`handler`](../building-modules/handler.md) 上执行，但大多数情况下，只要对储存区进行了读写，它就会自动完成。这种自动消耗的逻辑在[`GasKv`](../core/store.md#gaskv-store)中完成. - -### 块 Gas Meter - -`ctx.BlockGasMeter()` 是跟踪每个区块 `gas` 消耗并保证它没有超过限制的 `GasMeter`。每当 [`BeginBlock`](../core/baseapp.md#beginblock) 被调用的时候一个新的 `BlockGasMeter` 实例将会被创建。`BlockGasMeter` 的 `gas` 是有限的，每个块的 `gas` 限制应该在应用程序的共识参数中定义，Cosmos SDK 应用程序使用 Tendermint 提供的默认共识参数： - -+++ https://github.com/tendermint/tendermint/blob/f323c80cb3b78e123ea6238c8e136a30ff749ccc/types/params.go#L65-L72 - -当通过 `DeliverTx` 处理新的 [transaction](../core/transactions.md) 的时候，`BlockGasMeter` 的当前值会被校验是否超过上限，如果超过上限，`DeliverTx` 直接返回，由于 `BeginBlock` 会消耗 `gas`，这种情况可能会在第一个 `transaction` 到来时发生，如果没有发生这种情况，`transaction`将会被正常的执行。在 `DeliverTx` 的最后，`ctx.BlockGasMeter()` 会追踪 `gas` 消耗并将它增加到处理 `transaction` 的 `gas` 消耗中. - -```go -ctx.BlockGasMeter().ConsumeGas( - ctx.GasMeter().GasConsumedToLimit(), - "block gas meter", -) -``` - -## AnteHandler - -`AnteHandler` 是一个特殊的处理程序，它在 `CheckTx` 和 `DeliverTx` 期间为每一个 `transaction` 的每个 `message` 处理之前执行。`AnteHandler` 相比 `handler` 有不同的签名: - -```go -// AnteHandler authenticates transactions, before their internal messages are handled. -// If newCtx.IsZero(), ctx is used instead. -type AnteHandler func(ctx Context, tx Tx, simulate bool) (newCtx Context, result Result, abort bool) -``` - -`AnteHandler` 不是在核心 SDK 中实现的，而是在每一个模块中实现的，这使开发者可以使用适合其程序需求的`AnteHandler`版本，也就是说当前大多数应用程序都使用 [`auth` module](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth) 中定义的默认实现。下面是 `AnteHandler` 在普通 Cosmos SDK 程序中的作用: - -- 验证事务的类型正确。事务类型在实现 `anteHandler` 的模块中定义，它们遵循事务接口： - - +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/tx_msg.go#L33-L41 - - 这使开发人员可以使用各种类型的应用程序进行交易。 在默认的 auth 模块中，标准事务类型为 StdTx： - - +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/auth/types/stdtx.go#L22-L29 - -- 验证交易中包含的每个 [`message`](../building-modules/messages-and-queries.md#messages) 的签名，每个 `message` 应该由一个或多个发送者签名，这些签名必须在 `anteHandler` 中进行验证. -- 在 `CheckTx` 期间，验证 `transaction` 提供的 `gas prices` 是否大于本地配置 `min-gas-prices`(提醒一下，`gas-prices` 可以从以下等式中扣除`fees = gas * gas-prices`)`min-gas-prices` 是每个独立节点的本地配置，在`CheckTx`期间用于丢弃未提供最低费用的交易。这确保了内存池不会被垃圾交易填充. -- 设置 `newCtx.GasMeter` 到 0，限制为`GasWanted`。**这一步骤非常重要**，因为它不仅确保交易不会消耗无限的天然气，而且还会在每个 `DeliverTx` 重置 `ctx.GasMeter`(每次 `DeliverTx` 被调用的时候都会执行 `anteHandler`，`anteHandler` 运行之后 `ctx` 将会被设置为 `newCtx`) - -如上所述，`anteHandler` 返回 `transaction` 执行期间所能消耗的最大的 `gas` 数量，称之为 `GasWanted`。最后实际 `gas` 消耗数量记为 `GasUsed`，因此我们必须使 `GasUsed =< GasWanted`。当返回时 `GasWanted` 和 `GasUsed` 都会被中继到共识引擎中. diff --git a/docs/cn/basics/tx-lifecycle.md b/docs/cn/basics/tx-lifecycle.md deleted file mode 100644 index cae4644fa7..0000000000 --- a/docs/cn/basics/tx-lifecycle.md +++ /dev/null @@ -1,162 +0,0 @@ -# Transaction 的生命周期 - -本文档描述了 Transaction 从创建到提交的生命周期，Transaction 的定义在[其他文档](https://docs.cosmos.network/master/core/transactions.html)中有详细描述，后文中 Transaction 将统一被称为`Tx`。 - -## 创建 - -### Transaction 的创建 - -命令行界面是主要的应用程序界面之一，`Tx` 可以由用户输入[以下命令](https://docs.cosmos.network/master/interfaces/cli.html)来创建，其中 `[command]` 是 `Tx` 的类型，`[args]` 是相关参数，`[flags]` 是相关配置例如 gas price： - -```bash -[appname] tx [command] [args] [flags] -``` - -此命令将自动**创建** `Tx`，使用帐户的私钥对其进行**签名**，并将其**广播**到其他节点。 - -创建 `Tx` 有一些必需的和可选的参数，其中 `--from` 指定该 `Tx` 的发起[账户](https://docs.cosmos.network/master/basics/accounts.html)，例如一个发送代币的`Tx`，则将从 `from` 指定的账户提取资产。 - -#### Gas 和 Fee - -此外，用户可以使用这几个[参数](https://docs.cosmos.network/master/interfaces/cli.html)来表明他们愿意支付多少 [fee](https://docs.cosmos.network/master/basics/gas-fees.html)： - -- `--gas` 指的是 [gas](https://docs.cosmos.network/master/basics/gas-fees.html) 的数量，gas 代表 `Tx` 消耗的计算资源，需要消耗多少 gas 取决于具体的 `Tx`，在 `Tx` 执行之前无法被精确计算出来，但可以通过在 `--gas` 后带上参数 `auto` 来进行估算。 -- `--gas-adjustment`（可选）可用于适当的增加 `gas`，以避免其被低估。例如，用户可以将 `gas-adjustment` 设为 1.5，那么被指定的 gas 将是被估算 gas 的 1.5 倍。 -- `--gas-prices` 指定用户愿意为每单位 gas 支付多少 fee，可以是一种或多种代币。例如，`--gas-prices=0.025uatom, 0.025upho` 就表明用户愿意为每单位的 gas 支付 0.025uatom 和 0.025upho。 -- `--fees` 指定用户总共愿意支付的 fee。 - -所支付 fee 的最终价值等于 gas 的数量乘以 gas 的价格。换句话说，`fees = ceil(gas * gasPrices)`。由于可以使用 gas 价格来计算 fee，也可以使用 fee 来计算 gas 价格，因此用户仅指定两者之一即可。 - -随后，验证者通过将给定的或计算出的 `gas-prices` 与他们本地的 `min-gas-prices` 进行比较，来决定是否在其区块中写入该 `Tx`。如果 `gas-prices` 不够高，该 `Tx` 将被拒绝，因此鼓励用户支付更多 fee。 - -#### CLI 示例 - -应用程序的用户可以在其 CLI 中输入以下命令，用来生成一个将 1000uatom 从 `senderAddress` 发送到 `recipientAddress` 的 `Tx`，该命令指定了用户愿意支付的 gas（其中 gas 数量为自动估算的 1.5 倍，每单位 gas 价格为 0.025uatom）。 - -```bash -appcli tx send 1000uatom --from --gas auto --gas-adjustment 1.5 --gas-prices 0.025uatom -``` - -#### 其他的 Transaction 创建方法 - -命令行是与应用程序进行交互的一种简便方法，但是 `Tx` 也可以使用 [REST interface](https://docs.cosmos.network/master/interfaces/rest.html) 或应用程序开发人员定义的某些其他入口点来创建命令行。从用户的角度来看，交互方式取决于他们正在使用的是页面还是钱包（例如， `Tx` 使用 [Lunie.io](https://lunie.io/#/) 创建并使用 Ledger Nano S 对其进行签名）。 - -## 添加到交易池 - -每个全节点（Tendermint 节点）接收到 `Tx` 后都会发送一个名为 `CheckTx` 的 [ABCI message](https://tendermint.com/docs/spec/abci/abci.html#messages)，用来检查 `Tx` 的有效性，`CheckTx` 会返回 `abci.ResponseCheckTx`。 -如果 `Tx` 通过检查，则将其保留在节点的 [**交易池**](https://tendermint.com/docs/tendermint-core/mempool.html#mempool)（每个节点唯一的内存事务池）中等待出块，`Tx` 如果被发现无效，诚实的节点将丢弃该 `Tx`。在达成共识之前，节点会不断检查传入的 `Tx` 并将其广播出去。 - -### 检查的类型 - -全节点在 `CheckTx` 期间对 `Tx` 先执行无状态检查，然后进行有状态检查，目的是尽早识别并拒绝无效 `Tx`，以免浪费计算资源。 - -**_无状态检查_**不需要知道节点的状态，即轻客户端或脱机节点都可以检查，因此计算开销较小。无状态检查包括确保地址不为空、强制使用非负数、以及定义中指定的其他逻辑。 - -**_状态检查_**根据提交的状态验证 `Tx` 和 `Message`。例如，检查相关值是否存在并能够进行交易，账户是否有足够的资产，发送方是否被授权或拥有正确的交易所有权。在任何时刻，由于不同的原因，全节点通常具有应用程序内部状态的[多种版本](https://docs.cosmos.network/master/core/baseapp.html#volatile-states)。例如，节点将在验证 `Tx` 的过程中执行状态更改，但仍需要最后的提交状态才能响应请求，节点不能使用未提交的状态更改来响应请求。 - -为了验证 `Tx`，全节点调用的 `CheckTx` 包括无状态检查和有状态检查，进一步的验证将在 [`DeliverTx`](#delivertx) 阶段的后期进行。其中 `CheckTx` 从对 `Tx` 进行解码开始。 - -### 解码 - -当 `Tx` 从应用程序底层的共识引擎（如 Tendermint）被接收时，其仍处于 `[]byte`[编码](https://docs.cosmos.network/master/core/encoding.html) 形式，需要将其解码才能进行操作。随后，[`runTx`](https://docs.cosmos.network/master/core/baseapp.html#runtx-and-runmsgs) 函数会被调用，并以 `runTxModeCheck` 模式运行，这意味着该函数将运行所有检查，但是会在执行 `Message` 和写入状态更改之前退出。 - -### ValidateBasic - -[Message](https://docs.cosmos.network/master/core/transactions.html#messages) 是由 module 的开发者实现的 `Msg` 接口中的一个方法。它应包括基本的**无状态**完整性检查。例如，如果 `Message` 是要将代币从一个账户发送到另一个账户，则 `ValidateBasic` 会检查账户是否存在，并确认账户中代币金额为正，但不需要了解状态，例如帐户余额。 - -### AnteHandler - -[`AnteHandler`](https://docs.cosmos.network/master/basics/gas-fees.html#antehandler)是可选的，但每个应用程序都需要定义。`AnteHandler` 使用副本为特定的 `Tx` 执行有限的检查，副本可以使对 `Tx` 进行状态检查时无需修改最后的提交状态，如果执行失败，还可以还原为原始状态。 - -例如，[`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec) 模块的 `AnteHandler` 检查并增加序列号，检查签名和帐号，并从 `Tx` 的第一个签名者中扣除费用，这个过程中所有状态更改都使用 `checkState` - -### Gas - -[`Context`](https://docs.cosmos.network/master/core/context.html) 相当于`GasMeter`，会计算出在 `Tx` 的执行过程中多少 `gas` 已被使用。用户提供的 `Tx` 所需的 `gas` 数量称为 `GasWanted`。`Tx` 在实际执行过程中消耗的 `gas` 被称为`GasConsumed`，如果 `GasConsumed` 超过 `GasWanted`，将停止执行，并且对状态副本的修改不会被提交。否则，`CheckTx` 设置 `GasUsed` 等于 `GasConsumed` 并返回结果。在计算完 gas 和 fee 后，验证器节点检查用户指定的值 `gas-prices` 是否小于其本地定义的值 `min-gas-prices`。 - -### 丢弃或添加到交易池 - -如果在 `CheckTx` 期间有任何失败，`Tx` 将被丢弃，并且 `Tx` 的生命周期结束。如果 `CheckTx` 成功，则 `Tx` 将被广播到其他节点，并会被添加到交易池，以便成为待出区块中的候选 `Tx`。 - -**交易池**保存所有全节点可见的 `Tx`，全节点会将其最近的 `Tx` 保留在**交易池缓存**中，作为防止重放攻击的第一道防线。理想情况下，`mempool.cache_size` 的大小足以容纳整个交易池中的所有 `Tx`。如果交易池缓存太小而无法跟踪所有 `Tx`，`CheckTx` 会识别出并拒绝重放的 `Tx`。 - -现有的预防措施包括 fee 和`序列号`计数器，用来区分重放 `Tx` 和相同的 `Tx`。如果攻击者尝试向某个节点发送多个相同的 `Tx`，则保留交易池缓存的完整节点将拒绝相同的 `Tx`，而不是在所有 `Tx` 上运行 `CheckTx`。如果 `Tx` 有不同的`序列号`，攻击者会因为需要支付费用而取消攻击。 - -验证器节点与全节点一样，保留一个交易池以防止重放攻击，但它也用作出块过程中未经验证的交易池。请注意，即使 `Tx` 在此阶段通过了所有检查，仍然可能会被发现无效，因为 `CheckTx` 没有完全验证 `Tx`（`CheckTx` 实际上并未执行 `message`）。 - -## 写入区块 - -共识是验证者节点就接受哪些 `Tx` 达成协议的过程，它是**反复进行**的。每个回合都始于出块节点创建一个包含最近 `Tx` 的区块，并由验证者节点（具有投票权的特殊全节点）负责达成共识，同意接受该区块或出一个空块。验证者节点执行共识算法，例如[Tendermint BFT](https://tendermint.com/docs/spec/consensus/consensus.html#terms)，调用 ABCI 请求确认 `Tx`，从而达成共识。 - -达成共识的第一步是**区块提案**，共识算法从验证者节点中选择一个出块节点来创建和提议一个区块，用来写入 `Tx`，`Tx` 必须在该提议者的交易池中。 - -## 状态变更 - -共识的下一步是执行 `Tx` 以完全验证它们，所有的全节点收到出块节点广播的区块并调用 ABCI 函数[`BeginBlock`](https://docs.cosmos.network/master/basics/app-anatomy.html#beginblocker-and-endblocker)，`DeliverTx`，和 [`EndBlock`](https://docs.cosmos.network/master/basics/app-anatomy.html#beginblocker-and-endblocker)。全节点在本地运行的每个过程将产生一个明确的结果，因为 `message` 的状态转换是确定性的，并且 `Tx` 在提案中有明确的顺序。 - -``` - ----------------------------- - |Receive Block Proposal| - ----------------------------- - | - v - ----------------------------- - | BeginBlock | - ----------------------------- - | - v - ----------------------------- - | DeliverTx(tx0) | - | DeliverTx(tx1) | - | DeliverTx(tx2) | - | DeliverTx(tx3) | - | . | - | . | - | . | - ----------------------------- - | - v - ----------------------------- - | EndBlock | - ----------------------------- - | - v - ----------------------------- - | Consensus | - ----------------------------- - | - v - ----------------------------- - | Commit | - ----------------------------- -``` - -### DeliverTx - -[`baseapp`](https://docs.cosmos.network/master/core/baseapp.html) 中定义的 ABCI 函数 `DeliverTx` 会执行大部分状态转换，`DeliverTx` 会针对共识中确定的顺序，对块中的每个 `Tx` 按顺序运行。`DeliverTx` 几乎和 `CheckTx` 相同，但是会以 deliver 模式调用[`runTx`](../core/baseapp.md#runtx)函数而不是 check 模式。全节点不使用 `checkState`，而是使用 `deliverState`。 - -- **解码：** 由于 `DeliverTx` 是通过 ABCI 调用的，因此 `Tx` 会以 `[]byte` 的形式被接收。节点首先会对 `Tx` 进行解码，然后在 `runTxModeDeliver` 中调用 `runTx`，`runTx` 除了会执行 `CheckTx` 中的检查外，还会执行 `Tx` 和并写入状态的变化。 - -- **检查：** 全节点会再次调用 `validateBasicMsgs` 和 `AnteHandler`。之所以进行第二次检查，是因为在 `Tx` 进交易池的过程中，可能没有相同的 `Tx`，但恶意出块节点的区块可能包括无效 `Tx`。但是这次检查特殊的地方在于，`AnteHandler` 不会将 `gas-prices` 与节点的 `min-gas-prices` 比较，因为每个节点的 `min-gas-prices` 可能都不同，这样比较的话可能会产生不确定的结果。 - -- **路由和 Handler：** `CheckTx` 退出后，`DeliverTx` 会继续运行 [`runMsgs`](https://docs.cosmos.network/master/core/baseapp.html#runtx-and-runmsgs) 来执行 `Tx` 中的每个 `Msg`。由于 `Tx` 可能具有来自不同模块的 `message`，因此 `baseapp` 需要知道哪个模块可以找到适当的 `Handler`。因此，`路由`通过[模块管理器](https://docs.cosmos.network/master/building-modules/module-manager.html)来检索路由名称并找到对应的[`Handler`](https://docs.cosmos.network/master/building-modules/handler.html)。 - -- **Handler：** `handler` 是用来执行 `Tx` 中的每个 `message`，并且使状态转换到从而保持 `deliverTxState`。`handler` 在 `Msg` 的模块中定义，并写入模块中的适当存储区。 - -- **Gas：** 在 `Tx` 被传递的过程中，`GasMeter` 是用来记录有多少 gas 被使用，如果执行完成，`GasUsed` 会被赋值并返回 `abci.ResponseDeliverTx`。如果由于 `BlockGasMeter` 或者 `GasMeter` 耗尽或其他原因导致执行中断，程序则会报出相应的错误。 - -如果由于 `Tx` 无效或 `GasMeter` 用尽而导致任何状态更改失败，`Tx` 的处理将被终止，并且所有状态更改都将还原。区块提案中无效的 `Tx` 会导致验证者节点拒绝该区块并投票给空块。 - -### 提交 - -最后一步是让节点提交区块和状态更改，在重跑了区块中所有的 `Tx` 之后，验证者节点会验证区块的签名以最终确认它。不是验证者节点的全节点不参与共识（即无法投票），而是接受投票信息以了解是否应提交状态更改。 - -当收到足够的验证者票数（2/3+的加权票数）时，完整的节点将提交一个新的区块，以添加到区块链网络中并最终确定应用程序层中的状态转换。此过程会生成一个新的状态根，用作状态转换的默克尔证明。应用程序使用从[Baseapp](https://docs.cosmos.network/master/core/baseapp.html)继承的 ABCI 方法[`Commit`](https://docs.cosmos.network/master/core/baseapp.html#commit)，`Commit` 通过将 `deliverState` 写入应用程序的内部状态来同步所有的状态转换。提交状态更改后，`checkState` 从最近提交的状态重新开始，并将 `deliverState` 重置为空以保持一致并反映更改。 - -请注意，并非所有区块都具有相同数量的 `Tx`，并且共识可能会导致一个空块。在公共区块链网络中，验证者可能是**拜占庭恶意**的，这可能会阻止将 `Tx` 提交到区块链中。可能的恶意行为包括出块节点将某个 `Tx` 排除在区块链之外，或者投票反对某个出块节点。 - -至此，`Tx`的生命周期结束，节点已验证其有效性，并提交了这些更改。`Tx`本身，以 `[]byte` 的形式被存储在区块上进入了区块链网络。 - -## 下一节 - -了解 [accounts](./accounts.md) diff --git a/docs/cn/clients/README.md b/docs/cn/clients/README.md deleted file mode 100644 index 39e8b6e1c2..0000000000 --- a/docs/cn/clients/README.md +++ /dev/null @@ -1,18 +0,0 @@ -# 客户端 - -本节说明包含区块链 SDK 的客户端的信息。 - -> _注_：此部分仍在开发中。 - -## 轻客户端 - -轻客户端使用户能够与您的应用程序进行交互，且无需下载整个状态历史记录，并且具有良好的安全性。 - -- [轻客户端概述](./lite/README.md) -- [启动轻客户端服务器](./lite/getting_started.md) -- [轻客户端规范](./lite/specification.md) - -## 其他客户端 - -- [区块链 SDK 的 CLI](./cli.md) -- [服务提供商文档](./service-providers.md) diff --git a/docs/cn/clients/cli.md b/docs/cn/clients/cli.md deleted file mode 100644 index 5e5c937a86..0000000000 --- a/docs/cn/clients/cli.md +++ /dev/null @@ -1,3 +0,0 @@ -# CLI - -> TODO: Rewrite this section to explain how CLI works for a generic SDK app. diff --git a/docs/cn/clients/lite/README.md b/docs/cn/clients/lite/README.md deleted file mode 100644 index b5eb140672..0000000000 --- a/docs/cn/clients/lite/README.md +++ /dev/null @@ -1,60 +0,0 @@ -# 轻客户端概览 - -**点击[这里](https://cosmos.network/rpc/)查看 Cosmos SDK 轻客户端 RPC 文档** - -## 简介 - -轻客户端允许客户端（例如移动电话）从任何全节点接收区块链状态的证明。 轻客户端不必信任任何全节点，因为他们能够验证他们收到的任何证明，因此全节点不能对网络状态撒谎。 - -轻客户端可以用最低的带宽、计算和存储资源提供与全节点相同的安全性。 同时，它还可以根据用户的配置提供模块化功能。 这些出色的功能允许开发人员构建完全安全、高效且可用的移动应用、网站或任何其他应用程序，而无需部署或维护任何完整的区块链节点。 - -### 什么是轻节点 - -Cosmos SDK 轻节点（Gaia-lite）分为两个独立的组件。 第一个组件对于任何基于 Tendermint 的应用程序都是通用的，它处理区块头相关的安全性和连接性，并验证来自全节点的证明与本地可信验证人集合的对比。 此外，它暴露与任何 Tendermint 核心节点完全相同的 API。 第二个组件专用于 Cosmos Hub（`gaiad`），它作为查询端点工作，并公开特定于应用程序的功能，这些功能可以是任意的。 针对应用程序状态的所有查询都必须通过查询端点。 查询端点的优点是它可以验证应用程序返回的证据。 - -### 高层体系结构 - -想要为 Cosmos Hub（或任何其他 zone）构建第三方客户端应用程序的应用程序开发人员，应根据其规范 API 构建。 该 API 是多个部分的组合。 所有 zone 都必须暴露 ICS0（TendermintAPI）。 除此之外，任何 zone 都可以自由选择模块 API 的任意组合，具体取决于状态机使用的模块。 Cosmos Hub 最初将支持[ICS0](https://cosmos.network/rpc/#/ICS0) (TendermintAPI)、 [ICS1](https://cosmos.network/rpc/#/ICS1) (KeyAPI)、 [ICS20](https://cosmos.network/rpc/#/ICS20) (TokenAPI)、 [ICS21](https://cosmos.network/rpc/#/ICS21) (StakingAPI)、 [ICS22](https://cosmos.network/rpc/#/ICS22) (GovernanceAPI) 和 [ICS23](https://cosmos.network/rpc/#/ICS23) (SlashingAPI)。 - -![high-level](../../../kr/clients/lite/pics/high-level.png) - -预计所有应用程序仅依赖于 Gaia-lite 运行。 Gaia-lite 是唯一一款围绕 zone API 提供稳定性保证的软件。 - -### 对比 - -ABCI 的全节点与其轻客户端的区别在于以下方面： - -| | Full Node | 轻客户端 | Description | -| -------------- | ---------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 执行并验证交易 | Yes | No | 全节点将执行并验证所有交易，而 Gaia-lite 则不会 | -| 验证和存储区块 | Yes | No | 全节点将验证并保存所有块，而 Gaia-lite 则不会 | -| 参与共识 | Yes | No | 只有当全节点是验证人时，它才会参与共识。 Lite 节点永远不会参与共识。 | -| 带宽开销 | 巨大 | 很小 | 全节点将接收所有块。 如果带宽有限，它将落后于主网络。 更重要的是，如果碰巧是验证人，它将减缓共识过程。 轻客户端需要很少的带宽， 只有在提供本地请求时，才会占用带宽。 | -| 计算资源 | 巨大 | 很小 | 全节点将执行所有交易并验证所有块，这需要大量的计算资源 | -| 存储资源 | 巨大 | 很小 | 全节点将保存所有块和 ABCI 状态，而 Gaia-lite 只保存验证人集合和一些检查点。 | -| 电力资源 | 巨大 | 很小 | 全节点必须在具有高性能并能一直运行的机器上部署，因此功耗将是巨大的。 Gaia-lite 可以部署在与用户应用程序相同的机器上，也可以部署在独立但性能较差的机器上。 此外，Lite 客户端可以在必要时随时关闭。所以 Gaia-lite 只消耗很少的功率，即使移动设备也能满足功率需求。 | -| 提供的 APIs | 所有 cosmos APIs | 部分模块 APIs | 全节点支持所有 cosmos API。 Gaia-lite 根据用户的配置提供模块化 API。 | -| 安全等级 | 高 | 高 | 全节点将自行验证所有交易和块。 轻型客户端无法执行此操作，但它可以查询来自其他全节点的任何数据并独立验证数据。 因此，全节点和轻型客户端都不需要信任任何第三方节点，它们都可以实现高安全性。 | - -根据上表，Gaia-lite 可以满足所有用户的功能和安全需求，但只需要很少的带宽、计算、存储和电力资源。 - -## 安全实现 - -### 可信验证人集合 - -Gaia-lite 的基本设计理念遵循两个规则： - -1. **不信任任何区块链节点，包括验证人节点和其他全节点** -2. **只信任整个验证人集合** - -原始的可信验证人集应该预先放置到其信任库中，通常这个验证人集来自 genesis 文件。 在运行时期间，如果 Gaia-lite 检测到不同的验证人集，它将验证它并将可信的验证人集保存到信任库中。 - -![validator-set-change](../../../kr/clients/lite/pics/validatorSetChange.png) - -### 信任传播 - -从上面的小节中，我们了解了如何获得可信验证器集以及 LCD 如何跟踪验证人集演化。 验证人集是信任的基础，信任可以传播到其他区块链数据，例如块和交易。 传播架构如下所示： - -![change-process](../../../kr/clients/lite/pics/trustPropagate.png) - -通常，通过可信验证人集，轻客户端可以验证包含所有预提交数据和块头数据的每个提交块。 此时块哈希、数据哈希和应用哈希是可信的。 基于此和默克尔证明，所有交易数据和 ABCI 状态也可以被验证。 diff --git a/docs/cn/clients/lite/getting_started.md b/docs/cn/clients/lite/getting_started.md deleted file mode 100644 index 796fb7e44d..0000000000 --- a/docs/cn/clients/lite/getting_started.md +++ /dev/null @@ -1,20 +0,0 @@ -# 入门 - -要启动 REST 服务器，我们需要指定以下参数： - -| 参数 | 类型 | 默认值 | 必填 | 描述 | -| ----------- | --------- | ----------------------- | ----- | ---------------------------- | -| chain-id | string | null | true | 要链接全节点的 chain id | -| node | URL | "tcp://localhost:46657" | true | 要链接全节点的地址和端口号 | -| laddr | URL | "tcp://localhost:1317" | true | 提供 REST 服务的地址和端口号 | -| trust-store | DIRECTORY | "\$HOME/.lcd" | false | 保存检查点和验证人集的目录 | - -示例： - -```bash -gaiacli rest-server --chain-id=test \ - --laddr=tcp://localhost:1317 \ - --node tcp://localhost:26657 \ -``` - -有关 Gaia-Lite RPC 的更多信息，请参阅 [swagger documentation](https://cosmos.network/rpc/) diff --git a/docs/cn/clients/lite/specification.md b/docs/cn/clients/lite/specification.md deleted file mode 100644 index 2b8dc0acd0..0000000000 --- a/docs/cn/clients/lite/specification.md +++ /dev/null @@ -1,183 +0,0 @@ -# 规范 - -该规范描述了如何实现 LCD。 LCD 支持模块化 API。 目前，仅支持 ICS0（TendermintAPI），ICS1（密钥 API）和 ICS20（Key API）。 如有必要，后续可以包含更多 API。 - -## 构建并验证 ABCI 状态的证明 - -众所周知，基于 cosmos-sdk 的应用程序的存储包含多个子库。 每个子目录由 IAVL 存储实现。 这些子组件由简单的 Merkle 树组成。 创建树时，我们需要从这些子库中提取名字、高度和存储根哈希以构建一组简单的 Merkle 叶节点，然后计算从叶节点到根的哈希。 简单 Merkle 树的根哈希是 AppHash，它将包含在块头中。 - -![Simple Merkle Tree](../../../kr/clients/lite/pics/simpleMerkleTree.png) - -正如我们在[LCD 信任传播](https://github.com/irisnet/cosmos-sdk/tree/bianjie/lcd_spec/docs/spec/lcd#trust-propagation)中所讨论的那样，可以通过检查针对可信验证人集的投票权来验证 AppHash。 这里我们只需要建立从 ABCI 状态到 AppHash 的证明。 证据包含两部分： - -- IAVL 证明 -- 子库到 AppHash 的证明 - -### IAVL 证明 - -证明有两种类型：存在证明和缺席证明。 如果查询密钥存在于 IAVL 存储中，则它返回键值及其存在证明。 另一方面，如果密钥不存在，那么它只返回缺席证明，这可以证明密钥肯定不存在。 - -### IAVL 存在证明 - -```go -type CommitID struct { - Version int64 - Hash []byte -} - -type storeCore struct { - CommitID CommitID -} - -type MultiStoreCommitID struct { - Name string - Core storeCore -} - -type proofInnerNode struct { - Height int8 - Size int64 - Version int64 - Left []byte - Right []byte -} - -type KeyExistsProof struct { - MultiStoreCommitInfo []MultiStoreCommitID // 所有子库提交id - StoreName string // 当前子库名字 - Height int64 // 当前子库提交高度 - RootHash cmn.HexBytes // 此 IAVL 树的根哈希 - Version int64 // 此 IAVL 树中 key-value 的版本号 - InnerNodes []proofInnerNode // 从根节点到 key-value 叶子节点的路径 -} -``` - -存在证据的数据结构如上所示。 构建和验证存在证明的过程如下所示： - -![Exist Proof](../../../kr/clients/lite/pics/existProof.png) - -构建证明的步骤： - -- 从根节点访问 IAVL 树 -- 记录 InnerNodes 中的访问节点 -- 找到目标叶节点后，将叶节点版本赋值给证明版本 -- 将当前 IAVL 树高赋值给证明高度 -- 将当前 IAVL 树根哈希赋值给证明根哈希 -- 将当前的子目录名称赋值给证明 StoreName -- 从 multistore 读取指定高度的 commitInfo 并将其赋值给证明 StoreCommitInfo - -验证证明的步骤： - -- 使用证明版本中的键、值构建叶节点 -- 计算叶节点哈希 -- 将哈希值分配给第一个 innerNode 的 rightHash，然后计算第一个 innerNode 哈希值 -- 传播哈希计算过程。 如果先前的 innerNode 是下一个 innerNode 的左子节点，则将先前的 innerNode 散列分配给下一个 innerNode 的左散列。否则，将先前的 innerNode 散列分配给下一个 innerNode 的右散列 -- 最后 innerNode 的哈希应该等于此证明的根哈希， 否则证明无效。 - -### IAVL 缺席证明 - -众所周知，所有 IAVL 叶节点都按每个叶节点的密钥排序。 因此，我们可以在 IAVL 树的整个密钥集中计算出目标密钥的位置。 如下图所示，我们可以找到左键和右键。 如果我们可以证明左键和右键肯定存在，并且它们是相邻的节点，那么目标密钥肯定不存在。 - -![Absence Proof1](../../../kr/clients/lite/pics/absence1.png) - -如果目标密钥大于最右边的叶节点或小于最左边的叶子节点，则目标密钥肯定不存在。 - -![Absence Proof2](../../../kr/clients/lite/pics/absence2.png)![Absence Proof3](../../../kr/clients/lite/pics/absence3.png) - -```go -type proofLeafNode struct { - KeyBytes cmn.HexBytes - ValueBytes cmn.HexBytes - Version int64 -} - -type pathWithNode struct { - InnerNodes []proofInnerNode - Node proofLeafNode -} - -type KeyAbsentProof struct { - MultiStoreCommitInfo []MultiStoreCommitID - StoreName string - Height int64 - RootHash cmn.HexBytes - Left *pathWithNode // Proof the left key exist - Right *pathWithNode //Proof the right key exist -} -``` - -以上是缺席证明的数据结构。 构建证据的步骤： - -- 从根节点访问 IAVL 树 -- 获取整个密钥集中密钥的对应索引（标记为 INDEX） -- 如果返回的索引等于 0，则右索引应为 0，且左节点不存在 -- 如果返回的索引等于整个密钥集的大小，则左节点索引应为 INDEX-1，且右节点不存在 -- 否则，右节点索引应为 INDEX，左节点索引应为 INDEX-1 -- 将当前 IAVL 树高赋值给证明高度 -- 将当前 IAVL 树根哈希赋值给证明根哈希 -- 将当前的子目录名称赋值给证明 StoreName -- 从 multistore 读取指定高度的 commitInfo 并将其赋值给证明 StoreCommitInfo - -验证证明的步骤： - -- 如果只存在右节点，请验证其存在的证明，并验证它是否是最左侧的节点 -- 如果仅存在左节点，请验证其存在的证据，并验证它是否是最右侧的节点 -- 如果右节点和左节点都存在，请验证它们是否相邻 - -### Substores 到 AppHash 的证明 - -在验证了 IAVL 证明之后，我们就可以开始验证针对 AppHash 的 substore 证明。 首先，迭代 MultiStoreCommitInfo 并通过证明 StoreName 找到 substore commitID。 验证 commitID 中的哈希是否等于证明根哈希，如果不相等则证明无效。 然后通过 substore name 的哈希对 substore commitInfo 数组进行排序。 最后，使用所有 substore commitInfo 数组构建简单的 Merkle 树，并验证 Merkle 根哈希值是否等于 appHash。 - -![substore proof](../../../kr/clients/lite/pics/substoreProof.png) - -```go -func SimpleHashFromTwoHashes(left []byte, right []byte) []byte { - var hasher = ripemd160.New() - - err := encodeByteSlice(hasher, left) - if err != nil { - panic(err) - } - - err = encodeByteSlice(hasher, right) - if err != nil { - panic(err) - } - - return hasher.Sum(nil) -} - -func SimpleHashFromHashes(hashes [][]byte) []byte { - // Recursive impl. - switch len(hashes) { - case 0: - return nil - case 1: - return hashes[0] - default: - left := SimpleHashFromHashes(hashes[:(len(hashes)+1)/2]) - right := SimpleHashFromHashes(hashes[(len(hashes)+1)/2:]) - return SimpleHashFromTwoHashes(left, right) - } -} -``` - -## 根据验证人集验证区块头 - -上面的小节中经常提到 appHash，但可信的 appHash 来自哪里？ 实际上，appHash 存在于区块头中，因此接下来我们需要针对 LCD 可信验证人集验证特定高度的区块头。 验证流程如下所示： - -![commit verification](../../../kr/clients/lite/pics/commitValidation.png) - -当可信验证人集与区块头不匹配时，我们需要尝试将验证人集更新为此块的高度。 LCD 有一条规则，即每个验证人集的变化不应超过 1/3 投票权。 如果目标验证人集的投票权变化超过 1/3，则与可信验证人集进行比较。 我们必须验证，在目标验证人集之前是否存在隐含的验证人集变更。 只有当所有验证人集变更都遵循这条规则时，才能完成验证人集的更新。 - -例如： - -![Update validator set to height](../../../kr/clients/lite/pics/updateValidatorToHeight.png) - -- 更新到 10000，失败，变更太大 -- 更新到 5050，失败，变更太大 -- 更新至 2575，成功 -- 更新至 5050，成功 -- 更新到 10000，失败，变更太大 -- 更新至 7525，成功 -- 更新至 10000，成功 diff --git a/docs/cn/clients/service-providers.md b/docs/cn/clients/service-providers.md deleted file mode 100644 index 8a695ed0b3..0000000000 --- a/docs/cn/clients/service-providers.md +++ /dev/null @@ -1,177 +0,0 @@ -# 服务提供商（Service Providers） - -我们将“服务提供商”定义为可以为最终用户提供服务的实体，这些实体涉及与基于 Cosmos-SDK 的区块链（包括 Cosmos Hub）的某种形式的交互。更具体地说，本文档将集中于与 token 的交互。 - -本节不涉及想要提供[轻客户端](https://github.com/cosmos/cosmos-sdk/tree/master/docs/interfaces/lite)功能的钱包开发者。服务提供商将作为最终用户的区块链的可信接入点。 - -## 架构的高级描述 - -有三个主要部分需要考虑： - -- 全节点：与区块链交互。 -- Rest Server：它充当 HTTP 调用的中继者。 -- Rest API：为 Rest Server 定义可用端点。 - -## 运行全节点 - -### 安装和配置 - -我们将描述为 Cosmos Hub 运行和交互全节点的步骤。对于其他基于 SDK 的区块链，该过程是类似的。 - -首先，您需要[安装软件](../cosmos-hub/installation.md). - -然后，您可以开始[运行全节点](../cosmos-hub/join-testnet.md). - -### 命令行界面（CLI） - -接下来，您将用一些 CLI 命令与全节点交互。 - -#### 创建秘钥对 - -生成新秘钥（默认使用 secp256k1 椭圆曲线算法）： - -```bash -gaiacli keys add -``` - -系统将要求您为此密钥对输入密码（至少 8 个字符）。该命令返回 4 个信息： - -- `NAME`: 秘钥名称。 -- `TYPE`：秘钥类型，总是`local`。 -- `ADDRESS`：您的地址，用于接收资金。 -- `PUBKEY`：您的公钥, 用于验证者. -- `MNEMONIC`： 由 24 个单词组成的助记词。 **将这个助记词保存在安全的地方**，它用于在您忘记密码时恢复您的私钥。 - -您可以输入以下命令查看所有可用密钥： - -```bash -gaiacli keys list -``` - -#### 检查您的余额 - -收到代币到您的地址后，您可以输入以下命令查看帐户的余额： - -```bash -gaiacli account -``` - -_注意：当您查询没有 token 帐户的余额时，您将得到以下错误：找不到地址为的帐户。这是预料之中的！我们正在努力改进我们的错误提示信息。_ - -#### 通过 CLI 发送代币 - -以下是通过 CLI 发送代币的命令： - -```bash -gaiacli tx send \ - --chain-id= -``` - -参数： - -- ``: 发送账户的名称或地址。 -- ``: 接收者地址。 -- ``: 接受``格式的参数，例如 `10faucetToken`。 - -标识： - -- `--chain-id`: 此标志允许您指定链的 ID，不同的 testnet 链和主链会有不同的 id。 - -#### 帮助 - -如果您需要进行其他操作，最合适的命令是： - -```bash -gaiacli -``` - -它将显示所有可用命令。对于每个命令，您可以使用`--help`标识来获取更多信息。 - -## 设置 Rest 服务器 - -Rest 服务器充当前端点和全节点之间的媒介。 Rest 服务器不必与全节点同一台计算机上运行。 - -要启动 Rest 服务器： - -```bash -gaiacli rest-server --node= -``` - -Flags: - -- `--node`: 全节点的 IP 地址和端口。格式为 ``。如果全节点在同一台机器上，则地址应为 `tcp：// localhost：26657`。 -- `--laddr`: 此标识允许您指定 Rest 服务器的地址和端口（默认为“1317”）。通常只使用这个标识指定端口，此时只需输入 “localhost” 作为地址，格式为``。 - -### 监听入向交易 - -监听入向交易推荐的方法是通过 LCD 的以下端点定期查询区块链： - - - -## Rest API - -Rest API 记录了可用于与全节点交互的所有可用端点，您可以在[这里](https://cosmos.network/rpc/)查看。 - -API 针对每种类别的端点归纳为 ICS 标准。例如，[ICS20](https://cosmos.network/rpc/#/ICS20/)描述了 API 与 token 的交互。 - -为了给开发者提供更大的灵活性，我们提供了生成未签名交易、[签名](https://cosmos.network/rpc/#/ICS20/post_tx_sign)和[广播](https://cosmos.network/rpc/#/ICS20/post_tx_broadcast)等不同的 API 端点。这允许服务提供商使用他们自己的签名机制。 - -为了生成一个未签名交易（例如 [coin transfer](https://cosmos.network/rpc/#/ICS20/post_bank_accounts__address__transfers)），你需要在 `base_req` 的主体中使用 `generate_only` 字段。 - -## Cosmos SDK 交易签名 - -Cosmos SDK 签名是一个相当简单的过程。 - -每个 Cosmos SDK 交易都有一个规范的 JSON 描述。 `gaiacli`和 REST 接口为交易提供规范的 JSON 描述，“广播”功能将提供紧凑的 Amino（类似 protobuf 的格式）编码转换。 - -签名消息时的注意事项： - -格式如下 - -```json -{ - "account_number": XXX, - "chain_id": XXX, - "fee": XXX, - "sequence": XXX, - "memo": XXX, - "msgs": XXX -} -``` - -签名者必须提供 `"chain_id"`、 `"account number"` 和 `"sequence number"`。 - -交易构造接口将生成 `"fee"`、 `"msgs"` 和 `"memo"` 等字段. - -You can load the mempool of a full node or validator with a sequence of uncommitted transactions with incrementing -sequence numbers and it will mostly do the correct thing. - -`"account_number"` 和 `"sequence"` 字段可以直接从区块链或本地缓存中查询。 错误的获取了这些数值和 chainId，是产生无效签名错误的常见原因。您可以通过加载全节点或验证人中的 mempool 来获取未提交交易的自增序号，这样大大增加成功概率。 - -您可以使用递增序列号的一系列未提交事务加载完整节点或验证器的 mempool，它将主要执行正确的操作。 - -在签名之前，所有键都要按字典顺序排序，并从 JSON 输出中删除所有空格。 - -签名编码是 ECDSArands 的 64 字节连结（即`r || s`），其中`s`按字典顺序小于其反转以防止延展性。 这就像以太坊一样，但没有用户公钥恢复的额外字节，因为 Tendermint 假定公钥一定会提供。 - -已签名交易中的签名和公钥示例: - -```json -{ - "type": "lbm-sdk/StdTx", - "value": { - "msg": [...], - "signatures": [ - { - "pub_key": { - "type": "ostracon/PubKeySecp256k1", - "value": XXX - }, - "signature": XXX - } - ], - } -} -``` - -正确生成签名后，将 JSON 插入生成的交易中，然后调用广播端点进行广播。 diff --git a/docs/cn/cn-translation-progress.md b/docs/cn/cn-translation-progress.md deleted file mode 100644 index 47362cdb8e..0000000000 --- a/docs/cn/cn-translation-progress.md +++ /dev/null @@ -1,45 +0,0 @@ -# Cosmos SDK Documentation Translation (Chinese) - -This document tracks the progress of the Chinese translation of the official Cosmos SDK documentation. - -Documentation has been translated for **reference use only** and may contain typos, factual errors and be out-of-date with the latest english documentation. - -Please refer to the official english version of the documentation for the latest and accurate information. - -## Cosmos SDK 文档翻译 - -本文档跟踪官方 Cosmos SDK 文档的中文翻译进度。 - -已翻译的文件**仅供参考**，可能包含拼写错误、翻译不准确，并且可能慢于英文版更新。 - -有关最新和准确的信息，请参阅文档的官方英文版。 - -## Progress by directory - -### README.md - -- Synced until commit [b18bd06a](https://github.com/cosmos/cosmos-sdk/commit/b18bd06a364e6ac15f22423e6b66a9feb3eeae93) (2019-12-10) - -### [`concepts`](../concepts/) - -- ToDo - -### [`spec`](../spec/) - -- ToDo - -### [`cosmos-hub`](../cosmos-hub/) - -- Synced until commit [7558f760](https://github.com/cosmos/cosmos-sdk/commit/7558f7607918b6337a8b58b8f956d6776f503138) (2019-05-13) - -### [`intro`](../intro/) - -- Synced until commit [be194ca1](https://github.com/cosmos/cosmos-sdk/commit/be194ca1b7d159590a0147da3226b7e09eaa3f61) (2020-07-07) - -### [`modules`](../modules/) - -- ToDo - -### [`clients`](../clients/) - -- Synced until Commit [7558f760](https://github.com/cosmos/cosmos-sdk/commit/7558f7607918b6337a8b58b8f956d6776f503138) (2019-05-13) diff --git a/docs/cn/intro/README.md b/docs/cn/intro/README.md deleted file mode 100644 index c7438e97c8..0000000000 --- a/docs/cn/intro/README.md +++ /dev/null @@ -1,13 +0,0 @@ -# 介绍 - -此目录包含对 cosmos sdk 的相关介绍 - -1. [概述](./overview.md) - -2. [基于特定应用的区块链](./why-app-specific.md) - -3. [应用架构](./sdk-app-architecture.md) - -4. [Cosmos SDK 设计概述](./sdk-design.md) - -了解完成相关介绍后，可以前往 [基础文档](../basics/README.md) 了解更多。 diff --git a/docs/cn/intro/ocap.md b/docs/cn/intro/ocap.md deleted file mode 100644 index 72c062f2b3..0000000000 --- a/docs/cn/intro/ocap.md +++ /dev/null @@ -1,49 +0,0 @@ -# 对象能力模型（Object-Capability Model） - -## 介绍 - -在考虑安全性时，最好从特定的威胁模型开始。我们的威胁模型如下: - -> 我们假设蓬勃发展的 Cosmos-SDK 模块生态中会包含错误或恶意的模块。 - -Cosmos SDK 旨在通过以对象能力系统作为基础来解决此威胁。 - -> 对象能力系统的结构特性有利于代码设计模块化，并确保代码实现的可靠封装。 -> -> 这些结构上的特性便于分析一个对象能力程序或操作系统的某些安全属性。其中一些 - 特别是信息流属性 - 可以在对象引用和连接级别进行分析，而不需要依赖于了解或分析（决定对象行为的）代码。 -> -> 因此，可以在存在包含未知或（可能）恶意代码的新对象的情况下建立和维护这些安全属性。 -> -> 这些结构属性源于管理对已存在对象的访问的两个规则： -> -> 1. 只有在对象 A 持有对象 B 的引用，A 才可以向 B 发送一条消息 -> 2. 只有对象 A 收到了一条包含对象 C 引用的消息，A 才可以获得 C 的引用 -> -> 根据这两条规则，一个对象只有通过一条先前存在的引用链获得另一个对象的引用，简而言之，“只有连接才能产生连接”。 - -关于对象能力（object-capabilities），可以阅读这边[文章](http://habitatchronicles.com/2017/05/what-are-capabilities/)了解更多。 - -## 对象能力模式实践 - -想法就是只暴露完成工作所需要的部分。 - -比如，下面的代码片段违反了对象能力原则： - -```go -type AppAccount struct {...} -var account := &AppAccount{ - Address: pub.Address(), - Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)}, -} -var sumValue := externalModule.ComputeSumValue(account) -``` - -方法名`ComputeSumValue`暗示了这是一个不修改状态的纯函数，但传入指针值意味着函数可以修改其值。更好的函数定义是使用一个拷贝来替代： - -```go -var sumValue := externalModule.ComputeSumValue(*account) -``` - -在 Cosmos SDK 中，你可以看到[gaia app](https://github.com/cosmos/cosmos-sdk/blob/master/simapp/app.go)中对该原则的实践。 - -+++ https://github.com/cosmos/gaia/blob/master/app/app.go#L197-L209 diff --git a/docs/cn/intro/overview.md b/docs/cn/intro/overview.md deleted file mode 100644 index 96da5ebf54..0000000000 --- a/docs/cn/intro/overview.md +++ /dev/null @@ -1,33 +0,0 @@ -# Cosmos SDK 介绍 - -## 什么是 Cosmos SDK - -[Cosmos SDK](https://github.com/cosmos/cosmos-sdk)是开源框架，用于构建类似 Cosmos Hub 等基于 POS 共识算法的多元资产公有区块链，以及基于权威证明共识算法的许可链。使用 Cosmos SDK 构建的区块链通常被称为特定应用区块链（专用区块链）（application-specific blockchains）。 - -Cosmos SDK 的目标是让开发者可以快速地构建一条能与其他区块链以原生的方式进行互操作的可定制区块链。在我们的设想中，这套 SDK 就像 Web 应用框架一样，可以让开发者迅速构建出基于[Tendermint](https://github.com/tendermint/tendermint)的安全区块链应用程序。 基于 Cosmos SDK 的区块链由组合式[模块](https://docs.cosmos.network/master/building-modules/intro.html)构建，其中大部分模块都是开源的，且任何开发者均可使用。任何人都能为 Cosmos SDK 创建新的模块，集成已经构建的模块就像将他们导入你的区块链应用程序一样简单。还有一点，Cosmos SDK 是基于功能（capabilities）的系统，这允许开发者可以更好地考虑模块之间交互的安全性。更深入地了解功能，请跳至[本节](https://docs.cosmos.network/master/core/ocap.html)。 - -## 什么是特定应用区块链 - -目前在区块链领域中，一种开发模式是通过像以太坊这样的虚拟机区块链展开，即开发者在现有的区块链上通过智能合约的方式去构建去中心化应用。虽然智能合约在单用途应用场景（如 ICO）下非常有用，但在构建复杂的去中心化平台时无法达到要求。更具体地说，智能合约在灵活性、所有权、性能方面会受到限制。 - -特定应用区块链提供了与虚拟机区块链截然不同的开发模式。特定应用区块链是面向单个具体应用程序的高度定制化区块链：开发者可以完全自由地做出让应用程序可以达到最佳运行状态的设计决策。他们也可以提供更好的主导权、安全性和性能。 - -了解更多可参考[特定应用区块链](https://docs.cosmos.network/master/intro/why-app-specific.html)。 - -## 为什么选择 Cosmos SDK？ - -Cosmos SDK 是目前最先进的构建可定制化特定应用区块链的框架。以下是一些可能让你希望通过 Cosmos SDK 构建去中心化应用的原因： - -- Cosmos SDK 默认的共识引擎是[Tendermint Core](https://github.com/tendermint/tendermint). Tendermint 是目前最成熟的、唯一的 BFT 共识引擎。它被广泛应用于行业中，被认为是构建 POS 系统的最佳标准共识引擎。 - -- Cosmos SDK 是开源的，你可以通过组合式[modules](https://docs.cosmos.network/master/x/)轻松地构建出区块链。随着 SDK 生态中各种开源模块的发展，通过 Cosmos SDK 构建复杂的去中心化平台会变得越来越容易。 - -- Cosmos SDK 受基于功能的安全性所启发，并受益于多年来在区块链状态机领域的经验。这让 Cosmos SDK 成为一个非常安全的构建区块链的环境。 - -- 最重要的是，Cosmos SDK 已经构建出了多个正在运行中的特定应用区块链。例如，Cosmos HUB，IRIS HUB，Binance Chain, Terra 和 Kava。更多基于 Cosmos SDK 构建的区块链参考[这里](https://cosmos.network/ecosystem)。 - -## 开始使用 Cosmos SDK - -了解更多请参考[SDK 应用架构](https://docs.cosmos.network/master/intro/sdk-app-architecture.html)。 - -了解如何从头建立特定应用区块链，请参考[SDK 教程](https://cosmos.network/docs/tutorial)。 diff --git a/docs/cn/intro/sdk-app-architecture.md b/docs/cn/intro/sdk-app-architecture.md deleted file mode 100644 index 732655dac1..0000000000 --- a/docs/cn/intro/sdk-app-architecture.md +++ /dev/null @@ -1,91 +0,0 @@ -# 区块链架构 - -## 状态机 - -区块链的核心是[复制确定状态机](https://en.wikipedia.org/wiki/State_machine_replication)（replicated deterministic state machine）。 - -状态机是计算机科学领域的一个概念，即一台机器可以具有多个状态，但在任意给定时刻只具有一个确定的状态。我们用 `state` 描述系统当前状态，`transactions` 触发状态转换。 - -给定一个状态 S 和 Transaction T，状态机会返回新的状态 S'。 - -``` -+--------+ +--------+ -| | | | -| S +---------------->+ S' | -| | apply(T) | | -+--------+ +--------+ -``` - -在实际中，Transaction 集会被打包进区块中，以让处理过程更加高效。给定一个状态 S 和一个包含 Transaction 集 B 的区块，状态机就会返回新的状态 S'。 - -``` -+--------+ +--------+ -| | | | -| S +----------------------------> | S' | -| | For each T in B: apply(T) | | -+--------+ +--------+ -``` - -在区块链的上下文环境中，状态机是确定的。这意味着节点从给定状态开始，重放相同的 Transaction 序列，总能得到相同的最终状态。 - -Cosmos SDK 为开发者提供了最大程度的灵活性去定义应用程序的状态，Transaction 类型和状态转换功能。接下来的章节中会更详细地介绍使用 SDK 构建状态机的过程。在此之前，先让我们看看如何使用 Tendermint 复制状态机。 - -## Tendermint - -得益于 Cosmos SDK，开发者只需要定义好状态机，[Tendermint](https://tendermint.com/docs/introduction/what-is-tendermint.html) 就会处理好状态复制的工作。 - -``` - ^ +-------------------------------+ ^ - | | | | Built with Cosmos SDK - | | State-machine = Application | | - | | | v - | +-------------------------------+ - | | | ^ -Blockchain node | | Consensus | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Networking | | - | | | | - v +-------------------------------+ v -``` - -[Tendermint](https://tendermint.com/docs/introduction/what-is-tendermint.html) 是一个与应用程序无关的引擎，负责处理区块链的网络层和共识层。这意味着 Tendermint 负责对 Transaction 字节进行传播和排序。Tendermint Core 通过同名的拜占庭容错算法来达成 Transaction 顺序的共识。 - -Tendermint[共识算法](https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview)与一组被称为 Validator 的特殊节点共同运作。Validator 负责向区块链中添加包含 transaction 的区块。在任何给定的区块中，都有一组 Validator 集合 V。算法会从集合 V 中选出一个 Validator 作为下一个区块的 Proposer。如果一个区块被集合 V 中超过三分之二的 Validator 签署了 [prevote](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r) 和 [precommit](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)，且区块中所有 Transaction 都是有效的，则认为该区块有效。Validator 集合可以按照状态机中写定的规则更改。 - -## ABCI - -Tendermint 通过被称为 [ABCI](https://tendermint.com/docs/spec/abci/) 的接口向应用程序传递 Transactions，该接口必须由应用程序实现。 - -``` - +---------------------+ - | | - | Application | - | | - +--------+---+--------+ - ^ | - | | ABCI - | v - +--------+---+--------+ - | | - | | - | Tendermint | - | | - | | - +---------------------+ -``` - -需要注意的是，Tendermint 仅处理 transaction 字节，它并不知道这些字节的含义。Tendermint 所做的只是对 transaction 字节进行确定性地排序。Tendermint 通过 ABCI 向应用程序传递字节，并期望返回状态码以获知包含在 transactions 中的 messages 是否成功处理。 - -以下是 ABCI 最重要的 Messages： - -`CheckTx`：当 Tendermint Core 接收到一个 Transaction 时，它会传递给应用程序以检查是否满足一些基本要求。`CheckTx` 用于保护全节点的内存池免受垃圾 transactions 攻击。`AnteHandler` 这一特殊处理程序用于执行一系列验证步骤，例如检查手续费是否足够以及验证签名。如果检查通过，该 transaction 会被添加进[mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality)，并广播给其他共识节点。请注意，此时 transactions 尚未被 `CheckTx` 处理（即未进行状态修改），因为它们还没有被包含在区块中。 - -`DeliverTx`：当 Tendermint Core 收到一个[有效区块](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation)时，区块中的每一个 Transaction 都会通过 `DeliverTx` 传递给应用程序以进行处理。状态转换会在这个阶段中发生。`AnteHandler` 会与 Transaction 中每个 Message 的实际 [`handlers`](https://docs.cosmos.network/master/building-modules/handler.html) 一起再次执行。 - -`BeginBlock/EndBlock`：无论区块中是否包含 transaction，messages 都会在每个区块的开头和结尾处执行。触发自动执行的逻辑是很有用的。但需要谨慎使用，因为计算量庞大的循环会严重降低区块链的性能，而无限循环甚至会导致区块链宕机。 - -获知更多关于 ABCI 的详细内容可以访问 [Tendermint docs](https://tendermint.com/docs/spec/abci/abci.html#overview). - -基于 Tendermint 构建的任何程序都需要实现 ABCI 接口，以便和底层的本地 Tendermint 引擎通信。幸运的是，您不需要实现 ABCI 接口，Cosmos SDK 以 [baseapp](https://docs.cosmos.network/master/intro/sdk-design.html#baseapp) 的形式提供了样板实现。 diff --git a/docs/cn/intro/sdk-design.md b/docs/cn/intro/sdk-design.md deleted file mode 100644 index 94af6f87a0..0000000000 --- a/docs/cn/intro/sdk-design.md +++ /dev/null @@ -1,87 +0,0 @@ -# Cosmos SDK 的主要组件 - -Cosmos SDK 是一个框架，可以促进基于 Tendermint 的安全状态机的开发。SDK 的核心是一个基于 Golang 的[ABCI](https://docs.cosmos.network/master/intro/sdk-app-architecture.html#abci)样板实现。它带有一个用于存储数据的[`multistore`](https://docs.cosmos.network/master/core/store.html#multistore)，和一个用于处理 Transaction 的[`router`](https://docs.cosmos.network/master/core/baseapp.html#routing)。 - -下面的简化视图展示了当通过 `DeliverTx` 从 Tendermint 转移 transactions 时，基于 Cosmos SDK 构建的应用程序如何处理这些 transactions。 - -1. 解码从 Tendermint 共识引擎中接收到的 `transactions`（Tendermint 只能处理 `[]bytes` 类型的数据） -2. 从 `transactions` 中提取 `messages` 并进行基本的健全性检查。 -3. 将每个 Message 路由到对应的模块中，以进行相应处理。 -4. 提交状态更改。 - -## BaseApp - -`baseapp` 是 Cosmos SDK 应用程序的样本实现，它拥有能够处理和底层共识引擎的连接的 ABCI 实现。通常，Cosmos SDK 应用程序通过嵌入[`app.go`](https://docs.cosmos.network/master/basics/app-anatomy.html#core-application-file)来实现拓展。查看示例请参考 SDK 应用教程： - -+++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go - -`baseapp` 的目标是在存储和可拓展状态机之间提供安全的接口，同时尽可能少地定义状态机（对 ABCI 保持不变）。 - -更多关于`baseapp`的信息，请点击[这里](https://docs.cosmos.network/master/core/baseapp.html)。 - -## Multistore - -Cosmos SDK 为状态持久化提供了 `multistore`。Multistore 允许开发者声明任意数量的 `KVStores`。这些 `KVStores` 只接受 `[]byte` 类型的值，因此任何自定义的结构都需要在存储之前使用[codec](https://docs.cosmos.network/master/core/encoding.html)进行编码。 - -Multistore 抽象用于区分不同模块的状态，每个都由其自己的模块管理。更多关于 multistore 的信息请点击[这里](https://docs.cosmos.network/master/core/store.html#multistore)。 - -## Modules - -Cosmos SDK 的强大之处在于其模块化开发的理念。SDK 应用程序是通过组合一系列可互操作的模块而构建的。每个模块定义了状态子集，并包含其 Messages 与 Transactions 的处理器，同时 SDK 负责将每个 Message 路由到对应的模块中。 - -以下的简化视图展示了应用链中的每个全节点如何处理有效区块中的 Transaction。 - -```md - + - | - | Transaction relayed from the full-node's Tendermint engine - | to the node's application via DeliverTx - | - | - | - +---------------------v--------------------------+ - | APPLICATION | - | | - | Using baseapp's methods: Decode the Tx, | - | extract and route the message(s) | - | | - +---------------------+--------------------------+ - | - | - | - +---------------------------+ - | - | - | - | Message routed to the correct - | module to be processed - | - | -+----------------+ +---------------+ +----------------+ +------v----------+ -| | | | | | | | -| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | -| | | | | | | | -| | | | | | | Handles message,| -| | | | | | | Updates state | -| | | | | | | | -+----------------+ +---------------+ +----------------+ +------+----------+ - | - | - | - | - +--------------------------+ - | - | Return result to Tendermint - | (0=Ok, 1=Err) - v -``` - -每个模块都可以看成是一个小的状态机。开发者需要定义由模块处理的状态子集，同时自定义改变状态的 Message 类型（注意：`messages` 是通过 `baseapp` 从 `transactions` 中提取的）。通常，每个模块会在 `multistore` 中声明自己的 `KVStore`，以存储自定义的状态子集。大部分开发者在构建自己的模块时，需要访问其它第三方模块。由于 Cosmos SDK 是一个开放的框架，其中的一些模块可能是恶意的，这意味着需要一套安全原则去考虑模块间的交互。这些原则都基于[object-capabilities](https://docs.cosmos.network/master/core/ocap.html)。事实上，这也意味着，并不是要让每个模块都保留其他模块的访问控制列表，而是每个模块都实现了被称为 `keepers` 的特殊对象，它们可以被传递给其他模块，以授予一组预定义的功能。 - -SDK 模块被定义在 SDK 的 `x/` 文件夹中，一些核心的模块包括： - -- `x/auth`：用于管理账户和签名。 -- `x/bank`：用于启动 tokens 和 token 转账。 -- `x/staking` + `s/slashing`：用于构建 POS 区块链。 - -除了 `x/` 文件夹中已经存在的任何人都可以使用的模块，SDK 还允许您构建自己自定义的模块，您可以在[教程中查看示例](https://cosmos.network/docs/tutorial/keeper.html)。 diff --git a/docs/cn/intro/why-app-specific.md b/docs/cn/intro/why-app-specific.md deleted file mode 100644 index 199dbaa170..0000000000 --- a/docs/cn/intro/why-app-specific.md +++ /dev/null @@ -1,85 +0,0 @@ -# 特定应用区块链 - -## 概要 - -本文档解释了什么是特定应用区块链，以及为什么开发者更希望构建特定应用区块链，而不是开发智能合约。 - -## 什么是特定应用区块链？ - -特定应用区块链是面向单个具体应用程序的高度定制化区块链。与基于像以太坊这样的底层区块链搭建去中心化应用不同，开发者需要从头构建他们自己的区块链。这意味着构建全节点客户端、轻节点客户端和所有必要的接口（CLI, REST, 等等）来和节点交互。 - -``` - ^ +-------------------------------+ ^ - | | | | Built with Cosmos SDK - | | State-machine = Application | | - | | | v - | +-------------------------------+ - | | | ^ -Blockchain node | | Consensus | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Networking | | - | | | | - v +-------------------------------+ v -``` - -## 智能合约的局限是什么？ - -早在 2014 年，像 Ethereum 这样的虚拟机区块链就满足了可编程性的需求。当时，开发去中心化应用的选项非常有限。许多开发者只能在复杂且有限制的比特币脚本语言上开发，或者 fork 难以运行和定制化的比特币代码。 - -虚拟机区块链在当时提出了新的价值主张。他们的状态机集成了虚拟机，从而能够执行被称为智能合约的图灵完备程序。虽然智能合约在一次性事件（如 ICO）的应用场景下非常有用，但在构建复杂的去中心化平台时无法达到要求。以下是原因： - -- 智能合约通常由可以被底层虚拟机解释的特定编程语言开发。这些编程语言常常并不成熟，并受限于虚拟机本身。例如，以太坊虚拟机并不允许开发者实现代码的自动执行。开发或者也被限制于 EVM 的账户体系，他们只能从一组有限的功能中进行加密操作。虽然这些只是示例，但它们展现了智能合约环境通常缺少**灵活性**。 - -- 智能合约都运行在同一台虚拟机上，这意味着它们会相互争夺资源，并严重影响执行效果。即使状态机切分成多个子集（例如通过分片技术），智能合约依然需要由虚拟机解释，比起在状态机上实现的本地应用程序，这依然限制了合约应用的**性能**。（我们的基准测试表明，在删除虚拟机后，应用程序的性能提高了 10 倍。） - -- 智能合约共享底层环境带来的另一个问题是**主导权**的最终限制。去中心化应用是一个涉及众多参与者的生态系统，如果去中心化应用建立在通用的虚拟机区块链上，利益相关者（stakeholders）对他们的应用程序就只有非常有限的主导权，并最终会被底层区块链的治理所取代。如果该应用程序还存在着漏洞，那任何人都无能为力。 - -特定应用区块链的出现，就是要解决上述问题。 - -## 特定应用区块链的优势 - -### 灵活性 - -特定应用区块链赋予了开发者最大的灵活性： - -- 在 Cosmos 区块链中，状态机通常通过被称为 [ABCI](https://tendermint.com/docs/spec/abci/) 的接口和底层共识引擎连接。该接口可以被包装为任何编程语言，开发者可以自己决定用哪种编程语言来构建状态机。 - -- 开发者在构建状态机时有多种选择，目前最常用的是 Cosmos SDK，但也有其他的框架，如 [Lotion](https://github.com/nomic-io/lotion) 和 [Weave](https://github.com/iov-one/weave) 等。开发者通常都是基于他们使用的编程语言来选择使用哪一种框架（Cosmos SDK 和 Weave 基于 Golang，Lotion 则基于 JavaScript）。 - -- ABCI 允许开发者更换特定应用链的共识引擎。目前只有 Tendermint 共识可以投入使用，但在未来还会有更多共识引擎可被使用。 - -- 即使已经选好了开发框架和共识引擎，但如果他们不能完全符合原始格式的要求，开发者依然可以对其进行调整。 - -- 开发者可以自由探索出最能满足实际需求的方案（如验证人数量 vs Transaction 吞吐量；安全性 vs 异步可用性等）和链的设计选项（如 DB 存储或 IAVL 树；UTXO 或账户模型，等）。 - -- 开发者可以实现代码的自动执行。在 Cosmos SDK 中，每个块的开头和结尾都可以自动触发逻辑。与虚拟机区块链环境下的合约开发者不同，特定应用区块链的开发者可以自由地选择应用程序所需要的加密库，而不会受到底层环境的功能限制。 - -上述的列表展示了特定应用区块链给予开发者的充分灵活性。Cosmos 和 Cosmos SDK 的目标是让开发者工具尽可能的通用化、模块化，从而在保持兼容的情况下对堆栈的每个部分进行分叉、调整和优化。随着社区的不断发展，每个核心构建模块都将有更多可替代方案，为开发者提供更多选项。 - -### 性能 - -基于智能合约的去中心化应用在性能方面会天然地受到底层环境的限制。如果一个去中心化应用要进行性能优化，就需要将其构建为特定应用区块链。以下是特定应用区块链在性能方面的优势： - -- 特定应用区块链开发者可以选择像 Tendermint BFT 这样的新型共识引擎。与目前被大多数虚拟机区块链使用的 POW 共识相比，Tendermint BFT 在吞吐量方面有显著提高。 - -- 一个特定应用区块链只运行单个应用程序，所以该应用程序不需要和其他程序去竞争计算资源和存储资源。这与目前所有非分片虚拟机区块链正好相反，在这些区块链中的智能合约都会争夺计算和存储资源。 - -- 即使某种虚拟机区块链能够提供基于应用程序的分片和高效的共识算法，其性能也依然会被虚拟机本身所限制。真正的吞吐量瓶颈在于状态机，要求 Transaction 由虚拟机解释会大大增加处理它们的计算复杂度。 - -### 安全性 - -安全性很难进行量化，而且不同区块链平台之间存在很大差异。以下是特定应用区块链所能带来的重要优势： - -- 与不成熟的智能合约编程语言相反，开发者可以在构建特定应用区块链时选择像 Golang 这种可靠性已被验证的编程语言。 - -- 开发者不会局限于底层虚拟机所提供的加密功能，他们可以使用自定义的加密技术，也可以依赖经过可靠审核的加密库。 - -- 开发者无需担心底层虚拟机中潜在的漏洞或可被利用的机制，从而可以更容易地确保应用程序的安全性。 - -### 主导权 - -特定应用区块链的一大好处是主导权。去中心化应用是一个涉及众多参与者的生态系统，如用户、开发者、第三方服务，等等。当开发者在多个去中心化应用共存的虚拟机区块链上开发应用程序时，出现的一个问题是围绕应用程序所组成的社区人群和底层链的社区人群并不是一样的，但后者却会在治理的过程中取代前者。如果应用程序中存在一个漏洞，或者需要上线新的功能，应用的 stakeholders 几乎没有任何办法升级代码。如果底层区块链社区拒绝执行，那应用程序就无法升级。 - -根本问题是应用程序的治理和网络治理并不是统一的，而这个问题可以通过特定应用区块链解决。因为特定应用区块链只专门运行单个应用程序，所以应用的 stakeholders 对整条链有完全的主导权。这能确保社区在漏洞被发现时不会卡住，而且有充分的自由去选择链和应用程序的演化方向。 diff --git a/docs/core/README.md b/docs/core/README.md deleted file mode 100644 index 94a993f5a5..0000000000 --- a/docs/core/README.md +++ /dev/null @@ -1,27 +0,0 @@ - - -# Core Concepts - -This repository contains reference documentation on the core concepts of the Cosmos SDK. - -1. [`BaseApp`](./baseapp.md) -1. [Transaction](./transactions.md) -1. [Context](./context.md) -1. [Node Client](./node.md) -1. [Store](./store.md) -1. [Encoding](./encoding.md) -1. [gRPC, REST and Tendermint Endpoints](./grpc_rest.md) -1. [Command-Line Interface](./cli.md) -1. [Events](./events.md) -1. [Telemetry](./telemetry.md) -1. [Object-Capabilities](./ocap.md) -1. [RunTx recovery middleware](./runtx_middleware.md) -1. [Simulation](./simulation.md) -1. [Protobuf documentation](./proto-docs.md) - -After reading about the core concepts, check the [IBC documentation](../ibc/README.md) to learn more -about the IBC core concepts and how to integrate it to you application. diff --git a/docs/core/baseapp.md b/docs/core/baseapp.md deleted file mode 100644 index 5d0fd115f3..0000000000 --- a/docs/core/baseapp.md +++ /dev/null @@ -1,398 +0,0 @@ - - -# BaseApp - -This document describes `BaseApp`, the abstraction that implements the core functionalities of an SDK application. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} -- [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq} - -## Introduction - -`BaseApp` is a base type that implements the core of an SDK application, namely: - -- The [Application Blockchain Interface](#abci), for the state-machine to communicate with the underlying consensus engine (e.g. Tendermint). -- [Service Routers](#service-routers), to route messages and queries to the appropriate module. -- Different [states](#states), as the state-machine can have different volatile states updated based on the ABCI message received. - -The goal of `BaseApp` is to provide the fundamental layer of an SDK application -that developers can easily extend to build their own custom application. Usually, -developers will create a custom type for their application, like so: - -```go -type App struct { - // reference to a BaseApp - *baseapp.BaseApp - - // list of application store keys - - // list of application keepers - - // module manager -} -``` - -Extending the application with `BaseApp` gives the former access to all of `BaseApp`'s methods. -This allows developers to compose their custom application with the modules they want, while not -having to concern themselves with the hard work of implementing the ABCI, the service routers and state -management logic. - -## Type Definition - -The `BaseApp` type holds many important parameters for any Cosmos SDK based application. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/baseapp.go#L46-L131 - -Let us go through the most important components. - -> **Note**: Not all parameters are described, only the most important ones. Refer to the -> type definition for the full list. - -First, the important parameters that are initialized during the bootstrapping of the application: - -- [`CommitMultiStore`](./store.md#commitmultistore): This is the main store of the application, - which holds the canonical state that is committed at the [end of each block](#commit). This store - is **not** cached, meaning it is not used to update the application's volatile (un-committed) states. - The `CommitMultiStore` is a multi-store, meaning a store of stores. Each module of the application - uses one or multiple `KVStores` in the multi-store to persist their subset of the state. -- Database: The `db` is used by the `CommitMultiStore` to handle data persistence. -- [`Msg` Service Router](#msg-service-router): The `msgServiceRouter` facilitates the routing of service `Msg`s to the appropriate - module for it to be processed. Here a service `Msg` refers to the transaction components that need to be - processed by the application in order to update the state, and not to ABCI messages which implement - the interface between the application and the underlying consensus engine. -- [gRPC Query Router](#grpc-query-router): The `grpcQueryRouter` facilitates the routing of gRPC queries to the - appropriate module for it to be processed. These queries are not ABCI messages themselves, but they - are relayed to the relevant module's gRPC `Query` service. -- [`TxDecoder`](https://godoc.org/github.com/cosmos/cosmos-sdk/types#TxDecoder): It is used to decode - raw transaction bytes relayed by the underlying Tendermint engine. -- [`ParamStore`](#paramstore): The parameter store used to get and set application consensus parameters. -- [`AnteHandler`](#antehandler): This handler is used to handle signature verification, fee payment, - and other pre-message execution checks when a transaction is received. It's executed during - [`CheckTx/RecheckTx`](#checktx) and [`DeliverTx`](#delivertx). -- [`InitChainer`](../basics/app-anatomy.md#initchainer), - [`BeginBlocker` and `EndBlocker`](../basics/app-anatomy.md#beginblocker-and-endblocker): These are - the functions executed when the application receives the `InitChain`, `BeginBlock` and `EndBlock` - ABCI messages from the underlying Tendermint engine. - -Then, parameters used to define [volatile states](#volatile-states) (i.e. cached states): - -- `checkState`: This state is updated during [`CheckTx`](#checktx), and reset on [`Commit`](#commit). -- `deliverState`: This state is updated during [`DeliverTx`](#delivertx), and set to `nil` on - [`Commit`](#commit) and gets re-initialized on BeginBlock. - -Finally, a few more important parameterd: - -- `voteInfos`: This parameter carries the list of validators whose precommit is missing, either - because they did not vote or because the proposer did not include their vote. This information is - carried by the [Context](#context) and can be used by the application for various things like - punishing absent validators. -- `minGasPrices`: This parameter defines the minimum gas prices accepted by the node. This is a - **local** parameter, meaning each full-node can set a different `minGasPrices`. It is used in the - `AnteHandler` during [`CheckTx`](#checktx), mainly as a spam protection mechanism. The transaction - enters the [mempool](https://tendermint.com/docs/tendermint-core/mempool.html#transaction-ordering) - only if the gas prices of the transaction are greater than one of the minimum gas price in - `minGasPrices` (e.g. if `minGasPrices == 1uatom,1photon`, the `gas-price` of the transaction must be - greater than `1uatom` OR `1photon`). -- `appVersion`: Version of the application. It is set in the - [application's constructor function](../basics/app-anatomy.md#constructor-function). - -## Constructor - -```go -func NewBaseApp( - name string, logger log.Logger, db dbm.DB, txDecoder sdk.TxDecoder, options ...func(*BaseApp), -) *BaseApp { - - // ... -} -``` - -The `BaseApp` constructor function is pretty straightforward. The only thing worth noting is the -possibility to provide additional [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/options.go) -to the `BaseApp`, which will execute them in order. The `options` are generally `setter` functions -for important parameters, like `SetPruning()` to set pruning options or `SetMinGasPrices()` to set -the node's `min-gas-prices`. - -Naturally, developers can add additional `options` based on their application's needs. - -## State Updates - -The `BaseApp` maintains two primary volatile states and a root or main state. The main state -is the canonical state of the application and the volatile states, `checkState` and `deliverState`, -are used to handle state transitions in-between the main state made during [`Commit`](#commit). - -Internally, there is only a single `CommitMultiStore` which we refer to as the main or root state. -From this root state, we derive two volatile state through a mechanism called _store branching_ (performed by `CacheWrap` function). -The types can be illustrated as follows: - -![Types](./baseapp_state_types.png) - -### InitChain State Updates - -During `InitChain`, the two volatile states, `checkState` and `deliverState` are set by branching -the root `CommitMultiStore`. Any subsequent reads and writes happen on branched versions of the `CommitMultiStore`. -To avoid unnecessary roundtrip to the main state, all reads to the branched store are cached. - -![InitChain](./baseapp_state-initchain.png) - -### CheckTx State Updates - -During `CheckTx`, the `checkState`, which is based off of the last committed state from the root -store, is used for any reads and writes. Here we only execute the `AnteHandler` and verify a service router -exists for every message in the transaction. Note, when we execute the `AnteHandler`, we branch -the already branched `checkState`. This has the side effect that if the `AnteHandler` fails, -the state transitions won't be reflected in the `checkState` -- i.e. `checkState` is only updated on -success. - -![CheckTx](./baseapp_state-checktx.png) - -### BeginBlock State Updates - -During `BeginBlock`, the `deliverState` is set for use in subsequent `DeliverTx` ABCI messages. The -`deliverState` is based off of the last committed state from the root store and is branched. -Note, the `deliverState` is set to `nil` on [`Commit`](#commit). - -![BeginBlock](./baseapp_state-begin_block.png) - -### DeliverTx State Updates - -The state flow for `DeliverTx` is nearly identical to `CheckTx` except state transitions occur on -the `deliverState` and messages in a transaction are executed. Similarly to `CheckTx`, state transitions -occur on a doubly branched state -- `deliverState`. Successful message execution results in -writes being committed to `deliverState`. Note, if message execution fails, state transitions from -the AnteHandler are persisted. - -![DeliverTx](./baseapp_state-deliver_tx.png) - -### Commit State Updates - -During `Commit` all the state transitions that occurred in the `deliverState` are finally written to -the root `CommitMultiStore` which in turn is committed to disk and results in a new application -root hash. These state transitions are now considered final. Finally, the `checkState` is set to the -newly committed state and `deliverState` is set to `nil` to be reset on `BeginBlock`. - -![Commit](./baseapp_state-commit.png) - -## ParamStore - -During `InitChain`, the `RequestInitChain` provides `ConsensusParams` which contains parameters -related to block execution such as maximum gas and size in addition to evidence parameters. If these -parameters are non-nil, they are set in the BaseApp's `ParamStore`. Behind the scenes, the `ParamStore` -is actually managed by an `x/params` module `Subspace`. This allows the parameters to be tweaked via -on-chain governance. - -## Service Routers - -When messages and queries are received by the application, they must be routed to the appropriate module in order to be processed. Routing is done via `BaseApp`, which holds a `msgServiceRouter` for messages, and a `grpcQueryRouter` for queries. - -### `Msg` Service Router - -[`Msg`s](#../building-modules/messages-and-queries.md#messages) need to be routed after they are extracted from transactions, which are sent from the underlying Tendermint engine via the [`CheckTx`](#checktx) and [`DeliverTx`](#delivertx) ABCI messages. To do so, `BaseApp` holds a `msgServiceRouter` which maps fully-qualified service methods (`string`, defined in each module's `Msg` Protobuf service) to the appropriate module's `Msg` server implementation. - -The [default `msgServiceRouter` included in `BaseApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/msg_service_router.go) is stateless. However, some applications may want to make use of more stateful routing mechanisms such as allowing governance to disable certain routes or point them to new modules for upgrade purposes. For this reason, the `sdk.Context` is also passed into each [route handler inside `msgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/msg_service_router.go#L31-L32). For a stateless router that doesn't want to make use of this, you can just ignore the `ctx`. - -The application's `msgServiceRouter` is initialized with all the routes using the application's [module manager](../building-modules/module-manager.md#manager) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/app-anatomy.md#app-constructor). - -### gRPC Query Router - -Similar to `Msg`s, [`queries`](../building-modules/messages-and-queries.md#queries) need to be routed to the appropriate module's [`Query` service](../building-modules/query-services.md). To do so, `BaseApp` holds a `grpcQueryRouter`, which maps modules' fully-qualified service methods (`string`, defined in their Protobuf `Query` gRPC) to their `Query` server implementation. The `grpcQueryRouter` is called during the initial stages of query processing, which can be either by directly sending a gRPC query to the gRPC endpoint, or via the [`Query` ABCI message](#query) on the Tendermint RPC endpoint. - -Just like the `msgServiceRouter`, the `grpcQueryRouter` is initialized with all the query routes using the application's [module manager](../building-modules/module-manager.md) (via the `RegisterServices` method), which itself is initialized with all the application's modules in the application's [constructor](../basics/app-anatomy.md#app-constructor). - -## Main ABCI Messages - -The [Application-Blockchain Interface](https://tendermint.com/docs/spec/abci/) (ABCI) is a generic interface that connects a state-machine with a consensus engine to form a functional full-node. It can be wrapped in any language, and needs to be implemented by each application-specific blockchain built on top of an ABCI-compatible consensus engine like Tendermint. - -The consensus engine handles two main tasks: - -- The networking logic, which mainly consists in gossiping block parts, transactions and consensus votes. -- The consensus logic, which results in the deterministic ordering of transactions in the form of blocks. - -It is **not** the role of the consensus engine to define the state or the validity of transactions. Generally, transactions are handled by the consensus engine in the form of `[]bytes`, and relayed to the application via the ABCI to be decoded and processed. At keys moments in the networking and consensus processes (e.g. beginning of a block, commit of a block, reception of an unconfirmed transaction, ...), the consensus engine emits ABCI messages for the state-machine to act on. - -Developers building on top of the Cosmos SDK need not implement the ABCI themselves, as `BaseApp` comes with a built-in implementation of the interface. Let us go through the main ABCI messages that `BaseApp` implements: [`CheckTx`](#checktx) and [`DeliverTx`](#delivertx) - -### CheckTx - -`CheckTx` is sent by the underlying consensus engine when a new unconfirmed (i.e. not yet included in a valid block) -transaction is received by a full-node. The role of `CheckTx` is to guard the full-node's mempool -(where unconfirmed transactions are stored until they are included in a block) from spam transactions. -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 them lightweight. In the Cosmos SDK, after [decoding transactions](./encoding.md), `CheckTx()` is implemented -to do the following checks: - -1. Extract the `Msg`s from the transaction. -2. Perform _stateless_ checks by calling `ValidateBasic()` on each of the `Msg`s. This is done - first, as _stateless_ checks are less computationally expensive than _stateful_ checks. If - `ValidateBasic()` fail, `CheckTx` returns before running _stateful_ checks, which saves resources. -3. Perform non-module related _stateful_ checks on the [account](../basics/accounts.md). This step is mainly about checking - that the `Msg` signatures are valid, that enough fees are provided and that the sending account - has enough funds to pay for said fees. Note that no precise [`gas`](../basics/gas-fees.md) counting occurs here, - as `Msg`s are not processed. Usually, the [`AnteHandler`](../basics/gas-fees.md#antehandler) will check that the `gas` provided - with the transaction is superior to a minimum reference gas amount based on the raw transaction size, - in order to avoid spam with transactions that provide 0 gas. -4. Ensure that each `Msg`'s fully-qualified service method matches on of the routes inside the `msgServiceRouter`, but do **not** actually - process `Msg`s. `Msg`s only need to be processed when the canonical state need to be updated, - which happens during `DeliverTx`. - -Steps 2. and 3. are performed by the [`AnteHandler`](../basics/gas-fees.md#antehandler) in the [`RunTx()`](#runtx-antehandler-and-runmsgs) -function, which `CheckTx()` calls with the `runTxModeCheck` mode. During each step of `CheckTx()`, a -special [volatile state](#volatile-states) called `checkState` is updated. This state is used to keep -track of the temporary changes triggered by the `CheckTx()` calls of each transaction without modifying -the [main canonical state](#main-state) . For example, when a transaction goes through `CheckTx()`, the -transaction's fees are deducted from the sender's account in `checkState`. If a second transaction is -received from the same account before the first is processed, and the account has consumed all its -funds in `checkState` during the first transaction, the second transaction will fail `CheckTx`() and -be rejected. In any case, the sender's account will not actually pay the fees until the transaction -is actually included in a block, because `checkState` never gets committed to the main state. The -`checkState` is reset to the latest state of the main state each time a blocks gets [committed](#commit). - -`CheckTx` returns a response to the underlying consensus engine of type [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages). -The response contains: - -- `Code (uint32)`: Response Code. `0` if successful. -- `Data ([]byte)`: Result bytes, if any. -- `Log (string):` The output of the application's logger. May be non-deterministic. -- `Info (string):` Additional information. May be non-deterministic. -- `GasWanted (int64)`: Amount of gas requested for transaction. It is provided by users when they generate the transaction. -- `GasUsed (int64)`: Amount of gas consumed by transaction. During `CheckTx`, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction. Next is an example: - +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/auth/ante/basic.go#L104 -- `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./events.md) for more. -- `Codespace (string)`: Namespace for the Code. - -#### RecheckTx - -After `Commit`, `CheckTx` is run again on all transactions that remain in the node's local mempool -after filtering those included in the block. To prevent the mempool from rechecking all transactions -every time a block is committed, the configuration option `mempool.recheck=false` can be set. As of -Tendermint v0.32.1, an additional `Type` parameter is made available to the `CheckTx` function that -indicates whether an incoming transaction is new (`CheckTxType_New`), or a recheck (`CheckTxType_Recheck`). -This allows certain checks like signature verification can be skipped during `CheckTxType_Recheck`. - -### DeliverTx - -When the underlying consensus engine receives a block proposal, each transaction in the block needs to be processed by the application. To that end, the underlying consensus engine sends a `DeliverTx` message to the application for each transaction in a sequential order. - -Before the first transaction of a given block is processed, a [volatile state](#volatile-states) called `deliverState` is intialized during [`BeginBlock`](#beginblock). This state is updated each time a transaction is processed via `DeliverTx`, and committed to the [main state](#main-state) when the block is [committed](#commit), after what is is set to `nil`. - -`DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: - -1. The `AnteHandler` does **not** check that the transaction's `gas-prices` is sufficient. That is because the `min-gas-prices` value `gas-prices` is checked against is local to the node, and therefore what is enough for one full-node might not be for another. This means that the proposer can potentially include transactions for free, although they are not incentivised to do so, as they earn a bonus on the total fee of the block they propose. -2. For each `Msg` in the transaction, route to the appropriate module's [`Msg` service](../building-modules/msg-services.md). Additional _stateful_ checks are performed, and the branched multistore held in `deliverState`'s `context` is updated by the module's `keeper`. If the `Msg` service returns successfully, the branched multistore held in `context` is written to `deliverState` `CacheMultiStore`. - -During the additional fifth step outlined in (2), each read/write to the store increases the value of `GasConsumed`. You can find the default cost of each operation: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/store/types/gas.go#L153-L162 - -At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx` fails. - -`DeliverTx` returns a response to the underlying consensus engine of type [`abci.ResponseDeliverTx`](https://tendermint.com/docs/spec/abci/abci.html#delivertx). The response contains: - -- `Code (uint32)`: Response Code. `0` if successful. -- `Data ([]byte)`: Result bytes, if any. -- `Log (string):` The output of the application's logger. May be non-deterministic. -- `Info (string):` Additional information. May be non-deterministic. -- `GasWanted (int64)`: Amount of gas requested for transaction. It is provided by users when they generate the transaction. -- `GasUsed (int64)`: Amount of gas consumed by transaction. During `DeliverTx`, this value is computed by multiplying the standard cost of a transaction byte by the size of the raw transaction, and by adding gas each time a read/write to the store occurs. -- `Events ([]cmn.KVPair)`: Key-Value tags for filtering and indexing transactions (eg. by account). See [`event`s](./events.md) for more. -- `Codespace (string)`: Namespace for the Code. - -## RunTx, AnteHandler and RunMsgs - -### RunTx - -`RunTx` is called from `CheckTx`/`DeliverTx` to handle the transaction, with `runTxModeCheck` or `runTxModeDeliver` as parameter to differentiate between the two modes of execution. Note that when `RunTx` receives a transaction, it has already been decoded. - -The first thing `RunTx` does upon being called is to retrieve the `context`'s `CacheMultiStore` by calling the `getContextForTx()` function with the appropriate mode (either `runTxModeCheck` or `runTxModeDeliver`). This `CacheMultiStore` is a branch of the main store, with cache functionality (for query requests), instantiated during `BeginBlock` for `DeliverTx` and during the `Commit` of the previous block for `CheckTx`. After that, two `defer func()` are called for [`gas`](../basics/gas-fees.md) management. They are executed when `runTx` returns and make sure `gas` is actually consumed, and will throw errors, if any. - -After that, `RunTx()` calls `ValidateBasic()` on each `Msg`in the `Tx`, which runs preliminary _stateless_ validity checks. If any `Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. - -Then, the [`anteHandler`](#antehandler) of the application is run (if it exists). In preparation of this step, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/baseapp.go#L623-L630 - -This allows `RunTx` not to commit the changes made to the state during the execution of `anteHandler` if it ends up failing. It also prevents the module implementing the `anteHandler` from writing to state, which is an important part of the [object-capabilities](./ocap.md) of the Cosmos SDK. - -Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `Msg`s in the `Tx`. In preparation of this step, just like with the `anteHandler`, both the `checkState`/`deliverState`'s `context` and `context`'s `CacheMultiStore` are branched using the `cacheTxContext()` function. - -### AnteHandler - -The `AnteHandler` is a special handler that implements the `AnteHandler` interface and is used to authenticate the transaction before the transaction's internal messages are processed. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/handler.go#L6-L8 - -The `AnteHandler` is theoretically optional, but still a very important component of public blockchain networks. It serves 3 primary purposes: - -- Be a primary line of defense against spam and second line of defense (the first one being the mempool) against transaction replay with fees deduction and [`sequence`](./transactions.md#transaction-generation) checking. -- Perform preliminary _stateful_ validity checks like ensuring signatures are valid or that the sender has enough funds to pay for fees. -- Play a role in the incentivisation of stakeholders via the collection of transaction fees. - -`BaseApp` holds an `anteHandler` as paraemter, which is initialized in the [application's constructor](../basics/app-anatomy.md#application-constructor). The most widely used `anteHandler` today is that of the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/master/x/auth/ante/ante.go). - -Click [here](../basics/gas-fees.md#antehandler) for more on the `anteHandler`. - -### RunMsgs - -`RunMsgs` is called from `RunTx` with `runTxModeCheck` as parameter to check the existence of a route for each message the transaction, and with `runTxModeDeliver` to actually process the `Msg`s. - -First, it retrieves the `Msg`'s fully-qualified service method name, by checking the `type_url` of the Protobuf `Any` representing the service `Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of this fully-qualified service method. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. If instead `mode == runTxModeDeliver`, the [`Msg` server](../building-modules/msg-services.md) implementation for the message is executed, before `RunMsgs` returns. - -## Other ABCI Messages - -### InitChain - -The [`InitChain` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#initchain) is sent from the underlying Tendermint engine when the chain is first started. It is mainly used to **initialize** parameters and state like: - -- [Consensus Parameters](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters) via `setConsensusParams`. -- [`checkState` and `deliverState`](#volatile-states) via `setCheckState` and `setDeliverState`. -- The [block gas meter](../basics/gas-fees.md#block-gas-meter), with infinite gas to process genesis transactions. - -Finally, the `InitChain(req abci.RequestInitChain)` method of `BaseApp` calls the [`initChainer()`](../basics/app-anatomy.md#initchainer) of the application in order to initialize the main state of the application from the `genesis file` and, if defined, call the [`InitGenesis`](../building-modules/genesis.md#initgenesis) function of each of the application's modules. - -### BeginBlock - -The [`BeginBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#beginblock) is sent from the underlying Tendermint engine when a block proposal created by the correct proposer is received, before [`DeliverTx`](#delivertx) is run for each transaction in the block. It allows developers to have logic be executed at the beginning of each block. In the Cosmos SDK, the `BeginBlock(req abci.RequestBeginBlock)` method does the following: - -- Initialize [`deliverState`](#volatile-states) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setDeliverState` function. - +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/baseapp/baseapp.go#L387-L397 - This function also resets the [main gas meter](../basics/gas-fees.md#main-gas-meter). -- Initialize the [block gas meter](../basics/gas-fees.md#block-gas-meter) with the `maxGas` limit. The `gas` consumed within the block cannot go above `maxGas`. This parameter is defined in the application's consensus parameters. -- Run the application's [`beginBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`BeginBlocker()`](../building-modules/beginblock-endblock.md#beginblock) method of each of the application's modules. -- Set the [`VoteInfos`](https://tendermint.com/docs/app-dev/abci-spec.html#voteinfo) of the application, i.e. the list of validators whose _precommit_ for the previous block was included by the proposer of the current block. This information is carried into the [`Context`](./context.md) so that it can be used during `DeliverTx` and `EndBlock`. - -### EndBlock - -The [`EndBlock` ABCI message](#https://tendermint.com/docs/app-dev/abci-spec.html#endblock) is sent from the underlying Tendermint engine after [`DeliverTx`](#delivertx) as been run for each transaction in the block. It allows developers to have logic be executed at the end of each block. In the Cosmos SDK, the bulk `EndBlock(req abci.RequestEndBlock)` method is to run the application's [`EndBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock), which mainly runs the [`EndBlocker()`](../building-modules/beginblock-endblock.md#beginblock) method of each of the application's modules. - -### Commit - -The [`Commit` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#commit) is sent from the underlying Tendermint engine after the full-node has received _precommits_ from 2/3+ of validators (weighted by voting power). On the `BaseApp` end, the `Commit(res abci.ResponseCommit)` function is implemented to commit all the valid state transitions that occured during `BeginBlock`, `DeliverTx` and `EndBlock` and to reset state for the next block. - -To commit state-transitions, the `Commit` function calls the `Write()` function on `deliverState.ms`, where `deliverState.ms` is a branched multistore of the main store `app.cms`. Then, the `Commit` function sets `checkState` to the latest header (obtbained from `deliverState.ctx.BlockHeader`) and `deliverState` to `nil`. - -Finally, `Commit` returns the hash of the commitment of `app.cms` back to the underlying consensus engine. This hash is used as a reference in the header of the next block. - -### Info - -The [`Info` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#info) is a simple query from the underlying consensus engine, notably used to sync the latter with the application during a handshake that happens on startup. When called, the `Info(res abci.ResponseInfo)` function from `BaseApp` will return the application's name, version and the hash of the last commit of `app.cms`. - -### Query - -The [`Query` ABCI message](https://tendermint.com/docs/app-dev/abci-spec.html#query) is used to serve queries received from the underlying consensus engine, including queries received via RPC like Tendermint RPC. It used to be the main entrypoint to build interfaces with the application, but with the introduction of [gRPC queries](../building-modules/query-services.md) in Cosmos SDK v0.40, its usage is more limited. The application must respect a few rules when implementing the `Query` method, which are outlined [here](https://tendermint.com/docs/app-dev/abci-spec.html#query). - -Each Tendermint `query` comes with a `path`, which is a `string` which denotes what to query. If the `path` matches a gRPC fully-qualified service method, then `BaseApp` will defer the query to the `grpcQueryRouter` and let it handle it like explained [above](#grpc-query-router). Otherwise, the `path` represents a query that is not (yet) handled by the gRPC router. `BaseApp` splits the `path` string with the `/` delimiter. By convention, the first element of the splitted string (`splitted[0]`) contains the category of `query` (`app`, `p2p`, `store` or `custom` ). The `BaseApp` implementation of the `Query(req abci.RequestQuery)` method is a simple dispatcher serving these 4 main categories of queries: - -- Application-related queries like querying the application's version, which are served via the `handleQueryApp` method. -- Direct queries to the multistore, which are served by the `handlerQueryStore` method. These direct queryeis are different from custom queries which go through `app.queryRouter`, and are mainly used by third-party service provider like block explorers. -- P2P queries, which are served via the `handleQueryP2P` method. These queries return either `app.addrPeerFilter` or `app.ipPeerFilter` that contain the list of peers filtered by address or IP respectively. These lists are first initialized via `options` in `BaseApp`'s [constructor](#constructor). -- Custom queries, which encompass legacy queries (before the introduction of gRPC queries), are served via the `handleQueryCustom` method. The `handleQueryCustom` branches the multistore before using the `queryRoute` obtained from `app.queryRouter` to map the query to the appropriate module's [legacy `querier`](../building-modules/query-services.md#legacy-queriers). - -## Next {hide} - -Learn more about [transactions](./transactions.md) {hide} diff --git a/docs/core/baseapp_state-begin_block.png b/docs/core/baseapp_state-begin_block.png deleted file mode 100644 index 745d4a5a97..0000000000 Binary files a/docs/core/baseapp_state-begin_block.png and /dev/null differ diff --git a/docs/core/baseapp_state-checktx.png b/docs/core/baseapp_state-checktx.png deleted file mode 100644 index 38b217acdd..0000000000 Binary files a/docs/core/baseapp_state-checktx.png and /dev/null differ diff --git a/docs/core/baseapp_state-commit.png b/docs/core/baseapp_state-commit.png deleted file mode 100644 index b23c731252..0000000000 Binary files a/docs/core/baseapp_state-commit.png and /dev/null differ diff --git a/docs/core/baseapp_state-deliver_tx.png b/docs/core/baseapp_state-deliver_tx.png deleted file mode 100644 index f0a54b4ec3..0000000000 Binary files a/docs/core/baseapp_state-deliver_tx.png and /dev/null differ diff --git a/docs/core/baseapp_state-initchain.png b/docs/core/baseapp_state-initchain.png deleted file mode 100644 index d03e88ef2a..0000000000 Binary files a/docs/core/baseapp_state-initchain.png and /dev/null differ diff --git a/docs/core/baseapp_state_types.png b/docs/core/baseapp_state_types.png deleted file mode 100644 index a7f91a6093..0000000000 Binary files a/docs/core/baseapp_state_types.png and /dev/null differ diff --git a/docs/core/cli.md b/docs/core/cli.md deleted file mode 100644 index a09b81407c..0000000000 --- a/docs/core/cli.md +++ /dev/null @@ -1,143 +0,0 @@ - - -# Command-Line Interface - -This document describes how commmand-line interface (CLI) works on a high-level, for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](../building-modules/module-interfaces.md#cli). {synopsis} - -## Command-Line Interface - -### Example Command - -There is no set way to create a CLI, but SDK modules typically use the [Cobra Library](https://github.com/spf13/cobra). Building a CLI with Cobra entails defining commands, arguments, and flags. [**Commands**](#commands) understand the actions users wish to take, such as `tx` for creating a transaction and `query` for querying the application. Each command can also have nested subcommands, necessary for naming the specific transaction type. Users also supply **Arguments**, such as account numbers to send coins to, and [**Flags**](#flags) to modify various aspects of the commands, such as gas prices or which node to broadcast to. - -Here is an example of a command a user might enter to interact with the simapp CLI `simd` in order to send some tokens: - -```bash -simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --gas auto --gas-prices -``` - -The first four strings specify the command: - -- The root command for the entire application `simd`. -- The subcommand `tx`, which contains all commands that let users create transactions. -- The subcommand `bank` to indicate which module to route the command to ([`x/bank`](../../x/bank/spec/README.md) module in this case). -- The type of transaction `send`. - -The next two strings are arguments: the `from_address` the user wishes to send from, the `to_address` of the recipient, and the `amount` they want to send. Finally, the last few strings of the command are optional flags to indicate how much the user is willing to pay in fees (calculated using the amount of gas used to execute the transaction and the gas prices provided by the user). - -The CLI interacts with a [node](../core/node.md) to handle this command. The interface itself is defined in a `main.go` file. - -### Building the CLI - -The `main.go` file needs to have a `main()` function that creates a root command, to which all the application commands will be added as subcommands. The root command additionally handles: - -- **setting configurations** by reading in configuration files (e.g. the sdk config file). -- **adding any flags** to it, such as `--chain-id`. -- **instantiating the `codec`** by calling the application's `MakeCodec()` function (called `MakeTestEncodingConfig` in `simapp`). The [`codec`](../core/encoding.md) is used to encode and decode data structures for the application - stores can only persist `[]byte`s so the developer must define a serialization format for their data structures or use the default, Protobuf. -- **adding subcommand** for all the possible user interactions, including [transaction commands](#transaction-commands) and [query commands](#query-commands). - -The `main()` function finally creates an executor and [execute](https://godoc.org/github.com/spf13/cobra#Command.Execute) the root command. See an example of `main()` function from the `simapp` application: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/main.go#L12-L24 - -The rest of the document will detail what needs to be implemented for each step and include smaller portions of code from the `simapp` CLI files. - -## Adding Commands to the CLI - -Every application CLI first constructs a root command, then adds functionality by aggregating subcommands (often with further nested subcommands) using `rootCmd.AddCommand()`. The bulk of an application's unique capabilities lies in its transaction and query commands, called `TxCmd` and `QueryCmd` respectively. - -### Root Command - -The root command (called `rootCmd`) is what the user first types into the command line to indicate which application they wish to interact with. The string used to invoke the command (the "Use" field) is typically the name of the application suffixed with `-d`, e.g. `simd` or `gaiad`. The root command typically includes the following commands to support basic functionality in the application. - -- **Status** command from the SDK rpc client tools, which prints information about the status of the connected [`Node`](../core/node.md). The Status of a node includes `NodeInfo`,`SyncInfo` and `ValidatorInfo`. -- **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys) from the SDK client tools, which includes a collection of subcommands for using the key functions in the SDK crypto tools, including adding a new key and saving it to the keyring, listing all public keys stored in the keyring, and deleting a key. For example, users can type `simd keys add ` to add a new key and save an encrypted copy to the keyring, using the flag `--recover` to recover a private key from a seed phrase or the flag `--multisig` to group multiple keys together to create a multisig key. For full details on the `add` key command, see the code [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys/add.go). For more details about usage of `--keyring-backend` for storage of key credentials look at the [keyring docs](../run-node/keyring.md). -- **Server** commands from the SDK server package. These commands are responsible for providing the mechanisms necessary to start an ABCI Tendermint application and provides the CLI framework (based on [cobra](github.com/spf13/cobra)) necessary to fully bootstrap an application. The package exposes two core functions: `StartCmd` and `ExportCmd` which creates commands to start the application and export state respectively. Click [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/server) to learn more. -- [**Transaction**](#transaction-commands) commands. -- [**Query**](#query-commands) commands. - -Next is an example `rootCmd` function from the `simapp` application. It instantiates the root command, adds a [_persistent_ flag](#flags) and `PreRun` function to be run before every execution, and adds all of the necessary subcommands. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L37-L93 - -The root-level `status` and `keys` subcommands are common across most applications and do not interact with application state. The bulk of an application's functionality - what users can actually _do_ with it - is enabled by its `tx` and `query` commands. - -### Transaction Commands - -[Transactions](./transactions.md) are objects wrapping [`Msg`s](../building-modules/messages-and-queries.md#messages) that trigger state changes. To enable the creation of transactions using the CLI interface, a function `txCmd` is generally added to the `rootCmd`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L86-L92 - -This `txCmd` function adds all the transaction available to end-users for the application. This typically includes: - -- **Sign command** from the [`auth`](../../x/auth/spec/README.md) module that signs messages in a transaction. To enable multisig, add the `auth` module's `MultiSign` command. Since every transaction requires some sort of signature in order to be valid, thithe signing command is necessary for every application. -- **Broadcast command** from the SDK client tools, to broadcast transactions. -- **All [module transaction commands](../building-modules/module-interfaces.md#transaction-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/module-manager.md#basic-manager) `AddTxCommands()` function. - -Here is an example of a `txCmd` aggregating these subcommands from the `simapp` application: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L123-L149 - -### Query Commands - -[**Queries**](../building-modules/messages-and-queries.md#queries) are objects that allow users to retrieve information about the application's state. To enable the creation of transactions using the CLI interface, a function `txCmd` is generally added to the `rootCmd`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L86-L92 - -This `queryCmd` function adds all the queries available to end-users for the application. This typically includes: - -- **QueryTx** and/or other transaction query commands] from the `auth` module which allow the user to search for a transaction by inputting its hash, a list of tags, or a block height. These queries allow users to see if transactions have been included in a block. -- **Account command** from the `auth` module, which displays the state (e.g. account balance) of an account given an address. -- **Validator command** from the SDK rpc client tools, which displays the validator set of a given height. -- **Block command** from the SDK rpc client tools, which displays the block data for a given height. -- **All [module query commands](../building-modules/module-interfaces.md#query-commands)** the application is dependent on, retrieved by using the [basic module manager's](../building-modules/module-manager.md#basic-manager) `AddQueryCommands()` function. - -Here is an example of a `queryCmd` aggregating subcommands from the `simapp` application: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L99-L121 - -## Flags - -Flags are used to modify commands; developers can include them in a `flags.go` file with their CLI. Users can explicitly include them in commands or pre-configure them by inside their [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). Commonly pre-configured flags include the `--node` to connect to and `--chain-id` of the blockchain the user wishes to interact with. - -A _persistent_ flag (as opposed to a _local_ flag) added to a command transcends all of its children: subcommands will inherit the configured values for these flags. Additionally, all flags have default values when they are added to commands; some toggle an option off but others are empty values that the user needs to override to create valid commands. A flag can be explicitly marked as _required_ so that an error is automatically thrown if the user does not provide a value, but it is also acceptable to handle unexpected missing flags differently. - -Flags are added to commands directly (generally in the [module's CLI file](../building-modules/module-interfaces.md#flags) where module commands are defined) and no flag except for the `rootCmd` persistent flags has to be added at application level. It is common to add a _persistent_ flag for `--chain-id`, the unique identifier of the blockchain the application pertains to, to the root command. Adding this flag can be done in the `main()` function. Adding this flag makes sense as the chain ID should not be changing across commands in this application CLI. Here is an example from the `simapp` application: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L118 - -## Environment variables - -Each flag is bound to it's respecteve named environment variable. Then name of the environment variable consist of two parts - capital case `basename` followed by flag name of the flag. `-` must be substituted with `_`. For example flag `--home` for application with basename `GAIA` is bound to `GAIA_HOME`. It allows to reduce amount of flags typed for routine operations. For example instead of: -```sh -gaia --home=./ --node= --chain-id="testchain-1" --keyring-backend=test tx ... --from= -``` -this will be more convinient: -```sh -# define env variables in .env, .envrc etc -GAIA_HOME= -GAIA_NODE= -GAIA_CHAIN_ID="testchain-1" -GAIA_KEYRING_BACKEND="test" - -# and later just use -gaia tx ... --from= -``` - -## Configurations - -It is vital that the root command of an application uses `PersistentPreRun()` cobra command property for executing the command, so all child commands have access to the server and client contexts. These contexts are set as their default values initially and maybe modified, scoped to the command, in their respective `PersistentPreRun()` functions. Note that the `client.Context` is typically pre-populated with "default" values that may be useful for all commands to inherit and override if necessary. - -Here is an example of an `PersistentPreRun()` function from `simapp``: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L54-L60 - -The `SetCmdClientContextHandler` call reads persistent flags via `ReadPersistentCommandFlags` which creates a `client.Context` and sets that on the root command's `Context`. - -The `InterceptConfigsPreRunHandler` call creates a viper literal, default `server.Context`, and a logger and sets that on the root command's `Context`. The `server.Context` will be modified and saved to disk via the internal `interceptConfigs` call, which either reads or creates a Tendermint configuration based on the home path provided. In addition, `interceptConfigs` also reads and loads the application configuration, `app.toml`, and binds that to the `server.Context` viper literal. This is vital so the application can get access to not only the CLI flags, but also to the application configuration values provided by this file. - -## Next {hide} - -Learn about [events](./events.md) {hide} diff --git a/docs/core/context.md b/docs/core/context.md deleted file mode 100644 index c9e89b16a4..0000000000 --- a/docs/core/context.md +++ /dev/null @@ -1,104 +0,0 @@ - - -# Context - -The `context` is a data structure intended to be passed from function to function that carries information about the current state of the application. It provides an access to a branched storage (a safe branch of the entire state) as well as useful objects and information like `gasMeter`, `block height`, `consensus parameters` and more. {synopsis} - -## Pre-requisites Readings - -- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq} -- [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq} - -## Context Definition - -The SDK `Context` is a custom data structure that contains Go's stdlib [`context`](https://golang.org/pkg/context) as its base, and has many additional types within its definition that are specific to the Cosmos SDK. he `Context` is integral to transaction processing in that it allows modules to easily access their respective [store](./store.md#base-layer-kvstores) in the [`multistore`](./store.md#multistore) and retrieve transactional context such as the block header and gas meter. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/context.go#L16-L39 - -- **Context:** The base type is a Go [Context](https://golang.org/pkg/context), which is explained further in the [Go Context Package](#go-context-package) section below. -- **Multistore:** Every application's `BaseApp` contains a [`CommitMultiStore`](./store.md#multistore) which is provided when a `Context` is created. Calling the `KVStore()` and `TransientStore()` methods allows modules to fetch their respective [`KVStore`](./store.md#base-layer-kvstores) using their unique `StoreKey`. -- **ABCI Header:** The [header](https://tendermint.com/docs/spec/abci/abci.html#header) is an ABCI type. It carries important information about the state of the blockchain, such as block height and proposer of the current block. -- **Chain ID:** The unique identification number of the blockchain a block pertains to. -- **Transaction Bytes:** The `[]byte` representation of a transaction being processed using the context. Every transaction is processed by various parts of the SDK and consensus engine (e.g. Tendermint) throughout its [lifecycle](../basics/tx-lifecycle.md), some of which to not have any understanding of transaction types. Thus, transactions are marshaled into the generic `[]byte` type using some kind of [encoding format](./encoding.md) such as [Amino](./encoding.md). -- **Logger:** A `logger` from the Tendermint libraries. Learn more about logs [here](https://tendermint.com/docs/tendermint-core/how-to-read-logs.html#how-to-read-logs). Modules call this method to create their own unique module-specific logger. -- **VoteInfo:** A list of the ABCI type [`VoteInfo`](https://tendermint.com/docs/spec/abci/abci.html#voteinfo), which includes the name of a validator and a boolean indicating whether they have signed the block. -- **Gas Meters:** Specifically, a [`gasMeter`](../basics/gas-fees.md#main-gas-meter) for the transaction currently being processed using the context and a [`blockGasMeter`](../basics/gas-fees.md#block-gas-meter) for the entire block it belongs to. Users specify how much in fees they wish to pay for the execution of their transaction; these gas meters keep track of how much [gas](../basics/gas-fees.md) has been used in the transaction or block so far. If the gas meter runs out, execution halts. -- **CheckTx Mode:** A boolean value indicating whether a transaction should be processed in `CheckTx` or `DeliverTx` mode. -- **Min Gas Price:** The minimum [gas](../basics/gas-fees.md) price a node is willing to take in order to include a transaction in its block. This price is a local value configured by each node individually, and should therefore **not be used in any functions used in sequences leading to state-transitions**. -- **Consensus Params:** The ABCI type [Consensus Parameters](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters), which specify certain limits for the blockchain, such as maximum gas for a block. -- **Event Manager:** The event manager allows any caller with access to a `Context` to emit [`Events`](./events.md). Modules may define module specific - `Events` by defining various `Types` and `Attributes` or use the common definitions found in `types/`. Clients can subscribe or query for these `Events`. These `Events` are collected throughout `DeliverTx`, `BeginBlock`, and `EndBlock` and are returned to Tendermint for indexing. For example: - -```go -ctx.EventManager().EmitEvent(sdk.NewEvent( - sdk.EventTypeMessage, - sdk.NewAttribute(sdk.AttributeKeyModule, types.AttributeValueCategory)), -) -``` - -## Go Context Package - -A basic `Context` is defined in the [Golang Context Package](https://golang.org/pkg/context). A `Context` -is an immutable data structure that carries request-scoped data across APIs and processes. Contexts -are also designed to enable concurrency and to be used in goroutines. - -Contexts are intended to be **immutable**; they should never be edited. Instead, the convention is -to create a child context from its parent using a `With` function. For example: - -```go -childCtx = parentCtx.WithBlockHeader(header) -``` - -The [Golang Context Package](https://golang.org/pkg/context) documentation instructs developers to -explicitly pass a context `ctx` as the first argument of a process. - -## Store branching - -The `Context` contains a `MultiStore`, which allows for branchinig and caching functionality using `CacheMultiStore` -(queries in `CacheMultiStore` are cached to avoid future round trips). -Each `KVStore` is branched in a safe and isolated ephemeral storage. Processes are free to write changes to -the `CacheMultiStore`. If a state-transition sequence is performed without issue, the store branch can -be committed to the underlying store at the end of the sequence or disregard them if something -goes wrong. The pattern of usage for a Context is as follows: - -1. A process receives a Context `ctx` from its parent process, which provides information needed to - perform the process. -2. The `ctx.ms` is a **branched store**, i.e. a branch of the [multistore](./store.md#multistore) is made so that the process can make changes to the state as it executes, without changing the original`ctx.ms`. This is useful to protect the underlying multistore in case the changes need to be reverted at some point in the execution. -3. The process may read and write from `ctx` as it is executing. It may call a subprocess and pass - `ctx` to it as needed. -4. When a subprocess returns, it checks if the result is a success or failure. If a failure, nothing - needs to be done - the branch `ctx` is simply discarded. If successful, the changes made to - the `CacheMultiStore` can be committed to the original `ctx.ms` via `Write()`. - -For example, here is a snippet from the [`runTx`](./baseapp.md#runtx-and-runmsgs) function in -[`baseapp`](./baseapp.md): - -```go -runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) -result = app.runMsgs(runMsgCtx, msgs, mode) -result.GasWanted = gasWanted - -if mode != runTxModeDeliver { - return result -} - -if result.IsOK() { - msCache.Write() -} -``` - -Here is the process: - -1. Prior to calling `runMsgs` on the message(s) in the transaction, it uses `app.cacheTxContext()` - to branch and cache the context and multistore. -2. `runMsgCtx` - the context with branched store, is used in `runMsgs` to return a result. -3. If the process is running in [`checkTxMode`](./baseapp.md#checktx), there is no need to write the - changes - the result is returned immediately. -4. If the process is running in [`deliverTxMode`](./baseapp.md#delivertx) and the result indicates - a successful run over all the messages, the branched multistore is written back to the original. - -## Next {hide} - -Learn about the [node client](./node.md) {hide} diff --git a/docs/core/encoding.md b/docs/core/encoding.md deleted file mode 100644 index a4cbddc2ac..0000000000 --- a/docs/core/encoding.md +++ /dev/null @@ -1,154 +0,0 @@ - - -# Encoding - -While encoding in the SDK used to be mainly handled by `go-amino` codec, the SDK is moving towards using `gogoprotobuf` for both state and client-side encoding. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} - -## Encoding - -The Cosmos SDK utilizes two binary wire encoding protocols, [Amino](https://github.com/tendermint/go-amino/) which is an object encoding specification and [Protocol Buffers](https://developers.google.com/protocol-buffers), a subset of Proto3 with an extension for -interface support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3) -for more information on Proto3, which Amino is largely compatible with (but not with Proto2). - -Due to Amino having significant performance drawbacks, being reflection-based, and -not having any meaningful cross-language/client support, Protocol Buffers, specifically -[gogoprotobuf](https://github.com/gogo/protobuf/), is being used in place of Amino. -Note, this process of using Protocol Buffers over Amino is still an ongoing process. - -Binary wire encoding of types in the Cosmos SDK can be broken down into two main -categories, client encoding and store encoding. Client encoding mainly revolves -around transaction processing and signing, whereas store encoding revolves around -types used in state-machine transitions and what is ultimately stored in the Merkle -tree. - -For store encoding, protobuf definitions can exist for any type and will typically -have an Amino-based "intermediary" type. Specifically, the protobuf-based type -definition is used for serialization and persistence, whereas the Amino-based type -is used for business logic in the state-machine where they may converted back-n-forth. -Note, the Amino-based types may slowly be phased-out in the future so developers -should take note to use the protobuf message definitions where possible. - -In the `codec` package, there exists two core interfaces, `Marshaler` and `ProtoMarshaler`, -where the former encapsulates the current Amino interface except it operates on -types implementing the latter instead of generic `interface{}` types. - -In addition, there exists two implementations of `Marshaler`. The first being -`AminoCodec`, where both binary and JSON serialization is handled via Amino. The -second being `ProtoCodec`, where both binary and JSON serialization is handled -via Protobuf. - -This means that modules may use Amino or Protobuf encoding but the types must -implement `ProtoMarshaler`. If modules wish to avoid implementing this interface -for their types, they may use an Amino codec directly. - -### Amino - -Every module uses an Amino codec to serialize types and interfaces. This codec typically -has types and interfaces registered in that module's domain only (e.g. messages), -but there are exceptions like `x/gov`. Each module exposes a `RegisterLegacyAminoCodec` function -that allows a user to provide a codec and have all the types registered. An application -will call this method for each necessary module. - -Where there is no protobuf-based type definition for a module (see below), Amino -is used to encode and decode raw wire bytes to the concrete type or interface: - -```go -bz := keeper.cdc.MustMarshalBinaryBare(typeOrInterface) -keeper.cdc.MustUnmarshalBinaryBare(bz, &typeOrInterface) -``` - -Note, there are length-prefixed variants of the above functionality and this is -typically used for when the data needs to be streamed or grouped together -(e.g. `ResponseDeliverTx.Data`) - -### Gogoproto - -Modules are encouraged to utilize Protobuf encoding for their respective types. - -#### FAQ - -1. How to create modules using protobuf encoding? - -**Defining module types** - -Protobuf types can be defined to encode: - -- state -- [`Msg`s](../building-modules/messages-and-queries.md#messages) -- [Query services](../building-modules/query-services.md) -- [genesis](../building-modules/genesis.md) - -**Naming and conventions** - -We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) -and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](../architecture/adr-023-protobuf-naming.md) - -2. How to update modules to protobuf encoding? - -If modules do not contain any interfaces (e.g. `Account` or `Content`), then they -may simply migrate any existing types that -are encoded and persisted via their concrete Amino codec to Protobuf (see 1. for further guidelines) and accept a `Marshaler` as the codec which is implemented via the `ProtoCodec` -without any further customization. - -However, if a module type composes an interface, it must wrap it in the `skd.Any` (from `/types` package) type. To do that, a module-level .proto file must use [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto) for respective message type interface types. - -For example, in the `x/evidence` module defines an `Evidence` interface, which is used by the `MsgSubmitEvidence`. The structure definition must use `sdk.Any` to wrap the evidence file. In the proto file we define it as follows: - -```protobuf -// proto/cosmos/evidence/v1beta1/tx.proto - -message MsgSubmitEvidence { - string submitter = 1; - google.protobuf.Any evidence = 2 [(cosmos_proto.accepts_interface) = "Evidence"]; -} -``` - -The SDK `codec.Marshaler` interface provides support methods `MarshalInterface` and `UnmarshalInterface` to easy encoding of state to `Any`. - -Module should register interfaces using `InterfaceRegistry` which provides a mechanism for registering interfaces: `RegisterInterface(protoName string, iface interface{})` and implementations: `RegisterImplementations(iface interface{}, impls ...proto.Message)` that can be safely unpacked from Any, similarly to type registration with Amino: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/codec/types/interface_registry.go#L25-L66 - -In addition, an `UnpackInterfaces` phase should be introduced to deserialization to unpack interfaces before they're needed. Protobuf types that contain a protobuf `Any` either directly or via one of their members should implement the `UnpackInterfacesMessage` interface: - -```go -type UnpackInterfacesMessage interface { - UnpackInterfaces(InterfaceUnpacker) error -} -``` - -#### Guidelines for protobuf message definitions - -In addition to [following official guidelines](https://developers.google.com/protocol-buffers/docs/proto3#simple), we recommend to use these annotations in .proto files when dealing with interfaces: - -- fields which accept interfaces should be annotated with `cosmos_proto.accepts_interface` - using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` -- interface implementations should be annotated with `cosmos_proto.implements_interface` - using the same full-qualified name passed as `protoName` to `InterfaceRegistry.RegisterInterface` - -#### Transaction Encoding - -Another important use of Protobuf is the encoding and decoding of -[transactions](./transactions.md). Transactions are defined by the application or -the SDK, but passed to the underlying consensus engine in order to be relayed to -other peers. Since the underlying consensus engine is agnostic to the application, -it only accepts transactions in the form of raw bytes. The encoding is done by an -object called `TxEncoder` and the decoding by an object called `TxDecoder`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/types/tx_msg.go#L83-L87 - -A standard implementation of both these objects can be found in the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/master/x/auth): - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/x/auth/tx/decoder.go - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/x/auth/tx/encoder.go - -## Next {hide} - -Learn about [gRPC, REST and other endpoints](./grpc_rest.md) {hide} diff --git a/docs/core/events.md b/docs/core/events.md deleted file mode 100644 index 87bf870661..0000000000 --- a/docs/core/events.md +++ /dev/null @@ -1,116 +0,0 @@ - - -# Events - -`Event`s are objects that contain information about the execution of the application. They are mainly used by service providers like block explorers and wallet to track the execution of various messages and index transactions. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} - -## Events - -Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and -take the form of: `{eventType}.{eventAttribute}={value}`. - -+++ https://github.com/tendermint/tendermint/blob/bc572217c07b90ad9cee851f193aaa8e9557cbc7/abci/types/types.pb.go#L2187-L2193 - -Events contain: - -- A `type`, which is meant to categorize an event at a high-level (e.g. by module or action). -- A list of `attributes`, which are key-value pairs that give more information about - the categorized `event`. - +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/events.go#L51-L56 - -Events are returned to the underlying consensus engine in the response of the following ABCI messages: - -- [`BeginBlock`](./baseapp.md#beginblock) -- [`EndBlock`](./baseapp.md#endblock) -- [`CheckTx`](./baseapp.md#checktx) -- [`DeliverTx`](./baseapp.md#delivertx) - -Events, the `type` and `attributes`, are defined on a **per-module basis** in the module's -`/types/events.go` file, and triggered from the module's [`Msg` service](../building-modules/msg-services.md) -via the [`EventManager`](#eventmanager). In addition, each module documents its events under -`spec/xx_events.md`. - -## EventManager - -In Cosmos SDK applications, events are managed by an abstraction called the `EventManager`. -Internally, the `EventManager` tracks a list of `Events` for the entire execution flow of a -transaction or `BeginBlock`/`EndBlock`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/events.go#L16-L20 - -The `EventManager` comes with a set of useful methods to manage events. Among them, the one that is -used the most by module and application developers is the `EmitEvent` method, which tracks -an `event` in the `EventManager`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/events.go#L29-L31 - -Module developers should handle event emission via the `EventManager#EmitEvent` in each message -`Handler` and in each `BeginBlock`/`EndBlock` handler. The `EventManager` is accessed via -the [`Context`](./context.md), where event emission generally follows this pattern: - -```go -ctx.EventManager().EmitEvent( - sdk.NewEvent(eventType, sdk.NewAttribute(attributeKey, attributeValue)), -) -``` - -Module's `handler` function should also set a new `EventManager` to the `context` to isolate emitted events per `message`: -```go -func NewHandler(keeper Keeper) sdk.Handler { - return func(ctx sdk.Context, msg sdk.Msg) (*sdk.Result, error) { - ctx = ctx.WithEventManager(sdk.NewEventManager()) - switch msg := msg.(type) { -``` - -See the [`Msg` services](../building-modules/msg-services.md) concept doc for a more detailed -view on how to typically implement `Events` and use the `EventManager` in modules. - -## Subscribing to Events - -It is possible to subscribe to `Events` via Tendermint's [Websocket](https://tendermint.com/docs/app-dev/subscribing-to-events-via-websocket.html#subscribing-to-events-via-websocket). -This is done by calling the `subscribe` RPC method via Websocket: - -```json -{ - "jsonrpc": "2.0", - "method": "subscribe", - "id": "0", - "params": { - "query": "tm.event='eventCategory' AND eventType.eventAttribute='attributeValue'" - } -} -``` - -The main `eventCategory` you can subscribe to are: - -- `NewBlock`: Contains `events` triggered during `BeginBlock` and `EndBlock`. -- `Tx`: Contains `events` triggered during `DeliverTx` (i.e. transaction processing). -- `ValidatorSetUpdates`: Contains validator set updates for the block. - -These events are triggered from the `state` package after a block is committed. You can get the -full list of `event` categories [here](https://godoc.org/github.com/tendermint/tendermint/types#pkg-constants). - -The `type` and `attribute` value of the `query` allow you to filter the specific `event` you are looking for. For example, a `transfer` transaction triggers an `event` of type `Transfer` and has `Recipient` and `Sender` as `attributes` (as defined in the [`events` file of the `bank` module](https://github.com/cosmos/cosmos-sdk/blob/master/x/bank/types/events.go)). Subscribing to this `event` would be done like so: - -```json -{ - "jsonrpc": "2.0", - "method": "subscribe", - "id": "0", - "params": { - "query": "tm.event='Tx' AND transfer.sender='senderAddress'" - } -} -``` - -where `senderAddress` is an address following the [`AccAddress`](../basics/accounts.md#addresses) format. - -## Next {hide} - -Learn about SDK [telemetry](./telemetry.md) {hide} diff --git a/docs/core/grpc_rest.md b/docs/core/grpc_rest.md deleted file mode 100644 index cea6c0ed3c..0000000000 --- a/docs/core/grpc_rest.md +++ /dev/null @@ -1,113 +0,0 @@ - - -# gRPC, REST, and Tendermint Endpoints - -This document presents an overview of all the endpoints a node exposes: gRPC, REST as well as some other endpoints. {synopsis} - -## An Overview of All Endpoints - -Each node exposes the following endpoints for users to interact with a node, each endpoint is served on a different port. Details on how to configure each endpoint is provided in the endpoint's own section. - -- the gRPC server (default port: `9090`), -- the REST server (default port: `1317`), -- the Tendermint RPC endpoint (default port: `26657`). - -::: tip -The node also exposes some other endpoints, such as the Tendermint P2P endpoint, or the [Prometheus endpoint](https://docs.tendermint.com/master/nodes/metrics.html#metrics), which are not directly related to the Cosmos SDK. Please refer to the [Tendermint documentation](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html#configuration) for more information about these endpoints. -::: - -## gRPC Server - -::: warning -A patch introduced in `go-grpc v1.34.0` made gRPC incompatible with the `gogoproto` library, making some [gRPC queries](https://github.com/cosmos/cosmos-sdk/issues/8426) panic. As such, the SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. - -To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: - -``` -replace google.golang.org/grpc => google.golang.org/grpc v1.33.2 -``` - -Please see [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) for more info. -::: - -Cosmos SDK v0.40 introduced Protobuf as the main [encoding](./encoding) library, and this brings a wide range of Protobuf-based tools that can be plugged into the SDK. One such tool is [gRPC](https://grpc.io), a modern open source high performance RPC framework that has decent client support in several languages. - -Each module exposes [`Msg` and `Query` Protobuf services](../building-modules/messages-and-queries.md) to define state transitions and state queries. These services are hooked up to gRPC via the following function inside the application: - - - -The `grpc.Server` is a concrete gRPC server, which spawns and serves any gRPC requests. This server can be configured inside `~/.simapp/config/app.toml`: - -- `grpc.enable = true|false` field defines if the gRPC server should be enabled. Defaults to `true`. -- `grpc.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `0.0.0.0:9090`. - -::tip -`~/.simapp` is the directory where the node's configuration and databases are stored. By default, it's set to `~/.{app_name}`. -:: - -Once the gRPC server is started, you can send requests to it using a gRPC client. Some examples are given in our [Interact with the Node](../run-node/interact-node.md#using-grpc) tutorial. - -An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documention](./proto-docs.md). - -## REST Server - -In Cosmos SDK v0.40, the node continues to serve a REST server. However, the existing routes present in version v0.39 and earlier are now marked as deprecated, and new routes have been added via gRPC-gateway. - -All routes are configured under the following fields in `~/.simapp/config/app.toml`: - -- `api.enable = true|false` field defines if the REST server should be enabled. Defaults to `false`. -- `api.address = {string}` field defines the address (really, the port, since the host should be kept at `0.0.0.0`) the server should bind to. Defaults to `tcp://0.0.0.0:1317`. -- some additional API configuration options are defined in `~/.simapp/config/app.toml`, along with comments, please refer to that file directly. - -### gRPC-gateway REST Routes - -If, for various reasons, you cannot use gRPC (for example, you are building a web application, and browsers don't support HTTP2 on which gRPC is built), then the SDK offers REST routes via gRPC-gateway. - -[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) is a tool to expose gRPC endpoints as REST endpoints. For each RPC endpoint defined in a Protobuf service, the SDK offers a REST equivalent. For instance, querying a balance could be done via the `/cosmos.bank.v1beta1.Query/AllBalances` gRPC endpoint, or alternatively via the gRPC-gateway `"/cosmos/bank/v1beta1/balances/{address}"` REST endpoint: both will return the same result. For each RPC method defined in a Protobuf service, the corresponding REST endpoint is defined as an option: - -+++ - -For application developers, gRPC-gateway REST routes needs to be wired up to the REST server, this is done by calling the `RegisterGRPCGatewayRoutes` function on the ModuleManager. - -### Legacy REST API Routes - -The REST routes present in Cosmos SDK v0.39 and earlier are marked as deprecated via a [HTTP deprecation header](https://tools.ietf.org/id/draft-dalal-deprecation-header-01.html). They are still maintained to keep backwards compatibility, but will be removed in v0.41. For updating from Legacy REST routes to new gRPC-gateway REST routes, please refer to our [migration guide](../migrations/rest.md). - -For application developers, Legacy REST API routes needs to be wired up to the REST server, this is done by calling the `RegisterRESTRoutes` function on the ModuleManager. - -### Swagger - -A [Swagger](https://swagger.io/) (or OpenAPIv2) specification file is exposed under the `/swagger` route on the API server. Swagger is an open specification describing the API endpoints a server serves, including description, input arguments, return types and much more about each endpoint. - -Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default. - -For application developers, you may want to generate your own Swagger definitions based on your custom modules. The SDK's [Swagger generation script](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/scripts/protoc-swagger-gen.sh) is a good place to start. - -## Tendermint RPC - -Independently from the Cosmos SDK, Tendermint also exposes a RPC server. This RPC server can be configured by tuning parameters under the `rpc` table in the `~/.simapp/config/config.toml`, the default listening address is `tcp://0.0.0.0:26657`. An OpenAPI specification of all Tendermint RPC endpoints is available [here](https://docs.tendermint.com/master/rpc/). - -Some Tendermint RPC endpoints are directly related to the Cosmos SDK: - -- `/abci_query`: this endpoint will query the application for state. As the `path` parameter, you can send the following strings: - - any Protobuf fully-qualified service method, such as `/cosmos.bank.v1beta1.Query/AllBalances`. The `data` field should then include the method's request parameter(s) encoded as bytes using Protobuf. - - `/app/simulate`: this will simulate a transaction, and return some information such as gas used. - - `/app/version`: this will return the application's version. - - `/store/{path}`: this will query the store directly. - - `/p2p/filter/addr/{port}`: this will return a filtered list of the node's P2P peers by address port. - - `/p2p/filter/id/{id}`: this will return a filtered list of the node's P2P peers by ID. -- `/broadcast_tx_{aync,async,commit}`: these 3 endpoint will broadcast a transaction to other peers. CLI, gRPC and REST expose [a way to broadcast transations](./transactions.md#broadcasting-the-transaction), but they all use these 3 Tendermint RPCs under the hood. - -## Comparison Table - -| Name | Advantages | Disadvantages | -| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | -| gRPC | - can use code-generated stubs in various languages
- supports streaming and bidirectional communication (HTTP2)
- small wire binary sizes, faster transmission | - based on HTTP2, not available in browsers
- learning curve (mostly due to Protobuf) | -| REST | - ubiquitous
- client libraries in all languages, faster implementation
| - only supports unary request-response communication (HTTP1.1)
- bigger over-the-wire message sizes (JSON) | -| Tendermint RPC | - easy to use | - bigger over-the-wire message sizes (JSON) | - -## Next {hide} - -Learn about [the CLI](./cli.md) {hide} diff --git a/docs/core/node.md b/docs/core/node.md deleted file mode 100644 index 005aab3ab1..0000000000 --- a/docs/core/node.md +++ /dev/null @@ -1,76 +0,0 @@ - - -# Node Client (Daemon) - -The main endpoint of an SDK application is the daemon client, otherwise known as the full-node client. The full-node runs the state-machine, starting from a genesis file. It connects to peers running the same client in order to receive and relay transactions, block proposals and signatures. The full-node is constituted of the application, defined with the Cosmos SDK, and of a consensus engine connected to the application via the ABCI. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} - -## `main` function - -The full-node client of any SDK application is built by running a `main` function. The client is generally named by appending the `-d` suffix to the application name (e.g. `appd` for an application named `app`), and the `main` function is defined in a `./appd/cmd/main.go` file. Running this function creates an executable `appd` that comes with a set of commands. For an app named `app`, the main command is [`appd start`](#start-command), which starts the full-node. - -In general, developers will implement the `main.go` function with the following structure: - -- First, an [`appCodec`](./encoding.md) is instanciated for the application. -- Then, the `config` is retrieved and config parameters are set. This mainly involves setting the bech32 prefixes for [addresses and pubkeys](../basics/accounts.md#addresses-and-pubkeys). - +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/config.go#L13-L24 -- 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`. -- Add default server commands to `rootCmd` using the `server.AddCommands()` method. These commands are separated from the ones added above since they are standard and defined at SDK level. They should be shared by all SDK-based applications. They include the most important command: the [`start` command](#start-command). -- Prepare and execute the `executor`. - +++ https://github.com/tendermint/tendermint/blob/v0.34.0-rc6/libs/cli/setup.go#L74-L78 - -See an example of `main` function from the `simapp` application, the SDK's application for demo purposes: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/simd/main.go - -## `start` command - -The `start` command is defined in the `/server` folder of the Cosmos SDK. It is added to the root command of the full-node client in the [`main` function](#main-function) and called by the end-user to start their node: - -```bash -# For an example app named "app", the following command starts the full-node. -appd start - -# Using the SDK's own simapp, the following commands start the simapp node. -simd start -``` - -As a reminder, the full-node is composed of three conceptual layers: the networking layer, the consensus layer and the application layer. The first two are generally bundled together in an entity called the consensus engine (Tendermint Core by default), while the third is the state-machine defined with the help of the Cosmos SDK. Currently, the Cosmos SDK uses Tendermint as the default consensus engine, meaning the start command is implemented to boot up a Tendermint node. - -The flow of the `start` command is pretty straightforward. First, it retrieves the `config` from the `context` in order to open the `db` (a [`leveldb`](https://github.com/syndtr/goleveldb) instance by default). This `db` contains the latest known state of the application (empty if the application is started from the first time. - -With the `db`, the `start` command creates a new instance of the application using an `appCreator` function: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L227 - -Note that an `appCreator` is a function that fulfills the `AppCreator` signature: -+++https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/types/app.go#L48-L50 - -In practice, the [constructor of the application](../basics/app-anatomy.md#constructor-function) is passed as the `appCreator`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/simd/cmd/root.go#L170-L215 - -Then, the instance of `app` is used to instanciate a new Tendermint node: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L235-L244 - -The Tendermint node can be created with `app` because the latter satisfies the [`abci.Application` interface](https://github.com/tendermint/tendermint/blob/v0.34.0/abci/types/application.go#L7-L32) (given that `app` extends [`baseapp`](./baseapp.md)). As part of the `NewNode` method, Tendermint makes sure that the height of the application (i.e. number of blocks since genesis) is equal to the height of the Tendermint node. The difference between these two heights should always be negative or null. If it is strictly negative, `NewNode` will replay blocks until the height of the application reaches the height of the Tendermint node. Finally, if the height of the application is `0`, the Tendermint node will call [`InitChain`](./baseapp.md#initchain) on the application to initialize the state from the genesis file. - -Once the Tendermint node is instanciated and in sync with the application, the node can be started: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L250-L252 - -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. - -## Other commands - -To discover how to concretely run a node and interact with it, please refer to our [Running a Node, API and CLI](../run-node/README.md) guide. - -## Next {hide} - -Learn about the [store](./store.md) {hide} diff --git a/docs/core/ocap.md b/docs/core/ocap.md deleted file mode 100644 index 3f0ec2e1d7..0000000000 --- a/docs/core/ocap.md +++ /dev/null @@ -1,75 +0,0 @@ - - -# Object-Capability Model - -## Intro - -When thinking about security, it is good to start with a specific threat model. Our threat model is the following: - -> We assume that a thriving ecosystem of Cosmos-SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules. - -The Cosmos SDK is designed to address this threat by being the -foundation of an object capability system. - -> The structural properties of object capability systems favor -> modularity in code design and ensure reliable encapsulation in -> code implementation. -> -> These structural properties facilitate the analysis of some -> security properties of an object-capability program or operating -> system. Some of these — in particular, information flow properties -> — can be analyzed at the level of object references and -> connectivity, independent of any knowledge or analysis of the code -> that determines the behavior of the objects. -> -> As a consequence, these security properties can be established -> and maintained in the presence of new objects that contain unknown -> and possibly malicious code. -> -> These structural properties stem from the two rules governing -> access to existing objects: -> -> 1. An object A can send a message to B only if object A holds a -> reference to B. -> 2. An object A can obtain a reference to C only -> if object A receives a message containing a reference to C. As a -> consequence of these two rules, an object can obtain a reference -> to another object only through a preexisting chain of references. -> In short, "Only connectivity begets connectivity." - -For an introduction to object-capabilities, see this [Wikipedia article](https://en.wikipedia.org/wiki/Object-capability_model). - -## Ocaps in practice - -The idea is to only reveal what is necessary to get the work done. - -For example, the following code snippet violates the object capabilities -principle: - -```go -type AppAccount struct {...} -account := &AppAccount{ - Address: pub.Address(), - Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)}, -} -sumValue := externalModule.ComputeSumValue(account) -``` - -The method `ComputeSumValue` implies a pure function, yet the implied -capability of accepting a pointer value is the capability to modify that -value. The preferred method signature should take a copy instead. - -```go -sumValue := externalModule.ComputeSumValue(*account) -``` - -In the Cosmos SDK, you can see the application of this principle in the -gaia app. - -+++ https://github.com/cosmos/gaia/blob/master/app/app.go#L197-L209 - -## Next {hide} - -Learn about the [`runTx` middleware](./runtx_middleware.md) {hide} diff --git a/docs/core/proto-docs.md b/docs/core/proto-docs.md deleted file mode 100644 index 91acc46cfc..0000000000 --- a/docs/core/proto-docs.md +++ /dev/null @@ -1,10043 +0,0 @@ - -# Protobuf Documentation - - -## Table of Contents - -- [ibc/applications/transfer/v1/transfer.proto](#ibc/applications/transfer/v1/transfer.proto) - - [DenomTrace](#ibc.applications.transfer.v1.DenomTrace) - - [FungibleTokenPacketData](#ibc.applications.transfer.v1.FungibleTokenPacketData) - - [Params](#ibc.applications.transfer.v1.Params) - -- [ibc/applications/transfer/v1/genesis.proto](#ibc/applications/transfer/v1/genesis.proto) - - [GenesisState](#ibc.applications.transfer.v1.GenesisState) - -- [lbm/base/query/v1beta1/pagination.proto](#lbm/base/query/v1beta1/pagination.proto) - - [PageRequest](#lbm.base.query.v1beta1.PageRequest) - - [PageResponse](#lbm.base.query.v1beta1.PageResponse) - -- [ibc/applications/transfer/v1/query.proto](#ibc/applications/transfer/v1/query.proto) - - [QueryDenomTraceRequest](#ibc.applications.transfer.v1.QueryDenomTraceRequest) - - [QueryDenomTraceResponse](#ibc.applications.transfer.v1.QueryDenomTraceResponse) - - [QueryDenomTracesRequest](#ibc.applications.transfer.v1.QueryDenomTracesRequest) - - [QueryDenomTracesResponse](#ibc.applications.transfer.v1.QueryDenomTracesResponse) - - [QueryParamsRequest](#ibc.applications.transfer.v1.QueryParamsRequest) - - [QueryParamsResponse](#ibc.applications.transfer.v1.QueryParamsResponse) - - - [Query](#ibc.applications.transfer.v1.Query) - -- [lbm/base/v1beta1/coin.proto](#lbm/base/v1beta1/coin.proto) - - [Coin](#lbm.base.v1beta1.Coin) - - [DecCoin](#lbm.base.v1beta1.DecCoin) - - [DecProto](#lbm.base.v1beta1.DecProto) - - [IntProto](#lbm.base.v1beta1.IntProto) - -- [ibc/core/client/v1/client.proto](#ibc/core/client/v1/client.proto) - - [ClientConsensusStates](#ibc.core.client.v1.ClientConsensusStates) - - [ClientUpdateProposal](#ibc.core.client.v1.ClientUpdateProposal) - - [ConsensusStateWithHeight](#ibc.core.client.v1.ConsensusStateWithHeight) - - [Height](#ibc.core.client.v1.Height) - - [IdentifiedClientState](#ibc.core.client.v1.IdentifiedClientState) - - [Params](#ibc.core.client.v1.Params) - -- [ibc/applications/transfer/v1/tx.proto](#ibc/applications/transfer/v1/tx.proto) - - [MsgTransfer](#ibc.applications.transfer.v1.MsgTransfer) - - [MsgTransferResponse](#ibc.applications.transfer.v1.MsgTransferResponse) - - - [Msg](#ibc.applications.transfer.v1.Msg) - -- [ibc/core/channel/v1/channel.proto](#ibc/core/channel/v1/channel.proto) - - [Acknowledgement](#ibc.core.channel.v1.Acknowledgement) - - [Channel](#ibc.core.channel.v1.Channel) - - [Counterparty](#ibc.core.channel.v1.Counterparty) - - [IdentifiedChannel](#ibc.core.channel.v1.IdentifiedChannel) - - [Packet](#ibc.core.channel.v1.Packet) - - [PacketState](#ibc.core.channel.v1.PacketState) - - - [Order](#ibc.core.channel.v1.Order) - - [State](#ibc.core.channel.v1.State) - -- [ibc/core/channel/v1/genesis.proto](#ibc/core/channel/v1/genesis.proto) - - [GenesisState](#ibc.core.channel.v1.GenesisState) - - [PacketSequence](#ibc.core.channel.v1.PacketSequence) - -- [ibc/core/channel/v1/query.proto](#ibc/core/channel/v1/query.proto) - - [QueryChannelClientStateRequest](#ibc.core.channel.v1.QueryChannelClientStateRequest) - - [QueryChannelClientStateResponse](#ibc.core.channel.v1.QueryChannelClientStateResponse) - - [QueryChannelConsensusStateRequest](#ibc.core.channel.v1.QueryChannelConsensusStateRequest) - - [QueryChannelConsensusStateResponse](#ibc.core.channel.v1.QueryChannelConsensusStateResponse) - - [QueryChannelRequest](#ibc.core.channel.v1.QueryChannelRequest) - - [QueryChannelResponse](#ibc.core.channel.v1.QueryChannelResponse) - - [QueryChannelsRequest](#ibc.core.channel.v1.QueryChannelsRequest) - - [QueryChannelsResponse](#ibc.core.channel.v1.QueryChannelsResponse) - - [QueryConnectionChannelsRequest](#ibc.core.channel.v1.QueryConnectionChannelsRequest) - - [QueryConnectionChannelsResponse](#ibc.core.channel.v1.QueryConnectionChannelsResponse) - - [QueryNextSequenceReceiveRequest](#ibc.core.channel.v1.QueryNextSequenceReceiveRequest) - - [QueryNextSequenceReceiveResponse](#ibc.core.channel.v1.QueryNextSequenceReceiveResponse) - - [QueryPacketAcknowledgementRequest](#ibc.core.channel.v1.QueryPacketAcknowledgementRequest) - - [QueryPacketAcknowledgementResponse](#ibc.core.channel.v1.QueryPacketAcknowledgementResponse) - - [QueryPacketAcknowledgementsRequest](#ibc.core.channel.v1.QueryPacketAcknowledgementsRequest) - - [QueryPacketAcknowledgementsResponse](#ibc.core.channel.v1.QueryPacketAcknowledgementsResponse) - - [QueryPacketCommitmentRequest](#ibc.core.channel.v1.QueryPacketCommitmentRequest) - - [QueryPacketCommitmentResponse](#ibc.core.channel.v1.QueryPacketCommitmentResponse) - - [QueryPacketCommitmentsRequest](#ibc.core.channel.v1.QueryPacketCommitmentsRequest) - - [QueryPacketCommitmentsResponse](#ibc.core.channel.v1.QueryPacketCommitmentsResponse) - - [QueryPacketReceiptRequest](#ibc.core.channel.v1.QueryPacketReceiptRequest) - - [QueryPacketReceiptResponse](#ibc.core.channel.v1.QueryPacketReceiptResponse) - - [QueryUnreceivedAcksRequest](#ibc.core.channel.v1.QueryUnreceivedAcksRequest) - - [QueryUnreceivedAcksResponse](#ibc.core.channel.v1.QueryUnreceivedAcksResponse) - - [QueryUnreceivedPacketsRequest](#ibc.core.channel.v1.QueryUnreceivedPacketsRequest) - - [QueryUnreceivedPacketsResponse](#ibc.core.channel.v1.QueryUnreceivedPacketsResponse) - - - [Query](#ibc.core.channel.v1.Query) - -- [ibc/core/channel/v1/tx.proto](#ibc/core/channel/v1/tx.proto) - - [MsgAcknowledgement](#ibc.core.channel.v1.MsgAcknowledgement) - - [MsgAcknowledgementResponse](#ibc.core.channel.v1.MsgAcknowledgementResponse) - - [MsgChannelCloseConfirm](#ibc.core.channel.v1.MsgChannelCloseConfirm) - - [MsgChannelCloseConfirmResponse](#ibc.core.channel.v1.MsgChannelCloseConfirmResponse) - - [MsgChannelCloseInit](#ibc.core.channel.v1.MsgChannelCloseInit) - - [MsgChannelCloseInitResponse](#ibc.core.channel.v1.MsgChannelCloseInitResponse) - - [MsgChannelOpenAck](#ibc.core.channel.v1.MsgChannelOpenAck) - - [MsgChannelOpenAckResponse](#ibc.core.channel.v1.MsgChannelOpenAckResponse) - - [MsgChannelOpenConfirm](#ibc.core.channel.v1.MsgChannelOpenConfirm) - - [MsgChannelOpenConfirmResponse](#ibc.core.channel.v1.MsgChannelOpenConfirmResponse) - - [MsgChannelOpenInit](#ibc.core.channel.v1.MsgChannelOpenInit) - - [MsgChannelOpenInitResponse](#ibc.core.channel.v1.MsgChannelOpenInitResponse) - - [MsgChannelOpenTry](#ibc.core.channel.v1.MsgChannelOpenTry) - - [MsgChannelOpenTryResponse](#ibc.core.channel.v1.MsgChannelOpenTryResponse) - - [MsgRecvPacket](#ibc.core.channel.v1.MsgRecvPacket) - - [MsgRecvPacketResponse](#ibc.core.channel.v1.MsgRecvPacketResponse) - - [MsgTimeout](#ibc.core.channel.v1.MsgTimeout) - - [MsgTimeoutOnClose](#ibc.core.channel.v1.MsgTimeoutOnClose) - - [MsgTimeoutOnCloseResponse](#ibc.core.channel.v1.MsgTimeoutOnCloseResponse) - - [MsgTimeoutResponse](#ibc.core.channel.v1.MsgTimeoutResponse) - - - [Msg](#ibc.core.channel.v1.Msg) - -- [ibc/core/client/v1/genesis.proto](#ibc/core/client/v1/genesis.proto) - - [GenesisMetadata](#ibc.core.client.v1.GenesisMetadata) - - [GenesisState](#ibc.core.client.v1.GenesisState) - - [IdentifiedGenesisMetadata](#ibc.core.client.v1.IdentifiedGenesisMetadata) - -- [ibc/core/client/v1/query.proto](#ibc/core/client/v1/query.proto) - - [QueryClientParamsRequest](#ibc.core.client.v1.QueryClientParamsRequest) - - [QueryClientParamsResponse](#ibc.core.client.v1.QueryClientParamsResponse) - - [QueryClientStateRequest](#ibc.core.client.v1.QueryClientStateRequest) - - [QueryClientStateResponse](#ibc.core.client.v1.QueryClientStateResponse) - - [QueryClientStatesRequest](#ibc.core.client.v1.QueryClientStatesRequest) - - [QueryClientStatesResponse](#ibc.core.client.v1.QueryClientStatesResponse) - - [QueryConsensusStateRequest](#ibc.core.client.v1.QueryConsensusStateRequest) - - [QueryConsensusStateResponse](#ibc.core.client.v1.QueryConsensusStateResponse) - - [QueryConsensusStatesRequest](#ibc.core.client.v1.QueryConsensusStatesRequest) - - [QueryConsensusStatesResponse](#ibc.core.client.v1.QueryConsensusStatesResponse) - - - [Query](#ibc.core.client.v1.Query) - -- [ibc/core/client/v1/tx.proto](#ibc/core/client/v1/tx.proto) - - [MsgCreateClient](#ibc.core.client.v1.MsgCreateClient) - - [MsgCreateClientResponse](#ibc.core.client.v1.MsgCreateClientResponse) - - [MsgSubmitMisbehaviour](#ibc.core.client.v1.MsgSubmitMisbehaviour) - - [MsgSubmitMisbehaviourResponse](#ibc.core.client.v1.MsgSubmitMisbehaviourResponse) - - [MsgUpdateClient](#ibc.core.client.v1.MsgUpdateClient) - - [MsgUpdateClientResponse](#ibc.core.client.v1.MsgUpdateClientResponse) - - [MsgUpgradeClient](#ibc.core.client.v1.MsgUpgradeClient) - - [MsgUpgradeClientResponse](#ibc.core.client.v1.MsgUpgradeClientResponse) - - - [Msg](#ibc.core.client.v1.Msg) - -- [ibc/core/commitment/v1/commitment.proto](#ibc/core/commitment/v1/commitment.proto) - - [MerklePath](#ibc.core.commitment.v1.MerklePath) - - [MerklePrefix](#ibc.core.commitment.v1.MerklePrefix) - - [MerkleProof](#ibc.core.commitment.v1.MerkleProof) - - [MerkleRoot](#ibc.core.commitment.v1.MerkleRoot) - -- [ibc/core/connection/v1/connection.proto](#ibc/core/connection/v1/connection.proto) - - [ClientPaths](#ibc.core.connection.v1.ClientPaths) - - [ConnectionEnd](#ibc.core.connection.v1.ConnectionEnd) - - [ConnectionPaths](#ibc.core.connection.v1.ConnectionPaths) - - [Counterparty](#ibc.core.connection.v1.Counterparty) - - [IdentifiedConnection](#ibc.core.connection.v1.IdentifiedConnection) - - [Version](#ibc.core.connection.v1.Version) - - - [State](#ibc.core.connection.v1.State) - -- [ibc/core/connection/v1/genesis.proto](#ibc/core/connection/v1/genesis.proto) - - [GenesisState](#ibc.core.connection.v1.GenesisState) - -- [ibc/core/connection/v1/query.proto](#ibc/core/connection/v1/query.proto) - - [QueryClientConnectionsRequest](#ibc.core.connection.v1.QueryClientConnectionsRequest) - - [QueryClientConnectionsResponse](#ibc.core.connection.v1.QueryClientConnectionsResponse) - - [QueryConnectionClientStateRequest](#ibc.core.connection.v1.QueryConnectionClientStateRequest) - - [QueryConnectionClientStateResponse](#ibc.core.connection.v1.QueryConnectionClientStateResponse) - - [QueryConnectionConsensusStateRequest](#ibc.core.connection.v1.QueryConnectionConsensusStateRequest) - - [QueryConnectionConsensusStateResponse](#ibc.core.connection.v1.QueryConnectionConsensusStateResponse) - - [QueryConnectionRequest](#ibc.core.connection.v1.QueryConnectionRequest) - - [QueryConnectionResponse](#ibc.core.connection.v1.QueryConnectionResponse) - - [QueryConnectionsRequest](#ibc.core.connection.v1.QueryConnectionsRequest) - - [QueryConnectionsResponse](#ibc.core.connection.v1.QueryConnectionsResponse) - - - [Query](#ibc.core.connection.v1.Query) - -- [ibc/core/connection/v1/tx.proto](#ibc/core/connection/v1/tx.proto) - - [MsgConnectionOpenAck](#ibc.core.connection.v1.MsgConnectionOpenAck) - - [MsgConnectionOpenAckResponse](#ibc.core.connection.v1.MsgConnectionOpenAckResponse) - - [MsgConnectionOpenConfirm](#ibc.core.connection.v1.MsgConnectionOpenConfirm) - - [MsgConnectionOpenConfirmResponse](#ibc.core.connection.v1.MsgConnectionOpenConfirmResponse) - - [MsgConnectionOpenInit](#ibc.core.connection.v1.MsgConnectionOpenInit) - - [MsgConnectionOpenInitResponse](#ibc.core.connection.v1.MsgConnectionOpenInitResponse) - - [MsgConnectionOpenTry](#ibc.core.connection.v1.MsgConnectionOpenTry) - - [MsgConnectionOpenTryResponse](#ibc.core.connection.v1.MsgConnectionOpenTryResponse) - - - [Msg](#ibc.core.connection.v1.Msg) - -- [ibc/core/types/v1/genesis.proto](#ibc/core/types/v1/genesis.proto) - - [GenesisState](#ibc.core.types.v1.GenesisState) - -- [ibc/lightclients/localhost/v1/localhost.proto](#ibc/lightclients/localhost/v1/localhost.proto) - - [ClientState](#ibc.lightclients.localhost.v1.ClientState) - -- [ibc/lightclients/solomachine/v1/solomachine.proto](#ibc/lightclients/solomachine/v1/solomachine.proto) - - [ChannelStateData](#ibc.lightclients.solomachine.v1.ChannelStateData) - - [ClientState](#ibc.lightclients.solomachine.v1.ClientState) - - [ClientStateData](#ibc.lightclients.solomachine.v1.ClientStateData) - - [ConnectionStateData](#ibc.lightclients.solomachine.v1.ConnectionStateData) - - [ConsensusState](#ibc.lightclients.solomachine.v1.ConsensusState) - - [ConsensusStateData](#ibc.lightclients.solomachine.v1.ConsensusStateData) - - [Header](#ibc.lightclients.solomachine.v1.Header) - - [HeaderData](#ibc.lightclients.solomachine.v1.HeaderData) - - [Misbehaviour](#ibc.lightclients.solomachine.v1.Misbehaviour) - - [NextSequenceRecvData](#ibc.lightclients.solomachine.v1.NextSequenceRecvData) - - [PacketAcknowledgementData](#ibc.lightclients.solomachine.v1.PacketAcknowledgementData) - - [PacketCommitmentData](#ibc.lightclients.solomachine.v1.PacketCommitmentData) - - [PacketReceiptAbsenceData](#ibc.lightclients.solomachine.v1.PacketReceiptAbsenceData) - - [SignBytes](#ibc.lightclients.solomachine.v1.SignBytes) - - [SignatureAndData](#ibc.lightclients.solomachine.v1.SignatureAndData) - - [TimestampedSignatureData](#ibc.lightclients.solomachine.v1.TimestampedSignatureData) - - - [DataType](#ibc.lightclients.solomachine.v1.DataType) - -- [ibc/lightclients/tendermint/v1/tendermint.proto](#ibc/lightclients/tendermint/v1/tendermint.proto) - - [ClientState](#ibc.lightclients.tendermint.v1.ClientState) - - [ConsensusState](#ibc.lightclients.tendermint.v1.ConsensusState) - - [Fraction](#ibc.lightclients.tendermint.v1.Fraction) - - [Header](#ibc.lightclients.tendermint.v1.Header) - - [Misbehaviour](#ibc.lightclients.tendermint.v1.Misbehaviour) - -- [lbm/auth/v1beta1/auth.proto](#lbm/auth/v1beta1/auth.proto) - - [BaseAccount](#lbm.auth.v1beta1.BaseAccount) - - [ModuleAccount](#lbm.auth.v1beta1.ModuleAccount) - - [Params](#lbm.auth.v1beta1.Params) - -- [lbm/auth/v1beta1/genesis.proto](#lbm/auth/v1beta1/genesis.proto) - - [GenesisState](#lbm.auth.v1beta1.GenesisState) - -- [lbm/auth/v1beta1/query.proto](#lbm/auth/v1beta1/query.proto) - - [QueryAccountRequest](#lbm.auth.v1beta1.QueryAccountRequest) - - [QueryAccountResponse](#lbm.auth.v1beta1.QueryAccountResponse) - - [QueryParamsRequest](#lbm.auth.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.auth.v1beta1.QueryParamsResponse) - - - [Query](#lbm.auth.v1beta1.Query) - -- [lbm/auth/v1beta1/tx.proto](#lbm/auth/v1beta1/tx.proto) - - [MsgEmpty](#lbm.auth.v1beta1.MsgEmpty) - - [MsgEmptyResponse](#lbm.auth.v1beta1.MsgEmptyResponse) - - - [Msg](#lbm.auth.v1beta1.Msg) - -- [lbm/bank/v1beta1/bank.proto](#lbm/bank/v1beta1/bank.proto) - - [DenomUnit](#lbm.bank.v1beta1.DenomUnit) - - [Input](#lbm.bank.v1beta1.Input) - - [Metadata](#lbm.bank.v1beta1.Metadata) - - [Output](#lbm.bank.v1beta1.Output) - - [Params](#lbm.bank.v1beta1.Params) - - [SendEnabled](#lbm.bank.v1beta1.SendEnabled) - - [Supply](#lbm.bank.v1beta1.Supply) - -- [lbm/bank/v1beta1/genesis.proto](#lbm/bank/v1beta1/genesis.proto) - - [Balance](#lbm.bank.v1beta1.Balance) - - [GenesisState](#lbm.bank.v1beta1.GenesisState) - -- [lbm/bank/v1beta1/query.proto](#lbm/bank/v1beta1/query.proto) - - [QueryAllBalancesRequest](#lbm.bank.v1beta1.QueryAllBalancesRequest) - - [QueryAllBalancesResponse](#lbm.bank.v1beta1.QueryAllBalancesResponse) - - [QueryBalanceRequest](#lbm.bank.v1beta1.QueryBalanceRequest) - - [QueryBalanceResponse](#lbm.bank.v1beta1.QueryBalanceResponse) - - [QueryDenomMetadataRequest](#lbm.bank.v1beta1.QueryDenomMetadataRequest) - - [QueryDenomMetadataResponse](#lbm.bank.v1beta1.QueryDenomMetadataResponse) - - [QueryDenomsMetadataRequest](#lbm.bank.v1beta1.QueryDenomsMetadataRequest) - - [QueryDenomsMetadataResponse](#lbm.bank.v1beta1.QueryDenomsMetadataResponse) - - [QueryParamsRequest](#lbm.bank.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.bank.v1beta1.QueryParamsResponse) - - [QuerySupplyOfRequest](#lbm.bank.v1beta1.QuerySupplyOfRequest) - - [QuerySupplyOfResponse](#lbm.bank.v1beta1.QuerySupplyOfResponse) - - [QueryTotalSupplyRequest](#lbm.bank.v1beta1.QueryTotalSupplyRequest) - - [QueryTotalSupplyResponse](#lbm.bank.v1beta1.QueryTotalSupplyResponse) - - - [Query](#lbm.bank.v1beta1.Query) - -- [lbm/bank/v1beta1/tx.proto](#lbm/bank/v1beta1/tx.proto) - - [MsgMultiSend](#lbm.bank.v1beta1.MsgMultiSend) - - [MsgMultiSendResponse](#lbm.bank.v1beta1.MsgMultiSendResponse) - - [MsgSend](#lbm.bank.v1beta1.MsgSend) - - [MsgSendResponse](#lbm.bank.v1beta1.MsgSendResponse) - - - [Msg](#lbm.bank.v1beta1.Msg) - -- [lbm/base/abci/v1beta1/abci.proto](#lbm/base/abci/v1beta1/abci.proto) - - [ABCIMessageLog](#lbm.base.abci.v1beta1.ABCIMessageLog) - - [Attribute](#lbm.base.abci.v1beta1.Attribute) - - [GasInfo](#lbm.base.abci.v1beta1.GasInfo) - - [MsgData](#lbm.base.abci.v1beta1.MsgData) - - [Result](#lbm.base.abci.v1beta1.Result) - - [SearchTxsResult](#lbm.base.abci.v1beta1.SearchTxsResult) - - [SimulationResponse](#lbm.base.abci.v1beta1.SimulationResponse) - - [StringEvent](#lbm.base.abci.v1beta1.StringEvent) - - [TxMsgData](#lbm.base.abci.v1beta1.TxMsgData) - - [TxResponse](#lbm.base.abci.v1beta1.TxResponse) - -- [lbm/base/kv/v1beta1/kv.proto](#lbm/base/kv/v1beta1/kv.proto) - - [Pair](#lbm.base.kv.v1beta1.Pair) - - [Pairs](#lbm.base.kv.v1beta1.Pairs) - -- [lbm/base/ostracon/v1beta1/query.proto](#lbm/base/ostracon/v1beta1/query.proto) - - [GetBlockByHeightRequest](#lbm.base.ostracon.v1beta1.GetBlockByHeightRequest) - - [GetBlockByHeightResponse](#lbm.base.ostracon.v1beta1.GetBlockByHeightResponse) - - [GetLatestBlockRequest](#lbm.base.ostracon.v1beta1.GetLatestBlockRequest) - - [GetLatestBlockResponse](#lbm.base.ostracon.v1beta1.GetLatestBlockResponse) - - [GetLatestValidatorSetRequest](#lbm.base.ostracon.v1beta1.GetLatestValidatorSetRequest) - - [GetLatestValidatorSetResponse](#lbm.base.ostracon.v1beta1.GetLatestValidatorSetResponse) - - [GetNodeInfoRequest](#lbm.base.ostracon.v1beta1.GetNodeInfoRequest) - - [GetNodeInfoResponse](#lbm.base.ostracon.v1beta1.GetNodeInfoResponse) - - [GetSyncingRequest](#lbm.base.ostracon.v1beta1.GetSyncingRequest) - - [GetSyncingResponse](#lbm.base.ostracon.v1beta1.GetSyncingResponse) - - [GetValidatorSetByHeightRequest](#lbm.base.ostracon.v1beta1.GetValidatorSetByHeightRequest) - - [GetValidatorSetByHeightResponse](#lbm.base.ostracon.v1beta1.GetValidatorSetByHeightResponse) - - [Module](#lbm.base.ostracon.v1beta1.Module) - - [Validator](#lbm.base.ostracon.v1beta1.Validator) - - [VersionInfo](#lbm.base.ostracon.v1beta1.VersionInfo) - - - [Service](#lbm.base.ostracon.v1beta1.Service) - -- [lbm/base/reflection/v1beta1/reflection.proto](#lbm/base/reflection/v1beta1/reflection.proto) - - [ListAllInterfacesRequest](#lbm.base.reflection.v1beta1.ListAllInterfacesRequest) - - [ListAllInterfacesResponse](#lbm.base.reflection.v1beta1.ListAllInterfacesResponse) - - [ListImplementationsRequest](#lbm.base.reflection.v1beta1.ListImplementationsRequest) - - [ListImplementationsResponse](#lbm.base.reflection.v1beta1.ListImplementationsResponse) - - - [ReflectionService](#lbm.base.reflection.v1beta1.ReflectionService) - -- [lbm/base/snapshots/v1beta1/snapshot.proto](#lbm/base/snapshots/v1beta1/snapshot.proto) - - [Metadata](#lbm.base.snapshots.v1beta1.Metadata) - - [Snapshot](#lbm.base.snapshots.v1beta1.Snapshot) - -- [lbm/base/store/v1beta1/commit_info.proto](#lbm/base/store/v1beta1/commit_info.proto) - - [CommitID](#lbm.base.store.v1beta1.CommitID) - - [CommitInfo](#lbm.base.store.v1beta1.CommitInfo) - - [StoreInfo](#lbm.base.store.v1beta1.StoreInfo) - -- [lbm/base/store/v1beta1/snapshot.proto](#lbm/base/store/v1beta1/snapshot.proto) - - [SnapshotIAVLItem](#lbm.base.store.v1beta1.SnapshotIAVLItem) - - [SnapshotItem](#lbm.base.store.v1beta1.SnapshotItem) - - [SnapshotStoreItem](#lbm.base.store.v1beta1.SnapshotStoreItem) - -- [lbm/capability/v1beta1/capability.proto](#lbm/capability/v1beta1/capability.proto) - - [Capability](#lbm.capability.v1beta1.Capability) - - [CapabilityOwners](#lbm.capability.v1beta1.CapabilityOwners) - - [Owner](#lbm.capability.v1beta1.Owner) - -- [lbm/capability/v1beta1/genesis.proto](#lbm/capability/v1beta1/genesis.proto) - - [GenesisOwners](#lbm.capability.v1beta1.GenesisOwners) - - [GenesisState](#lbm.capability.v1beta1.GenesisState) - -- [lbm/crisis/v1beta1/genesis.proto](#lbm/crisis/v1beta1/genesis.proto) - - [GenesisState](#lbm.crisis.v1beta1.GenesisState) - -- [lbm/crisis/v1beta1/tx.proto](#lbm/crisis/v1beta1/tx.proto) - - [MsgVerifyInvariant](#lbm.crisis.v1beta1.MsgVerifyInvariant) - - [MsgVerifyInvariantResponse](#lbm.crisis.v1beta1.MsgVerifyInvariantResponse) - - - [Msg](#lbm.crisis.v1beta1.Msg) - -- [lbm/crypto/ed25519/keys.proto](#lbm/crypto/ed25519/keys.proto) - - [PrivKey](#lbm.crypto.ed25519.PrivKey) - - [PubKey](#lbm.crypto.ed25519.PubKey) - -- [lbm/crypto/multisig/keys.proto](#lbm/crypto/multisig/keys.proto) - - [LegacyAminoPubKey](#lbm.crypto.multisig.LegacyAminoPubKey) - -- [lbm/crypto/multisig/v1beta1/multisig.proto](#lbm/crypto/multisig/v1beta1/multisig.proto) - - [CompactBitArray](#lbm.crypto.multisig.v1beta1.CompactBitArray) - - [MultiSignature](#lbm.crypto.multisig.v1beta1.MultiSignature) - -- [lbm/crypto/secp256k1/keys.proto](#lbm/crypto/secp256k1/keys.proto) - - [PrivKey](#lbm.crypto.secp256k1.PrivKey) - - [PubKey](#lbm.crypto.secp256k1.PubKey) - -- [lbm/distribution/v1beta1/distribution.proto](#lbm/distribution/v1beta1/distribution.proto) - - [CommunityPoolSpendProposal](#lbm.distribution.v1beta1.CommunityPoolSpendProposal) - - [CommunityPoolSpendProposalWithDeposit](#lbm.distribution.v1beta1.CommunityPoolSpendProposalWithDeposit) - - [DelegationDelegatorReward](#lbm.distribution.v1beta1.DelegationDelegatorReward) - - [DelegatorStartingInfo](#lbm.distribution.v1beta1.DelegatorStartingInfo) - - [FeePool](#lbm.distribution.v1beta1.FeePool) - - [Params](#lbm.distribution.v1beta1.Params) - - [ValidatorAccumulatedCommission](#lbm.distribution.v1beta1.ValidatorAccumulatedCommission) - - [ValidatorCurrentRewards](#lbm.distribution.v1beta1.ValidatorCurrentRewards) - - [ValidatorHistoricalRewards](#lbm.distribution.v1beta1.ValidatorHistoricalRewards) - - [ValidatorOutstandingRewards](#lbm.distribution.v1beta1.ValidatorOutstandingRewards) - - [ValidatorSlashEvent](#lbm.distribution.v1beta1.ValidatorSlashEvent) - - [ValidatorSlashEvents](#lbm.distribution.v1beta1.ValidatorSlashEvents) - -- [lbm/distribution/v1beta1/genesis.proto](#lbm/distribution/v1beta1/genesis.proto) - - [DelegatorStartingInfoRecord](#lbm.distribution.v1beta1.DelegatorStartingInfoRecord) - - [DelegatorWithdrawInfo](#lbm.distribution.v1beta1.DelegatorWithdrawInfo) - - [GenesisState](#lbm.distribution.v1beta1.GenesisState) - - [ValidatorAccumulatedCommissionRecord](#lbm.distribution.v1beta1.ValidatorAccumulatedCommissionRecord) - - [ValidatorCurrentRewardsRecord](#lbm.distribution.v1beta1.ValidatorCurrentRewardsRecord) - - [ValidatorHistoricalRewardsRecord](#lbm.distribution.v1beta1.ValidatorHistoricalRewardsRecord) - - [ValidatorOutstandingRewardsRecord](#lbm.distribution.v1beta1.ValidatorOutstandingRewardsRecord) - - [ValidatorSlashEventRecord](#lbm.distribution.v1beta1.ValidatorSlashEventRecord) - -- [lbm/distribution/v1beta1/query.proto](#lbm/distribution/v1beta1/query.proto) - - [QueryCommunityPoolRequest](#lbm.distribution.v1beta1.QueryCommunityPoolRequest) - - [QueryCommunityPoolResponse](#lbm.distribution.v1beta1.QueryCommunityPoolResponse) - - [QueryDelegationRewardsRequest](#lbm.distribution.v1beta1.QueryDelegationRewardsRequest) - - [QueryDelegationRewardsResponse](#lbm.distribution.v1beta1.QueryDelegationRewardsResponse) - - [QueryDelegationTotalRewardsRequest](#lbm.distribution.v1beta1.QueryDelegationTotalRewardsRequest) - - [QueryDelegationTotalRewardsResponse](#lbm.distribution.v1beta1.QueryDelegationTotalRewardsResponse) - - [QueryDelegatorValidatorsRequest](#lbm.distribution.v1beta1.QueryDelegatorValidatorsRequest) - - [QueryDelegatorValidatorsResponse](#lbm.distribution.v1beta1.QueryDelegatorValidatorsResponse) - - [QueryDelegatorWithdrawAddressRequest](#lbm.distribution.v1beta1.QueryDelegatorWithdrawAddressRequest) - - [QueryDelegatorWithdrawAddressResponse](#lbm.distribution.v1beta1.QueryDelegatorWithdrawAddressResponse) - - [QueryParamsRequest](#lbm.distribution.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.distribution.v1beta1.QueryParamsResponse) - - [QueryValidatorCommissionRequest](#lbm.distribution.v1beta1.QueryValidatorCommissionRequest) - - [QueryValidatorCommissionResponse](#lbm.distribution.v1beta1.QueryValidatorCommissionResponse) - - [QueryValidatorOutstandingRewardsRequest](#lbm.distribution.v1beta1.QueryValidatorOutstandingRewardsRequest) - - [QueryValidatorOutstandingRewardsResponse](#lbm.distribution.v1beta1.QueryValidatorOutstandingRewardsResponse) - - [QueryValidatorSlashesRequest](#lbm.distribution.v1beta1.QueryValidatorSlashesRequest) - - [QueryValidatorSlashesResponse](#lbm.distribution.v1beta1.QueryValidatorSlashesResponse) - - - [Query](#lbm.distribution.v1beta1.Query) - -- [lbm/distribution/v1beta1/tx.proto](#lbm/distribution/v1beta1/tx.proto) - - [MsgFundCommunityPool](#lbm.distribution.v1beta1.MsgFundCommunityPool) - - [MsgFundCommunityPoolResponse](#lbm.distribution.v1beta1.MsgFundCommunityPoolResponse) - - [MsgSetWithdrawAddress](#lbm.distribution.v1beta1.MsgSetWithdrawAddress) - - [MsgSetWithdrawAddressResponse](#lbm.distribution.v1beta1.MsgSetWithdrawAddressResponse) - - [MsgWithdrawDelegatorReward](#lbm.distribution.v1beta1.MsgWithdrawDelegatorReward) - - [MsgWithdrawDelegatorRewardResponse](#lbm.distribution.v1beta1.MsgWithdrawDelegatorRewardResponse) - - [MsgWithdrawValidatorCommission](#lbm.distribution.v1beta1.MsgWithdrawValidatorCommission) - - [MsgWithdrawValidatorCommissionResponse](#lbm.distribution.v1beta1.MsgWithdrawValidatorCommissionResponse) - - - [Msg](#lbm.distribution.v1beta1.Msg) - -- [lbm/evidence/v1beta1/evidence.proto](#lbm/evidence/v1beta1/evidence.proto) - - [Equivocation](#lbm.evidence.v1beta1.Equivocation) - -- [lbm/evidence/v1beta1/genesis.proto](#lbm/evidence/v1beta1/genesis.proto) - - [GenesisState](#lbm.evidence.v1beta1.GenesisState) - -- [lbm/evidence/v1beta1/query.proto](#lbm/evidence/v1beta1/query.proto) - - [QueryAllEvidenceRequest](#lbm.evidence.v1beta1.QueryAllEvidenceRequest) - - [QueryAllEvidenceResponse](#lbm.evidence.v1beta1.QueryAllEvidenceResponse) - - [QueryEvidenceRequest](#lbm.evidence.v1beta1.QueryEvidenceRequest) - - [QueryEvidenceResponse](#lbm.evidence.v1beta1.QueryEvidenceResponse) - - - [Query](#lbm.evidence.v1beta1.Query) - -- [lbm/evidence/v1beta1/tx.proto](#lbm/evidence/v1beta1/tx.proto) - - [MsgSubmitEvidence](#lbm.evidence.v1beta1.MsgSubmitEvidence) - - [MsgSubmitEvidenceResponse](#lbm.evidence.v1beta1.MsgSubmitEvidenceResponse) - - - [Msg](#lbm.evidence.v1beta1.Msg) - -- [lbm/genutil/v1beta1/genesis.proto](#lbm/genutil/v1beta1/genesis.proto) - - [GenesisState](#lbm.genutil.v1beta1.GenesisState) - -- [lbm/gov/v1beta1/gov.proto](#lbm/gov/v1beta1/gov.proto) - - [Deposit](#lbm.gov.v1beta1.Deposit) - - [DepositParams](#lbm.gov.v1beta1.DepositParams) - - [Proposal](#lbm.gov.v1beta1.Proposal) - - [TallyParams](#lbm.gov.v1beta1.TallyParams) - - [TallyResult](#lbm.gov.v1beta1.TallyResult) - - [TextProposal](#lbm.gov.v1beta1.TextProposal) - - [Vote](#lbm.gov.v1beta1.Vote) - - [VotingParams](#lbm.gov.v1beta1.VotingParams) - - - [ProposalStatus](#lbm.gov.v1beta1.ProposalStatus) - - [VoteOption](#lbm.gov.v1beta1.VoteOption) - -- [lbm/gov/v1beta1/genesis.proto](#lbm/gov/v1beta1/genesis.proto) - - [GenesisState](#lbm.gov.v1beta1.GenesisState) - -- [lbm/gov/v1beta1/query.proto](#lbm/gov/v1beta1/query.proto) - - [QueryDepositRequest](#lbm.gov.v1beta1.QueryDepositRequest) - - [QueryDepositResponse](#lbm.gov.v1beta1.QueryDepositResponse) - - [QueryDepositsRequest](#lbm.gov.v1beta1.QueryDepositsRequest) - - [QueryDepositsResponse](#lbm.gov.v1beta1.QueryDepositsResponse) - - [QueryParamsRequest](#lbm.gov.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.gov.v1beta1.QueryParamsResponse) - - [QueryProposalRequest](#lbm.gov.v1beta1.QueryProposalRequest) - - [QueryProposalResponse](#lbm.gov.v1beta1.QueryProposalResponse) - - [QueryProposalsRequest](#lbm.gov.v1beta1.QueryProposalsRequest) - - [QueryProposalsResponse](#lbm.gov.v1beta1.QueryProposalsResponse) - - [QueryTallyResultRequest](#lbm.gov.v1beta1.QueryTallyResultRequest) - - [QueryTallyResultResponse](#lbm.gov.v1beta1.QueryTallyResultResponse) - - [QueryVoteRequest](#lbm.gov.v1beta1.QueryVoteRequest) - - [QueryVoteResponse](#lbm.gov.v1beta1.QueryVoteResponse) - - [QueryVotesRequest](#lbm.gov.v1beta1.QueryVotesRequest) - - [QueryVotesResponse](#lbm.gov.v1beta1.QueryVotesResponse) - - - [Query](#lbm.gov.v1beta1.Query) - -- [lbm/gov/v1beta1/tx.proto](#lbm/gov/v1beta1/tx.proto) - - [MsgDeposit](#lbm.gov.v1beta1.MsgDeposit) - - [MsgDepositResponse](#lbm.gov.v1beta1.MsgDepositResponse) - - [MsgSubmitProposal](#lbm.gov.v1beta1.MsgSubmitProposal) - - [MsgSubmitProposalResponse](#lbm.gov.v1beta1.MsgSubmitProposalResponse) - - [MsgVote](#lbm.gov.v1beta1.MsgVote) - - [MsgVoteResponse](#lbm.gov.v1beta1.MsgVoteResponse) - - - [Msg](#lbm.gov.v1beta1.Msg) - -- [lbm/mint/v1beta1/mint.proto](#lbm/mint/v1beta1/mint.proto) - - [Minter](#lbm.mint.v1beta1.Minter) - - [Params](#lbm.mint.v1beta1.Params) - -- [lbm/mint/v1beta1/genesis.proto](#lbm/mint/v1beta1/genesis.proto) - - [GenesisState](#lbm.mint.v1beta1.GenesisState) - -- [lbm/mint/v1beta1/query.proto](#lbm/mint/v1beta1/query.proto) - - [QueryAnnualProvisionsRequest](#lbm.mint.v1beta1.QueryAnnualProvisionsRequest) - - [QueryAnnualProvisionsResponse](#lbm.mint.v1beta1.QueryAnnualProvisionsResponse) - - [QueryInflationRequest](#lbm.mint.v1beta1.QueryInflationRequest) - - [QueryInflationResponse](#lbm.mint.v1beta1.QueryInflationResponse) - - [QueryParamsRequest](#lbm.mint.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.mint.v1beta1.QueryParamsResponse) - - - [Query](#lbm.mint.v1beta1.Query) - -- [lbm/params/v1beta1/params.proto](#lbm/params/v1beta1/params.proto) - - [ParamChange](#lbm.params.v1beta1.ParamChange) - - [ParameterChangeProposal](#lbm.params.v1beta1.ParameterChangeProposal) - -- [lbm/params/v1beta1/query.proto](#lbm/params/v1beta1/query.proto) - - [QueryParamsRequest](#lbm.params.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.params.v1beta1.QueryParamsResponse) - - - [Query](#lbm.params.v1beta1.Query) - -- [lbm/slashing/v1beta1/slashing.proto](#lbm/slashing/v1beta1/slashing.proto) - - [Params](#lbm.slashing.v1beta1.Params) - - [ValidatorSigningInfo](#lbm.slashing.v1beta1.ValidatorSigningInfo) - -- [lbm/slashing/v1beta1/genesis.proto](#lbm/slashing/v1beta1/genesis.proto) - - [GenesisState](#lbm.slashing.v1beta1.GenesisState) - - [MissedBlock](#lbm.slashing.v1beta1.MissedBlock) - - [SigningInfo](#lbm.slashing.v1beta1.SigningInfo) - - [ValidatorMissedBlocks](#lbm.slashing.v1beta1.ValidatorMissedBlocks) - -- [lbm/slashing/v1beta1/query.proto](#lbm/slashing/v1beta1/query.proto) - - [QueryParamsRequest](#lbm.slashing.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.slashing.v1beta1.QueryParamsResponse) - - [QuerySigningInfoRequest](#lbm.slashing.v1beta1.QuerySigningInfoRequest) - - [QuerySigningInfoResponse](#lbm.slashing.v1beta1.QuerySigningInfoResponse) - - [QuerySigningInfosRequest](#lbm.slashing.v1beta1.QuerySigningInfosRequest) - - [QuerySigningInfosResponse](#lbm.slashing.v1beta1.QuerySigningInfosResponse) - - - [Query](#lbm.slashing.v1beta1.Query) - -- [lbm/slashing/v1beta1/tx.proto](#lbm/slashing/v1beta1/tx.proto) - - [MsgUnjail](#lbm.slashing.v1beta1.MsgUnjail) - - [MsgUnjailResponse](#lbm.slashing.v1beta1.MsgUnjailResponse) - - - [Msg](#lbm.slashing.v1beta1.Msg) - -- [lbm/staking/v1beta1/staking.proto](#lbm/staking/v1beta1/staking.proto) - - [Commission](#lbm.staking.v1beta1.Commission) - - [CommissionRates](#lbm.staking.v1beta1.CommissionRates) - - [DVPair](#lbm.staking.v1beta1.DVPair) - - [DVPairs](#lbm.staking.v1beta1.DVPairs) - - [DVVTriplet](#lbm.staking.v1beta1.DVVTriplet) - - [DVVTriplets](#lbm.staking.v1beta1.DVVTriplets) - - [Delegation](#lbm.staking.v1beta1.Delegation) - - [DelegationResponse](#lbm.staking.v1beta1.DelegationResponse) - - [Description](#lbm.staking.v1beta1.Description) - - [HistoricalInfo](#lbm.staking.v1beta1.HistoricalInfo) - - [Params](#lbm.staking.v1beta1.Params) - - [Pool](#lbm.staking.v1beta1.Pool) - - [Redelegation](#lbm.staking.v1beta1.Redelegation) - - [RedelegationEntry](#lbm.staking.v1beta1.RedelegationEntry) - - [RedelegationEntryResponse](#lbm.staking.v1beta1.RedelegationEntryResponse) - - [RedelegationResponse](#lbm.staking.v1beta1.RedelegationResponse) - - [UnbondingDelegation](#lbm.staking.v1beta1.UnbondingDelegation) - - [UnbondingDelegationEntry](#lbm.staking.v1beta1.UnbondingDelegationEntry) - - [ValAddresses](#lbm.staking.v1beta1.ValAddresses) - - [Validator](#lbm.staking.v1beta1.Validator) - - - [BondStatus](#lbm.staking.v1beta1.BondStatus) - -- [lbm/staking/v1beta1/genesis.proto](#lbm/staking/v1beta1/genesis.proto) - - [GenesisState](#lbm.staking.v1beta1.GenesisState) - - [LastValidatorPower](#lbm.staking.v1beta1.LastValidatorPower) - -- [lbm/staking/v1beta1/query.proto](#lbm/staking/v1beta1/query.proto) - - [QueryDelegationRequest](#lbm.staking.v1beta1.QueryDelegationRequest) - - [QueryDelegationResponse](#lbm.staking.v1beta1.QueryDelegationResponse) - - [QueryDelegatorDelegationsRequest](#lbm.staking.v1beta1.QueryDelegatorDelegationsRequest) - - [QueryDelegatorDelegationsResponse](#lbm.staking.v1beta1.QueryDelegatorDelegationsResponse) - - [QueryDelegatorUnbondingDelegationsRequest](#lbm.staking.v1beta1.QueryDelegatorUnbondingDelegationsRequest) - - [QueryDelegatorUnbondingDelegationsResponse](#lbm.staking.v1beta1.QueryDelegatorUnbondingDelegationsResponse) - - [QueryDelegatorValidatorRequest](#lbm.staking.v1beta1.QueryDelegatorValidatorRequest) - - [QueryDelegatorValidatorResponse](#lbm.staking.v1beta1.QueryDelegatorValidatorResponse) - - [QueryDelegatorValidatorsRequest](#lbm.staking.v1beta1.QueryDelegatorValidatorsRequest) - - [QueryDelegatorValidatorsResponse](#lbm.staking.v1beta1.QueryDelegatorValidatorsResponse) - - [QueryHistoricalInfoRequest](#lbm.staking.v1beta1.QueryHistoricalInfoRequest) - - [QueryHistoricalInfoResponse](#lbm.staking.v1beta1.QueryHistoricalInfoResponse) - - [QueryParamsRequest](#lbm.staking.v1beta1.QueryParamsRequest) - - [QueryParamsResponse](#lbm.staking.v1beta1.QueryParamsResponse) - - [QueryPoolRequest](#lbm.staking.v1beta1.QueryPoolRequest) - - [QueryPoolResponse](#lbm.staking.v1beta1.QueryPoolResponse) - - [QueryRedelegationsRequest](#lbm.staking.v1beta1.QueryRedelegationsRequest) - - [QueryRedelegationsResponse](#lbm.staking.v1beta1.QueryRedelegationsResponse) - - [QueryUnbondingDelegationRequest](#lbm.staking.v1beta1.QueryUnbondingDelegationRequest) - - [QueryUnbondingDelegationResponse](#lbm.staking.v1beta1.QueryUnbondingDelegationResponse) - - [QueryValidatorDelegationsRequest](#lbm.staking.v1beta1.QueryValidatorDelegationsRequest) - - [QueryValidatorDelegationsResponse](#lbm.staking.v1beta1.QueryValidatorDelegationsResponse) - - [QueryValidatorRequest](#lbm.staking.v1beta1.QueryValidatorRequest) - - [QueryValidatorResponse](#lbm.staking.v1beta1.QueryValidatorResponse) - - [QueryValidatorUnbondingDelegationsRequest](#lbm.staking.v1beta1.QueryValidatorUnbondingDelegationsRequest) - - [QueryValidatorUnbondingDelegationsResponse](#lbm.staking.v1beta1.QueryValidatorUnbondingDelegationsResponse) - - [QueryValidatorsRequest](#lbm.staking.v1beta1.QueryValidatorsRequest) - - [QueryValidatorsResponse](#lbm.staking.v1beta1.QueryValidatorsResponse) - - - [Query](#lbm.staking.v1beta1.Query) - -- [lbm/staking/v1beta1/tx.proto](#lbm/staking/v1beta1/tx.proto) - - [MsgBeginRedelegate](#lbm.staking.v1beta1.MsgBeginRedelegate) - - [MsgBeginRedelegateResponse](#lbm.staking.v1beta1.MsgBeginRedelegateResponse) - - [MsgCreateValidator](#lbm.staking.v1beta1.MsgCreateValidator) - - [MsgCreateValidatorResponse](#lbm.staking.v1beta1.MsgCreateValidatorResponse) - - [MsgDelegate](#lbm.staking.v1beta1.MsgDelegate) - - [MsgDelegateResponse](#lbm.staking.v1beta1.MsgDelegateResponse) - - [MsgEditValidator](#lbm.staking.v1beta1.MsgEditValidator) - - [MsgEditValidatorResponse](#lbm.staking.v1beta1.MsgEditValidatorResponse) - - [MsgUndelegate](#lbm.staking.v1beta1.MsgUndelegate) - - [MsgUndelegateResponse](#lbm.staking.v1beta1.MsgUndelegateResponse) - - - [Msg](#lbm.staking.v1beta1.Msg) - -- [lbm/tx/signing/v1beta1/signing.proto](#lbm/tx/signing/v1beta1/signing.proto) - - [SignatureDescriptor](#lbm.tx.signing.v1beta1.SignatureDescriptor) - - [SignatureDescriptor.Data](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data) - - [SignatureDescriptor.Data.Multi](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data.Multi) - - [SignatureDescriptor.Data.Single](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data.Single) - - [SignatureDescriptors](#lbm.tx.signing.v1beta1.SignatureDescriptors) - - - [SignMode](#lbm.tx.signing.v1beta1.SignMode) - -- [lbm/tx/v1beta1/tx.proto](#lbm/tx/v1beta1/tx.proto) - - [AuthInfo](#lbm.tx.v1beta1.AuthInfo) - - [Fee](#lbm.tx.v1beta1.Fee) - - [ModeInfo](#lbm.tx.v1beta1.ModeInfo) - - [ModeInfo.Multi](#lbm.tx.v1beta1.ModeInfo.Multi) - - [ModeInfo.Single](#lbm.tx.v1beta1.ModeInfo.Single) - - [SignDoc](#lbm.tx.v1beta1.SignDoc) - - [SignerInfo](#lbm.tx.v1beta1.SignerInfo) - - [Tx](#lbm.tx.v1beta1.Tx) - - [TxBody](#lbm.tx.v1beta1.TxBody) - - [TxRaw](#lbm.tx.v1beta1.TxRaw) - -- [lbm/tx/v1beta1/service.proto](#lbm/tx/v1beta1/service.proto) - - [BroadcastTxRequest](#lbm.tx.v1beta1.BroadcastTxRequest) - - [BroadcastTxResponse](#lbm.tx.v1beta1.BroadcastTxResponse) - - [GetTxRequest](#lbm.tx.v1beta1.GetTxRequest) - - [GetTxResponse](#lbm.tx.v1beta1.GetTxResponse) - - [GetTxsEventRequest](#lbm.tx.v1beta1.GetTxsEventRequest) - - [GetTxsEventResponse](#lbm.tx.v1beta1.GetTxsEventResponse) - - [SimulateRequest](#lbm.tx.v1beta1.SimulateRequest) - - [SimulateResponse](#lbm.tx.v1beta1.SimulateResponse) - - - [BroadcastMode](#lbm.tx.v1beta1.BroadcastMode) - - - [Service](#lbm.tx.v1beta1.Service) - -- [lbm/upgrade/v1beta1/upgrade.proto](#lbm/upgrade/v1beta1/upgrade.proto) - - [CancelSoftwareUpgradeProposal](#lbm.upgrade.v1beta1.CancelSoftwareUpgradeProposal) - - [Plan](#lbm.upgrade.v1beta1.Plan) - - [SoftwareUpgradeProposal](#lbm.upgrade.v1beta1.SoftwareUpgradeProposal) - -- [lbm/upgrade/v1beta1/query.proto](#lbm/upgrade/v1beta1/query.proto) - - [QueryAppliedPlanRequest](#lbm.upgrade.v1beta1.QueryAppliedPlanRequest) - - [QueryAppliedPlanResponse](#lbm.upgrade.v1beta1.QueryAppliedPlanResponse) - - [QueryCurrentPlanRequest](#lbm.upgrade.v1beta1.QueryCurrentPlanRequest) - - [QueryCurrentPlanResponse](#lbm.upgrade.v1beta1.QueryCurrentPlanResponse) - - [QueryUpgradedConsensusStateRequest](#lbm.upgrade.v1beta1.QueryUpgradedConsensusStateRequest) - - [QueryUpgradedConsensusStateResponse](#lbm.upgrade.v1beta1.QueryUpgradedConsensusStateResponse) - - - [Query](#lbm.upgrade.v1beta1.Query) - -- [lbm/vesting/v1beta1/tx.proto](#lbm/vesting/v1beta1/tx.proto) - - [MsgCreateVestingAccount](#lbm.vesting.v1beta1.MsgCreateVestingAccount) - - [MsgCreateVestingAccountResponse](#lbm.vesting.v1beta1.MsgCreateVestingAccountResponse) - - - [Msg](#lbm.vesting.v1beta1.Msg) - -- [lbm/vesting/v1beta1/vesting.proto](#lbm/vesting/v1beta1/vesting.proto) - - [BaseVestingAccount](#lbm.vesting.v1beta1.BaseVestingAccount) - - [ContinuousVestingAccount](#lbm.vesting.v1beta1.ContinuousVestingAccount) - - [DelayedVestingAccount](#lbm.vesting.v1beta1.DelayedVestingAccount) - - [Period](#lbm.vesting.v1beta1.Period) - - [PeriodicVestingAccount](#lbm.vesting.v1beta1.PeriodicVestingAccount) - -- [Scalar Value Types](#scalar-value-types) - - - - -

Top

- -## ibc/applications/transfer/v1/transfer.proto - - - - - -### DenomTrace -DenomTrace contains the base denomination for ICS20 fungible tokens and the -source tracing information path. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [string](#string) | | path defines the chain of port/channel identifiers used for tracing the source of the fungible token. | -| `base_denom` | [string](#string) | | base denomination of the relayed fungible token. | - - - - - - - - -### FungibleTokenPacketData -FungibleTokenPacketData defines a struct for the packet payload -See FungibleTokenPacketData spec: -https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer#data-structures - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | the token denomination to be transferred | -| `amount` | [uint64](#uint64) | | the token amount to be transferred | -| `sender` | [string](#string) | | the sender address | -| `receiver` | [string](#string) | | the recipient address on the destination chain | - - - - - - - - -### Params -Params defines the set of IBC transfer parameters. -NOTE: To prevent a single token from being transferred, set the -TransfersEnabled parameter to true and then set the bank module's SendEnabled -parameter for the denomination to false. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `send_enabled` | [bool](#bool) | | send_enabled enables or disables all cross-chain token transfers from this chain. | -| `receive_enabled` | [bool](#bool) | | receive_enabled enables or disables all cross-chain token transfers to this chain. | - - - - - - - - - - - - - - - - -

Top

- -## ibc/applications/transfer/v1/genesis.proto - - - - - -### GenesisState -GenesisState defines the ibc-transfer genesis state - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `denom_traces` | [DenomTrace](#ibc.applications.transfer.v1.DenomTrace) | repeated | | -| `params` | [Params](#ibc.applications.transfer.v1.Params) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/base/query/v1beta1/pagination.proto - - - - - -### PageRequest -PageRequest is to be embedded in gRPC request messages for efficient -pagination. Ex: - - message SomeRequest { - Foo some_parameter = 1; - PageRequest pagination = 2; - } - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | key is a value returned in PageResponse.next_key to begin querying the next page most efficiently. Only one of offset or key should be set. | -| `offset` | [uint64](#uint64) | | offset is a numeric offset that can be used when key is unavailable. It is less efficient than using key. Only one of offset or key should be set. | -| `limit` | [uint64](#uint64) | | limit is the total number of results to be returned in the result page. If left empty it will default to a value to be set by each app. | -| `count_total` | [bool](#bool) | | count_total is set to true to indicate that the result set should include a count of the total number of items available for pagination in UIs. count_total is only respected when offset is used. It is ignored when key is set. | - - - - - - - - -### PageResponse -PageResponse is to be embedded in gRPC response messages where the -corresponding request message has used PageRequest. - - message SomeResponse { - repeated Bar results = 1; - PageResponse page = 2; - } - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `next_key` | [bytes](#bytes) | | next_key is the key to be passed to PageRequest.key to query the next page most efficiently | -| `total` | [uint64](#uint64) | | total is total number of results available if PageRequest.count_total was set, its value is undefined otherwise | - - - - - - - - - - - - - - - - -

Top

- -## ibc/applications/transfer/v1/query.proto - - - - - -### QueryDenomTraceRequest -QueryDenomTraceRequest is the request type for the Query/DenomTrace RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `hash` | [string](#string) | | hash (in hex format) of the denomination trace information. | - - - - - - - - -### QueryDenomTraceResponse -QueryDenomTraceResponse is the response type for the Query/DenomTrace RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom_trace` | [DenomTrace](#ibc.applications.transfer.v1.DenomTrace) | | denom_trace returns the requested denomination trace information. | - - - - - - - - -### QueryDenomTracesRequest -QueryConnectionsRequest is the request type for the Query/DenomTraces RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryDenomTracesResponse -QueryConnectionsResponse is the response type for the Query/DenomTraces RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom_traces` | [DenomTrace](#ibc.applications.transfer.v1.DenomTrace) | repeated | denom_traces returns all denominations trace information. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest is the request type for the Query/Params RPC method. - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is the response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#ibc.applications.transfer.v1.Params) | | params defines the parameters of the module. | - - - - - - - - - - - - - - -### Query -Query provides defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `DenomTrace` | [QueryDenomTraceRequest](#ibc.applications.transfer.v1.QueryDenomTraceRequest) | [QueryDenomTraceResponse](#ibc.applications.transfer.v1.QueryDenomTraceResponse) | DenomTrace queries a denomination trace information. | GET|/ibc/applications/transfer/v1beta1/denom_traces/{hash}| -| `DenomTraces` | [QueryDenomTracesRequest](#ibc.applications.transfer.v1.QueryDenomTracesRequest) | [QueryDenomTracesResponse](#ibc.applications.transfer.v1.QueryDenomTracesResponse) | DenomTraces queries all denomination traces. | GET|/ibc/applications/transfer/v1beta1/denom_traces| -| `Params` | [QueryParamsRequest](#ibc.applications.transfer.v1.QueryParamsRequest) | [QueryParamsResponse](#ibc.applications.transfer.v1.QueryParamsResponse) | Params queries all parameters of the ibc-transfer module. | GET|/ibc/applications/transfer/v1beta1/params| - - - - - - -

Top

- -## lbm/base/v1beta1/coin.proto - - - - - -### Coin -Coin defines a token with a denomination and an amount. - -NOTE: The amount field is an Int which implements the custom method -signatures required by gogoproto. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | | -| `amount` | [string](#string) | | | - - - - - - - - -### DecCoin -DecCoin defines a token with a denomination and a decimal amount. - -NOTE: The amount field is an Dec which implements the custom method -signatures required by gogoproto. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | | -| `amount` | [string](#string) | | | - - - - - - - - -### DecProto -DecProto defines a Protobuf wrapper around a Dec object. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `dec` | [string](#string) | | | - - - - - - - - -### IntProto -IntProto defines a Protobuf wrapper around an Int object. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `int` | [string](#string) | | | - - - - - - - - - - - - - - - - -

Top

- -## ibc/core/client/v1/client.proto - - - - - -### ClientConsensusStates -ClientConsensusStates defines all the stored consensus states for a given -client. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client identifier | -| `consensus_states` | [ConsensusStateWithHeight](#ibc.core.client.v1.ConsensusStateWithHeight) | repeated | consensus states and their heights associated with the client | - - - - - - - - -### ClientUpdateProposal -ClientUpdateProposal is a governance proposal. If it passes, the client is -updated with the provided header. The update may fail if the header is not -valid given certain conditions specified by the client implementation. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | the title of the update proposal | -| `description` | [string](#string) | | the description of the proposal | -| `client_id` | [string](#string) | | the client identifier for the client to be updated if the proposal passes | -| `header` | [google.protobuf.Any](#google.protobuf.Any) | | the header used to update the client if the proposal passes | - - - - - - - - -### ConsensusStateWithHeight -ConsensusStateWithHeight defines a consensus state with an additional height field. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [Height](#ibc.core.client.v1.Height) | | consensus state height | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | consensus state | - - - - - - - - -### Height -Height is a monotonically increasing data type -that can be compared against another Height for the purposes of updating and -freezing clients - -Normally the RevisionHeight is incremented at each height while keeping RevisionNumber -the same. However some consensus algorithms may choose to reset the -height in certain conditions e.g. hard forks, state-machine breaking changes -In these cases, the RevisionNumber is incremented so that height continues to -be monitonically increasing even as the RevisionHeight gets reset - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `revision_number` | [uint64](#uint64) | | the revision that the client is currently on | -| `revision_height` | [uint64](#uint64) | | the height within the given revision | - - - - - - - - -### IdentifiedClientState -IdentifiedClientState defines a client state with an additional client -identifier field. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client identifier | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | client state | - - - - - - - - -### Params -Params defines the set of IBC light client parameters. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `allowed_clients` | [string](#string) | repeated | allowed_clients defines the list of allowed client state types. | - - - - - - - - - - - - - - - - -

Top

- -## ibc/applications/transfer/v1/tx.proto - - - - - -### MsgTransfer -MsgTransfer defines a msg to transfer fungible tokens (i.e Coins) between -ICS20 enabled chains. See ICS Spec here: -https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer#data-structures - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `source_port` | [string](#string) | | the port on which the packet will be sent | -| `source_channel` | [string](#string) | | the channel by which the packet will be sent | -| `token` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | the tokens to be transferred | -| `sender` | [string](#string) | | the sender address | -| `receiver` | [string](#string) | | the recipient address on the destination chain | -| `timeout_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | Timeout height relative to the current block height. The timeout is disabled when set to 0. | -| `timeout_timestamp` | [uint64](#uint64) | | Timeout timestamp (in nanoseconds) relative to the current block timestamp. The timeout is disabled when set to 0. | - - - - - - - - -### MsgTransferResponse -MsgTransferResponse defines the Msg/Transfer response type. - - - - - - - - - - - - - - -### Msg -Msg defines the ibc/transfer Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Transfer` | [MsgTransfer](#ibc.applications.transfer.v1.MsgTransfer) | [MsgTransferResponse](#ibc.applications.transfer.v1.MsgTransferResponse) | Transfer defines a rpc handler method for MsgTransfer. | | - - - - - - -

Top

- -## ibc/core/channel/v1/channel.proto - - - - - -### Acknowledgement -Acknowledgement is the recommended acknowledgement format to be used by -app-specific protocols. -NOTE: The field numbers 21 and 22 were explicitly chosen to avoid accidental -conflicts with other protobuf message formats used for acknowledgements. -The first byte of any message with this format will be the non-ASCII values -`0xaa` (result) or `0xb2` (error). Implemented as defined by ICS: -https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics#acknowledgement-envelope - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `result` | [bytes](#bytes) | | | -| `error` | [string](#string) | | | - - - - - - - - -### Channel -Channel defines pipeline for exactly-once packet delivery between specific -modules on separate blockchains, which has at least one end capable of -sending packets and one end capable of receiving packets. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `state` | [State](#ibc.core.channel.v1.State) | | current state of the channel end | -| `ordering` | [Order](#ibc.core.channel.v1.Order) | | whether the channel is ordered or unordered | -| `counterparty` | [Counterparty](#ibc.core.channel.v1.Counterparty) | | counterparty channel end | -| `connection_hops` | [string](#string) | repeated | list of connection identifiers, in order, along which packets sent on this channel will travel | -| `version` | [string](#string) | | opaque channel version, which is agreed upon during the handshake | - - - - - - - - -### Counterparty -Counterparty defines a channel end counterparty - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port on the counterparty chain which owns the other end of the channel. | -| `channel_id` | [string](#string) | | channel end on the counterparty chain | - - - - - - - - -### IdentifiedChannel -IdentifiedChannel defines a channel with additional port and channel -identifier fields. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `state` | [State](#ibc.core.channel.v1.State) | | current state of the channel end | -| `ordering` | [Order](#ibc.core.channel.v1.Order) | | whether the channel is ordered or unordered | -| `counterparty` | [Counterparty](#ibc.core.channel.v1.Counterparty) | | counterparty channel end | -| `connection_hops` | [string](#string) | repeated | list of connection identifiers, in order, along which packets sent on this channel will travel | -| `version` | [string](#string) | | opaque channel version, which is agreed upon during the handshake | -| `port_id` | [string](#string) | | port identifier | -| `channel_id` | [string](#string) | | channel identifier | - - - - - - - - -### Packet -Packet defines a type that carries data across different chains through IBC - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sequence` | [uint64](#uint64) | | number corresponds to the order of sends and receives, where a Packet with an earlier sequence number must be sent and received before a Packet with a later sequence number. | -| `source_port` | [string](#string) | | identifies the port on the sending chain. | -| `source_channel` | [string](#string) | | identifies the channel end on the sending chain. | -| `destination_port` | [string](#string) | | identifies the port on the receiving chain. | -| `destination_channel` | [string](#string) | | identifies the channel end on the receiving chain. | -| `data` | [bytes](#bytes) | | actual opaque bytes transferred directly to the application module | -| `timeout_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | block height after which the packet times out | -| `timeout_timestamp` | [uint64](#uint64) | | block timestamp (in nanoseconds) after which the packet times out | - - - - - - - - -### PacketState -PacketState defines the generic type necessary to retrieve and store -packet commitments, acknowledgements, and receipts. -Caller is responsible for knowing the context necessary to interpret this -state as a commitment, acknowledgement, or a receipt. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | channel port identifier. | -| `channel_id` | [string](#string) | | channel unique identifier. | -| `sequence` | [uint64](#uint64) | | packet sequence. | -| `data` | [bytes](#bytes) | | embedded data that represents packet state. | - - - - - - - - - - -### Order -Order defines if a channel is ORDERED or UNORDERED - -| Name | Number | Description | -| ---- | ------ | ----------- | -| ORDER_NONE_UNSPECIFIED | 0 | zero-value for channel ordering | -| ORDER_UNORDERED | 1 | packets can be delivered in any order, which may differ from the order in which they were sent. | -| ORDER_ORDERED | 2 | packets are delivered exactly in the order which they were sent | - - - - - -### State -State defines if a channel is in one of the following states: -CLOSED, INIT, TRYOPEN, OPEN or UNINITIALIZED. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| STATE_UNINITIALIZED_UNSPECIFIED | 0 | Default State | -| STATE_INIT | 1 | A channel has just started the opening handshake. | -| STATE_TRYOPEN | 2 | A channel has acknowledged the handshake step on the counterparty chain. | -| STATE_OPEN | 3 | A channel has completed the handshake. Open channels are ready to send and receive packets. | -| STATE_CLOSED | 4 | A channel has been closed and can no longer be used to send or receive packets. | - - - - - - - - - - - -

Top

- -## ibc/core/channel/v1/genesis.proto - - - - - -### GenesisState -GenesisState defines the ibc channel submodule's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `channels` | [IdentifiedChannel](#ibc.core.channel.v1.IdentifiedChannel) | repeated | | -| `acknowledgements` | [PacketState](#ibc.core.channel.v1.PacketState) | repeated | | -| `commitments` | [PacketState](#ibc.core.channel.v1.PacketState) | repeated | | -| `receipts` | [PacketState](#ibc.core.channel.v1.PacketState) | repeated | | -| `send_sequences` | [PacketSequence](#ibc.core.channel.v1.PacketSequence) | repeated | | -| `recv_sequences` | [PacketSequence](#ibc.core.channel.v1.PacketSequence) | repeated | | -| `ack_sequences` | [PacketSequence](#ibc.core.channel.v1.PacketSequence) | repeated | | -| `next_channel_sequence` | [uint64](#uint64) | | the sequence for the next generated channel identifier | - - - - - - - - -### PacketSequence -PacketSequence defines the genesis type necessary to retrieve and store -next send and receive sequences. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `channel_id` | [string](#string) | | | -| `sequence` | [uint64](#uint64) | | | - - - - - - - - - - - - - - - - -

Top

- -## ibc/core/channel/v1/query.proto - - - - - -### QueryChannelClientStateRequest -QueryChannelClientStateRequest is the request type for the Query/ClientState -RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | - - - - - - - - -### QueryChannelClientStateResponse -QueryChannelClientStateResponse is the Response type for the -Query/QueryChannelClientState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `identified_client_state` | [ibc.core.client.v1.IdentifiedClientState](#ibc.core.client.v1.IdentifiedClientState) | | client state associated with the channel | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryChannelConsensusStateRequest -QueryChannelConsensusStateRequest is the request type for the -Query/ConsensusState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `revision_number` | [uint64](#uint64) | | revision number of the consensus state | -| `revision_height` | [uint64](#uint64) | | revision height of the consensus state | - - - - - - - - -### QueryChannelConsensusStateResponse -QueryChannelClientStateResponse is the Response type for the -Query/QueryChannelClientState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | consensus state associated with the channel | -| `client_id` | [string](#string) | | client ID associated with the consensus state | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryChannelRequest -QueryChannelRequest is the request type for the Query/Channel RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | - - - - - - - - -### QueryChannelResponse -QueryChannelResponse is the response type for the Query/Channel RPC method. -Besides the Channel end, it includes a proof and the height from which the -proof was retrieved. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `channel` | [Channel](#ibc.core.channel.v1.Channel) | | channel associated with the request identifiers | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryChannelsRequest -QueryChannelsRequest is the request type for the Query/Channels RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination request | - - - - - - - - -### QueryChannelsResponse -QueryChannelsResponse is the response type for the Query/Channels RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `channels` | [IdentifiedChannel](#ibc.core.channel.v1.IdentifiedChannel) | repeated | list of stored channels of the chain. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - -### QueryConnectionChannelsRequest -QueryConnectionChannelsRequest is the request type for the -Query/QueryConnectionChannels RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection` | [string](#string) | | connection unique identifier | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination request | - - - - - - - - -### QueryConnectionChannelsResponse -QueryConnectionChannelsResponse is the Response type for the -Query/QueryConnectionChannels RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `channels` | [IdentifiedChannel](#ibc.core.channel.v1.IdentifiedChannel) | repeated | list of channels associated with a connection. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - -### QueryNextSequenceReceiveRequest -QueryNextSequenceReceiveRequest is the request type for the -Query/QueryNextSequenceReceiveRequest RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | - - - - - - - - -### QueryNextSequenceReceiveResponse -QuerySequenceResponse is the request type for the -Query/QueryNextSequenceReceiveResponse RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `next_sequence_receive` | [uint64](#uint64) | | next sequence receive number | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryPacketAcknowledgementRequest -QueryPacketAcknowledgementRequest is the request type for the -Query/PacketAcknowledgement RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `sequence` | [uint64](#uint64) | | packet sequence | - - - - - - - - -### QueryPacketAcknowledgementResponse -QueryPacketAcknowledgementResponse defines the client query response for a -packet which also includes a proof and the height from which the -proof was retrieved - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `acknowledgement` | [bytes](#bytes) | | packet associated with the request fields | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryPacketAcknowledgementsRequest -QueryPacketAcknowledgementsRequest is the request type for the -Query/QueryPacketCommitments RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination request | - - - - - - - - -### QueryPacketAcknowledgementsResponse -QueryPacketAcknowledgemetsResponse is the request type for the -Query/QueryPacketAcknowledgements RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `acknowledgements` | [PacketState](#ibc.core.channel.v1.PacketState) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - -### QueryPacketCommitmentRequest -QueryPacketCommitmentRequest is the request type for the -Query/PacketCommitment RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `sequence` | [uint64](#uint64) | | packet sequence | - - - - - - - - -### QueryPacketCommitmentResponse -QueryPacketCommitmentResponse defines the client query response for a packet -which also includes a proof and the height from which the proof was -retrieved - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `commitment` | [bytes](#bytes) | | packet associated with the request fields | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryPacketCommitmentsRequest -QueryPacketCommitmentsRequest is the request type for the -Query/QueryPacketCommitments RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination request | - - - - - - - - -### QueryPacketCommitmentsResponse -QueryPacketCommitmentsResponse is the request type for the -Query/QueryPacketCommitments RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `commitments` | [PacketState](#ibc.core.channel.v1.PacketState) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - -### QueryPacketReceiptRequest -QueryPacketReceiptRequest is the request type for the -Query/PacketReceipt RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `sequence` | [uint64](#uint64) | | packet sequence | - - - - - - - - -### QueryPacketReceiptResponse -QueryPacketReceiptResponse defines the client query response for a packet receipt -which also includes a proof, and the height from which the proof was -retrieved - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `received` | [bool](#bool) | | success flag for if receipt exists | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryUnreceivedAcksRequest -QueryUnreceivedAcks is the request type for the -Query/UnreceivedAcks RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `packet_ack_sequences` | [uint64](#uint64) | repeated | list of acknowledgement sequences | - - - - - - - - -### QueryUnreceivedAcksResponse -QueryUnreceivedAcksResponse is the response type for the -Query/UnreceivedAcks RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sequences` | [uint64](#uint64) | repeated | list of unreceived acknowledgement sequences | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - -### QueryUnreceivedPacketsRequest -QueryUnreceivedPacketsRequest is the request type for the -Query/UnreceivedPackets RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | port unique identifier | -| `channel_id` | [string](#string) | | channel unique identifier | -| `packet_commitment_sequences` | [uint64](#uint64) | repeated | list of packet sequences | - - - - - - - - -### QueryUnreceivedPacketsResponse -QueryUnreceivedPacketsResponse is the response type for the -Query/UnreceivedPacketCommitments RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sequences` | [uint64](#uint64) | repeated | list of unreceived packet sequences | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - - - - - - - -### Query -Query provides defines the gRPC querier service - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Channel` | [QueryChannelRequest](#ibc.core.channel.v1.QueryChannelRequest) | [QueryChannelResponse](#ibc.core.channel.v1.QueryChannelResponse) | Channel queries an IBC Channel. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}| -| `Channels` | [QueryChannelsRequest](#ibc.core.channel.v1.QueryChannelsRequest) | [QueryChannelsResponse](#ibc.core.channel.v1.QueryChannelsResponse) | Channels queries all the IBC channels of a chain. | GET|/ibc/core/channel/v1beta1/channels| -| `ConnectionChannels` | [QueryConnectionChannelsRequest](#ibc.core.channel.v1.QueryConnectionChannelsRequest) | [QueryConnectionChannelsResponse](#ibc.core.channel.v1.QueryConnectionChannelsResponse) | ConnectionChannels queries all the channels associated with a connection end. | GET|/ibc/core/channel/v1beta1/connections/{connection}/channels| -| `ChannelClientState` | [QueryChannelClientStateRequest](#ibc.core.channel.v1.QueryChannelClientStateRequest) | [QueryChannelClientStateResponse](#ibc.core.channel.v1.QueryChannelClientStateResponse) | ChannelClientState queries for the client state for the channel associated with the provided channel identifiers. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/client_state| -| `ChannelConsensusState` | [QueryChannelConsensusStateRequest](#ibc.core.channel.v1.QueryChannelConsensusStateRequest) | [QueryChannelConsensusStateResponse](#ibc.core.channel.v1.QueryChannelConsensusStateResponse) | ChannelConsensusState queries for the consensus state for the channel associated with the provided channel identifiers. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/consensus_state/revision/{revision_number}/height/{revision_height}| -| `PacketCommitment` | [QueryPacketCommitmentRequest](#ibc.core.channel.v1.QueryPacketCommitmentRequest) | [QueryPacketCommitmentResponse](#ibc.core.channel.v1.QueryPacketCommitmentResponse) | PacketCommitment queries a stored packet commitment hash. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_commitments/{sequence}| -| `PacketCommitments` | [QueryPacketCommitmentsRequest](#ibc.core.channel.v1.QueryPacketCommitmentsRequest) | [QueryPacketCommitmentsResponse](#ibc.core.channel.v1.QueryPacketCommitmentsResponse) | PacketCommitments returns all the packet commitments hashes associated with a channel. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_commitments| -| `PacketReceipt` | [QueryPacketReceiptRequest](#ibc.core.channel.v1.QueryPacketReceiptRequest) | [QueryPacketReceiptResponse](#ibc.core.channel.v1.QueryPacketReceiptResponse) | PacketReceipt queries if a given packet sequence has been received on the queried chain | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_receipts/{sequence}| -| `PacketAcknowledgement` | [QueryPacketAcknowledgementRequest](#ibc.core.channel.v1.QueryPacketAcknowledgementRequest) | [QueryPacketAcknowledgementResponse](#ibc.core.channel.v1.QueryPacketAcknowledgementResponse) | PacketAcknowledgement queries a stored packet acknowledgement hash. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_acks/{sequence}| -| `PacketAcknowledgements` | [QueryPacketAcknowledgementsRequest](#ibc.core.channel.v1.QueryPacketAcknowledgementsRequest) | [QueryPacketAcknowledgementsResponse](#ibc.core.channel.v1.QueryPacketAcknowledgementsResponse) | PacketAcknowledgements returns all the packet acknowledgements associated with a channel. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_acknowledgements| -| `UnreceivedPackets` | [QueryUnreceivedPacketsRequest](#ibc.core.channel.v1.QueryUnreceivedPacketsRequest) | [QueryUnreceivedPacketsResponse](#ibc.core.channel.v1.QueryUnreceivedPacketsResponse) | UnreceivedPackets returns all the unreceived IBC packets associated with a channel and sequences. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_commitments/{packet_commitment_sequences}/unreceived_packets| -| `UnreceivedAcks` | [QueryUnreceivedAcksRequest](#ibc.core.channel.v1.QueryUnreceivedAcksRequest) | [QueryUnreceivedAcksResponse](#ibc.core.channel.v1.QueryUnreceivedAcksResponse) | UnreceivedAcks returns all the unreceived IBC acknowledgements associated with a channel and sequences. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/packet_commitments/{packet_ack_sequences}/unreceived_acks| -| `NextSequenceReceive` | [QueryNextSequenceReceiveRequest](#ibc.core.channel.v1.QueryNextSequenceReceiveRequest) | [QueryNextSequenceReceiveResponse](#ibc.core.channel.v1.QueryNextSequenceReceiveResponse) | NextSequenceReceive returns the next receive sequence for a given channel. | GET|/ibc/core/channel/v1beta1/channels/{channel_id}/ports/{port_id}/next_sequence| - - - - - - -

Top

- -## ibc/core/channel/v1/tx.proto - - - - - -### MsgAcknowledgement -MsgAcknowledgement receives incoming IBC acknowledgement - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `packet` | [Packet](#ibc.core.channel.v1.Packet) | | | -| `acknowledgement` | [bytes](#bytes) | | | -| `proof_acked` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgAcknowledgementResponse -MsgAcknowledgementResponse defines the Msg/Acknowledgement response type. - - - - - - - - -### MsgChannelCloseConfirm -MsgChannelCloseConfirm defines a msg sent by a Relayer to Chain B -to acknowledge the change of channel state to CLOSED on Chain A. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `channel_id` | [string](#string) | | | -| `proof_init` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgChannelCloseConfirmResponse -MsgChannelCloseConfirmResponse defines the Msg/ChannelCloseConfirm response type. - - - - - - - - -### MsgChannelCloseInit -MsgChannelCloseInit defines a msg sent by a Relayer to Chain A -to close a channel with Chain B. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `channel_id` | [string](#string) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgChannelCloseInitResponse -MsgChannelCloseInitResponse defines the Msg/ChannelCloseInit response type. - - - - - - - - -### MsgChannelOpenAck -MsgChannelOpenAck defines a msg sent by a Relayer to Chain A to acknowledge -the change of channel state to TRYOPEN on Chain B. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `channel_id` | [string](#string) | | | -| `counterparty_channel_id` | [string](#string) | | | -| `counterparty_version` | [string](#string) | | | -| `proof_try` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgChannelOpenAckResponse -MsgChannelOpenAckResponse defines the Msg/ChannelOpenAck response type. - - - - - - - - -### MsgChannelOpenConfirm -MsgChannelOpenConfirm defines a msg sent by a Relayer to Chain B to -acknowledge the change of channel state to OPEN on Chain A. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `channel_id` | [string](#string) | | | -| `proof_ack` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgChannelOpenConfirmResponse -MsgChannelOpenConfirmResponse defines the Msg/ChannelOpenConfirm response type. - - - - - - - - -### MsgChannelOpenInit -MsgChannelOpenInit defines an sdk.Msg to initialize a channel handshake. It -is called by a relayer on Chain A. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `channel` | [Channel](#ibc.core.channel.v1.Channel) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgChannelOpenInitResponse -MsgChannelOpenInitResponse defines the Msg/ChannelOpenInit response type. - - - - - - - - -### MsgChannelOpenTry -MsgChannelOpenInit defines a msg sent by a Relayer to try to open a channel -on Chain B. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `port_id` | [string](#string) | | | -| `previous_channel_id` | [string](#string) | | in the case of crossing hello's, when both chains call OpenInit, we need the channel identifier of the previous channel in state INIT | -| `channel` | [Channel](#ibc.core.channel.v1.Channel) | | | -| `counterparty_version` | [string](#string) | | | -| `proof_init` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgChannelOpenTryResponse -MsgChannelOpenTryResponse defines the Msg/ChannelOpenTry response type. - - - - - - - - -### MsgRecvPacket -MsgRecvPacket receives incoming IBC packet - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `packet` | [Packet](#ibc.core.channel.v1.Packet) | | | -| `proof_commitment` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgRecvPacketResponse -MsgRecvPacketResponse defines the Msg/RecvPacket response type. - - - - - - - - -### MsgTimeout -MsgTimeout receives timed-out packet - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `packet` | [Packet](#ibc.core.channel.v1.Packet) | | | -| `proof_unreceived` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `next_sequence_recv` | [uint64](#uint64) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgTimeoutOnClose -MsgTimeoutOnClose timed-out packet upon counterparty channel closure. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `packet` | [Packet](#ibc.core.channel.v1.Packet) | | | -| `proof_unreceived` | [bytes](#bytes) | | | -| `proof_close` | [bytes](#bytes) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `next_sequence_recv` | [uint64](#uint64) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgTimeoutOnCloseResponse -MsgTimeoutOnCloseResponse defines the Msg/TimeoutOnClose response type. - - - - - - - - -### MsgTimeoutResponse -MsgTimeoutResponse defines the Msg/Timeout response type. - - - - - - - - - - - - - - -### Msg -Msg defines the ibc/channel Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `ChannelOpenInit` | [MsgChannelOpenInit](#ibc.core.channel.v1.MsgChannelOpenInit) | [MsgChannelOpenInitResponse](#ibc.core.channel.v1.MsgChannelOpenInitResponse) | ChannelOpenInit defines a rpc handler method for MsgChannelOpenInit. | | -| `ChannelOpenTry` | [MsgChannelOpenTry](#ibc.core.channel.v1.MsgChannelOpenTry) | [MsgChannelOpenTryResponse](#ibc.core.channel.v1.MsgChannelOpenTryResponse) | ChannelOpenTry defines a rpc handler method for MsgChannelOpenTry. | | -| `ChannelOpenAck` | [MsgChannelOpenAck](#ibc.core.channel.v1.MsgChannelOpenAck) | [MsgChannelOpenAckResponse](#ibc.core.channel.v1.MsgChannelOpenAckResponse) | ChannelOpenAck defines a rpc handler method for MsgChannelOpenAck. | | -| `ChannelOpenConfirm` | [MsgChannelOpenConfirm](#ibc.core.channel.v1.MsgChannelOpenConfirm) | [MsgChannelOpenConfirmResponse](#ibc.core.channel.v1.MsgChannelOpenConfirmResponse) | ChannelOpenConfirm defines a rpc handler method for MsgChannelOpenConfirm. | | -| `ChannelCloseInit` | [MsgChannelCloseInit](#ibc.core.channel.v1.MsgChannelCloseInit) | [MsgChannelCloseInitResponse](#ibc.core.channel.v1.MsgChannelCloseInitResponse) | ChannelCloseInit defines a rpc handler method for MsgChannelCloseInit. | | -| `ChannelCloseConfirm` | [MsgChannelCloseConfirm](#ibc.core.channel.v1.MsgChannelCloseConfirm) | [MsgChannelCloseConfirmResponse](#ibc.core.channel.v1.MsgChannelCloseConfirmResponse) | ChannelCloseConfirm defines a rpc handler method for MsgChannelCloseConfirm. | | -| `RecvPacket` | [MsgRecvPacket](#ibc.core.channel.v1.MsgRecvPacket) | [MsgRecvPacketResponse](#ibc.core.channel.v1.MsgRecvPacketResponse) | RecvPacket defines a rpc handler method for MsgRecvPacket. | | -| `Timeout` | [MsgTimeout](#ibc.core.channel.v1.MsgTimeout) | [MsgTimeoutResponse](#ibc.core.channel.v1.MsgTimeoutResponse) | Timeout defines a rpc handler method for MsgTimeout. | | -| `TimeoutOnClose` | [MsgTimeoutOnClose](#ibc.core.channel.v1.MsgTimeoutOnClose) | [MsgTimeoutOnCloseResponse](#ibc.core.channel.v1.MsgTimeoutOnCloseResponse) | TimeoutOnClose defines a rpc handler method for MsgTimeoutOnClose. | | -| `Acknowledgement` | [MsgAcknowledgement](#ibc.core.channel.v1.MsgAcknowledgement) | [MsgAcknowledgementResponse](#ibc.core.channel.v1.MsgAcknowledgementResponse) | Acknowledgement defines a rpc handler method for MsgAcknowledgement. | | - - - - - - -

Top

- -## ibc/core/client/v1/genesis.proto - - - - - -### GenesisMetadata -GenesisMetadata defines the genesis type for metadata that clients may return -with ExportMetadata - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | store key of metadata without clientID-prefix | -| `value` | [bytes](#bytes) | | metadata value | - - - - - - - - -### GenesisState -GenesisState defines the ibc client submodule's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `clients` | [IdentifiedClientState](#ibc.core.client.v1.IdentifiedClientState) | repeated | client states with their corresponding identifiers | -| `clients_consensus` | [ClientConsensusStates](#ibc.core.client.v1.ClientConsensusStates) | repeated | consensus states from each client | -| `clients_metadata` | [IdentifiedGenesisMetadata](#ibc.core.client.v1.IdentifiedGenesisMetadata) | repeated | metadata from each client | -| `params` | [Params](#ibc.core.client.v1.Params) | | | -| `create_localhost` | [bool](#bool) | | create localhost on initialization | -| `next_client_sequence` | [uint64](#uint64) | | the sequence for the next generated client identifier | - - - - - - - - -### IdentifiedGenesisMetadata -IdentifiedGenesisMetadata has the client metadata with the corresponding client id. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | | -| `client_metadata` | [GenesisMetadata](#ibc.core.client.v1.GenesisMetadata) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## ibc/core/client/v1/query.proto - - - - - -### QueryClientParamsRequest -QueryClientParamsRequest is the request type for the Query/ClientParams RPC method. - - - - - - - - -### QueryClientParamsResponse -QueryClientParamsResponse is the response type for the Query/ClientParams RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#ibc.core.client.v1.Params) | | params defines the parameters of the module. | - - - - - - - - -### QueryClientStateRequest -QueryClientStateRequest is the request type for the Query/ClientState RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client state unique identifier | - - - - - - - - -### QueryClientStateResponse -QueryClientStateResponse is the response type for the Query/ClientState RPC -method. Besides the client state, it includes a proof and the height from -which the proof was retrieved. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | client state associated with the request identifier | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryClientStatesRequest -QueryClientStatesRequest is the request type for the Query/ClientStates RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination request | - - - - - - - - -### QueryClientStatesResponse -QueryClientStatesResponse is the response type for the Query/ClientStates RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_states` | [IdentifiedClientState](#ibc.core.client.v1.IdentifiedClientState) | repeated | list of stored ClientStates of the chain. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | - - - - - - - - -### QueryConsensusStateRequest -QueryConsensusStateRequest is the request type for the Query/ConsensusState -RPC method. Besides the consensus state, it includes a proof and the height -from which the proof was retrieved. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client identifier | -| `revision_number` | [uint64](#uint64) | | consensus state revision number | -| `revision_height` | [uint64](#uint64) | | consensus state revision height | -| `latest_height` | [bool](#bool) | | latest_height overrrides the height field and queries the latest stored ConsensusState | - - - - - - - - -### QueryConsensusStateResponse -QueryConsensusStateResponse is the response type for the Query/ConsensusState -RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | consensus state associated with the client identifier at the given height | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryConsensusStatesRequest -QueryConsensusStatesRequest is the request type for the Query/ConsensusStates -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client identifier | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination request | - - - - - - - - -### QueryConsensusStatesResponse -QueryConsensusStatesResponse is the response type for the -Query/ConsensusStates RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `consensus_states` | [ConsensusStateWithHeight](#ibc.core.client.v1.ConsensusStateWithHeight) | repeated | consensus states associated with the identifier | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | - - - - - - - - - - - - - - -### Query -Query provides defines the gRPC querier service - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `ClientState` | [QueryClientStateRequest](#ibc.core.client.v1.QueryClientStateRequest) | [QueryClientStateResponse](#ibc.core.client.v1.QueryClientStateResponse) | ClientState queries an IBC light client. | GET|/ibc/core/client/v1beta1/client_states/{client_id}| -| `ClientStates` | [QueryClientStatesRequest](#ibc.core.client.v1.QueryClientStatesRequest) | [QueryClientStatesResponse](#ibc.core.client.v1.QueryClientStatesResponse) | ClientStates queries all the IBC light clients of a chain. | GET|/ibc/core/client/v1beta1/client_states| -| `ConsensusState` | [QueryConsensusStateRequest](#ibc.core.client.v1.QueryConsensusStateRequest) | [QueryConsensusStateResponse](#ibc.core.client.v1.QueryConsensusStateResponse) | ConsensusState queries a consensus state associated with a client state at a given height. | GET|/ibc/core/client/v1beta1/consensus_states/{client_id}/revision/{revision_number}/height/{revision_height}| -| `ConsensusStates` | [QueryConsensusStatesRequest](#ibc.core.client.v1.QueryConsensusStatesRequest) | [QueryConsensusStatesResponse](#ibc.core.client.v1.QueryConsensusStatesResponse) | ConsensusStates queries all the consensus state associated with a given client. | GET|/ibc/core/client/v1beta1/consensus_states/{client_id}| -| `ClientParams` | [QueryClientParamsRequest](#ibc.core.client.v1.QueryClientParamsRequest) | [QueryClientParamsResponse](#ibc.core.client.v1.QueryClientParamsResponse) | ClientParams queries all parameters of the ibc client. | GET|/ibc/client/v1beta1/params| - - - - - - -

Top

- -## ibc/core/client/v1/tx.proto - - - - - -### MsgCreateClient -MsgCreateClient defines a message to create an IBC client - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | light client state | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | consensus state associated with the client that corresponds to a given height. | -| `signer` | [string](#string) | | signer address | - - - - - - - - -### MsgCreateClientResponse -MsgCreateClientResponse defines the Msg/CreateClient response type. - - - - - - - - -### MsgSubmitMisbehaviour -MsgSubmitMisbehaviour defines an sdk.Msg type that submits Evidence for -light client misbehaviour. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client unique identifier | -| `misbehaviour` | [google.protobuf.Any](#google.protobuf.Any) | | misbehaviour used for freezing the light client | -| `signer` | [string](#string) | | signer address | - - - - - - - - -### MsgSubmitMisbehaviourResponse -MsgSubmitMisbehaviourResponse defines the Msg/SubmitMisbehaviour response type. - - - - - - - - -### MsgUpdateClient -MsgUpdateClient defines an sdk.Msg to update a IBC client state using -the given header. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client unique identifier | -| `header` | [google.protobuf.Any](#google.protobuf.Any) | | header to update the light client | -| `signer` | [string](#string) | | signer address | - - - - - - - - -### MsgUpdateClientResponse -MsgUpdateClientResponse defines the Msg/UpdateClient response type. - - - - - - - - -### MsgUpgradeClient -MsgUpgradeClient defines an sdk.Msg to upgrade an IBC client to a new client state - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client unique identifier | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | upgraded client state | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | upgraded consensus state, only contains enough information to serve as a basis of trust in update logic | -| `proof_upgrade_client` | [bytes](#bytes) | | proof that old chain committed to new client | -| `proof_upgrade_consensus_state` | [bytes](#bytes) | | proof that old chain committed to new consensus state | -| `signer` | [string](#string) | | signer address | - - - - - - - - -### MsgUpgradeClientResponse -MsgUpgradeClientResponse defines the Msg/UpgradeClient response type. - - - - - - - - - - - - - - -### Msg -Msg defines the ibc/client Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `CreateClient` | [MsgCreateClient](#ibc.core.client.v1.MsgCreateClient) | [MsgCreateClientResponse](#ibc.core.client.v1.MsgCreateClientResponse) | CreateClient defines a rpc handler method for MsgCreateClient. | | -| `UpdateClient` | [MsgUpdateClient](#ibc.core.client.v1.MsgUpdateClient) | [MsgUpdateClientResponse](#ibc.core.client.v1.MsgUpdateClientResponse) | UpdateClient defines a rpc handler method for MsgUpdateClient. | | -| `UpgradeClient` | [MsgUpgradeClient](#ibc.core.client.v1.MsgUpgradeClient) | [MsgUpgradeClientResponse](#ibc.core.client.v1.MsgUpgradeClientResponse) | UpgradeClient defines a rpc handler method for MsgUpgradeClient. | | -| `SubmitMisbehaviour` | [MsgSubmitMisbehaviour](#ibc.core.client.v1.MsgSubmitMisbehaviour) | [MsgSubmitMisbehaviourResponse](#ibc.core.client.v1.MsgSubmitMisbehaviourResponse) | SubmitMisbehaviour defines a rpc handler method for MsgSubmitMisbehaviour. | | - - - - - - -

Top

- -## ibc/core/commitment/v1/commitment.proto - - - - - -### MerklePath -MerklePath is the path used to verify commitment proofs, which can be an -arbitrary structured object (defined by a commitment type). -MerklePath is represented from root-to-leaf - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key_path` | [string](#string) | repeated | | - - - - - - - - -### MerklePrefix -MerklePrefix is merkle path prefixed to the key. -The constructed key from the Path and the key will be append(Path.KeyPath, -append(Path.KeyPrefix, key...)) - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key_prefix` | [bytes](#bytes) | | | - - - - - - - - -### MerkleProof -MerkleProof is a wrapper type over a chain of CommitmentProofs. -It demonstrates membership or non-membership for an element or set of -elements, verifiable in conjunction with a known commitment root. Proofs -should be succinct. -MerkleProofs are ordered from leaf-to-root - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proofs` | [ics23.CommitmentProof](#ics23.CommitmentProof) | repeated | | - - - - - - - - -### MerkleRoot -MerkleRoot defines a merkle root hash. -In the Cosmos SDK, the AppHash of a block header becomes the root. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `hash` | [bytes](#bytes) | | | - - - - - - - - - - - - - - - - -

Top

- -## ibc/core/connection/v1/connection.proto - - - - - -### ClientPaths -ClientPaths define all the connection paths for a client state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `paths` | [string](#string) | repeated | list of connection paths | - - - - - - - - -### ConnectionEnd -ConnectionEnd defines a stateful object on a chain connected to another -separate one. -NOTE: there must only be 2 defined ConnectionEnds to establish -a connection between two chains. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client associated with this connection. | -| `versions` | [Version](#ibc.core.connection.v1.Version) | repeated | IBC version which can be utilised to determine encodings or protocols for channels or packets utilising this connection. | -| `state` | [State](#ibc.core.connection.v1.State) | | current state of the connection end. | -| `counterparty` | [Counterparty](#ibc.core.connection.v1.Counterparty) | | counterparty chain associated with this connection. | -| `delay_period` | [uint64](#uint64) | | delay period that must pass before a consensus state can be used for packet-verification NOTE: delay period logic is only implemented by some clients. | - - - - - - - - -### ConnectionPaths -ConnectionPaths define all the connection paths for a given client state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client state unique identifier | -| `paths` | [string](#string) | repeated | list of connection paths | - - - - - - - - -### Counterparty -Counterparty defines the counterparty chain associated with a connection end. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | identifies the client on the counterparty chain associated with a given connection. | -| `connection_id` | [string](#string) | | identifies the connection end on the counterparty chain associated with a given connection. | -| `prefix` | [ibc.core.commitment.v1.MerklePrefix](#ibc.core.commitment.v1.MerklePrefix) | | commitment merkle prefix of the counterparty chain. | - - - - - - - - -### IdentifiedConnection -IdentifiedConnection defines a connection with additional connection -identifier field. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `id` | [string](#string) | | connection identifier. | -| `client_id` | [string](#string) | | client associated with this connection. | -| `versions` | [Version](#ibc.core.connection.v1.Version) | repeated | IBC version which can be utilised to determine encodings or protocols for channels or packets utilising this connection | -| `state` | [State](#ibc.core.connection.v1.State) | | current state of the connection end. | -| `counterparty` | [Counterparty](#ibc.core.connection.v1.Counterparty) | | counterparty chain associated with this connection. | -| `delay_period` | [uint64](#uint64) | | delay period associated with this connection. | - - - - - - - - -### Version -Version defines the versioning scheme used to negotiate the IBC verison in -the connection handshake. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `identifier` | [string](#string) | | unique version identifier | -| `features` | [string](#string) | repeated | list of features compatible with the specified identifier | - - - - - - - - - - -### State -State defines if a connection is in one of the following states: -INIT, TRYOPEN, OPEN or UNINITIALIZED. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| STATE_UNINITIALIZED_UNSPECIFIED | 0 | Default State | -| STATE_INIT | 1 | A connection end has just started the opening handshake. | -| STATE_TRYOPEN | 2 | A connection end has acknowledged the handshake step on the counterparty chain. | -| STATE_OPEN | 3 | A connection end has completed the handshake. | - - - - - - - - - - - -

Top

- -## ibc/core/connection/v1/genesis.proto - - - - - -### GenesisState -GenesisState defines the ibc connection submodule's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connections` | [IdentifiedConnection](#ibc.core.connection.v1.IdentifiedConnection) | repeated | | -| `client_connection_paths` | [ConnectionPaths](#ibc.core.connection.v1.ConnectionPaths) | repeated | | -| `next_connection_sequence` | [uint64](#uint64) | | the sequence for the next generated connection identifier | - - - - - - - - - - - - - - - - -

Top

- -## ibc/core/connection/v1/query.proto - - - - - -### QueryClientConnectionsRequest -QueryClientConnectionsRequest is the request type for the -Query/ClientConnections RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | client identifier associated with a connection | - - - - - - - - -### QueryClientConnectionsResponse -QueryClientConnectionsResponse is the response type for the -Query/ClientConnections RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection_paths` | [string](#string) | repeated | slice of all the connection paths associated with a client. | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was generated | - - - - - - - - -### QueryConnectionClientStateRequest -QueryConnectionClientStateRequest is the request type for the -Query/ConnectionClientState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection_id` | [string](#string) | | connection identifier | - - - - - - - - -### QueryConnectionClientStateResponse -QueryConnectionClientStateResponse is the response type for the -Query/ConnectionClientState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `identified_client_state` | [ibc.core.client.v1.IdentifiedClientState](#ibc.core.client.v1.IdentifiedClientState) | | client state associated with the channel | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryConnectionConsensusStateRequest -QueryConnectionConsensusStateRequest is the request type for the -Query/ConnectionConsensusState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection_id` | [string](#string) | | connection identifier | -| `revision_number` | [uint64](#uint64) | | | -| `revision_height` | [uint64](#uint64) | | | - - - - - - - - -### QueryConnectionConsensusStateResponse -QueryConnectionConsensusStateResponse is the response type for the -Query/ConnectionConsensusState RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | consensus state associated with the channel | -| `client_id` | [string](#string) | | client ID associated with the consensus state | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryConnectionRequest -QueryConnectionRequest is the request type for the Query/Connection RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection_id` | [string](#string) | | connection unique identifier | - - - - - - - - -### QueryConnectionResponse -QueryConnectionResponse is the response type for the Query/Connection RPC -method. Besides the connection end, it includes a proof and the height from -which the proof was retrieved. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection` | [ConnectionEnd](#ibc.core.connection.v1.ConnectionEnd) | | connection associated with the request identifier | -| `proof` | [bytes](#bytes) | | merkle proof of existence | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | height at which the proof was retrieved | - - - - - - - - -### QueryConnectionsRequest -QueryConnectionsRequest is the request type for the Query/Connections RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | | - - - - - - - - -### QueryConnectionsResponse -QueryConnectionsResponse is the response type for the Query/Connections RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connections` | [IdentifiedConnection](#ibc.core.connection.v1.IdentifiedConnection) | repeated | list of stored connections of the chain. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination response | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | query block height | - - - - - - - - - - - - - - -### Query -Query provides defines the gRPC querier service - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Connection` | [QueryConnectionRequest](#ibc.core.connection.v1.QueryConnectionRequest) | [QueryConnectionResponse](#ibc.core.connection.v1.QueryConnectionResponse) | Connection queries an IBC connection end. | GET|/ibc/core/connection/v1beta1/connections/{connection_id}| -| `Connections` | [QueryConnectionsRequest](#ibc.core.connection.v1.QueryConnectionsRequest) | [QueryConnectionsResponse](#ibc.core.connection.v1.QueryConnectionsResponse) | Connections queries all the IBC connections of a chain. | GET|/ibc/core/connection/v1beta1/connections| -| `ClientConnections` | [QueryClientConnectionsRequest](#ibc.core.connection.v1.QueryClientConnectionsRequest) | [QueryClientConnectionsResponse](#ibc.core.connection.v1.QueryClientConnectionsResponse) | ClientConnections queries the connection paths associated with a client state. | GET|/ibc/core/connection/v1beta1/client_connections/{client_id}| -| `ConnectionClientState` | [QueryConnectionClientStateRequest](#ibc.core.connection.v1.QueryConnectionClientStateRequest) | [QueryConnectionClientStateResponse](#ibc.core.connection.v1.QueryConnectionClientStateResponse) | ConnectionClientState queries the client state associated with the connection. | GET|/ibc/core/connection/v1beta1/connections/{connection_id}/client_state| -| `ConnectionConsensusState` | [QueryConnectionConsensusStateRequest](#ibc.core.connection.v1.QueryConnectionConsensusStateRequest) | [QueryConnectionConsensusStateResponse](#ibc.core.connection.v1.QueryConnectionConsensusStateResponse) | ConnectionConsensusState queries the consensus state associated with the connection. | GET|/ibc/core/connection/v1beta1/connections/{connection_id}/consensus_state/revision/{revision_number}/height/{revision_height}| - - - - - - -

Top

- -## ibc/core/connection/v1/tx.proto - - - - - -### MsgConnectionOpenAck -MsgConnectionOpenAck defines a msg sent by a Relayer to Chain A to -acknowledge the change of connection state to TRYOPEN on Chain B. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection_id` | [string](#string) | | | -| `counterparty_connection_id` | [string](#string) | | | -| `version` | [Version](#ibc.core.connection.v1.Version) | | | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `proof_try` | [bytes](#bytes) | | proof of the initialization the connection on Chain B: `UNITIALIZED -> TRYOPEN` | -| `proof_client` | [bytes](#bytes) | | proof of client state included in message | -| `proof_consensus` | [bytes](#bytes) | | proof of client consensus state | -| `consensus_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgConnectionOpenAckResponse -MsgConnectionOpenAckResponse defines the Msg/ConnectionOpenAck response type. - - - - - - - - -### MsgConnectionOpenConfirm -MsgConnectionOpenConfirm defines a msg sent by a Relayer to Chain B to -acknowledge the change of connection state to OPEN on Chain A. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `connection_id` | [string](#string) | | | -| `proof_ack` | [bytes](#bytes) | | proof for the change of the connection state on Chain A: `INIT -> OPEN` | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgConnectionOpenConfirmResponse -MsgConnectionOpenConfirmResponse defines the Msg/ConnectionOpenConfirm response type. - - - - - - - - -### MsgConnectionOpenInit -MsgConnectionOpenInit defines the msg sent by an account on Chain A to -initialize a connection with Chain B. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | | -| `counterparty` | [Counterparty](#ibc.core.connection.v1.Counterparty) | | | -| `version` | [Version](#ibc.core.connection.v1.Version) | | | -| `delay_period` | [uint64](#uint64) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgConnectionOpenInitResponse -MsgConnectionOpenInitResponse defines the Msg/ConnectionOpenInit response type. - - - - - - - - -### MsgConnectionOpenTry -MsgConnectionOpenTry defines a msg sent by a Relayer to try to open a -connection on Chain B. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | | -| `previous_connection_id` | [string](#string) | | in the case of crossing hello's, when both chains call OpenInit, we need the connection identifier of the previous connection in state INIT | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `counterparty` | [Counterparty](#ibc.core.connection.v1.Counterparty) | | | -| `delay_period` | [uint64](#uint64) | | | -| `counterparty_versions` | [Version](#ibc.core.connection.v1.Version) | repeated | | -| `proof_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `proof_init` | [bytes](#bytes) | | proof of the initialization the connection on Chain A: `UNITIALIZED -> INIT` | -| `proof_client` | [bytes](#bytes) | | proof of client state included in message | -| `proof_consensus` | [bytes](#bytes) | | proof of client consensus state | -| `consensus_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `signer` | [string](#string) | | | - - - - - - - - -### MsgConnectionOpenTryResponse -MsgConnectionOpenTryResponse defines the Msg/ConnectionOpenTry response type. - - - - - - - - - - - - - - -### Msg -Msg defines the ibc/connection Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `ConnectionOpenInit` | [MsgConnectionOpenInit](#ibc.core.connection.v1.MsgConnectionOpenInit) | [MsgConnectionOpenInitResponse](#ibc.core.connection.v1.MsgConnectionOpenInitResponse) | ConnectionOpenInit defines a rpc handler method for MsgConnectionOpenInit. | | -| `ConnectionOpenTry` | [MsgConnectionOpenTry](#ibc.core.connection.v1.MsgConnectionOpenTry) | [MsgConnectionOpenTryResponse](#ibc.core.connection.v1.MsgConnectionOpenTryResponse) | ConnectionOpenTry defines a rpc handler method for MsgConnectionOpenTry. | | -| `ConnectionOpenAck` | [MsgConnectionOpenAck](#ibc.core.connection.v1.MsgConnectionOpenAck) | [MsgConnectionOpenAckResponse](#ibc.core.connection.v1.MsgConnectionOpenAckResponse) | ConnectionOpenAck defines a rpc handler method for MsgConnectionOpenAck. | | -| `ConnectionOpenConfirm` | [MsgConnectionOpenConfirm](#ibc.core.connection.v1.MsgConnectionOpenConfirm) | [MsgConnectionOpenConfirmResponse](#ibc.core.connection.v1.MsgConnectionOpenConfirmResponse) | ConnectionOpenConfirm defines a rpc handler method for MsgConnectionOpenConfirm. | | - - - - - - -

Top

- -## ibc/core/types/v1/genesis.proto - - - - - -### GenesisState -GenesisState defines the ibc module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_genesis` | [ibc.core.client.v1.GenesisState](#ibc.core.client.v1.GenesisState) | | ICS002 - Clients genesis state | -| `connection_genesis` | [ibc.core.connection.v1.GenesisState](#ibc.core.connection.v1.GenesisState) | | ICS003 - Connections genesis state | -| `channel_genesis` | [ibc.core.channel.v1.GenesisState](#ibc.core.channel.v1.GenesisState) | | ICS004 - Channel genesis state | - - - - - - - - - - - - - - - - -

Top

- -## ibc/lightclients/localhost/v1/localhost.proto - - - - - -### ClientState -ClientState defines a loopback (localhost) client. It requires (read-only) -access to keys outside the client prefix. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `chain_id` | [string](#string) | | self chain ID | -| `height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | self latest block height | - - - - - - - - - - - - - - - - -

Top

- -## ibc/lightclients/solomachine/v1/solomachine.proto - - - - - -### ChannelStateData -ChannelStateData returns the SignBytes data for channel state -verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `channel` | [ibc.core.channel.v1.Channel](#ibc.core.channel.v1.Channel) | | | - - - - - - - - -### ClientState -ClientState defines a solo machine client that tracks the current consensus -state and if the client is frozen. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sequence` | [uint64](#uint64) | | latest sequence of the client state | -| `frozen_sequence` | [uint64](#uint64) | | frozen sequence of the solo machine | -| `consensus_state` | [ConsensusState](#ibc.lightclients.solomachine.v1.ConsensusState) | | | -| `allow_update_after_proposal` | [bool](#bool) | | when set to true, will allow governance to update a solo machine client. The client will be unfrozen if it is frozen. | - - - - - - - - -### ClientStateData -ClientStateData returns the SignBytes data for client state verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `client_state` | [google.protobuf.Any](#google.protobuf.Any) | | | - - - - - - - - -### ConnectionStateData -ConnectionStateData returns the SignBytes data for connection state -verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `connection` | [ibc.core.connection.v1.ConnectionEnd](#ibc.core.connection.v1.ConnectionEnd) | | | - - - - - - - - -### ConsensusState -ConsensusState defines a solo machine consensus state. The sequence of a consensus state -is contained in the "height" key used in storing the consensus state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `public_key` | [google.protobuf.Any](#google.protobuf.Any) | | public key of the solo machine | -| `diversifier` | [string](#string) | | diversifier allows the same public key to be re-used across different solo machine clients (potentially on different chains) without being considered misbehaviour. | -| `timestamp` | [uint64](#uint64) | | | - - - - - - - - -### ConsensusStateData -ConsensusStateData returns the SignBytes data for consensus state -verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | | - - - - - - - - -### Header -Header defines a solo machine consensus header - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sequence` | [uint64](#uint64) | | sequence to update solo machine public key at | -| `timestamp` | [uint64](#uint64) | | | -| `signature` | [bytes](#bytes) | | | -| `new_public_key` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `new_diversifier` | [string](#string) | | | - - - - - - - - -### HeaderData -HeaderData returns the SignBytes data for update verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `new_pub_key` | [google.protobuf.Any](#google.protobuf.Any) | | header public key | -| `new_diversifier` | [string](#string) | | header diversifier | - - - - - - - - -### Misbehaviour -Misbehaviour defines misbehaviour for a solo machine which consists -of a sequence and two signatures over different messages at that sequence. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | | -| `sequence` | [uint64](#uint64) | | | -| `signature_one` | [SignatureAndData](#ibc.lightclients.solomachine.v1.SignatureAndData) | | | -| `signature_two` | [SignatureAndData](#ibc.lightclients.solomachine.v1.SignatureAndData) | | | - - - - - - - - -### NextSequenceRecvData -NextSequenceRecvData returns the SignBytes data for verification of the next -sequence to be received. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `next_seq_recv` | [uint64](#uint64) | | | - - - - - - - - -### PacketAcknowledgementData -PacketAcknowledgementData returns the SignBytes data for acknowledgement -verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `acknowledgement` | [bytes](#bytes) | | | - - - - - - - - -### PacketCommitmentData -PacketCommitmentData returns the SignBytes data for packet commitment -verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | -| `commitment` | [bytes](#bytes) | | | - - - - - - - - -### PacketReceiptAbsenceData -PacketReceiptAbsenceData returns the SignBytes data for -packet receipt absence verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [bytes](#bytes) | | | - - - - - - - - -### SignBytes -SignBytes defines the signed bytes used for signature verification. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sequence` | [uint64](#uint64) | | | -| `timestamp` | [uint64](#uint64) | | | -| `diversifier` | [string](#string) | | | -| `data_type` | [DataType](#ibc.lightclients.solomachine.v1.DataType) | | type of the data used | -| `data` | [bytes](#bytes) | | marshaled data | - - - - - - - - -### SignatureAndData -SignatureAndData contains a signature and the data signed over to create that -signature. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signature` | [bytes](#bytes) | | | -| `data_type` | [DataType](#ibc.lightclients.solomachine.v1.DataType) | | | -| `data` | [bytes](#bytes) | | | -| `timestamp` | [uint64](#uint64) | | | - - - - - - - - -### TimestampedSignatureData -TimestampedSignatureData contains the signature data and the timestamp of the -signature. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signature_data` | [bytes](#bytes) | | | -| `timestamp` | [uint64](#uint64) | | | - - - - - - - - - - -### DataType -DataType defines the type of solo machine proof being created. This is done to preserve uniqueness of different -data sign byte encodings. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| DATA_TYPE_UNINITIALIZED_UNSPECIFIED | 0 | Default State | -| DATA_TYPE_CLIENT_STATE | 1 | Data type for client state verification | -| DATA_TYPE_CONSENSUS_STATE | 2 | Data type for consensus state verification | -| DATA_TYPE_CONNECTION_STATE | 3 | Data type for connection state verification | -| DATA_TYPE_CHANNEL_STATE | 4 | Data type for channel state verification | -| DATA_TYPE_PACKET_COMMITMENT | 5 | Data type for packet commitment verification | -| DATA_TYPE_PACKET_ACKNOWLEDGEMENT | 6 | Data type for packet acknowledgement verification | -| DATA_TYPE_PACKET_RECEIPT_ABSENCE | 7 | Data type for packet receipt absence verification | -| DATA_TYPE_NEXT_SEQUENCE_RECV | 8 | Data type for next sequence recv verification | -| DATA_TYPE_HEADER | 9 | Data type for header verification | - - - - - - - - - - - -

Top

- -## ibc/lightclients/tendermint/v1/tendermint.proto - - - - - -### ClientState -ClientState from Tendermint tracks the current validator set, latest height, -and a possible frozen height. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `chain_id` | [string](#string) | | | -| `trust_level` | [Fraction](#ibc.lightclients.tendermint.v1.Fraction) | | | -| `trusting_period` | [google.protobuf.Duration](#google.protobuf.Duration) | | duration of the period since the LastestTimestamp during which the submitted headers are valid for upgrade | -| `unbonding_period` | [google.protobuf.Duration](#google.protobuf.Duration) | | duration of the staking unbonding period | -| `max_clock_drift` | [google.protobuf.Duration](#google.protobuf.Duration) | | defines how much new (untrusted) header's Time can drift into the future. | -| `frozen_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | Block height when the client was frozen due to a misbehaviour | -| `latest_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | Latest height the client was updated to | -| `proof_specs` | [ics23.ProofSpec](#ics23.ProofSpec) | repeated | Proof specifications used in verifying counterparty state | -| `upgrade_path` | [string](#string) | repeated | Path at which next upgraded client will be committed. Each element corresponds to the key for a single CommitmentProof in the chained proof. NOTE: ClientState must stored under `{upgradePath}/{upgradeHeight}/clientState` ConsensusState must be stored under `{upgradepath}/{upgradeHeight}/consensusState` For SDK chains using the default upgrade module, upgrade_path should be []string{"upgrade", "upgradedIBCState"}` | -| `allow_update_after_expiry` | [bool](#bool) | | This flag, when set to true, will allow governance to recover a client which has expired | -| `allow_update_after_misbehaviour` | [bool](#bool) | | This flag, when set to true, will allow governance to unfreeze a client whose chain has experienced a misbehaviour event | - - - - - - - - -### ConsensusState -ConsensusState defines the consensus state from Tendermint. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `timestamp` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | timestamp that corresponds to the block height in which the ConsensusState was stored. | -| `root` | [ibc.core.commitment.v1.MerkleRoot](#ibc.core.commitment.v1.MerkleRoot) | | commitment root (i.e app hash) | -| `next_validators_hash` | [bytes](#bytes) | | | - - - - - - - - -### Fraction -Fraction defines the protobuf message type for tmmath.Fraction that only supports positive values. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `numerator` | [uint64](#uint64) | | | -| `denominator` | [uint64](#uint64) | | | - - - - - - - - -### Header -Header defines the Tendermint client consensus Header. -It encapsulates all the information necessary to update from a trusted -Tendermint ConsensusState. The inclusion of TrustedHeight and -TrustedValidators allows this update to process correctly, so long as the -ConsensusState for the TrustedHeight exists, this removes race conditions -among relayers The SignedHeader and ValidatorSet are the new untrusted update -fields for the client. The TrustedHeight is the height of a stored -ConsensusState on the client that will be used to verify the new untrusted -header. The Trusted ConsensusState must be within the unbonding period of -current time in order to correctly verify, and the TrustedValidators must -hash to TrustedConsensusState.NextValidatorsHash since that is the last -trusted validator set at the TrustedHeight. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signed_header` | [ostracon.types.SignedHeader](#ostracon.types.SignedHeader) | | | -| `validator_set` | [ostracon.types.ValidatorSet](#ostracon.types.ValidatorSet) | | | -| `trusted_height` | [ibc.core.client.v1.Height](#ibc.core.client.v1.Height) | | | -| `trusted_validators` | [ostracon.types.ValidatorSet](#ostracon.types.ValidatorSet) | | | - - - - - - - - -### Misbehaviour -Misbehaviour is a wrapper over two conflicting Headers -that implements Misbehaviour interface expected by ICS-02 - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `client_id` | [string](#string) | | | -| `header_1` | [Header](#ibc.lightclients.tendermint.v1.Header) | | | -| `header_2` | [Header](#ibc.lightclients.tendermint.v1.Header) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/auth/v1beta1/auth.proto - - - - - -### BaseAccount -BaseAccount defines a base account type. It contains all the necessary fields -for basic account functionality. Any custom account type should extend this -type for additional functionality (e.g. vesting). - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | | -| `pub_key` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `account_number` | [uint64](#uint64) | | | -| `sequence` | [uint64](#uint64) | | | - - - - - - - - -### ModuleAccount -ModuleAccount defines an account for modules that holds coins on a pool. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `base_account` | [BaseAccount](#lbm.auth.v1beta1.BaseAccount) | | | -| `name` | [string](#string) | | | -| `permissions` | [string](#string) | repeated | | - - - - - - - - -### Params -Params defines the parameters for the auth module. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `max_memo_characters` | [uint64](#uint64) | | | -| `tx_sig_limit` | [uint64](#uint64) | | | -| `tx_size_cost_per_byte` | [uint64](#uint64) | | | -| `sig_verify_cost_ed25519` | [uint64](#uint64) | | | -| `sig_verify_cost_secp256k1` | [uint64](#uint64) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/auth/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the auth module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.auth.v1beta1.Params) | | params defines all the paramaters of the module. | -| `accounts` | [google.protobuf.Any](#google.protobuf.Any) | repeated | accounts are the accounts present at genesis. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/auth/v1beta1/query.proto - - - - - -### QueryAccountRequest -QueryAccountRequest is the request type for the Query/Account RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address defines the address to query for. | - - - - - - - - -### QueryAccountResponse -QueryAccountResponse is the response type for the Query/Account RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `account` | [google.protobuf.Any](#google.protobuf.Any) | | account defines the account of the corresponding address. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest is the request type for the Query/Params RPC method. - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is the response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.auth.v1beta1.Params) | | params defines the parameters of the module. | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Account` | [QueryAccountRequest](#lbm.auth.v1beta1.QueryAccountRequest) | [QueryAccountResponse](#lbm.auth.v1beta1.QueryAccountResponse) | Account returns account details based on address. | GET|/lbm/auth/v1beta1/accounts/{address}| -| `Params` | [QueryParamsRequest](#lbm.auth.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.auth.v1beta1.QueryParamsResponse) | Params queries all parameters. | GET|/lbm/auth/v1beta1/params| - - - - - - -

Top

- -## lbm/auth/v1beta1/tx.proto - - - - - -### MsgEmpty -MsgEmpty represents a message that doesn't do anything. Used to measure performance. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `from_address` | [string](#string) | | | - - - - - - - - -### MsgEmptyResponse -MsgEmptyResponse defines the Msg/Empty response type. - - - - - - - - - - - - - - -### Msg -Msg defines the auth Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Empty` | [MsgEmpty](#lbm.auth.v1beta1.MsgEmpty) | [MsgEmptyResponse](#lbm.auth.v1beta1.MsgEmptyResponse) | Empty defines a method that doesn't do anything. Used to measure performance. | | - - - - - - -

Top

- -## lbm/bank/v1beta1/bank.proto - - - - - -### DenomUnit -DenomUnit represents a struct that describes a given -denomination unit of the basic token. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | denom represents the string name of the given denom unit (e.g uatom). | -| `exponent` | [uint32](#uint32) | | exponent represents power of 10 exponent that one must raise the base_denom to in order to equal the given DenomUnit's denom 1 denom = 1^exponent base_denom (e.g. with a base_denom of uatom, one can create a DenomUnit of 'atom' with exponent = 6, thus: 1 atom = 10^6 uatom). | -| `aliases` | [string](#string) | repeated | aliases is a list of string aliases for the given denom | - - - - - - - - -### Input -Input models transaction input. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | | -| `coins` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### Metadata -Metadata represents a struct that describes -a basic token. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `description` | [string](#string) | | | -| `denom_units` | [DenomUnit](#lbm.bank.v1beta1.DenomUnit) | repeated | denom_units represents the list of DenomUnit's for a given coin | -| `base` | [string](#string) | | base represents the base denom (should be the DenomUnit with exponent = 0). | -| `display` | [string](#string) | | display indicates the suggested denom that should be displayed in clients. | - - - - - - - - -### Output -Output models transaction outputs. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | | -| `coins` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### Params -Params defines the parameters for the bank module. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `send_enabled` | [SendEnabled](#lbm.bank.v1beta1.SendEnabled) | repeated | | -| `default_send_enabled` | [bool](#bool) | | | - - - - - - - - -### SendEnabled -SendEnabled maps coin denom to a send_enabled status (whether a denom is -sendable). - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | | -| `enabled` | [bool](#bool) | | | - - - - - - - - -### Supply -Supply represents a struct that passively keeps track of the total supply -amounts in the network. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `total` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/bank/v1beta1/genesis.proto - - - - - -### Balance -Balance defines an account address and balance pair used in the bank module's -genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address is the address of the balance holder. | -| `coins` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | coins defines the different coins this balance holds. | - - - - - - - - -### GenesisState -GenesisState defines the bank module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.bank.v1beta1.Params) | | params defines all the paramaters of the module. | -| `balances` | [Balance](#lbm.bank.v1beta1.Balance) | repeated | balances is an array containing the balances of all the accounts. | -| `supply` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | supply represents the total supply. | -| `denom_metadata` | [Metadata](#lbm.bank.v1beta1.Metadata) | repeated | denom_metadata defines the metadata of the differents coins. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/bank/v1beta1/query.proto - - - - - -### QueryAllBalancesRequest -QueryBalanceRequest is the request type for the Query/AllBalances RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address is the address to query balances for. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryAllBalancesResponse -QueryAllBalancesResponse is the response type for the Query/AllBalances RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `balances` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | balances is the balances of all the coins. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryBalanceRequest -QueryBalanceRequest is the request type for the Query/Balance RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address is the address to query balances for. | -| `denom` | [string](#string) | | denom is the coin denom to query balances for. | - - - - - - - - -### QueryBalanceResponse -QueryBalanceResponse is the response type for the Query/Balance RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `balance` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | balance is the balance of the coin. | - - - - - - - - -### QueryDenomMetadataRequest -QueryDenomMetadataRequest is the request type for the Query/DenomMetadata RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | denom is the coin denom to query the metadata for. | - - - - - - - - -### QueryDenomMetadataResponse -QueryDenomMetadataResponse is the response type for the Query/DenomMetadata RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `metadata` | [Metadata](#lbm.bank.v1beta1.Metadata) | | metadata describes and provides all the client information for the requested token. | - - - - - - - - -### QueryDenomsMetadataRequest -QueryDenomsMetadataRequest is the request type for the Query/DenomsMetadata RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryDenomsMetadataResponse -QueryDenomsMetadataResponse is the response type for the Query/DenomsMetadata RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `metadatas` | [Metadata](#lbm.bank.v1beta1.Metadata) | repeated | metadata provides the client information for all the registered tokens. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest defines the request type for querying x/bank parameters. - - - - - - - - -### QueryParamsResponse -QueryParamsResponse defines the response type for querying x/bank parameters. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.bank.v1beta1.Params) | | | - - - - - - - - -### QuerySupplyOfRequest -QuerySupplyOfRequest is the request type for the Query/SupplyOf RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `denom` | [string](#string) | | denom is the coin denom to query balances for. | - - - - - - - - -### QuerySupplyOfResponse -QuerySupplyOfResponse is the response type for the Query/SupplyOf RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | amount is the supply of the coin. | - - - - - - - - -### QueryTotalSupplyRequest -QueryTotalSupplyRequest is the request type for the Query/TotalSupply RPC -method. - - - - - - - - -### QueryTotalSupplyResponse -QueryTotalSupplyResponse is the response type for the Query/TotalSupply RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `supply` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | supply is the supply of the coins | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Balance` | [QueryBalanceRequest](#lbm.bank.v1beta1.QueryBalanceRequest) | [QueryBalanceResponse](#lbm.bank.v1beta1.QueryBalanceResponse) | Balance queries the balance of a single coin for a single account. | GET|/lbm/bank/v1beta1/balances/{address}/{denom}| -| `AllBalances` | [QueryAllBalancesRequest](#lbm.bank.v1beta1.QueryAllBalancesRequest) | [QueryAllBalancesResponse](#lbm.bank.v1beta1.QueryAllBalancesResponse) | AllBalances queries the balance of all coins for a single account. | GET|/lbm/bank/v1beta1/balances/{address}| -| `TotalSupply` | [QueryTotalSupplyRequest](#lbm.bank.v1beta1.QueryTotalSupplyRequest) | [QueryTotalSupplyResponse](#lbm.bank.v1beta1.QueryTotalSupplyResponse) | TotalSupply queries the total supply of all coins. | GET|/lbm/bank/v1beta1/supply| -| `SupplyOf` | [QuerySupplyOfRequest](#lbm.bank.v1beta1.QuerySupplyOfRequest) | [QuerySupplyOfResponse](#lbm.bank.v1beta1.QuerySupplyOfResponse) | SupplyOf queries the supply of a single coin. | GET|/lbm/bank/v1beta1/supply/{denom}| -| `Params` | [QueryParamsRequest](#lbm.bank.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.bank.v1beta1.QueryParamsResponse) | Params queries the parameters of x/bank module. | GET|/lbm/bank/v1beta1/params| -| `DenomMetadata` | [QueryDenomMetadataRequest](#lbm.bank.v1beta1.QueryDenomMetadataRequest) | [QueryDenomMetadataResponse](#lbm.bank.v1beta1.QueryDenomMetadataResponse) | DenomsMetadata queries the client metadata of a given coin denomination. | GET|/lbm/bank/v1beta1/denoms_metadata/{denom}| -| `DenomsMetadata` | [QueryDenomsMetadataRequest](#lbm.bank.v1beta1.QueryDenomsMetadataRequest) | [QueryDenomsMetadataResponse](#lbm.bank.v1beta1.QueryDenomsMetadataResponse) | DenomsMetadata queries the client metadata for all registered coin denominations. | GET|/lbm/bank/v1beta1/denoms_metadata| - - - - - - -

Top

- -## lbm/bank/v1beta1/tx.proto - - - - - -### MsgMultiSend -MsgMultiSend represents an arbitrary multi-in, multi-out send message. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `inputs` | [Input](#lbm.bank.v1beta1.Input) | repeated | | -| `outputs` | [Output](#lbm.bank.v1beta1.Output) | repeated | | - - - - - - - - -### MsgMultiSendResponse -MsgMultiSendResponse defines the Msg/MultiSend response type. - - - - - - - - -### MsgSend -MsgSend represents a message to send coins from one account to another. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `from_address` | [string](#string) | | | -| `to_address` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### MsgSendResponse -MsgSendResponse defines the Msg/Send response type. - - - - - - - - - - - - - - -### Msg -Msg defines the bank Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Send` | [MsgSend](#lbm.bank.v1beta1.MsgSend) | [MsgSendResponse](#lbm.bank.v1beta1.MsgSendResponse) | Send defines a method for sending coins from one account to another account. | | -| `MultiSend` | [MsgMultiSend](#lbm.bank.v1beta1.MsgMultiSend) | [MsgMultiSendResponse](#lbm.bank.v1beta1.MsgMultiSendResponse) | MultiSend defines a method for sending coins from some accounts to other accounts. | | - - - - - - -

Top

- -## lbm/base/abci/v1beta1/abci.proto - - - - - -### ABCIMessageLog -ABCIMessageLog defines a structure containing an indexed tx ABCI message log. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `msg_index` | [uint32](#uint32) | | | -| `log` | [string](#string) | | | -| `events` | [StringEvent](#lbm.base.abci.v1beta1.StringEvent) | repeated | Events contains a slice of Event objects that were emitted during some execution. | - - - - - - - - -### Attribute -Attribute defines an attribute wrapper where the key and value are -strings instead of raw bytes. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [string](#string) | | | -| `value` | [string](#string) | | | - - - - - - - - -### GasInfo -GasInfo defines tx execution gas context. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `gas_wanted` | [uint64](#uint64) | | GasWanted is the maximum units of work we allow this tx to perform. | -| `gas_used` | [uint64](#uint64) | | GasUsed is the amount of gas actually consumed. | - - - - - - - - -### MsgData -MsgData defines the data returned in a Result object during message -execution. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `msg_type` | [string](#string) | | | -| `data` | [bytes](#bytes) | | | - - - - - - - - -### Result -Result is the union of ResponseFormat and ResponseCheckTx. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `data` | [bytes](#bytes) | | Data is any data returned from message or handler execution. It MUST be length prefixed in order to separate data from multiple message executions. | -| `log` | [string](#string) | | Log contains the log information from message or handler execution. | -| `events` | [ostracon.abci.Event](#ostracon.abci.Event) | repeated | Events contains a slice of Event objects that were emitted during message or handler execution. | - - - - - - - - -### SearchTxsResult -SearchTxsResult defines a structure for querying txs pageable - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `total_count` | [uint64](#uint64) | | Count of all txs | -| `count` | [uint64](#uint64) | | Count of txs in current page | -| `page_number` | [uint64](#uint64) | | Index of current page, start from 1 | -| `page_total` | [uint64](#uint64) | | Count of total pages | -| `limit` | [uint64](#uint64) | | Max count txs per page | -| `txs` | [TxResponse](#lbm.base.abci.v1beta1.TxResponse) | repeated | List of txs in current page | - - - - - - - - -### SimulationResponse -SimulationResponse defines the response generated when a transaction is -successfully simulated. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `gas_info` | [GasInfo](#lbm.base.abci.v1beta1.GasInfo) | | | -| `result` | [Result](#lbm.base.abci.v1beta1.Result) | | | - - - - - - - - -### StringEvent -StringEvent defines en Event object wrapper where all the attributes -contain key/value pairs that are strings instead of raw bytes. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `type` | [string](#string) | | | -| `attributes` | [Attribute](#lbm.base.abci.v1beta1.Attribute) | repeated | | - - - - - - - - -### TxMsgData -TxMsgData defines a list of MsgData. A transaction will have a MsgData object -for each message. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `data` | [MsgData](#lbm.base.abci.v1beta1.MsgData) | repeated | | - - - - - - - - -### TxResponse -TxResponse defines a structure containing relevant tx data and metadata. The -tags are stringified and the log is JSON decoded. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [int64](#int64) | | The block height | -| `txhash` | [string](#string) | | The transaction hash. | -| `codespace` | [string](#string) | | Namespace for the Code | -| `code` | [uint32](#uint32) | | Response code. | -| `data` | [string](#string) | | Result bytes, if any. | -| `raw_log` | [string](#string) | | The output of the application's logger (raw string). May be non-deterministic. | -| `logs` | [ABCIMessageLog](#lbm.base.abci.v1beta1.ABCIMessageLog) | repeated | The output of the application's logger (typed). May be non-deterministic. | -| `info` | [string](#string) | | Additional information. May be non-deterministic. | -| `gas_wanted` | [int64](#int64) | | Amount of gas requested for transaction. | -| `gas_used` | [int64](#int64) | | Amount of gas consumed by transaction. | -| `tx` | [google.protobuf.Any](#google.protobuf.Any) | | The request transaction bytes. | -| `timestamp` | [string](#string) | | Time of the previous block. For heights > 1, it's the weighted median of the timestamps of the valid votes in the block.LastCommit. For height == 1, it's genesis time. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/base/kv/v1beta1/kv.proto - - - - - -### Pair -Pair defines a key/value bytes tuple. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | | -| `value` | [bytes](#bytes) | | | - - - - - - - - -### Pairs -Pairs defines a repeated slice of Pair objects. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pairs` | [Pair](#lbm.base.kv.v1beta1.Pair) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/base/ostracon/v1beta1/query.proto - - - - - -### GetBlockByHeightRequest -GetBlockByHeightRequest is the request type for the Query/GetBlockByHeight RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [int64](#int64) | | | - - - - - - - - -### GetBlockByHeightResponse -GetBlockByHeightResponse is the response type for the Query/GetBlockByHeight RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `block_id` | [ostracon.types.BlockID](#ostracon.types.BlockID) | | | -| `block` | [ostracon.types.Block](#ostracon.types.Block) | | | - - - - - - - - -### GetLatestBlockRequest -GetLatestBlockRequest is the request type for the Query/GetLatestBlock RPC method. - - - - - - - - -### GetLatestBlockResponse -GetLatestBlockResponse is the response type for the Query/GetLatestBlock RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `block_id` | [ostracon.types.BlockID](#ostracon.types.BlockID) | | | -| `block` | [ostracon.types.Block](#ostracon.types.Block) | | | - - - - - - - - -### GetLatestValidatorSetRequest -GetLatestValidatorSetRequest is the request type for the Query/GetValidatorSetByHeight RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an pagination for the request. | - - - - - - - - -### GetLatestValidatorSetResponse -GetLatestValidatorSetResponse is the response type for the Query/GetValidatorSetByHeight RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `block_height` | [int64](#int64) | | | -| `validators` | [Validator](#lbm.base.ostracon.v1beta1.Validator) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines an pagination for the response. | - - - - - - - - -### GetNodeInfoRequest -GetNodeInfoRequest is the request type for the Query/GetNodeInfo RPC method. - - - - - - - - -### GetNodeInfoResponse -GetNodeInfoResponse is the request type for the Query/GetNodeInfo RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `default_node_info` | [ostracon.p2p.DefaultNodeInfo](#ostracon.p2p.DefaultNodeInfo) | | | -| `application_version` | [VersionInfo](#lbm.base.ostracon.v1beta1.VersionInfo) | | | - - - - - - - - -### GetSyncingRequest -GetSyncingRequest is the request type for the Query/GetSyncing RPC method. - - - - - - - - -### GetSyncingResponse -GetSyncingResponse is the response type for the Query/GetSyncing RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `syncing` | [bool](#bool) | | | - - - - - - - - -### GetValidatorSetByHeightRequest -GetValidatorSetByHeightRequest is the request type for the Query/GetValidatorSetByHeight RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [int64](#int64) | | | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an pagination for the request. | - - - - - - - - -### GetValidatorSetByHeightResponse -GetValidatorSetByHeightResponse is the response type for the Query/GetValidatorSetByHeight RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `block_height` | [int64](#int64) | | | -| `validators` | [Validator](#lbm.base.ostracon.v1beta1.Validator) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines an pagination for the response. | - - - - - - - - -### Module -Module is the type for VersionInfo - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `path` | [string](#string) | | module path | -| `version` | [string](#string) | | module version | -| `sum` | [string](#string) | | checksum | - - - - - - - - -### Validator -Validator is the type for the validator-set. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | | -| `pub_key` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `voting_power` | [int64](#int64) | | | -| `proposer_priority` | [int64](#int64) | | | - - - - - - - - -### VersionInfo -VersionInfo is the type for the GetNodeInfoResponse message. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `name` | [string](#string) | | | -| `app_name` | [string](#string) | | | -| `version` | [string](#string) | | | -| `git_commit` | [string](#string) | | | -| `build_tags` | [string](#string) | | | -| `go_version` | [string](#string) | | | -| `build_deps` | [Module](#lbm.base.ostracon.v1beta1.Module) | repeated | | - - - - - - - - - - - - - - -### Service -Service defines the gRPC querier service for ostracon queries. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `GetNodeInfo` | [GetNodeInfoRequest](#lbm.base.ostracon.v1beta1.GetNodeInfoRequest) | [GetNodeInfoResponse](#lbm.base.ostracon.v1beta1.GetNodeInfoResponse) | GetNodeInfo queries the current node info. | GET|/lbm/base/ostracon/v1beta1/node_info| -| `GetSyncing` | [GetSyncingRequest](#lbm.base.ostracon.v1beta1.GetSyncingRequest) | [GetSyncingResponse](#lbm.base.ostracon.v1beta1.GetSyncingResponse) | GetSyncing queries node syncing. | GET|/lbm/base/ostracon/v1beta1/syncing| -| `GetLatestBlock` | [GetLatestBlockRequest](#lbm.base.ostracon.v1beta1.GetLatestBlockRequest) | [GetLatestBlockResponse](#lbm.base.ostracon.v1beta1.GetLatestBlockResponse) | GetLatestBlock returns the latest block. | GET|/lbm/base/ostracon/v1beta1/blocks/latest| -| `GetBlockByHeight` | [GetBlockByHeightRequest](#lbm.base.ostracon.v1beta1.GetBlockByHeightRequest) | [GetBlockByHeightResponse](#lbm.base.ostracon.v1beta1.GetBlockByHeightResponse) | GetBlockByHeight queries block for given height. | GET|/lbm/base/ostracon/v1beta1/blocks/{height}| -| `GetLatestValidatorSet` | [GetLatestValidatorSetRequest](#lbm.base.ostracon.v1beta1.GetLatestValidatorSetRequest) | [GetLatestValidatorSetResponse](#lbm.base.ostracon.v1beta1.GetLatestValidatorSetResponse) | GetLatestValidatorSet queries latest validator-set. | GET|/lbm/base/ostracon/v1beta1/validatorsets/latest| -| `GetValidatorSetByHeight` | [GetValidatorSetByHeightRequest](#lbm.base.ostracon.v1beta1.GetValidatorSetByHeightRequest) | [GetValidatorSetByHeightResponse](#lbm.base.ostracon.v1beta1.GetValidatorSetByHeightResponse) | GetValidatorSetByHeight queries validator-set at a given height. | GET|/lbm/base/ostracon/v1beta1/validatorsets/{height}| - - - - - - -

Top

- -## lbm/base/reflection/v1beta1/reflection.proto - - - - - -### ListAllInterfacesRequest -ListAllInterfacesRequest is the request type of the ListAllInterfaces RPC. - - - - - - - - -### ListAllInterfacesResponse -ListAllInterfacesResponse is the response type of the ListAllInterfaces RPC. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `interface_names` | [string](#string) | repeated | interface_names is an array of all the registered interfaces. | - - - - - - - - -### ListImplementationsRequest -ListImplementationsRequest is the request type of the ListImplementations -RPC. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `interface_name` | [string](#string) | | interface_name defines the interface to query the implementations for. | - - - - - - - - -### ListImplementationsResponse -ListImplementationsResponse is the response type of the ListImplementations -RPC. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `implementation_message_names` | [string](#string) | repeated | | - - - - - - - - - - - - - - -### ReflectionService -ReflectionService defines a service for interface reflection. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `ListAllInterfaces` | [ListAllInterfacesRequest](#lbm.base.reflection.v1beta1.ListAllInterfacesRequest) | [ListAllInterfacesResponse](#lbm.base.reflection.v1beta1.ListAllInterfacesResponse) | ListAllInterfaces lists all the interfaces registered in the interface registry. | GET|/lbm/base/reflection/v1beta1/interfaces| -| `ListImplementations` | [ListImplementationsRequest](#lbm.base.reflection.v1beta1.ListImplementationsRequest) | [ListImplementationsResponse](#lbm.base.reflection.v1beta1.ListImplementationsResponse) | ListImplementations list all the concrete types that implement a given interface. | GET|/lbm/base/reflection/v1beta1/interfaces/{interface_name}/implementations| - - - - - - -

Top

- -## lbm/base/snapshots/v1beta1/snapshot.proto - - - - - -### Metadata -Metadata contains SDK-specific snapshot metadata. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `chunk_hashes` | [bytes](#bytes) | repeated | SHA-256 chunk hashes | - - - - - - - - -### Snapshot -Snapshot contains Tendermint state sync snapshot info. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [uint64](#uint64) | | | -| `format` | [uint32](#uint32) | | | -| `chunks` | [uint32](#uint32) | | | -| `hash` | [bytes](#bytes) | | | -| `metadata` | [Metadata](#lbm.base.snapshots.v1beta1.Metadata) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/base/store/v1beta1/commit_info.proto - - - - - -### CommitID -CommitID defines the committment information when a specific store is -committed. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `version` | [int64](#int64) | | | -| `hash` | [bytes](#bytes) | | | - - - - - - - - -### CommitInfo -CommitInfo defines commit information used by the multi-store when committing -a version/height. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `version` | [int64](#int64) | | | -| `store_infos` | [StoreInfo](#lbm.base.store.v1beta1.StoreInfo) | repeated | | - - - - - - - - -### StoreInfo -StoreInfo defines store-specific commit information. It contains a reference -between a store name and the commit ID. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `name` | [string](#string) | | | -| `commit_id` | [CommitID](#lbm.base.store.v1beta1.CommitID) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/base/store/v1beta1/snapshot.proto - - - - - -### SnapshotIAVLItem -SnapshotIAVLItem is an exported IAVL node. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | | -| `value` | [bytes](#bytes) | | | -| `version` | [int64](#int64) | | | -| `height` | [int32](#int32) | | | - - - - - - - - -### SnapshotItem -SnapshotItem is an item contained in a rootmulti.Store snapshot. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `store` | [SnapshotStoreItem](#lbm.base.store.v1beta1.SnapshotStoreItem) | | | -| `iavl` | [SnapshotIAVLItem](#lbm.base.store.v1beta1.SnapshotIAVLItem) | | | - - - - - - - - -### SnapshotStoreItem -SnapshotStoreItem contains metadata about a snapshotted store. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `name` | [string](#string) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/capability/v1beta1/capability.proto - - - - - -### Capability -Capability defines an implementation of an object capability. The index -provided to a Capability must be globally unique. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `index` | [uint64](#uint64) | | | - - - - - - - - -### CapabilityOwners -CapabilityOwners defines a set of owners of a single Capability. The set of -owners must be unique. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `owners` | [Owner](#lbm.capability.v1beta1.Owner) | repeated | | - - - - - - - - -### Owner -Owner defines a single capability owner. An owner is defined by the name of -capability and the module name. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `module` | [string](#string) | | | -| `name` | [string](#string) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/capability/v1beta1/genesis.proto - - - - - -### GenesisOwners -GenesisOwners defines the capability owners with their corresponding index. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `index` | [uint64](#uint64) | | index is the index of the capability owner. | -| `index_owners` | [CapabilityOwners](#lbm.capability.v1beta1.CapabilityOwners) | | index_owners are the owners at the given index. | - - - - - - - - -### GenesisState -GenesisState defines the capability module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `index` | [uint64](#uint64) | | index is the capability global index. | -| `owners` | [GenesisOwners](#lbm.capability.v1beta1.GenesisOwners) | repeated | owners represents a map from index to owners of the capability index index key is string to allow amino marshalling. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/crisis/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the crisis module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `constant_fee` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | constant_fee is the fee used to verify the invariant in the crisis module. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/crisis/v1beta1/tx.proto - - - - - -### MsgVerifyInvariant -MsgVerifyInvariant represents a message to verify a particular invariance. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `sender` | [string](#string) | | | -| `invariant_module_name` | [string](#string) | | | -| `invariant_route` | [string](#string) | | | - - - - - - - - -### MsgVerifyInvariantResponse -MsgVerifyInvariantResponse defines the Msg/VerifyInvariant response type. - - - - - - - - - - - - - - -### Msg -Msg defines the bank Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `VerifyInvariant` | [MsgVerifyInvariant](#lbm.crisis.v1beta1.MsgVerifyInvariant) | [MsgVerifyInvariantResponse](#lbm.crisis.v1beta1.MsgVerifyInvariantResponse) | VerifyInvariant defines a method to verify a particular invariance. | | - - - - - - -

Top

- -## lbm/crypto/ed25519/keys.proto - - - - - -### PrivKey -PrivKey defines a ed25519 private key. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | | - - - - - - - - -### PubKey -PubKey defines a ed25519 public key -Key is the compressed form of the pubkey. The first byte depends is a 0x02 byte -if the y-coordinate is the lexicographically largest of the two associated with -the x-coordinate. Otherwise the first byte is a 0x03. -This prefix is followed with the x-coordinate. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/crypto/multisig/keys.proto - - - - - -### LegacyAminoPubKey -LegacyAminoPubKey specifies a public key type -which nests multiple public keys and a threshold, -it uses legacy amino address rules. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `threshold` | [uint32](#uint32) | | | -| `public_keys` | [google.protobuf.Any](#google.protobuf.Any) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/crypto/multisig/v1beta1/multisig.proto - - - - - -### CompactBitArray -CompactBitArray is an implementation of a space efficient bit array. -This is used to ensure that the encoded data takes up a minimal amount of -space after proto encoding. -This is not thread safe, and is not intended for concurrent usage. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `extra_bits_stored` | [uint32](#uint32) | | | -| `elems` | [bytes](#bytes) | | | - - - - - - - - -### MultiSignature -MultiSignature wraps the signatures from a multisig.LegacyAminoPubKey. -See lbm.tx.v1betata1.ModeInfo.Multi for how to specify which signers -signed and with which modes. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signatures` | [bytes](#bytes) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/crypto/secp256k1/keys.proto - - - - - -### PrivKey -PrivKey defines a secp256k1 private key. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | | - - - - - - - - -### PubKey -PubKey defines a secp256k1 public key -Key is the compressed form of the pubkey. The first byte depends is a 0x02 byte -if the y-coordinate is the lexicographically largest of the two associated with -the x-coordinate. Otherwise the first byte is a 0x03. -This prefix is followed with the x-coordinate. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `key` | [bytes](#bytes) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/distribution/v1beta1/distribution.proto - - - - - -### CommunityPoolSpendProposal -CommunityPoolSpendProposal details a proposal for use of community funds, -together with how many coins are proposed to be spent, and to which -recipient account. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | | -| `description` | [string](#string) | | | -| `recipient` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### CommunityPoolSpendProposalWithDeposit -CommunityPoolSpendProposalWithDeposit defines a CommunityPoolSpendProposal -with a deposit - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | | -| `description` | [string](#string) | | | -| `recipient` | [string](#string) | | | -| `amount` | [string](#string) | | | -| `deposit` | [string](#string) | | | - - - - - - - - -### DelegationDelegatorReward -DelegationDelegatorReward represents the properties -of a delegator's delegation reward. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | | -| `reward` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | | - - - - - - - - -### DelegatorStartingInfo -DelegatorStartingInfo represents the starting info for a delegator reward -period. It tracks the previous validator period, the delegation's amount of -staking token, and the creation height (to check later on if any slashes have -occurred). NOTE: Even though validators are slashed to whole staking tokens, -the delegators within the validator may be left with less than a full token, -thus sdk.Dec is used. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `previous_period` | [uint64](#uint64) | | | -| `stake` | [string](#string) | | | -| `height` | [uint64](#uint64) | | | - - - - - - - - -### FeePool -FeePool is the global fee pool for distribution. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `community_pool` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | | - - - - - - - - -### Params -Params defines the set of params for the distribution module. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `community_tax` | [string](#string) | | | -| `base_proposer_reward` | [string](#string) | | | -| `bonus_proposer_reward` | [string](#string) | | | -| `withdraw_addr_enabled` | [bool](#bool) | | | - - - - - - - - -### ValidatorAccumulatedCommission -ValidatorAccumulatedCommission represents accumulated commission -for a validator kept as a running counter, can be withdrawn at any time. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `commission` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | | - - - - - - - - -### ValidatorCurrentRewards -ValidatorCurrentRewards represents current rewards and current -period for a validator kept as a running counter and incremented -each block as long as the validator's tokens remain constant. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `rewards` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | | -| `period` | [uint64](#uint64) | | | - - - - - - - - -### ValidatorHistoricalRewards -ValidatorHistoricalRewards represents historical rewards for a validator. -Height is implicit within the store key. -Cumulative reward ratio is the sum from the zeroeth period -until this period of rewards / tokens, per the spec. -The reference count indicates the number of objects -which might need to reference this historical entry at any point. -ReferenceCount = - number of outstanding delegations which ended the associated period (and - might need to read that record) - + number of slashes which ended the associated period (and might need to - read that record) - + one per validator for the zeroeth period, set on initialization - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `cumulative_reward_ratio` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | | -| `reference_count` | [uint32](#uint32) | | | - - - - - - - - -### ValidatorOutstandingRewards -ValidatorOutstandingRewards represents outstanding (un-withdrawn) rewards -for a validator inexpensive to track, allows simple sanity checks. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `rewards` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | | - - - - - - - - -### ValidatorSlashEvent -ValidatorSlashEvent represents a validator slash event. -Height is implicit within the store key. -This is needed to calculate appropriate amount of staking tokens -for delegations which are withdrawn after a slash has occurred. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_period` | [uint64](#uint64) | | | -| `fraction` | [string](#string) | | | - - - - - - - - -### ValidatorSlashEvents -ValidatorSlashEvents is a collection of ValidatorSlashEvent messages. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_slash_events` | [ValidatorSlashEvent](#lbm.distribution.v1beta1.ValidatorSlashEvent) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/distribution/v1beta1/genesis.proto - - - - - -### DelegatorStartingInfoRecord -DelegatorStartingInfoRecord used for import / export via genesis json. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address is the address of the delegator. | -| `validator_address` | [string](#string) | | validator_address is the address of the validator. | -| `starting_info` | [DelegatorStartingInfo](#lbm.distribution.v1beta1.DelegatorStartingInfo) | | starting_info defines the starting info of a delegator. | - - - - - - - - -### DelegatorWithdrawInfo -DelegatorWithdrawInfo is the address for where distributions rewards are -withdrawn to by default this struct is only used at genesis to feed in -default withdraw addresses. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address is the address of the delegator. | -| `withdraw_address` | [string](#string) | | withdraw_address is the address to withdraw the delegation rewards to. | - - - - - - - - -### GenesisState -GenesisState defines the distribution module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.distribution.v1beta1.Params) | | params defines all the paramaters of the module. | -| `fee_pool` | [FeePool](#lbm.distribution.v1beta1.FeePool) | | fee_pool defines the fee pool at genesis. | -| `delegator_withdraw_infos` | [DelegatorWithdrawInfo](#lbm.distribution.v1beta1.DelegatorWithdrawInfo) | repeated | fee_pool defines the delegator withdraw infos at genesis. | -| `previous_proposer` | [string](#string) | | fee_pool defines the previous proposer at genesis. | -| `outstanding_rewards` | [ValidatorOutstandingRewardsRecord](#lbm.distribution.v1beta1.ValidatorOutstandingRewardsRecord) | repeated | fee_pool defines the outstanding rewards of all validators at genesis. | -| `validator_accumulated_commissions` | [ValidatorAccumulatedCommissionRecord](#lbm.distribution.v1beta1.ValidatorAccumulatedCommissionRecord) | repeated | fee_pool defines the accumulated commisions of all validators at genesis. | -| `validator_historical_rewards` | [ValidatorHistoricalRewardsRecord](#lbm.distribution.v1beta1.ValidatorHistoricalRewardsRecord) | repeated | fee_pool defines the historical rewards of all validators at genesis. | -| `validator_current_rewards` | [ValidatorCurrentRewardsRecord](#lbm.distribution.v1beta1.ValidatorCurrentRewardsRecord) | repeated | fee_pool defines the current rewards of all validators at genesis. | -| `delegator_starting_infos` | [DelegatorStartingInfoRecord](#lbm.distribution.v1beta1.DelegatorStartingInfoRecord) | repeated | fee_pool defines the delegator starting infos at genesis. | -| `validator_slash_events` | [ValidatorSlashEventRecord](#lbm.distribution.v1beta1.ValidatorSlashEventRecord) | repeated | fee_pool defines the validator slash events at genesis. | - - - - - - - - -### ValidatorAccumulatedCommissionRecord -ValidatorAccumulatedCommissionRecord is used for import / export via genesis -json. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address is the address of the validator. | -| `accumulated` | [ValidatorAccumulatedCommission](#lbm.distribution.v1beta1.ValidatorAccumulatedCommission) | | accumulated is the accumulated commission of a validator. | - - - - - - - - -### ValidatorCurrentRewardsRecord -ValidatorCurrentRewardsRecord is used for import / export via genesis json. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address is the address of the validator. | -| `rewards` | [ValidatorCurrentRewards](#lbm.distribution.v1beta1.ValidatorCurrentRewards) | | rewards defines the current rewards of a validator. | - - - - - - - - -### ValidatorHistoricalRewardsRecord -ValidatorHistoricalRewardsRecord is used for import / export via genesis -json. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address is the address of the validator. | -| `period` | [uint64](#uint64) | | period defines the period the historical rewards apply to. | -| `rewards` | [ValidatorHistoricalRewards](#lbm.distribution.v1beta1.ValidatorHistoricalRewards) | | rewards defines the historical rewards of a validator. | - - - - - - - - -### ValidatorOutstandingRewardsRecord -ValidatorOutstandingRewardsRecord is used for import/export via genesis json. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address is the address of the validator. | -| `outstanding_rewards` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | outstanding_rewards represents the oustanding rewards of a validator. | - - - - - - - - -### ValidatorSlashEventRecord -ValidatorSlashEventRecord is used for import / export via genesis json. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address is the address of the validator. | -| `height` | [uint64](#uint64) | | height defines the block height at which the slash event occured. | -| `period` | [uint64](#uint64) | | period is the period of the slash event. | -| `validator_slash_event` | [ValidatorSlashEvent](#lbm.distribution.v1beta1.ValidatorSlashEvent) | | validator_slash_event describes the slash event. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/distribution/v1beta1/query.proto - - - - - -### QueryCommunityPoolRequest -QueryCommunityPoolRequest is the request type for the Query/CommunityPool RPC -method. - - - - - - - - -### QueryCommunityPoolResponse -QueryCommunityPoolResponse is the response type for the Query/CommunityPool -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pool` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | pool defines community pool's coins. | - - - - - - - - -### QueryDelegationRewardsRequest -QueryDelegationRewardsRequest is the request type for the -Query/DelegationRewards RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address defines the delegator address to query for. | -| `validator_address` | [string](#string) | | validator_address defines the validator address to query for. | - - - - - - - - -### QueryDelegationRewardsResponse -QueryDelegationRewardsResponse is the response type for the -Query/DelegationRewards RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `rewards` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | rewards defines the rewards accrued by a delegation. | - - - - - - - - -### QueryDelegationTotalRewardsRequest -QueryDelegationTotalRewardsRequest is the request type for the -Query/DelegationTotalRewards RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address defines the delegator address to query for. | - - - - - - - - -### QueryDelegationTotalRewardsResponse -QueryDelegationTotalRewardsResponse is the response type for the -Query/DelegationTotalRewards RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `rewards` | [DelegationDelegatorReward](#lbm.distribution.v1beta1.DelegationDelegatorReward) | repeated | rewards defines all the rewards accrued by a delegator. | -| `total` | [lbm.base.v1beta1.DecCoin](#lbm.base.v1beta1.DecCoin) | repeated | total defines the sum of all the rewards. | - - - - - - - - -### QueryDelegatorValidatorsRequest -QueryDelegatorValidatorsRequest is the request type for the -Query/DelegatorValidators RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address defines the delegator address to query for. | - - - - - - - - -### QueryDelegatorValidatorsResponse -QueryDelegatorValidatorsResponse is the response type for the -Query/DelegatorValidators RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validators` | [string](#string) | repeated | validators defines the validators a delegator is delegating for. | - - - - - - - - -### QueryDelegatorWithdrawAddressRequest -QueryDelegatorWithdrawAddressRequest is the request type for the -Query/DelegatorWithdrawAddress RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address defines the delegator address to query for. | - - - - - - - - -### QueryDelegatorWithdrawAddressResponse -QueryDelegatorWithdrawAddressResponse is the response type for the -Query/DelegatorWithdrawAddress RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `withdraw_address` | [string](#string) | | withdraw_address defines the delegator address to query for. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest is the request type for the Query/Params RPC method. - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is the response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.distribution.v1beta1.Params) | | params defines the parameters of the module. | - - - - - - - - -### QueryValidatorCommissionRequest -QueryValidatorCommissionRequest is the request type for the -Query/ValidatorCommission RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address defines the validator address to query for. | - - - - - - - - -### QueryValidatorCommissionResponse -QueryValidatorCommissionResponse is the response type for the -Query/ValidatorCommission RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `commission` | [ValidatorAccumulatedCommission](#lbm.distribution.v1beta1.ValidatorAccumulatedCommission) | | commission defines the commision the validator received. | - - - - - - - - -### QueryValidatorOutstandingRewardsRequest -QueryValidatorOutstandingRewardsRequest is the request type for the -Query/ValidatorOutstandingRewards RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address defines the validator address to query for. | - - - - - - - - -### QueryValidatorOutstandingRewardsResponse -QueryValidatorOutstandingRewardsResponse is the response type for the -Query/ValidatorOutstandingRewards RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `rewards` | [ValidatorOutstandingRewards](#lbm.distribution.v1beta1.ValidatorOutstandingRewards) | | | - - - - - - - - -### QueryValidatorSlashesRequest -QueryValidatorSlashesRequest is the request type for the -Query/ValidatorSlashes RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | validator_address defines the validator address to query for. | -| `starting_height` | [uint64](#uint64) | | starting_height defines the optional starting height to query the slashes. | -| `ending_height` | [uint64](#uint64) | | starting_height defines the optional ending height to query the slashes. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryValidatorSlashesResponse -QueryValidatorSlashesResponse is the response type for the -Query/ValidatorSlashes RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `slashes` | [ValidatorSlashEvent](#lbm.distribution.v1beta1.ValidatorSlashEvent) | repeated | slashes defines the slashes the validator received. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service for distribution module. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Params` | [QueryParamsRequest](#lbm.distribution.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.distribution.v1beta1.QueryParamsResponse) | Params queries params of the distribution module. | GET|/lbm/distribution/v1beta1/params| -| `ValidatorOutstandingRewards` | [QueryValidatorOutstandingRewardsRequest](#lbm.distribution.v1beta1.QueryValidatorOutstandingRewardsRequest) | [QueryValidatorOutstandingRewardsResponse](#lbm.distribution.v1beta1.QueryValidatorOutstandingRewardsResponse) | ValidatorOutstandingRewards queries rewards of a validator address. | GET|/lbm/distribution/v1beta1/validators/{validator_address}/outstanding_rewards| -| `ValidatorCommission` | [QueryValidatorCommissionRequest](#lbm.distribution.v1beta1.QueryValidatorCommissionRequest) | [QueryValidatorCommissionResponse](#lbm.distribution.v1beta1.QueryValidatorCommissionResponse) | ValidatorCommission queries accumulated commission for a validator. | GET|/lbm/distribution/v1beta1/validators/{validator_address}/commission| -| `ValidatorSlashes` | [QueryValidatorSlashesRequest](#lbm.distribution.v1beta1.QueryValidatorSlashesRequest) | [QueryValidatorSlashesResponse](#lbm.distribution.v1beta1.QueryValidatorSlashesResponse) | ValidatorSlashes queries slash events of a validator. | GET|/lbm/distribution/v1beta1/validators/{validator_address}/slashes| -| `DelegationRewards` | [QueryDelegationRewardsRequest](#lbm.distribution.v1beta1.QueryDelegationRewardsRequest) | [QueryDelegationRewardsResponse](#lbm.distribution.v1beta1.QueryDelegationRewardsResponse) | DelegationRewards queries the total rewards accrued by a delegation. | GET|/lbm/distribution/v1beta1/delegators/{delegator_address}/rewards/{validator_address}| -| `DelegationTotalRewards` | [QueryDelegationTotalRewardsRequest](#lbm.distribution.v1beta1.QueryDelegationTotalRewardsRequest) | [QueryDelegationTotalRewardsResponse](#lbm.distribution.v1beta1.QueryDelegationTotalRewardsResponse) | DelegationTotalRewards queries the total rewards accrued by a each validator. | GET|/lbm/distribution/v1beta1/delegators/{delegator_address}/rewards| -| `DelegatorValidators` | [QueryDelegatorValidatorsRequest](#lbm.distribution.v1beta1.QueryDelegatorValidatorsRequest) | [QueryDelegatorValidatorsResponse](#lbm.distribution.v1beta1.QueryDelegatorValidatorsResponse) | DelegatorValidators queries the validators of a delegator. | GET|/lbm/distribution/v1beta1/delegators/{delegator_address}/validators| -| `DelegatorWithdrawAddress` | [QueryDelegatorWithdrawAddressRequest](#lbm.distribution.v1beta1.QueryDelegatorWithdrawAddressRequest) | [QueryDelegatorWithdrawAddressResponse](#lbm.distribution.v1beta1.QueryDelegatorWithdrawAddressResponse) | DelegatorWithdrawAddress queries withdraw address of a delegator. | GET|/lbm/distribution/v1beta1/delegators/{delegator_address}/withdraw_address| -| `CommunityPool` | [QueryCommunityPoolRequest](#lbm.distribution.v1beta1.QueryCommunityPoolRequest) | [QueryCommunityPoolResponse](#lbm.distribution.v1beta1.QueryCommunityPoolResponse) | CommunityPool queries the community pool coins. | GET|/lbm/distribution/v1beta1/community_pool| - - - - - - -

Top

- -## lbm/distribution/v1beta1/tx.proto - - - - - -### MsgFundCommunityPool -MsgFundCommunityPool allows an account to directly -fund the community pool. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `depositor` | [string](#string) | | | - - - - - - - - -### MsgFundCommunityPoolResponse -MsgFundCommunityPoolResponse defines the Msg/FundCommunityPool response type. - - - - - - - - -### MsgSetWithdrawAddress -MsgSetWithdrawAddress sets the withdraw address for -a delegator (or validator self-delegation). - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `withdraw_address` | [string](#string) | | | - - - - - - - - -### MsgSetWithdrawAddressResponse -MsgSetWithdrawAddressResponse defines the Msg/SetWithdrawAddress response type. - - - - - - - - -### MsgWithdrawDelegatorReward -MsgWithdrawDelegatorReward represents delegation withdrawal to a delegator -from a single validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `validator_address` | [string](#string) | | | - - - - - - - - -### MsgWithdrawDelegatorRewardResponse -MsgWithdrawDelegatorRewardResponse defines the Msg/WithdrawDelegatorReward response type. - - - - - - - - -### MsgWithdrawValidatorCommission -MsgWithdrawValidatorCommission withdraws the full commission to the validator -address. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_address` | [string](#string) | | | - - - - - - - - -### MsgWithdrawValidatorCommissionResponse -MsgWithdrawValidatorCommissionResponse defines the Msg/WithdrawValidatorCommission response type. - - - - - - - - - - - - - - -### Msg -Msg defines the distribution Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `SetWithdrawAddress` | [MsgSetWithdrawAddress](#lbm.distribution.v1beta1.MsgSetWithdrawAddress) | [MsgSetWithdrawAddressResponse](#lbm.distribution.v1beta1.MsgSetWithdrawAddressResponse) | SetWithdrawAddress defines a method to change the withdraw address for a delegator (or validator self-delegation). | | -| `WithdrawDelegatorReward` | [MsgWithdrawDelegatorReward](#lbm.distribution.v1beta1.MsgWithdrawDelegatorReward) | [MsgWithdrawDelegatorRewardResponse](#lbm.distribution.v1beta1.MsgWithdrawDelegatorRewardResponse) | WithdrawDelegatorReward defines a method to withdraw rewards of delegator from a single validator. | | -| `WithdrawValidatorCommission` | [MsgWithdrawValidatorCommission](#lbm.distribution.v1beta1.MsgWithdrawValidatorCommission) | [MsgWithdrawValidatorCommissionResponse](#lbm.distribution.v1beta1.MsgWithdrawValidatorCommissionResponse) | WithdrawValidatorCommission defines a method to withdraw the full commission to the validator address. | | -| `FundCommunityPool` | [MsgFundCommunityPool](#lbm.distribution.v1beta1.MsgFundCommunityPool) | [MsgFundCommunityPoolResponse](#lbm.distribution.v1beta1.MsgFundCommunityPoolResponse) | FundCommunityPool defines a method to allow an account to directly fund the community pool. | | - - - - - - -

Top

- -## lbm/evidence/v1beta1/evidence.proto - - - - - -### Equivocation -Equivocation implements the Evidence interface and defines evidence of double -signing misbehavior. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [int64](#int64) | | | -| `time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | -| `power` | [int64](#int64) | | | -| `consensus_address` | [string](#string) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/evidence/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the evidence module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `evidence` | [google.protobuf.Any](#google.protobuf.Any) | repeated | evidence defines all the evidence at genesis. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/evidence/v1beta1/query.proto - - - - - -### QueryAllEvidenceRequest -QueryEvidenceRequest is the request type for the Query/AllEvidence RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryAllEvidenceResponse -QueryAllEvidenceResponse is the response type for the Query/AllEvidence RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `evidence` | [google.protobuf.Any](#google.protobuf.Any) | repeated | evidence returns all evidences. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryEvidenceRequest -QueryEvidenceRequest is the request type for the Query/Evidence RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `evidence_hash` | [bytes](#bytes) | | evidence_hash defines the hash of the requested evidence. | - - - - - - - - -### QueryEvidenceResponse -QueryEvidenceResponse is the response type for the Query/Evidence RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `evidence` | [google.protobuf.Any](#google.protobuf.Any) | | evidence returns the requested evidence. | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Evidence` | [QueryEvidenceRequest](#lbm.evidence.v1beta1.QueryEvidenceRequest) | [QueryEvidenceResponse](#lbm.evidence.v1beta1.QueryEvidenceResponse) | Evidence queries evidence based on evidence hash. | GET|/lbm/evidence/v1beta1/evidence/{evidence_hash}| -| `AllEvidence` | [QueryAllEvidenceRequest](#lbm.evidence.v1beta1.QueryAllEvidenceRequest) | [QueryAllEvidenceResponse](#lbm.evidence.v1beta1.QueryAllEvidenceResponse) | AllEvidence queries all evidence. | GET|/lbm/evidence/v1beta1/evidence| - - - - - - -

Top

- -## lbm/evidence/v1beta1/tx.proto - - - - - -### MsgSubmitEvidence -MsgSubmitEvidence represents a message that supports submitting arbitrary -Evidence of misbehavior such as equivocation or counterfactual signing. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `submitter` | [string](#string) | | | -| `evidence` | [google.protobuf.Any](#google.protobuf.Any) | | | - - - - - - - - -### MsgSubmitEvidenceResponse -MsgSubmitEvidenceResponse defines the Msg/SubmitEvidence response type. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `hash` | [bytes](#bytes) | | hash defines the hash of the evidence. | - - - - - - - - - - - - - - -### Msg -Msg defines the evidence Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `SubmitEvidence` | [MsgSubmitEvidence](#lbm.evidence.v1beta1.MsgSubmitEvidence) | [MsgSubmitEvidenceResponse](#lbm.evidence.v1beta1.MsgSubmitEvidenceResponse) | SubmitEvidence submits an arbitrary Evidence of misbehavior such as equivocation or counterfactual signing. | | - - - - - - -

Top

- -## lbm/genutil/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the raw genesis transaction in JSON. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `gen_txs` | [bytes](#bytes) | repeated | gen_txs defines the genesis transactions. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/gov/v1beta1/gov.proto - - - - - -### Deposit -Deposit defines an amount deposited by an account address to an active -proposal. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | | -| `depositor` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### DepositParams -DepositParams defines the params for deposits on governance proposals. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `min_deposit` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | Minimum deposit for a proposal to enter voting period. | -| `max_deposit_period` | [google.protobuf.Duration](#google.protobuf.Duration) | | Maximum period for Atom holders to deposit on a proposal. Initial value: 2 months. | - - - - - - - - -### Proposal -Proposal defines the core field members of a governance proposal. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | | -| `content` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `status` | [ProposalStatus](#lbm.gov.v1beta1.ProposalStatus) | | | -| `final_tally_result` | [TallyResult](#lbm.gov.v1beta1.TallyResult) | | | -| `submit_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | -| `deposit_end_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | -| `total_deposit` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `voting_start_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | -| `voting_end_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | - - - - - - - - -### TallyParams -TallyParams defines the params for tallying votes on governance proposals. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `quorum` | [bytes](#bytes) | | Minimum percentage of total stake needed to vote for a result to be considered valid. | -| `threshold` | [bytes](#bytes) | | Minimum proportion of Yes votes for proposal to pass. Default value: 0.5. | -| `veto_threshold` | [bytes](#bytes) | | Minimum value of Veto votes to Total votes ratio for proposal to be vetoed. Default value: 1/3. | - - - - - - - - -### TallyResult -TallyResult defines a standard tally for a governance proposal. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `yes` | [string](#string) | | | -| `abstain` | [string](#string) | | | -| `no` | [string](#string) | | | -| `no_with_veto` | [string](#string) | | | - - - - - - - - -### TextProposal -TextProposal defines a standard text proposal whose changes need to be -manually updated in case of approval. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | | -| `description` | [string](#string) | | | - - - - - - - - -### Vote -Vote defines a vote on a governance proposal. -A Vote consists of a proposal ID, the voter, and the vote option. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | | -| `voter` | [string](#string) | | | -| `option` | [VoteOption](#lbm.gov.v1beta1.VoteOption) | | | - - - - - - - - -### VotingParams -VotingParams defines the params for voting on governance proposals. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `voting_period` | [google.protobuf.Duration](#google.protobuf.Duration) | | Length of the voting period. | - - - - - - - - - - -### ProposalStatus -ProposalStatus enumerates the valid statuses of a proposal. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| PROPOSAL_STATUS_UNSPECIFIED | 0 | PROPOSAL_STATUS_UNSPECIFIED defines the default propopsal status. | -| PROPOSAL_STATUS_DEPOSIT_PERIOD | 1 | PROPOSAL_STATUS_DEPOSIT_PERIOD defines a proposal status during the deposit period. | -| PROPOSAL_STATUS_VOTING_PERIOD | 2 | PROPOSAL_STATUS_VOTING_PERIOD defines a proposal status during the voting period. | -| PROPOSAL_STATUS_PASSED | 3 | PROPOSAL_STATUS_PASSED defines a proposal status of a proposal that has passed. | -| PROPOSAL_STATUS_REJECTED | 4 | PROPOSAL_STATUS_REJECTED defines a proposal status of a proposal that has been rejected. | -| PROPOSAL_STATUS_FAILED | 5 | PROPOSAL_STATUS_FAILED defines a proposal status of a proposal that has failed. | - - - - - -### VoteOption -VoteOption enumerates the valid vote options for a given governance proposal. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| VOTE_OPTION_UNSPECIFIED | 0 | VOTE_OPTION_UNSPECIFIED defines a no-op vote option. | -| VOTE_OPTION_YES | 1 | VOTE_OPTION_YES defines a yes vote option. | -| VOTE_OPTION_ABSTAIN | 2 | VOTE_OPTION_ABSTAIN defines an abstain vote option. | -| VOTE_OPTION_NO | 3 | VOTE_OPTION_NO defines a no vote option. | -| VOTE_OPTION_NO_WITH_VETO | 4 | VOTE_OPTION_NO_WITH_VETO defines a no with veto vote option. | - - - - - - - - - - - -

Top

- -## lbm/gov/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the gov module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `starting_proposal_id` | [uint64](#uint64) | | starting_proposal_id is the ID of the starting proposal. | -| `deposits` | [Deposit](#lbm.gov.v1beta1.Deposit) | repeated | deposits defines all the deposits present at genesis. | -| `votes` | [Vote](#lbm.gov.v1beta1.Vote) | repeated | votes defines all the votes present at genesis. | -| `proposals` | [Proposal](#lbm.gov.v1beta1.Proposal) | repeated | proposals defines all the proposals present at genesis. | -| `deposit_params` | [DepositParams](#lbm.gov.v1beta1.DepositParams) | | params defines all the paramaters of related to deposit. | -| `voting_params` | [VotingParams](#lbm.gov.v1beta1.VotingParams) | | params defines all the paramaters of related to voting. | -| `tally_params` | [TallyParams](#lbm.gov.v1beta1.TallyParams) | | params defines all the paramaters of related to tally. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/gov/v1beta1/query.proto - - - - - -### QueryDepositRequest -QueryDepositRequest is the request type for the Query/Deposit RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | proposal_id defines the unique id of the proposal. | -| `depositor` | [string](#string) | | depositor defines the deposit addresses from the proposals. | - - - - - - - - -### QueryDepositResponse -QueryDepositResponse is the response type for the Query/Deposit RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `deposit` | [Deposit](#lbm.gov.v1beta1.Deposit) | | deposit defines the requested deposit. | - - - - - - - - -### QueryDepositsRequest -QueryDepositsRequest is the request type for the Query/Deposits RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | proposal_id defines the unique id of the proposal. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryDepositsResponse -QueryDepositsResponse is the response type for the Query/Deposits RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `deposits` | [Deposit](#lbm.gov.v1beta1.Deposit) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest is the request type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params_type` | [string](#string) | | params_type defines which parameters to query for, can be one of "voting", "tallying" or "deposit". | - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is the response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `voting_params` | [VotingParams](#lbm.gov.v1beta1.VotingParams) | | voting_params defines the parameters related to voting. | -| `deposit_params` | [DepositParams](#lbm.gov.v1beta1.DepositParams) | | deposit_params defines the parameters related to deposit. | -| `tally_params` | [TallyParams](#lbm.gov.v1beta1.TallyParams) | | tally_params defines the parameters related to tally. | - - - - - - - - -### QueryProposalRequest -QueryProposalRequest is the request type for the Query/Proposal RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | proposal_id defines the unique id of the proposal. | - - - - - - - - -### QueryProposalResponse -QueryProposalResponse is the response type for the Query/Proposal RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal` | [Proposal](#lbm.gov.v1beta1.Proposal) | | | - - - - - - - - -### QueryProposalsRequest -QueryProposalsRequest is the request type for the Query/Proposals RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_status` | [ProposalStatus](#lbm.gov.v1beta1.ProposalStatus) | | proposal_status defines the status of the proposals. | -| `voter` | [string](#string) | | voter defines the voter address for the proposals. | -| `depositor` | [string](#string) | | depositor defines the deposit addresses from the proposals. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryProposalsResponse -QueryProposalsResponse is the response type for the Query/Proposals RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposals` | [Proposal](#lbm.gov.v1beta1.Proposal) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryTallyResultRequest -QueryTallyResultRequest is the request type for the Query/Tally RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | proposal_id defines the unique id of the proposal. | - - - - - - - - -### QueryTallyResultResponse -QueryTallyResultResponse is the response type for the Query/Tally RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `tally` | [TallyResult](#lbm.gov.v1beta1.TallyResult) | | tally defines the requested tally. | - - - - - - - - -### QueryVoteRequest -QueryVoteRequest is the request type for the Query/Vote RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | proposal_id defines the unique id of the proposal. | -| `voter` | [string](#string) | | voter defines the oter address for the proposals. | - - - - - - - - -### QueryVoteResponse -QueryVoteResponse is the response type for the Query/Vote RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `vote` | [Vote](#lbm.gov.v1beta1.Vote) | | vote defined the queried vote. | - - - - - - - - -### QueryVotesRequest -QueryVotesRequest is the request type for the Query/Votes RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | proposal_id defines the unique id of the proposal. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryVotesResponse -QueryVotesResponse is the response type for the Query/Votes RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `votes` | [Vote](#lbm.gov.v1beta1.Vote) | repeated | votes defined the queried votes. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service for gov module - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Proposal` | [QueryProposalRequest](#lbm.gov.v1beta1.QueryProposalRequest) | [QueryProposalResponse](#lbm.gov.v1beta1.QueryProposalResponse) | Proposal queries proposal details based on ProposalID. | GET|/lbm/gov/v1beta1/proposals/{proposal_id}| -| `Proposals` | [QueryProposalsRequest](#lbm.gov.v1beta1.QueryProposalsRequest) | [QueryProposalsResponse](#lbm.gov.v1beta1.QueryProposalsResponse) | Proposals queries all proposals based on given status. | GET|/lbm/gov/v1beta1/proposals| -| `Vote` | [QueryVoteRequest](#lbm.gov.v1beta1.QueryVoteRequest) | [QueryVoteResponse](#lbm.gov.v1beta1.QueryVoteResponse) | Vote queries voted information based on proposalID, voterAddr. | GET|/lbm/gov/v1beta1/proposals/{proposal_id}/votes/{voter}| -| `Votes` | [QueryVotesRequest](#lbm.gov.v1beta1.QueryVotesRequest) | [QueryVotesResponse](#lbm.gov.v1beta1.QueryVotesResponse) | Votes queries votes of a given proposal. | GET|/lbm/gov/v1beta1/proposals/{proposal_id}/votes| -| `Params` | [QueryParamsRequest](#lbm.gov.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.gov.v1beta1.QueryParamsResponse) | Params queries all parameters of the gov module. | GET|/lbm/gov/v1beta1/params/{params_type}| -| `Deposit` | [QueryDepositRequest](#lbm.gov.v1beta1.QueryDepositRequest) | [QueryDepositResponse](#lbm.gov.v1beta1.QueryDepositResponse) | Deposit queries single deposit information based proposalID, depositAddr. | GET|/lbm/gov/v1beta1/proposals/{proposal_id}/deposits/{depositor}| -| `Deposits` | [QueryDepositsRequest](#lbm.gov.v1beta1.QueryDepositsRequest) | [QueryDepositsResponse](#lbm.gov.v1beta1.QueryDepositsResponse) | Deposits queries all deposits of a single proposal. | GET|/lbm/gov/v1beta1/proposals/{proposal_id}/deposits| -| `TallyResult` | [QueryTallyResultRequest](#lbm.gov.v1beta1.QueryTallyResultRequest) | [QueryTallyResultResponse](#lbm.gov.v1beta1.QueryTallyResultResponse) | TallyResult queries the tally of a proposal vote. | GET|/lbm/gov/v1beta1/proposals/{proposal_id}/tally| - - - - - - -

Top

- -## lbm/gov/v1beta1/tx.proto - - - - - -### MsgDeposit -MsgDeposit defines a message to submit a deposit to an existing proposal. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | | -| `depositor` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### MsgDepositResponse -MsgDepositResponse defines the Msg/Deposit response type. - - - - - - - - -### MsgSubmitProposal -MsgSubmitProposal defines an sdk.Msg type that supports submitting arbitrary -proposal Content. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `content` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `initial_deposit` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `proposer` | [string](#string) | | | - - - - - - - - -### MsgSubmitProposalResponse -MsgSubmitProposalResponse defines the Msg/SubmitProposal response type. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | | - - - - - - - - -### MsgVote -MsgVote defines a message to cast a vote. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `proposal_id` | [uint64](#uint64) | | | -| `voter` | [string](#string) | | | -| `option` | [VoteOption](#lbm.gov.v1beta1.VoteOption) | | | - - - - - - - - -### MsgVoteResponse -MsgVoteResponse defines the Msg/Vote response type. - - - - - - - - - - - - - - -### Msg -Msg defines the bank Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `SubmitProposal` | [MsgSubmitProposal](#lbm.gov.v1beta1.MsgSubmitProposal) | [MsgSubmitProposalResponse](#lbm.gov.v1beta1.MsgSubmitProposalResponse) | SubmitProposal defines a method to create new proposal given a content. | | -| `Vote` | [MsgVote](#lbm.gov.v1beta1.MsgVote) | [MsgVoteResponse](#lbm.gov.v1beta1.MsgVoteResponse) | Vote defines a method to add a vote on a specific proposal. | | -| `Deposit` | [MsgDeposit](#lbm.gov.v1beta1.MsgDeposit) | [MsgDepositResponse](#lbm.gov.v1beta1.MsgDepositResponse) | Deposit defines a method to add deposit on a specific proposal. | | - - - - - - -

Top

- -## lbm/mint/v1beta1/mint.proto - - - - - -### Minter -Minter represents the minting state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `inflation` | [string](#string) | | current annual inflation rate | -| `annual_provisions` | [string](#string) | | current annual expected provisions | - - - - - - - - -### Params -Params holds parameters for the mint module. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `mint_denom` | [string](#string) | | type of coin to mint | -| `inflation_rate_change` | [string](#string) | | maximum annual change in inflation rate | -| `inflation_max` | [string](#string) | | maximum inflation rate | -| `inflation_min` | [string](#string) | | minimum inflation rate | -| `goal_bonded` | [string](#string) | | goal of percent bonded atoms | -| `blocks_per_year` | [uint64](#uint64) | | expected blocks per year | - - - - - - - - - - - - - - - - -

Top

- -## lbm/mint/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the mint module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `minter` | [Minter](#lbm.mint.v1beta1.Minter) | | minter is a space for holding current inflation information. | -| `params` | [Params](#lbm.mint.v1beta1.Params) | | params defines all the paramaters of the module. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/mint/v1beta1/query.proto - - - - - -### QueryAnnualProvisionsRequest -QueryAnnualProvisionsRequest is the request type for the -Query/AnnualProvisions RPC method. - - - - - - - - -### QueryAnnualProvisionsResponse -QueryAnnualProvisionsResponse is the response type for the -Query/AnnualProvisions RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `annual_provisions` | [bytes](#bytes) | | annual_provisions is the current minting annual provisions value. | - - - - - - - - -### QueryInflationRequest -QueryInflationRequest is the request type for the Query/Inflation RPC method. - - - - - - - - -### QueryInflationResponse -QueryInflationResponse is the response type for the Query/Inflation RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `inflation` | [bytes](#bytes) | | inflation is the current minting inflation value. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest is the request type for the Query/Params RPC method. - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is the response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.mint.v1beta1.Params) | | params defines the parameters of the module. | - - - - - - - - - - - - - - -### Query -Query provides defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Params` | [QueryParamsRequest](#lbm.mint.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.mint.v1beta1.QueryParamsResponse) | Params returns the total set of minting parameters. | GET|/lbm/mint/v1beta1/params| -| `Inflation` | [QueryInflationRequest](#lbm.mint.v1beta1.QueryInflationRequest) | [QueryInflationResponse](#lbm.mint.v1beta1.QueryInflationResponse) | Inflation returns the current minting inflation value. | GET|/lbm/mint/v1beta1/inflation| -| `AnnualProvisions` | [QueryAnnualProvisionsRequest](#lbm.mint.v1beta1.QueryAnnualProvisionsRequest) | [QueryAnnualProvisionsResponse](#lbm.mint.v1beta1.QueryAnnualProvisionsResponse) | AnnualProvisions current minting annual provisions value. | GET|/lbm/mint/v1beta1/annual_provisions| - - - - - - -

Top

- -## lbm/params/v1beta1/params.proto - - - - - -### ParamChange -ParamChange defines an individual parameter change, for use in -ParameterChangeProposal. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `subspace` | [string](#string) | | | -| `key` | [string](#string) | | | -| `value` | [string](#string) | | | - - - - - - - - -### ParameterChangeProposal -ParameterChangeProposal defines a proposal to change one or more parameters. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | | -| `description` | [string](#string) | | | -| `changes` | [ParamChange](#lbm.params.v1beta1.ParamChange) | repeated | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/params/v1beta1/query.proto - - - - - -### QueryParamsRequest -QueryParamsRequest is request type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `subspace` | [string](#string) | | subspace defines the module to query the parameter for. | -| `key` | [string](#string) | | key defines the key of the parameter in the subspace. | - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `param` | [ParamChange](#lbm.params.v1beta1.ParamChange) | | param defines the queried parameter. | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Params` | [QueryParamsRequest](#lbm.params.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.params.v1beta1.QueryParamsResponse) | Params queries a specific parameter of a module, given its subspace and key. | GET|/lbm/params/v1beta1/params| - - - - - - -

Top

- -## lbm/slashing/v1beta1/slashing.proto - - - - - -### Params -Params represents the parameters used for by the slashing module. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signed_blocks_window` | [int64](#int64) | | | -| `min_signed_per_window` | [bytes](#bytes) | | | -| `downtime_jail_duration` | [google.protobuf.Duration](#google.protobuf.Duration) | | | -| `slash_fraction_double_sign` | [bytes](#bytes) | | | -| `slash_fraction_downtime` | [bytes](#bytes) | | | - - - - - - - - -### ValidatorSigningInfo -ValidatorSigningInfo defines a validator's signing info for monitoring their -liveness activity. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | | -| `start_height` | [int64](#int64) | | height at which validator was first a candidate OR was unjailed | -| `index_offset` | [int64](#int64) | | index offset into signed block bit array | -| `jailed_until` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | timestamp validator cannot be unjailed until | -| `tombstoned` | [bool](#bool) | | whether or not a validator has been tombstoned (killed out of validator set) | -| `missed_blocks_counter` | [int64](#int64) | | missed blocks counter (to avoid scanning the array every time) | - - - - - - - - - - - - - - - - -

Top

- -## lbm/slashing/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the slashing module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.slashing.v1beta1.Params) | | params defines all the paramaters of related to deposit. | -| `signing_infos` | [SigningInfo](#lbm.slashing.v1beta1.SigningInfo) | repeated | signing_infos represents a map between validator addresses and their signing infos. | -| `missed_blocks` | [ValidatorMissedBlocks](#lbm.slashing.v1beta1.ValidatorMissedBlocks) | repeated | signing_infos represents a map between validator addresses and their missed blocks. | - - - - - - - - -### MissedBlock -MissedBlock contains height and missed status as boolean. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `index` | [int64](#int64) | | index is the height at which the block was missed. | -| `missed` | [bool](#bool) | | missed is the missed status. | - - - - - - - - -### SigningInfo -SigningInfo stores validator signing info of corresponding address. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address is the validator address. | -| `validator_signing_info` | [ValidatorSigningInfo](#lbm.slashing.v1beta1.ValidatorSigningInfo) | | validator_signing_info represents the signing info of this validator. | - - - - - - - - -### ValidatorMissedBlocks -ValidatorMissedBlocks contains array of missed blocks of corresponding -address. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address is the validator address. | -| `missed_blocks` | [MissedBlock](#lbm.slashing.v1beta1.MissedBlock) | repeated | missed_blocks is an array of missed blocks by the validator. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/slashing/v1beta1/query.proto - - - - - -### QueryParamsRequest -QueryParamsRequest is the request type for the Query/Params RPC method - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is the response type for the Query/Params RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.slashing.v1beta1.Params) | | | - - - - - - - - -### QuerySigningInfoRequest -QuerySigningInfoRequest is the request type for the Query/SigningInfo RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `cons_address` | [string](#string) | | cons_address is the address to query signing info of | - - - - - - - - -### QuerySigningInfoResponse -QuerySigningInfoResponse is the response type for the Query/SigningInfo RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `val_signing_info` | [ValidatorSigningInfo](#lbm.slashing.v1beta1.ValidatorSigningInfo) | | val_signing_info is the signing info of requested val cons address | - - - - - - - - -### QuerySigningInfosRequest -QuerySigningInfosRequest is the request type for the Query/SigningInfos RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | | - - - - - - - - -### QuerySigningInfosResponse -QuerySigningInfosResponse is the response type for the Query/SigningInfos RPC -method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `info` | [ValidatorSigningInfo](#lbm.slashing.v1beta1.ValidatorSigningInfo) | repeated | info is the signing info of all validators | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | | - - - - - - - - - - - - - - -### Query -Query provides defines the gRPC querier service - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Params` | [QueryParamsRequest](#lbm.slashing.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.slashing.v1beta1.QueryParamsResponse) | Params queries the parameters of slashing module | GET|/lbm/slashing/v1beta1/params| -| `SigningInfo` | [QuerySigningInfoRequest](#lbm.slashing.v1beta1.QuerySigningInfoRequest) | [QuerySigningInfoResponse](#lbm.slashing.v1beta1.QuerySigningInfoResponse) | SigningInfo queries the signing info of given cons address | GET|/lbm/slashing/v1beta1/signing_infos/{cons_address}| -| `SigningInfos` | [QuerySigningInfosRequest](#lbm.slashing.v1beta1.QuerySigningInfosRequest) | [QuerySigningInfosResponse](#lbm.slashing.v1beta1.QuerySigningInfosResponse) | SigningInfos queries signing info of all validators | GET|/lbm/slashing/v1beta1/signing_infos| - - - - - - -

Top

- -## lbm/slashing/v1beta1/tx.proto - - - - - -### MsgUnjail -MsgUnjail defines the Msg/Unjail request type - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_addr` | [string](#string) | | | - - - - - - - - -### MsgUnjailResponse -MsgUnjailResponse defines the Msg/Unjail response type - - - - - - - - - - - - - - -### Msg -Msg defines the slashing Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Unjail` | [MsgUnjail](#lbm.slashing.v1beta1.MsgUnjail) | [MsgUnjailResponse](#lbm.slashing.v1beta1.MsgUnjailResponse) | Unjail defines a method for unjailing a jailed validator, thus returning them into the bonded validator set, so they can begin receiving provisions and rewards again. | | - - - - - - -

Top

- -## lbm/staking/v1beta1/staking.proto - - - - - -### Commission -Commission defines commission parameters for a given validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `commission_rates` | [CommissionRates](#lbm.staking.v1beta1.CommissionRates) | | commission_rates defines the initial commission rates to be used for creating a validator. | -| `update_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | update_time is the last time the commission rate was changed. | - - - - - - - - -### CommissionRates -CommissionRates defines the initial commission rates to be used for creating -a validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `rate` | [string](#string) | | rate is the commission rate charged to delegators, as a fraction. | -| `max_rate` | [string](#string) | | max_rate defines the maximum commission rate which validator can ever charge, as a fraction. | -| `max_change_rate` | [string](#string) | | max_change_rate defines the maximum daily increase of the validator commission, as a fraction. | - - - - - - - - -### DVPair -DVPair is struct that just has a delegator-validator pair with no other data. -It is intended to be used as a marshalable pointer. For example, a DVPair can -be used to construct the key to getting an UnbondingDelegation from state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `validator_address` | [string](#string) | | | - - - - - - - - -### DVPairs -DVPairs defines an array of DVPair objects. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pairs` | [DVPair](#lbm.staking.v1beta1.DVPair) | repeated | | - - - - - - - - -### DVVTriplet -DVVTriplet is struct that just has a delegator-validator-validator triplet -with no other data. It is intended to be used as a marshalable pointer. For -example, a DVVTriplet can be used to construct the key to getting a -Redelegation from state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `validator_src_address` | [string](#string) | | | -| `validator_dst_address` | [string](#string) | | | - - - - - - - - -### DVVTriplets -DVVTriplets defines an array of DVVTriplet objects. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `triplets` | [DVVTriplet](#lbm.staking.v1beta1.DVVTriplet) | repeated | | - - - - - - - - -### Delegation -Delegation represents the bond with tokens held by an account. It is -owned by one delegator, and is associated with the voting power of one -validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address is the bech32-encoded address of the delegator. | -| `validator_address` | [string](#string) | | validator_address is the bech32-encoded address of the validator. | -| `shares` | [string](#string) | | shares define the delegation shares received. | - - - - - - - - -### DelegationResponse -DelegationResponse is equivalent to Delegation except that it contains a -balance in addition to shares which is more suitable for client responses. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegation` | [Delegation](#lbm.staking.v1beta1.Delegation) | | | -| `balance` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | | - - - - - - - - -### Description -Description defines a validator description. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `moniker` | [string](#string) | | moniker defines a human-readable name for the validator. | -| `identity` | [string](#string) | | identity defines an optional identity signature (ex. UPort or Keybase). | -| `website` | [string](#string) | | website defines an optional website link. | -| `security_contact` | [string](#string) | | security_contact defines an optional email for security contact. | -| `details` | [string](#string) | | details define other optional details. | - - - - - - - - -### HistoricalInfo -HistoricalInfo contains header and validator information for a given block. -It is stored as part of staking module's state, which persists the `n` most -recent HistoricalInfo -(`n` is set by the staking module's `historical_entries` parameter). - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `header` | [ostracon.types.Header](#ostracon.types.Header) | | | -| `valset` | [Validator](#lbm.staking.v1beta1.Validator) | repeated | | - - - - - - - - -### Params -Params defines the parameters for the staking module. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `unbonding_time` | [google.protobuf.Duration](#google.protobuf.Duration) | | unbonding_time is the time duration of unbonding. | -| `max_validators` | [uint32](#uint32) | | max_validators is the maximum number of validators. | -| `max_entries` | [uint32](#uint32) | | max_entries is the max entries for either unbonding delegation or redelegation (per pair/trio). | -| `historical_entries` | [uint32](#uint32) | | historical_entries is the number of historical entries to persist. | -| `bond_denom` | [string](#string) | | bond_denom defines the bondable coin denomination. | - - - - - - - - -### Pool -Pool is used for tracking bonded and not-bonded token supply of the bond -denomination. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `not_bonded_tokens` | [string](#string) | | | -| `bonded_tokens` | [string](#string) | | | - - - - - - - - -### Redelegation -Redelegation contains the list of a particular delegator's redelegating bonds -from a particular source validator to a particular destination validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address is the bech32-encoded address of the delegator. | -| `validator_src_address` | [string](#string) | | validator_src_address is the validator redelegation source operator address. | -| `validator_dst_address` | [string](#string) | | validator_dst_address is the validator redelegation destination operator address. | -| `entries` | [RedelegationEntry](#lbm.staking.v1beta1.RedelegationEntry) | repeated | entries are the redelegation entries. - -redelegation entries | - - - - - - - - -### RedelegationEntry -RedelegationEntry defines a redelegation object with relevant metadata. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `creation_height` | [int64](#int64) | | creation_height defines the height which the redelegation took place. | -| `completion_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | completion_time defines the unix time for redelegation completion. | -| `initial_balance` | [string](#string) | | initial_balance defines the initial balance when redelegation started. | -| `shares_dst` | [string](#string) | | shares_dst is the amount of destination-validator shares created by redelegation. | - - - - - - - - -### RedelegationEntryResponse -RedelegationEntryResponse is equivalent to a RedelegationEntry except that it -contains a balance in addition to shares which is more suitable for client -responses. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `redelegation_entry` | [RedelegationEntry](#lbm.staking.v1beta1.RedelegationEntry) | | | -| `balance` | [string](#string) | | | - - - - - - - - -### RedelegationResponse -RedelegationResponse is equivalent to a Redelegation except that its entries -contain a balance in addition to shares which is more suitable for client -responses. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `redelegation` | [Redelegation](#lbm.staking.v1beta1.Redelegation) | | | -| `entries` | [RedelegationEntryResponse](#lbm.staking.v1beta1.RedelegationEntryResponse) | repeated | | - - - - - - - - -### UnbondingDelegation -UnbondingDelegation stores all of a single delegator's unbonding bonds -for a single validator in an time-ordered list. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | delegator_address is the bech32-encoded address of the delegator. | -| `validator_address` | [string](#string) | | validator_address is the bech32-encoded address of the validator. | -| `entries` | [UnbondingDelegationEntry](#lbm.staking.v1beta1.UnbondingDelegationEntry) | repeated | entries are the unbonding delegation entries. - -unbonding delegation entries | - - - - - - - - -### UnbondingDelegationEntry -UnbondingDelegationEntry defines an unbonding object with relevant metadata. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `creation_height` | [int64](#int64) | | creation_height is the height which the unbonding took place. | -| `completion_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | completion_time is the unix time for unbonding completion. | -| `initial_balance` | [string](#string) | | initial_balance defines the tokens initially scheduled to receive at completion. | -| `balance` | [string](#string) | | balance defines the tokens to receive at completion. | - - - - - - - - -### ValAddresses -ValAddresses defines a repeated set of validator addresses. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `addresses` | [string](#string) | repeated | | - - - - - - - - -### Validator -Validator defines a validator, together with the total amount of the -Validator's bond shares and their exchange rate to coins. Slashing results in -a decrease in the exchange rate, allowing correct calculation of future -undelegations without iterating over delegators. When coins are delegated to -this validator, the validator is credited with a delegation whose number of -bond shares is based on the amount of coins delegated divided by the current -exchange rate. Voting power can be calculated as total bonded shares -multiplied by exchange rate. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `operator_address` | [string](#string) | | operator_address defines the address of the validator's operator; bech encoded in JSON. | -| `consensus_pubkey` | [google.protobuf.Any](#google.protobuf.Any) | | consensus_pubkey is the consensus public key of the validator, as a Protobuf Any. | -| `jailed` | [bool](#bool) | | jailed defined whether the validator has been jailed from bonded status or not. | -| `status` | [BondStatus](#lbm.staking.v1beta1.BondStatus) | | status is the validator status (bonded/unbonding/unbonded). | -| `tokens` | [string](#string) | | tokens define the delegated tokens (incl. self-delegation). | -| `delegator_shares` | [string](#string) | | delegator_shares defines total shares issued to a validator's delegators. | -| `description` | [Description](#lbm.staking.v1beta1.Description) | | description defines the description terms for the validator. | -| `unbonding_height` | [int64](#int64) | | unbonding_height defines, if unbonding, the height at which this validator has begun unbonding. | -| `unbonding_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | unbonding_time defines, if unbonding, the min time for the validator to complete unbonding. | -| `commission` | [Commission](#lbm.staking.v1beta1.Commission) | | commission defines the commission parameters. | -| `min_self_delegation` | [string](#string) | | min_self_delegation is the validator's self declared minimum self delegation. | - - - - - - - - - - -### BondStatus -BondStatus is the status of a validator. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| BOND_STATUS_UNSPECIFIED | 0 | UNSPECIFIED defines an invalid validator status. | -| BOND_STATUS_UNBONDED | 1 | UNBONDED defines a validator that is not bonded. | -| BOND_STATUS_UNBONDING | 2 | UNBONDING defines a validator that is unbonding. | -| BOND_STATUS_BONDED | 3 | BONDED defines a validator that is bonded. | - - - - - - - - - - - -

Top

- -## lbm/staking/v1beta1/genesis.proto - - - - - -### GenesisState -GenesisState defines the staking module's genesis state. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.staking.v1beta1.Params) | | params defines all the paramaters of related to deposit. | -| `last_total_power` | [bytes](#bytes) | | last_total_power tracks the total amounts of bonded tokens recorded during the previous end block. | -| `last_validator_powers` | [LastValidatorPower](#lbm.staking.v1beta1.LastValidatorPower) | repeated | last_validator_powers is a special index that provides a historical list of the last-block's bonded validators. | -| `validators` | [Validator](#lbm.staking.v1beta1.Validator) | repeated | delegations defines the validator set at genesis. | -| `delegations` | [Delegation](#lbm.staking.v1beta1.Delegation) | repeated | delegations defines the delegations active at genesis. | -| `unbonding_delegations` | [UnbondingDelegation](#lbm.staking.v1beta1.UnbondingDelegation) | repeated | unbonding_delegations defines the unbonding delegations active at genesis. | -| `redelegations` | [Redelegation](#lbm.staking.v1beta1.Redelegation) | repeated | redelegations defines the redelegations active at genesis. | -| `exported` | [bool](#bool) | | | - - - - - - - - -### LastValidatorPower -LastValidatorPower required for validator set update logic. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `address` | [string](#string) | | address is the address of the validator. | -| `power` | [int64](#int64) | | power defines the power of the validator. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/staking/v1beta1/query.proto - - - - - -### QueryDelegationRequest -QueryDelegationRequest is request type for the Query/Delegation RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `validator_addr` | [string](#string) | | validator_addr defines the validator address to query for. | - - - - - - - - -### QueryDelegationResponse -QueryDelegationResponse is response type for the Query/Delegation RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegation_response` | [DelegationResponse](#lbm.staking.v1beta1.DelegationResponse) | | delegation_responses defines the delegation info of a delegation. | - - - - - - - - -### QueryDelegatorDelegationsRequest -QueryDelegatorDelegationsRequest is request type for the -Query/DelegatorDelegations RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryDelegatorDelegationsResponse -QueryDelegatorDelegationsResponse is response type for the -Query/DelegatorDelegations RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegation_responses` | [DelegationResponse](#lbm.staking.v1beta1.DelegationResponse) | repeated | delegation_responses defines all the delegations' info of a delegator. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryDelegatorUnbondingDelegationsRequest -QueryDelegatorUnbondingDelegationsRequest is request type for the -Query/DelegatorUnbondingDelegations RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryDelegatorUnbondingDelegationsResponse -QueryUnbondingDelegatorDelegationsResponse is response type for the -Query/UnbondingDelegatorDelegations RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `unbonding_responses` | [UnbondingDelegation](#lbm.staking.v1beta1.UnbondingDelegation) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryDelegatorValidatorRequest -QueryDelegatorValidatorRequest is request type for the -Query/DelegatorValidator RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `validator_addr` | [string](#string) | | validator_addr defines the validator address to query for. | - - - - - - - - -### QueryDelegatorValidatorResponse -QueryDelegatorValidatorResponse response type for the -Query/DelegatorValidator RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator` | [Validator](#lbm.staking.v1beta1.Validator) | | validator defines the the validator info. | - - - - - - - - -### QueryDelegatorValidatorsRequest -QueryDelegatorValidatorsRequest is request type for the -Query/DelegatorValidators RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryDelegatorValidatorsResponse -QueryDelegatorValidatorsResponse is response type for the -Query/DelegatorValidators RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validators` | [Validator](#lbm.staking.v1beta1.Validator) | repeated | validators defines the the validators' info of a delegator. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryHistoricalInfoRequest -QueryHistoricalInfoRequest is request type for the Query/HistoricalInfo RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [int64](#int64) | | height defines at which height to query the historical info. | - - - - - - - - -### QueryHistoricalInfoResponse -QueryHistoricalInfoResponse is response type for the Query/HistoricalInfo RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `hist` | [HistoricalInfo](#lbm.staking.v1beta1.HistoricalInfo) | | hist defines the historical info at the given height. | - - - - - - - - -### QueryParamsRequest -QueryParamsRequest is request type for the Query/Params RPC method. - - - - - - - - -### QueryParamsResponse -QueryParamsResponse is response type for the Query/Params RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `params` | [Params](#lbm.staking.v1beta1.Params) | | params holds all the parameters of this module. | - - - - - - - - -### QueryPoolRequest -QueryPoolRequest is request type for the Query/Pool RPC method. - - - - - - - - -### QueryPoolResponse -QueryPoolResponse is response type for the Query/Pool RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `pool` | [Pool](#lbm.staking.v1beta1.Pool) | | pool defines the pool info. | - - - - - - - - -### QueryRedelegationsRequest -QueryRedelegationsRequest is request type for the Query/Redelegations RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `src_validator_addr` | [string](#string) | | src_validator_addr defines the validator address to redelegate from. | -| `dst_validator_addr` | [string](#string) | | dst_validator_addr defines the validator address to redelegate to. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryRedelegationsResponse -QueryRedelegationsResponse is response type for the Query/Redelegations RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `redelegation_responses` | [RedelegationResponse](#lbm.staking.v1beta1.RedelegationResponse) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryUnbondingDelegationRequest -QueryUnbondingDelegationRequest is request type for the -Query/UnbondingDelegation RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_addr` | [string](#string) | | delegator_addr defines the delegator address to query for. | -| `validator_addr` | [string](#string) | | validator_addr defines the validator address to query for. | - - - - - - - - -### QueryUnbondingDelegationResponse -QueryDelegationResponse is response type for the Query/UnbondingDelegation -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `unbond` | [UnbondingDelegation](#lbm.staking.v1beta1.UnbondingDelegation) | | unbond defines the unbonding information of a delegation. | - - - - - - - - -### QueryValidatorDelegationsRequest -QueryValidatorDelegationsRequest is request type for the -Query/ValidatorDelegations RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_addr` | [string](#string) | | validator_addr defines the validator address to query for. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryValidatorDelegationsResponse -QueryValidatorDelegationsResponse is response type for the -Query/ValidatorDelegations RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegation_responses` | [DelegationResponse](#lbm.staking.v1beta1.DelegationResponse) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryValidatorRequest -QueryValidatorRequest is response type for the Query/Validator RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_addr` | [string](#string) | | validator_addr defines the validator address to query for. | - - - - - - - - -### QueryValidatorResponse -QueryValidatorResponse is response type for the Query/Validator RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator` | [Validator](#lbm.staking.v1beta1.Validator) | | validator defines the the validator info. | - - - - - - - - -### QueryValidatorUnbondingDelegationsRequest -QueryValidatorUnbondingDelegationsRequest is required type for the -Query/ValidatorUnbondingDelegations RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validator_addr` | [string](#string) | | validator_addr defines the validator address to query for. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryValidatorUnbondingDelegationsResponse -QueryValidatorUnbondingDelegationsResponse is response type for the -Query/ValidatorUnbondingDelegations RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `unbonding_responses` | [UnbondingDelegation](#lbm.staking.v1beta1.UnbondingDelegation) | repeated | | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - -### QueryValidatorsRequest -QueryValidatorsRequest is request type for Query/Validators RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `status` | [string](#string) | | status enables to query for validators matching a given status. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an optional pagination for the request. | - - - - - - - - -### QueryValidatorsResponse -QueryValidatorsResponse is response type for the Query/Validators RPC method - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `validators` | [Validator](#lbm.staking.v1beta1.Validator) | repeated | validators contains all the queried validators. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines the pagination in the response. | - - - - - - - - - - - - - - -### Query -Query defines the gRPC querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Validators` | [QueryValidatorsRequest](#lbm.staking.v1beta1.QueryValidatorsRequest) | [QueryValidatorsResponse](#lbm.staking.v1beta1.QueryValidatorsResponse) | Validators queries all validators that match the given status. | GET|/lbm/staking/v1beta1/validators| -| `Validator` | [QueryValidatorRequest](#lbm.staking.v1beta1.QueryValidatorRequest) | [QueryValidatorResponse](#lbm.staking.v1beta1.QueryValidatorResponse) | Validator queries validator info for given validator address. | GET|/lbm/staking/v1beta1/validators/{validator_addr}| -| `ValidatorDelegations` | [QueryValidatorDelegationsRequest](#lbm.staking.v1beta1.QueryValidatorDelegationsRequest) | [QueryValidatorDelegationsResponse](#lbm.staking.v1beta1.QueryValidatorDelegationsResponse) | ValidatorDelegations queries delegate info for given validator. | GET|/lbm/staking/v1beta1/validators/{validator_addr}/delegations| -| `ValidatorUnbondingDelegations` | [QueryValidatorUnbondingDelegationsRequest](#lbm.staking.v1beta1.QueryValidatorUnbondingDelegationsRequest) | [QueryValidatorUnbondingDelegationsResponse](#lbm.staking.v1beta1.QueryValidatorUnbondingDelegationsResponse) | ValidatorUnbondingDelegations queries unbonding delegations of a validator. | GET|/lbm/staking/v1beta1/validators/{validator_addr}/unbonding_delegations| -| `Delegation` | [QueryDelegationRequest](#lbm.staking.v1beta1.QueryDelegationRequest) | [QueryDelegationResponse](#lbm.staking.v1beta1.QueryDelegationResponse) | Delegation queries delegate info for given validator delegator pair. | GET|/lbm/staking/v1beta1/validators/{validator_addr}/delegations/{delegator_addr}| -| `UnbondingDelegation` | [QueryUnbondingDelegationRequest](#lbm.staking.v1beta1.QueryUnbondingDelegationRequest) | [QueryUnbondingDelegationResponse](#lbm.staking.v1beta1.QueryUnbondingDelegationResponse) | UnbondingDelegation queries unbonding info for given validator delegator pair. | GET|/lbm/staking/v1beta1/validators/{validator_addr}/delegations/{delegator_addr}/unbonding_delegation| -| `DelegatorDelegations` | [QueryDelegatorDelegationsRequest](#lbm.staking.v1beta1.QueryDelegatorDelegationsRequest) | [QueryDelegatorDelegationsResponse](#lbm.staking.v1beta1.QueryDelegatorDelegationsResponse) | DelegatorDelegations queries all delegations of a given delegator address. | GET|/lbm/staking/v1beta1/delegations/{delegator_addr}| -| `DelegatorUnbondingDelegations` | [QueryDelegatorUnbondingDelegationsRequest](#lbm.staking.v1beta1.QueryDelegatorUnbondingDelegationsRequest) | [QueryDelegatorUnbondingDelegationsResponse](#lbm.staking.v1beta1.QueryDelegatorUnbondingDelegationsResponse) | DelegatorUnbondingDelegations queries all unbonding delegations of a given delegator address. | GET|/lbm/staking/v1beta1/delegators/{delegator_addr}/unbonding_delegations| -| `Redelegations` | [QueryRedelegationsRequest](#lbm.staking.v1beta1.QueryRedelegationsRequest) | [QueryRedelegationsResponse](#lbm.staking.v1beta1.QueryRedelegationsResponse) | Redelegations queries redelegations of given address. | GET|/lbm/staking/v1beta1/delegators/{delegator_addr}/redelegations| -| `DelegatorValidators` | [QueryDelegatorValidatorsRequest](#lbm.staking.v1beta1.QueryDelegatorValidatorsRequest) | [QueryDelegatorValidatorsResponse](#lbm.staking.v1beta1.QueryDelegatorValidatorsResponse) | DelegatorValidators queries all validators info for given delegator address. | GET|/lbm/staking/v1beta1/delegators/{delegator_addr}/validators| -| `DelegatorValidator` | [QueryDelegatorValidatorRequest](#lbm.staking.v1beta1.QueryDelegatorValidatorRequest) | [QueryDelegatorValidatorResponse](#lbm.staking.v1beta1.QueryDelegatorValidatorResponse) | DelegatorValidator queries validator info for given delegator validator pair. | GET|/lbm/staking/v1beta1/delegators/{delegator_addr}/validators/{validator_addr}| -| `HistoricalInfo` | [QueryHistoricalInfoRequest](#lbm.staking.v1beta1.QueryHistoricalInfoRequest) | [QueryHistoricalInfoResponse](#lbm.staking.v1beta1.QueryHistoricalInfoResponse) | HistoricalInfo queries the historical info for given height. | GET|/lbm/staking/v1beta1/historical_info/{height}| -| `Pool` | [QueryPoolRequest](#lbm.staking.v1beta1.QueryPoolRequest) | [QueryPoolResponse](#lbm.staking.v1beta1.QueryPoolResponse) | Pool queries the pool info. | GET|/lbm/staking/v1beta1/pool| -| `Params` | [QueryParamsRequest](#lbm.staking.v1beta1.QueryParamsRequest) | [QueryParamsResponse](#lbm.staking.v1beta1.QueryParamsResponse) | Parameters queries the staking parameters. | GET|/lbm/staking/v1beta1/params| - - - - - - -

Top

- -## lbm/staking/v1beta1/tx.proto - - - - - -### MsgBeginRedelegate -MsgBeginRedelegate defines a SDK message for performing a redelegation -of coins from a delegator and source validator to a destination validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `validator_src_address` | [string](#string) | | | -| `validator_dst_address` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | | - - - - - - - - -### MsgBeginRedelegateResponse -MsgBeginRedelegateResponse defines the Msg/BeginRedelegate response type. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `completion_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | - - - - - - - - -### MsgCreateValidator -MsgCreateValidator defines a SDK message for creating a new validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `description` | [Description](#lbm.staking.v1beta1.Description) | | | -| `commission` | [CommissionRates](#lbm.staking.v1beta1.CommissionRates) | | | -| `min_self_delegation` | [string](#string) | | | -| `delegator_address` | [string](#string) | | | -| `validator_address` | [string](#string) | | | -| `pubkey` | [google.protobuf.Any](#google.protobuf.Any) | | | -| `value` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | | - - - - - - - - -### MsgCreateValidatorResponse -MsgCreateValidatorResponse defines the Msg/CreateValidator response type. - - - - - - - - -### MsgDelegate -MsgDelegate defines a SDK message for performing a delegation of coins -from a delegator to a validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `validator_address` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | | - - - - - - - - -### MsgDelegateResponse -MsgDelegateResponse defines the Msg/Delegate response type. - - - - - - - - -### MsgEditValidator -MsgEditValidator defines a SDK message for editing an existing validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `description` | [Description](#lbm.staking.v1beta1.Description) | | | -| `validator_address` | [string](#string) | | | -| `commission_rate` | [string](#string) | | We pass a reference to the new commission rate and min self delegation as it's not mandatory to update. If not updated, the deserialized rate will be zero with no way to distinguish if an update was intended. REF: #2373 | -| `min_self_delegation` | [string](#string) | | | - - - - - - - - -### MsgEditValidatorResponse -MsgEditValidatorResponse defines the Msg/EditValidator response type. - - - - - - - - -### MsgUndelegate -MsgUndelegate defines a SDK message for performing an undelegation from a -delegate and a validator. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `delegator_address` | [string](#string) | | | -| `validator_address` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | | | - - - - - - - - -### MsgUndelegateResponse -MsgUndelegateResponse defines the Msg/Undelegate response type. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `completion_time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | | - - - - - - - - - - - - - - -### Msg -Msg defines the staking Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `CreateValidator` | [MsgCreateValidator](#lbm.staking.v1beta1.MsgCreateValidator) | [MsgCreateValidatorResponse](#lbm.staking.v1beta1.MsgCreateValidatorResponse) | CreateValidator defines a method for creating a new validator. | | -| `EditValidator` | [MsgEditValidator](#lbm.staking.v1beta1.MsgEditValidator) | [MsgEditValidatorResponse](#lbm.staking.v1beta1.MsgEditValidatorResponse) | EditValidator defines a method for editing an existing validator. | | -| `Delegate` | [MsgDelegate](#lbm.staking.v1beta1.MsgDelegate) | [MsgDelegateResponse](#lbm.staking.v1beta1.MsgDelegateResponse) | Delegate defines a method for performing a delegation of coins from a delegator to a validator. | | -| `BeginRedelegate` | [MsgBeginRedelegate](#lbm.staking.v1beta1.MsgBeginRedelegate) | [MsgBeginRedelegateResponse](#lbm.staking.v1beta1.MsgBeginRedelegateResponse) | BeginRedelegate defines a method for performing a redelegation of coins from a delegator and source validator to a destination validator. | | -| `Undelegate` | [MsgUndelegate](#lbm.staking.v1beta1.MsgUndelegate) | [MsgUndelegateResponse](#lbm.staking.v1beta1.MsgUndelegateResponse) | Undelegate defines a method for performing an undelegation from a delegate and a validator. | | - - - - - - -

Top

- -## lbm/tx/signing/v1beta1/signing.proto - - - - - -### SignatureDescriptor -SignatureDescriptor is a convenience type which represents the full data for -a signature including the public key of the signer, signing modes and the -signature itself. It is primarily used for coordinating signatures between -clients. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `public_key` | [google.protobuf.Any](#google.protobuf.Any) | | public_key is the public key of the signer | -| `data` | [SignatureDescriptor.Data](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data) | | | -| `sequence` | [uint64](#uint64) | | sequence is the sequence of the account, which describes the number of committed transactions signed by a given address. It is used to prevent replay attacks. | - - - - - - - - -### SignatureDescriptor.Data -Data represents signature data - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `single` | [SignatureDescriptor.Data.Single](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data.Single) | | single represents a single signer | -| `multi` | [SignatureDescriptor.Data.Multi](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data.Multi) | | multi represents a multisig signer | - - - - - - - - -### SignatureDescriptor.Data.Multi -Multi is the signature data for a multisig public key - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `bitarray` | [lbm.crypto.multisig.v1beta1.CompactBitArray](#lbm.crypto.multisig.v1beta1.CompactBitArray) | | bitarray specifies which keys within the multisig are signing | -| `signatures` | [SignatureDescriptor.Data](#lbm.tx.signing.v1beta1.SignatureDescriptor.Data) | repeated | signatures is the signatures of the multi-signature | - - - - - - - - -### SignatureDescriptor.Data.Single -Single is the signature data for a single signer - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `mode` | [SignMode](#lbm.tx.signing.v1beta1.SignMode) | | mode is the signing mode of the single signer | -| `signature` | [bytes](#bytes) | | signature is the raw signature bytes | - - - - - - - - -### SignatureDescriptors -SignatureDescriptors wraps multiple SignatureDescriptor's. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signatures` | [SignatureDescriptor](#lbm.tx.signing.v1beta1.SignatureDescriptor) | repeated | signatures are the signature descriptors | - - - - - - - - - - -### SignMode -SignMode represents a signing mode with its own security guarantees. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| SIGN_MODE_UNSPECIFIED | 0 | SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be rejected | -| SIGN_MODE_DIRECT | 1 | SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is verified with raw bytes from Tx | -| SIGN_MODE_TEXTUAL | 2 | SIGN_MODE_TEXTUAL is a future signing mode that will verify some human-readable textual representation on top of the binary representation from SIGN_MODE_DIRECT | -| SIGN_MODE_LEGACY_AMINO_JSON | 127 | SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses Amino JSON and will be removed in the future | - - - - - - - - - - - -

Top

- -## lbm/tx/v1beta1/tx.proto - - - - - -### AuthInfo -AuthInfo describes the fee and signer modes that are used to sign a -transaction. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `signer_infos` | [SignerInfo](#lbm.tx.v1beta1.SignerInfo) | repeated | signer_infos defines the signing modes for the required signers. The number and order of elements must match the required signers from TxBody's messages. The first element is the primary signer and the one which pays the fee. | -| `fee` | [Fee](#lbm.tx.v1beta1.Fee) | | Fee is the fee and gas limit for the transaction. The first signer is the primary signer and the one which pays the fee. The fee can be calculated based on the cost of evaluating the body and doing signature verification of the signers. This can be estimated via simulation. | - - - - - - - - -### Fee -Fee includes the amount of coins paid in fees and the maximum -gas to be used by the transaction. The ratio yields an effective "gasprice", -which must be above some miminum to be accepted into the mempool. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | amount is the amount of coins to be paid as a fee | -| `gas_limit` | [uint64](#uint64) | | gas_limit is the maximum gas that can be used in transaction processing before an out of gas error occurs | -| `payer` | [string](#string) | | if unset, the first signer is responsible for paying the fees. If set, the specified account must pay the fees. the payer must be a tx signer (and thus have signed this field in AuthInfo). setting this field does *not* change the ordering of required signers for the transaction. | -| `granter` | [string](#string) | | if set, the fee payer (either the first signer or the value of the payer field) requests that a fee grant be used to pay fees instead of the fee payer's own balance. If an appropriate fee grant does not exist or the chain does not support fee grants, this will fail | - - - - - - - - -### ModeInfo -ModeInfo describes the signing mode of a single or nested multisig signer. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `single` | [ModeInfo.Single](#lbm.tx.v1beta1.ModeInfo.Single) | | single represents a single signer | -| `multi` | [ModeInfo.Multi](#lbm.tx.v1beta1.ModeInfo.Multi) | | multi represents a nested multisig signer | - - - - - - - - -### ModeInfo.Multi -Multi is the mode info for a multisig public key - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `bitarray` | [lbm.crypto.multisig.v1beta1.CompactBitArray](#lbm.crypto.multisig.v1beta1.CompactBitArray) | | bitarray specifies which keys within the multisig are signing | -| `mode_infos` | [ModeInfo](#lbm.tx.v1beta1.ModeInfo) | repeated | mode_infos is the corresponding modes of the signers of the multisig which could include nested multisig public keys | - - - - - - - - -### ModeInfo.Single -Single is the mode info for a single signer. It is structured as a message -to allow for additional fields such as locale for SIGN_MODE_TEXTUAL in the -future - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `mode` | [lbm.tx.signing.v1beta1.SignMode](#lbm.tx.signing.v1beta1.SignMode) | | mode is the signing mode of the single signer | - - - - - - - - -### SignDoc -SignDoc is the type used for generating sign bytes for SIGN_MODE_DIRECT. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `body_bytes` | [bytes](#bytes) | | body_bytes is protobuf serialization of a TxBody that matches the representation in TxRaw. | -| `auth_info_bytes` | [bytes](#bytes) | | auth_info_bytes is a protobuf serialization of an AuthInfo that matches the representation in TxRaw. | -| `chain_id` | [string](#string) | | chain_id is the unique identifier of the chain this transaction targets. It prevents signed transactions from being used on another chain by an attacker | -| `account_number` | [uint64](#uint64) | | account_number is the account number of the account in state | - - - - - - - - -### SignerInfo -SignerInfo describes the public key and signing mode of a single top-level -signer. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `public_key` | [google.protobuf.Any](#google.protobuf.Any) | | public_key is the public key of the signer. It is optional for accounts that already exist in state. If unset, the verifier can use the required \ signer address for this position and lookup the public key. | -| `mode_info` | [ModeInfo](#lbm.tx.v1beta1.ModeInfo) | | mode_info describes the signing mode of the signer and is a nested structure to support nested multisig pubkey's | -| `sequence` | [uint64](#uint64) | | sequence is the sequence of the account, which describes the number of committed transactions signed by a given address. It is used to prevent replay attacks. | - - - - - - - - -### Tx -Tx is the standard type used for broadcasting transactions. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `body` | [TxBody](#lbm.tx.v1beta1.TxBody) | | body is the processable content of the transaction | -| `auth_info` | [AuthInfo](#lbm.tx.v1beta1.AuthInfo) | | auth_info is the authorization related content of the transaction, specifically signers, signer modes and fee | -| `signatures` | [bytes](#bytes) | repeated | signatures is a list of signatures that matches the length and order of AuthInfo's signer_infos to allow connecting signature meta information like public key and signing mode by position. | - - - - - - - - -### TxBody -TxBody is the body of a transaction that all signers sign over. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `messages` | [google.protobuf.Any](#google.protobuf.Any) | repeated | messages is a list of messages to be executed. The required signers of those messages define the number and order of elements in AuthInfo's signer_infos and Tx's signatures. Each required signer address is added to the list only the first time it occurs. By convention, the first required signer (usually from the first message) is referred to as the primary signer and pays the fee for the whole transaction. | -| `memo` | [string](#string) | | memo is any arbitrary memo to be added to the transaction | -| `timeout_height` | [uint64](#uint64) | | timeout is the block height after which this transaction will not be processed by the chain | -| `extension_options` | [google.protobuf.Any](#google.protobuf.Any) | repeated | extension_options are arbitrary options that can be added by chains when the default options are not sufficient. If any of these are present and can't be handled, the transaction will be rejected | -| `non_critical_extension_options` | [google.protobuf.Any](#google.protobuf.Any) | repeated | extension_options are arbitrary options that can be added by chains when the default options are not sufficient. If any of these are present and can't be handled, they will be ignored | - - - - - - - - -### TxRaw -TxRaw is a variant of Tx that pins the signer's exact binary representation -of body and auth_info. This is used for signing, broadcasting and -verification. The binary `serialize(tx: TxRaw)` is stored in Tendermint and -the hash `sha256(serialize(tx: TxRaw))` becomes the "txhash", commonly used -as the transaction ID. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `body_bytes` | [bytes](#bytes) | | body_bytes is a protobuf serialization of a TxBody that matches the representation in SignDoc. | -| `auth_info_bytes` | [bytes](#bytes) | | auth_info_bytes is a protobuf serialization of an AuthInfo that matches the representation in SignDoc. | -| `signatures` | [bytes](#bytes) | repeated | signatures is a list of signatures that matches the length and order of AuthInfo's signer_infos to allow connecting signature meta information like public key and signing mode by position. | - - - - - - - - - - - - - - - - -

Top

- -## lbm/tx/v1beta1/service.proto - - - - - -### BroadcastTxRequest -BroadcastTxRequest is the request type for the Service.BroadcastTxRequest -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `tx_bytes` | [bytes](#bytes) | | tx_bytes is the raw transaction. | -| `mode` | [BroadcastMode](#lbm.tx.v1beta1.BroadcastMode) | | | - - - - - - - - -### BroadcastTxResponse -BroadcastTxResponse is the response type for the -Service.BroadcastTx method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `tx_response` | [lbm.base.abci.v1beta1.TxResponse](#lbm.base.abci.v1beta1.TxResponse) | | tx_response is the queried TxResponses. | - - - - - - - - -### GetTxRequest -GetTxRequest is the request type for the Service.GetTx -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `hash` | [string](#string) | | hash is the tx hash to query, encoded as a hex string. | - - - - - - - - -### GetTxResponse -GetTxResponse is the response type for the Service.GetTx method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `tx` | [Tx](#lbm.tx.v1beta1.Tx) | | tx is the queried transaction. | -| `tx_response` | [lbm.base.abci.v1beta1.TxResponse](#lbm.base.abci.v1beta1.TxResponse) | | tx_response is the queried TxResponses. | - - - - - - - - -### GetTxsEventRequest -GetTxsEventRequest is the request type for the Service.TxsByEvents -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `events` | [string](#string) | repeated | events is the list of transaction event type. | -| `pagination` | [lbm.base.query.v1beta1.PageRequest](#lbm.base.query.v1beta1.PageRequest) | | pagination defines an pagination for the request. | - - - - - - - - -### GetTxsEventResponse -GetTxsEventResponse is the response type for the Service.TxsByEvents -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `txs` | [Tx](#lbm.tx.v1beta1.Tx) | repeated | txs is the list of queried transactions. | -| `tx_responses` | [lbm.base.abci.v1beta1.TxResponse](#lbm.base.abci.v1beta1.TxResponse) | repeated | tx_responses is the list of queried TxResponses. | -| `pagination` | [lbm.base.query.v1beta1.PageResponse](#lbm.base.query.v1beta1.PageResponse) | | pagination defines an pagination for the response. | - - - - - - - - -### SimulateRequest -SimulateRequest is the request type for the Service.Simulate -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `tx` | [Tx](#lbm.tx.v1beta1.Tx) | | tx is the transaction to simulate. | - - - - - - - - -### SimulateResponse -SimulateResponse is the response type for the -Service.SimulateRPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `gas_info` | [lbm.base.abci.v1beta1.GasInfo](#lbm.base.abci.v1beta1.GasInfo) | | gas_info is the information about gas used in the simulation. | -| `result` | [lbm.base.abci.v1beta1.Result](#lbm.base.abci.v1beta1.Result) | | result is the result of the simulation. | - - - - - - - - - - -### BroadcastMode -BroadcastMode specifies the broadcast mode for the TxService.Broadcast RPC method. - -| Name | Number | Description | -| ---- | ------ | ----------- | -| BROADCAST_MODE_UNSPECIFIED | 0 | zero-value for mode ordering | -| BROADCAST_MODE_BLOCK | 1 | BROADCAST_MODE_BLOCK defines a tx broadcasting mode where the client waits for the tx to be committed in a block. | -| BROADCAST_MODE_SYNC | 2 | BROADCAST_MODE_SYNC defines a tx broadcasting mode where the client waits for a CheckTx execution response only. | -| BROADCAST_MODE_ASYNC | 3 | BROADCAST_MODE_ASYNC defines a tx broadcasting mode where the client returns immediately. | - - - - - - - - - -### Service -Service defines a gRPC service for interacting with transactions. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `Simulate` | [SimulateRequest](#lbm.tx.v1beta1.SimulateRequest) | [SimulateResponse](#lbm.tx.v1beta1.SimulateResponse) | Simulate simulates executing a transaction for estimating gas usage. | POST|/lbm/tx/v1beta1/simulate| -| `GetTx` | [GetTxRequest](#lbm.tx.v1beta1.GetTxRequest) | [GetTxResponse](#lbm.tx.v1beta1.GetTxResponse) | GetTx fetches a tx by hash. | GET|/lbm/tx/v1beta1/txs/{hash}| -| `BroadcastTx` | [BroadcastTxRequest](#lbm.tx.v1beta1.BroadcastTxRequest) | [BroadcastTxResponse](#lbm.tx.v1beta1.BroadcastTxResponse) | BroadcastTx broadcast transaction. | POST|/lbm/tx/v1beta1/txs| -| `GetTxsEvent` | [GetTxsEventRequest](#lbm.tx.v1beta1.GetTxsEventRequest) | [GetTxsEventResponse](#lbm.tx.v1beta1.GetTxsEventResponse) | GetTxsEvent fetches txs by event. | GET|/lbm/tx/v1beta1/txs| - - - - - - -

Top

- -## lbm/upgrade/v1beta1/upgrade.proto - - - - - -### CancelSoftwareUpgradeProposal -CancelSoftwareUpgradeProposal is a gov Content type for cancelling a software -upgrade. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | | -| `description` | [string](#string) | | | - - - - - - - - -### Plan -Plan specifies information about a planned upgrade and when it should occur. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `name` | [string](#string) | | Sets the name for the upgrade. This name will be used by the upgraded version of the software to apply any special "on-upgrade" commands during the first BeginBlock method after the upgrade is applied. It is also used to detect whether a software version can handle a given upgrade. If no upgrade handler with this name has been set in the software, it will be assumed that the software is out-of-date when the upgrade Time or Height is reached and the software will exit. | -| `time` | [google.protobuf.Timestamp](#google.protobuf.Timestamp) | | The time after which the upgrade must be performed. Leave set to its zero value to use a pre-defined Height instead. | -| `height` | [int64](#int64) | | The height at which the upgrade must be performed. Only used if Time is not set. | -| `info` | [string](#string) | | Any application specific upgrade info to be included on-chain such as a git commit that validators could automatically upgrade to | -| `upgraded_client_state` | [google.protobuf.Any](#google.protobuf.Any) | | IBC-enabled chains can opt-in to including the upgraded client state in its upgrade plan This will make the chain commit to the correct upgraded (self) client state before the upgrade occurs, so that connecting chains can verify that the new upgraded client is valid by verifying a proof on the previous version of the chain. This will allow IBC connections to persist smoothly across planned chain upgrades | - - - - - - - - -### SoftwareUpgradeProposal -SoftwareUpgradeProposal is a gov Content type for initiating a software -upgrade. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `title` | [string](#string) | | | -| `description` | [string](#string) | | | -| `plan` | [Plan](#lbm.upgrade.v1beta1.Plan) | | | - - - - - - - - - - - - - - - - -

Top

- -## lbm/upgrade/v1beta1/query.proto - - - - - -### QueryAppliedPlanRequest -QueryCurrentPlanRequest is the request type for the Query/AppliedPlan RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `name` | [string](#string) | | name is the name of the applied plan to query for. | - - - - - - - - -### QueryAppliedPlanResponse -QueryAppliedPlanResponse is the response type for the Query/AppliedPlan RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `height` | [int64](#int64) | | height is the block height at which the plan was applied. | - - - - - - - - -### QueryCurrentPlanRequest -QueryCurrentPlanRequest is the request type for the Query/CurrentPlan RPC -method. - - - - - - - - -### QueryCurrentPlanResponse -QueryCurrentPlanResponse is the response type for the Query/CurrentPlan RPC -method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `plan` | [Plan](#lbm.upgrade.v1beta1.Plan) | | plan is the current upgrade plan. | - - - - - - - - -### QueryUpgradedConsensusStateRequest -QueryUpgradedConsensusStateRequest is the request type for the Query/UpgradedConsensusState -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `last_height` | [int64](#int64) | | last height of the current chain must be sent in request as this is the height under which next consensus state is stored | - - - - - - - - -### QueryUpgradedConsensusStateResponse -QueryUpgradedConsensusStateResponse is the response type for the Query/UpgradedConsensusState -RPC method. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `upgraded_consensus_state` | [google.protobuf.Any](#google.protobuf.Any) | | | - - - - - - - - - - - - - - -### Query -Query defines the gRPC upgrade querier service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `CurrentPlan` | [QueryCurrentPlanRequest](#lbm.upgrade.v1beta1.QueryCurrentPlanRequest) | [QueryCurrentPlanResponse](#lbm.upgrade.v1beta1.QueryCurrentPlanResponse) | CurrentPlan queries the current upgrade plan. | GET|/lbm/upgrade/v1beta1/current_plan| -| `AppliedPlan` | [QueryAppliedPlanRequest](#lbm.upgrade.v1beta1.QueryAppliedPlanRequest) | [QueryAppliedPlanResponse](#lbm.upgrade.v1beta1.QueryAppliedPlanResponse) | AppliedPlan queries a previously applied upgrade plan by its name. | GET|/lbm/upgrade/v1beta1/applied_plan/{name}| -| `UpgradedConsensusState` | [QueryUpgradedConsensusStateRequest](#lbm.upgrade.v1beta1.QueryUpgradedConsensusStateRequest) | [QueryUpgradedConsensusStateResponse](#lbm.upgrade.v1beta1.QueryUpgradedConsensusStateResponse) | UpgradedConsensusState queries the consensus state that will serve as a trusted kernel for the next version of this chain. It will only be stored at the last height of this chain. UpgradedConsensusState RPC not supported with legacy querier | GET|/lbm/upgrade/v1beta1/upgraded_consensus_state/{last_height}| - - - - - - -

Top

- -## lbm/vesting/v1beta1/tx.proto - - - - - -### MsgCreateVestingAccount -MsgCreateVestingAccount defines a message that enables creating a vesting -account. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `from_address` | [string](#string) | | | -| `to_address` | [string](#string) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `end_time` | [int64](#int64) | | | -| `delayed` | [bool](#bool) | | | - - - - - - - - -### MsgCreateVestingAccountResponse -MsgCreateVestingAccountResponse defines the Msg/CreateVestingAccount response type. - - - - - - - - - - - - - - -### Msg -Msg defines the bank Msg service. - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -| `CreateVestingAccount` | [MsgCreateVestingAccount](#lbm.vesting.v1beta1.MsgCreateVestingAccount) | [MsgCreateVestingAccountResponse](#lbm.vesting.v1beta1.MsgCreateVestingAccountResponse) | CreateVestingAccount defines a method that enables creating a vesting account. | | - - - - - - -

Top

- -## lbm/vesting/v1beta1/vesting.proto - - - - - -### BaseVestingAccount -BaseVestingAccount implements the VestingAccount interface. It contains all -the necessary fields needed for any vesting account implementation. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `base_account` | [lbm.auth.v1beta1.BaseAccount](#lbm.auth.v1beta1.BaseAccount) | | | -| `original_vesting` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `delegated_free` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `delegated_vesting` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | -| `end_time` | [int64](#int64) | | | - - - - - - - - -### ContinuousVestingAccount -ContinuousVestingAccount implements the VestingAccount interface. It -continuously vests by unlocking coins linearly with respect to time. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `base_vesting_account` | [BaseVestingAccount](#lbm.vesting.v1beta1.BaseVestingAccount) | | | -| `start_time` | [int64](#int64) | | | - - - - - - - - -### DelayedVestingAccount -DelayedVestingAccount implements the VestingAccount interface. It vests all -coins after a specific time, but non prior. In other words, it keeps them -locked until a specified time. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `base_vesting_account` | [BaseVestingAccount](#lbm.vesting.v1beta1.BaseVestingAccount) | | | - - - - - - - - -### Period -Period defines a length of time and amount of coins that will vest. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `length` | [int64](#int64) | | | -| `amount` | [lbm.base.v1beta1.Coin](#lbm.base.v1beta1.Coin) | repeated | | - - - - - - - - -### PeriodicVestingAccount -PeriodicVestingAccount implements the VestingAccount interface. It -periodically vests by unlocking coins during each specified period. - - -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -| `base_vesting_account` | [BaseVestingAccount](#lbm.vesting.v1beta1.BaseVestingAccount) | | | -| `start_time` | [int64](#int64) | | | -| `vesting_periods` | [Period](#lbm.vesting.v1beta1.Period) | repeated | | - - - - - - - - - - - - - - - -## Scalar Value Types - -| .proto Type | Notes | C++ | Java | Python | Go | C# | PHP | Ruby | -| ----------- | ----- | --- | ---- | ------ | -- | -- | --- | ---- | -| double | | double | double | float | float64 | double | float | Float | -| float | | float | float | float | float32 | float | float | Float | -| int32 | Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint32 instead. | int32 | int | int | int32 | int | integer | Bignum or Fixnum (as required) | -| int64 | Uses variable-length encoding. Inefficient for encoding negative numbers – if your field is likely to have negative values, use sint64 instead. | int64 | long | int/long | int64 | long | integer/string | Bignum | -| uint32 | Uses variable-length encoding. | uint32 | int | int/long | uint32 | uint | integer | Bignum or Fixnum (as required) | -| uint64 | Uses variable-length encoding. | uint64 | long | int/long | uint64 | ulong | integer/string | Bignum or Fixnum (as required) | -| sint32 | Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int32s. | int32 | int | int | int32 | int | integer | Bignum or Fixnum (as required) | -| sint64 | Uses variable-length encoding. Signed int value. These more efficiently encode negative numbers than regular int64s. | int64 | long | int/long | int64 | long | integer/string | Bignum | -| fixed32 | Always four bytes. More efficient than uint32 if values are often greater than 2^28. | uint32 | int | int | uint32 | uint | integer | Bignum or Fixnum (as required) | -| fixed64 | Always eight bytes. More efficient than uint64 if values are often greater than 2^56. | uint64 | long | int/long | uint64 | ulong | integer/string | Bignum | -| sfixed32 | Always four bytes. | int32 | int | int | int32 | int | integer | Bignum or Fixnum (as required) | -| sfixed64 | Always eight bytes. | int64 | long | int/long | int64 | long | integer/string | Bignum | -| bool | | bool | boolean | boolean | bool | bool | boolean | TrueClass/FalseClass | -| string | A string must always contain UTF-8 encoded or 7-bit ASCII text. | string | String | str/unicode | string | string | string | String (UTF-8) | -| bytes | May contain any arbitrary sequence of bytes. | string | ByteString | str | []byte | ByteString | string | String (ASCII-8BIT) | - diff --git a/docs/core/runtx_middleware.md b/docs/core/runtx_middleware.md deleted file mode 100644 index 9c978fbbe0..0000000000 --- a/docs/core/runtx_middleware.md +++ /dev/null @@ -1,73 +0,0 @@ - - -# RunTx recovery middleware - -`BaseApp.runTx()` function handles Golang panics that might occur during transactions execution, for example, keeper has faced an invalid state and paniced. -Depending on the panic type different handler is used, for instance the default one prints an error log message. -Recovery middleware is used to add custom panic recovery for SDK application developers. - -More context could be found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md). - -Implementation could be found in the [recovery.go](../../baseapp/recovery.go) file. - -## Interface - -```go -type RecoveryHandler func(recoveryObj interface{}) error -``` - -`recoveryObj` is a return value for `recover()` function from the `buildin` Golang package. - -**Contract:** - -- RecoveryHandler returns `nil` if `recoveryObj` wasn't handled and should be passed to the next recovery middleware; -- RecoveryHandler returns a non-nil `error` if `recoveryObj` was handled; - -## Custom RecoveryHandler register - -`BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)` - -BaseApp method adds recovery middleware to the default recovery chain. - -## Example - -Lets assume we want to emit the "Consensus failure" chain state if some particular error occurred. - -We have a module keeper that panics: - -```go -func (k FooKeeper) Do(obj interface{}) { - if obj == nil { - // that shouldn't happen, we need to crash the app - err := sdkErrors.Wrap(fooTypes.InternalError, "obj is nil") - panic(err) - } -} -``` - -By default that panic would be recovered and an error message will be printed to log. To override that behaviour we should register a custom RecoveryHandler: - -```go -// SDK application constructor -customHandler := func(recoveryObj interface{}) error { - err, ok := recoveryObj.(error) - if !ok { - return nil - } - - if fooTypes.InternalError.Is(err) { - panic(fmt.Errorf("FooKeeper did panic with error: %w", err)) - } - - return nil -} - -baseApp := baseapp.NewBaseApp(...) -baseApp.AddRunTxRecoveryHandler(customHandler) -``` - -## Next {hide} - -Learn about the [IBC](./../ibc/README.md) protocol {hide} diff --git a/docs/core/simulation.md b/docs/core/simulation.md deleted file mode 100644 index 9b838b40b5..0000000000 --- a/docs/core/simulation.md +++ /dev/null @@ -1,101 +0,0 @@ - - -# Cosmos Blockchain Simulator - -The Cosmos SDK offers a full fledged simulation framework to fuzz test every -message defined by a module. - -On the SDK, this functionality is provided by the[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/app.go), which is a -`Baseapp` application that is used for running the [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation) module. -This module defines all the simulation logic as well as the operations for -randomized parameters like accounts, balances etc. - -## Goals - -The blockchain simulator tests how the blockchain application would behave under -real life circumstances by generating and sending randomized messages. -The goal of this is to detect and debug failures that could halt a live chain, -by providing logs and statistics about the operations run by the simulator as -well as exporting the latest application state when a failure was found. - -Its main difference with integration testing is that the simulator app allows -you to pass parameters to customize the chain that's being simulated. -This comes in handy when trying to reproduce bugs that were generated in the -provided operations (randomized or not). - -## Simulation commands - -The simulation app has different commands, each of which tests a different -failure type: - -- `AppImportExport`: The simulator exports the initial app state and then it - creates a new app with the exported `genesis.json` as an input, checking for - inconsistencies between the stores. -- `AppSimulationAfterImport`: Queues two simulations together. The first one provides the app state (_i.e_ genesis) to the second. Useful to test software upgrades or hard-forks from a live chain. -- `AppStateDeterminism`: Checks that all the nodes return the same values, in the same order. -- `BenchmarkInvariants`: Analysis of the performance of running all modules' invariants (_i.e_ sequentially runs a [benchmark](https://golang.org/pkg/testing/#hdr-Benchmarks) test). An invariant checks for - differences between the values that are on the store and the passive tracker. Eg: total coins held by accounts vs total supply tracker. -- `FullAppSimulation`: General simulation mode. Runs the chain and the specified operations for a given number of blocks. Tests that there're no `panics` on the simulation. It does also run invariant checks on every `Period` but they are not benchmarked. - -Each simulation must receive a set of inputs (_i.e_ flags) such as the number of -blocks that the simulation is run, seed, block size, etc. -Check the full list of flags [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/config.go#L32-L55). - -## Simulator Modes - -In addition to the various inputs and commands, the simulator runs in three modes: - -1. Completely random where the initial state, module parameters and simulation - parameters are **pseudo-randomly generated**. -2. From a `genesis.json` file where the initial state and the module parameters are defined. - This mode is helpful for running simulations on a known state such as a live network export where a new (mostly likely breaking) version of the application needs to be tested. -3. From a `params.json` file where the initial state is pseudo-randomly generated but the module and simulation parameters can be provided manually. - This allows for a more controlled and deterministic simulation setup while allowing the state space to still be pseudo-randomly simulated. - The list of available parameters are listed [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation/params.go#L44-L52). - -::: tip -These modes are not mutually exclusive. So you can for example run a randomly -generated genesis state (`1`) with manually generated simulation params (`3`). -::: - -## Usage - -This is a general example of how simulations are run. For more specific examples -check the SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/Makefile#L251-L287). - -```bash - $ go test -mod=readonly github.com/cosmos/cosmos-sdk/simapp \ - -run=TestApp \ - ... - -v -timeout 24h -``` - -## Debugging Tips - -Here are some suggestions when encountering a simulation failure: - -- Export the app state at the height were the failure was found. You can do this - by passing the `-ExportStatePath` flag to the simulator. -- Use `-Verbose` logs. They could give you a better hint on all the operations - involved. -- Reduce the simulation `-Period`. This will run the invariants checks more - frequently. -- Print all the failed invariants at once with `-PrintAllInvariants`. -- Try using another `-Seed`. If it can reproduce the same error and if it fails - sooner you will spend less time running the simulations. -- Reduce the `-NumBlocks` . How's the app state at the height previous to the - failure? -- Run invariants on every operation with `-SimulateEveryOperation`. _Note_: this - will slow down your simulation **a lot**. -- Try adding logs to operations that are not logged. You will have to define a - [Logger](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/keeper/keeper.go#L66-L69) on your `Keeper`. - -## Use simulation in your SDK-based application - -Learn how you can integrate the simulation into your SDK-based application: - -- Application Simulation Manager -- [Building modules: Simulator](../building-modules/simulator.md) -- Simulator tests diff --git a/docs/core/store.md b/docs/core/store.md deleted file mode 100644 index 79be79d4c6..0000000000 --- a/docs/core/store.md +++ /dev/null @@ -1,227 +0,0 @@ - - -# Store - -A store is a data structure that holds the state of the application. {synopsis} - -### Pre-requisite Readings - -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} - -## Introduction to SDK Stores - -The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of SDK applications is a `multistore`, i.e. a store of stores. Developers can add any number of key-value stores to the multistore, depending on their application needs. The multistore exists to support the modularity of the Cosmos SDK, as it lets each module declare and manage their own subset of the state. Key-value stores in the multistore can only be accessed with a specific capability `key`, which is typically held in the [`keeper`](../building-modules/keeper.md) of the module that declared the store. - -``` -+-----------------------------------------------------+ -| | -| +--------------------------------------------+ | -| | | | -| | KVStore 1 - Manage by keeper of Module 1 | -| | | | -| +--------------------------------------------+ | -| | -| +--------------------------------------------+ | -| | | | -| | KVStore 2 - Manage by keeper of Module 2 | | -| | | | -| +--------------------------------------------+ | -| | -| +--------------------------------------------+ | -| | | | -| | KVStore 3 - Manage by keeper of Module 2 | | -| | | | -| +--------------------------------------------+ | -| | -| +--------------------------------------------+ | -| | | | -| | KVStore 4 - Manage by keeper of Module 3 | | -| | | | -| +--------------------------------------------+ | -| | -| +--------------------------------------------+ | -| | | | -| | KVStore 5 - Manage by keeper of Module 4 | | -| | | | -| +--------------------------------------------+ | -| | -| Main Multistore | -| | -+-----------------------------------------------------+ - - Application's State -``` - -### Store Interface - -At its very core, a Cosmos SDK `store` is an object that holds a `CacheWrapper` and has a `GetStoreType()` method: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L15-L18 - -The `GetStoreType` is a simple method that returns the type of store, whereas a `CacheWrapper` is a simple interface that implements store read caching and write branching through `Write` method: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L240-L264 - -Branching and cache is used ubiquitously in the Cosmos SDK and required to be implemented on every store type. A storage branch creates an isolated, ephemeral branch of a store that can be passed around and updated without affecting the main underlying store. This is used to trigger temporary state-transitions that may be reverted later should an error occur. Read more about it in [context](./context.md#Store-branching) - -### Commit Store - -A commit store is a store that has the ability to commit changes made to the underlying tree or db. The Cosmos SDK differentiates simple stores from commit stores by extending the basic store interfaces with a `Committer`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L29-L33 - -The `Committer` is an interface that defines methods to persist changes to disk: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L20-L27 - -The `CommitID` is a deterministic commit of the state tree. Its hash is returned to the underlying consensus engine and stored in the block header. Note that commit store interfaces exist for various purposes, one of which is to make sure not every object can commit the store. As part of the [object-capabilities model](./ocap.md) of the Cosmos SDK, only `baseapp` should have the ability to commit stores. For example, this is the reason why the `ctx.KVStore()` method by which modules typically access stores returns a `KVStore` and not a `CommitKVStore`. - -The Cosmos SDK comes with many types of stores, the most used being [`CommitMultiStore`](#multistore), [`KVStore`](#kvstore) and [`GasKv` store](#gaskv-store). [Other types of stores](#other-stores) include `Transient` and `TraceKV` stores. - -## Multistore - -### Multistore Interface - -Each Cosmos SDK application holds a multistore at its root to persist its state. The multistore is a store of `KVStores` that follows the `Multistore` interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L104-L133 - -If tracing is enabled, then branching the multistore will firstly wrap all the underlying `KVStore` in [`TraceKv.Store`](#tracekv-store). - -### CommitMultiStore - -The main type of `Multistore` used in the Cosmos SDK is `CommitMultiStore`, which is an extension of the `Multistore` interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L141-L184 - -As for concrete implementation, the [`rootMulti.Store`] is the go-to implementation of the `CommitMultiStore` interface. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/rootmulti/store.go#L43-L61 - -The `rootMulti.Store` is a base-layer multistore built around a `db` on top of which multiple `KVStores` can be mounted, and is the default multistore store used in [`baseapp`](./baseapp.md). - -### CacheMultiStore - -Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/master/store/cachemulti/store.go) is used. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/cachemulti/store.go#L17-L28 - -`cachemulti.Store` branches all substores (creates a virtual store for each substore) in its constructor and hold them in `Store.stores`. Moreover cachese all read queries. `Store.GetKVStore()` returns the store from `Store.stores`, and `Store.Write()` recursively calls `CacheWrap.Write()` on all the substores. - -## Base-layer KVStores - -### `KVStore` and `CommitKVStore` Interfaces - -A `KVStore` is a simple key-value store used to store and retrieve data. A `CommitKVStore` is a `KVStore` that also implements a `Committer`. By default, stores mounted in `baseapp`'s main `CommitMultiStore` are `CommitKVStore`s. The `KVStore` interface is primarily used to restrict modules from accessing the committer. - -Individual `KVStore`s are used by modules to manage a subset of the global state. `KVStores` can be accessed by objects that hold a specific key. This `key` should only be exposed to the [`keeper`](../building-modules/keeper.md) of the module that defines the store. - -`CommitKVStore`s are declared by proxy of their respective `key` and mounted on the application's [multistore](#multistore) in the [main application file](../basics/app-anatomy.md#core-application-file). In the same file, the `key` is also passed to the module's `keeper` that is responsible for managing the store. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/store.go#L189-L219 - -Apart from the traditional `Get` and `Set` methods, a `KVStore` must provide an `Iterator(start, end)` method which returns an `Iterator` object. It is used to iterate over a range of keys, typically keys that share a common prefix. Below is an example from the bank's module keeper, used to iterate over all account balances: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/keeper/view.go#L115-L134 - -### `IAVL` Store - -The default implementation of `KVStore` and `CommitKVStore` used in `baseapp` is the `iavl.Store`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/iavl/store.go#L37-L40 - -`iavl` stores are based around an [IAVL Tree](https://github.com/tendermint/iavl), a self-balancing binary tree which guarantees that: - -- `Get` and `Set` operations are O(log n), where n is the number of elements in the tree. -- Iteration efficiently returns the sorted elements within the range. -- Each tree version is immutable and can be retrieved even after a commit (depending on the pruning settings). - -The documentation on the IAVL Tree is located [here](https://github.com/cosmos/iavl/blob/v0.15.0-rc5/docs/overview.md). - -### `DbAdapter` Store - -`dbadapter.Store` is a adapter for `dbm.DB` making it fulfilling the `KVStore` interface. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/dbadapter/store.go#L13-L16 - -`dbadapter.Store` embeds `dbm.DB`, meaning most of the `KVStore` interface functions are implemented. The other functions (mostly miscellaneous) are manually implemented. This store is primarily used within [Transient Stores](#transient-stores) - -### `Transient` Store - -`Transient.Store` is a base-layer `KVStore` which is automatically discarded at the end of the block. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/transient/store.go#L13-L16 - -`Transient.Store` is a `dbadapter.Store` with a `dbm.NewMemDB()`. All `KVStore` methods are reused. When `Store.Commit()` is called, a new `dbadapter.Store` is assigned, discarding previous reference and making it garbage collected. - -This type of store is useful to persist information that is only relevant per-block. One example would be to store parameter changes (i.e. a bool set to `true` if a parameter changed in a block). - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/params/types/subspace.go#L20-L30 - -Transient stores are typically accessed via the [`context`](./context.md) via the `TransientStore()` method: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/context.go#L232-L235 - -## KVStore Wrappers - -### CacheKVStore - -`cachekv.Store` is a wrapper `KVStore` which provides buffered writing / cached reading functionalities over the underlying `KVStore`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/cachekv/store.go#L27-L34 - -This is the type used whenever an IAVL Store needs to be branched to create an isolated store (typically when we need to mutate a state that might be reverted later). - -#### `Get` - -`Store.Get()` firstly checks if `Store.cache` has an associated value with the key. If the value exists, the function returns it. If not, the function calls `Store.parent.Get()`, caches the result in `Store.cache`, and returns it. - -#### `Set` - -`Store.Set()` sets the key-value pair to the `Store.cache`. `cValue` has the field dirty bool which indicates whether the cached value is different from the underlying value. When `Store.Set()` cachees a new pair, the `cValue.dirty` is set `true` so when `Store.Write()` is called it can be written to the underlying store. - -#### `Iterator` - -`Store.Iterator()` have to traverse on both cached items and the original items. In `Store.iterator()`, two iterators are generated for each of them, and merged. `memIterator` is essentially a slice of the `KVPairs`, used for cached items. `mergeIterator` is a combination of two iterators, where traverse happens ordered on both iterators. - -### `GasKv` Store - -Cosmos SDK applications use [`gas`](../basics/gas-fees.md) to track resources usage and prevent spam. [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/gaskv/store.go) is a `KVStore` wrapper that enables automatic gas consumption each time a read or write to the store is made. It is the solution of choice to track storage usage in Cosmos SDK applications. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/gaskv/store.go#L13-L19 - -When methods of the parent `KVStore` are called, `GasKv.Store` automatically consumes appropriate amount of gas depending on the `Store.gasConfig`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/gas.go#L153-L162 - -By default, all `KVStores` are wrapped in `GasKv.Stores` when retrieved. This is done in the `KVStore()` method of the [`context`](./context.md): - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/context.go#L227-L230 - -In this case, the default gas configuration is used: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/types/gas.go#L164-L175 - -### `TraceKv` Store - -`tracekv.Store` is a wrapper `KVStore` which provides operation tracing functionalities over the underlying `KVStore`. It is applied automatically by the Cosmos SDK on all `KVStore` if tracing is enabled on the parent `MultiStore`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/tracekv/store.go#L20-L43 - -When each `KVStore` methods are called, `tracekv.Store` automatically logs `traceOperation` to the `Store.writer`. `traceOperation.Metadata` is filled with `Store.context` when it is not nil. `TraceContext` is a `map[string]interface{}`. - -### `Prefix` Store - -`prefix.Store` is a wrapper `KVStore` which provides automatic key-prefixing functionalities over the underlying `KVStore`. - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/prefix/store.go#L15-L21 - -When `Store.{Get, Set}()` is called, the store forwards the call to its parent, with the key prefixed with the `Store.prefix`. - -When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`, since it does not work as intended. In that case, some of the elements are traversed even they are not starting with the prefix. - -## Next {hide} - -Learn about [encoding](./encoding.md) {hide} diff --git a/docs/core/telemetry.md b/docs/core/telemetry.md deleted file mode 100644 index 9e434eef2b..0000000000 --- a/docs/core/telemetry.md +++ /dev/null @@ -1,145 +0,0 @@ - - -# Telemetry - -Gather relevant insights about your application and modules with custom metrics and telemetry. {synopsis} - -The Cosmos SDK enables operators and developers to gain insight into the performance and behavior of -their application through the use of the `telemetry` package. The Cosmos SDK currently supports -enabling in-memory and prometheus as telemetry sinks. This allows the ability to query for and scrape -metrics from a single exposed API endpoint -- `/metrics?format={text|prometheus}`, the default being -`text`. - -If telemetry is enabled via configuration, a single global metrics collector is registered via the -[go-metrics](https://github.com/armon/go-metrics) library. This allows emitting and collecting -metrics through simple API calls. - -Example: - -```go -func EndBlocker(ctx sdk.Context, k keeper.Keeper) { - defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), telemetry.MetricKeyEndBlocker) - - // ... -} -``` - -Developers may use the `telemetry` package directly, which provides wrappers around metric APIs -that include adding useful labels, or they must use the `go-metrics` library directly. It is preferable -to add as much context and adequate dimensionality to metrics as possible, so the `telemetry` package -is advised. Regardless of the package or method used, the Cosmos SDK supports the following metrics -types: - -* gauges -* summaries -* counters - -## Labels - -Certain components of modules will have their name automatically added as a label (e.g. `BeginBlock`). -Operators may also supply the application with a global set of labels that will be applied to all -metrics emitted using the `telemetry` package (e.g. chain-id). Global labels are supplied as a list -of [name, value] tuples. - -Example: - -```toml -global-labels = [ - ["chain_id", "chain-OfXo4V"], -] -``` - -## Cardinality - -Cardinality is key, specifically label and key cardinality. Cardinality is how many unique values of -something there are. So there is naturally a tradeoff between granularity and how much stress is put -on the telemetry sink in terms of indexing, scrape, and query performance. - -Developers should take care to support metrics with enough dimensionality and granularity to be -useful, but not increase the cardinality beyond the sink's limits. A general rule of thumb is to not -exceed a cardinality of 10. - -Consider the following examples with enough granularity and adequate cardinality: - -* begin/end blocker time -* tx gas used -* block gas used -* amount of tokens minted -* amount of accounts created - -The following examples expose too much cardinality and may not even prove to be useful: - -* transfers between accounts with amount -* voting/deposit amount from unique addresses - -## Supported Metrics - -| Metric | Description | Unit | Type | -|:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------| -| `tx_count` | Total number of txs processed via `DeliverTx` | tx | counter | -| `tx_successful` | Total number of successful txs processed via `DeliverTx` | tx | counter | -| `tx_failed` | Total number of failed txs processed via `DeliverTx` | tx | counter | -| `tx_gas_used` | The total amount of gas used by a tx | gas | gauge | -| `tx_gas_wanted` | The total amount of gas requested by a tx | gas | gauge | -| `tx_msg_send` | The total amount of tokens sent in a `MsgSend` (per denom) | token | gauge | -| `tx_msg_withdraw_reward` | The total amount of tokens withdrawn in a `MsgWithdrawDelegatorReward` (per denom) | token | gauge | -| `tx_msg_withdraw_commission` | The total amount of tokens withdrawn in a `MsgWithdrawValidatorCommission` (per denom) | token | gauge | -| `tx_msg_delegate` | The total amount of tokens delegated in a `MsgDelegate` | token | gauge | -| `tx_msg_begin_unbonding` | The total amount of tokens undelegated in a `MsgUndelegate` | token | gauge | -| `tx_msg_begin_begin_redelegate` | The total amount of tokens redelegated in a `MsgBeginRedelegate` | token | gauge | -| `tx_msg_ibc_transfer` | The total amount of tokens transferred via IBC in a `MsgTransfer` (source or sink chain) | token | gauge | -| `ibc_transfer_packet_receive` | The total amount of tokens received in a `FungibleTokenPacketData` (source or sink chain) | token | gauge | -| `new_account` | Total number of new accounts created | account | counter | -| `gov_proposal` | Total number of governance proposals | proposal | counter | -| `gov_vote` | Total number of governance votes for a proposal | vote | counter | -| `gov_deposit` | Total number of governance deposits for a proposal | deposit | counter | -| `staking_delegate` | Total number of delegations | delegation | counter | -| `staking_undelegate` | Total number of undelegations | undelegation | counter | -| `staking_redelegate` | Total number of redelegations | redelegation | counter | -| `ibc_transfer_send` | Total number of IBC transfers sent from a chain (source or sink) | transfer | counter | -| `ibc_transfer_receive` | Total number of IBC transfers received to a chain (source or sink) | transfer | counter | -| `ibc_client_create` | Total number of clients created | create | counter | -| `ibc_client_update` | Total number of client updates | update | counter | -| `ibc_client_upgrade` | Total number of client upgrades | upgrade | counter | -| `ibc_client_misbehaviour` | Total number of client misbehaviours | misbehaviour | counter | -| `ibc_connection_open-init` | Total number of connection `OpenInit` handshakes | handshake | counter | -| `ibc_connection_open-try` | Total number of connection `OpenTry` handshakes | handshake | counter | -| `ibc_connection_open-ack` | Total number of connection `OpenAck` handshakes | handshake | counter | -| `ibc_connection_open-confirm` | Total number of connection `OpenConfirm` handshakes | handshake | counter | -| `ibc_channel_open-init` | Total number of channel `OpenInit` handshakes | handshake | counter | -| `ibc_channel_open-try` | Total number of channel `OpenTry` handshakes | handshake | counter | -| `ibc_channel_open-ack` | Total number of channel `OpenAck` handshakes | handshake | counter | -| `ibc_channel_open-confirm` | Total number of channel `OpenConfirm` handshakes | handshake | counter | -| `ibc_channel_close-init` | Total number of channel `CloseInit` handshakes | handshake | counter | -| `ibc_channel_close-confirm` | Total number of channel `CloseConfirm` handshakes | handshake | counter | -| `tx_msg_ibc_recv_packet` | Total number of IBC packets received | packet | counter | -| `tx_msg_ibc_acknowledge_packet` | Total number of IBC packets acknowledged | acknowledgement | counter | -| `ibc_timeout_packet` | Total number of IBC timeout packets | timeout | counter | -| `abci_check_tx` | Duration of ABCI `CheckTx` | ms | summary | -| `abci_deliver_tx` | Duration of ABCI `DeliverTx` | ms | summary | -| `abci_commit` | Duration of ABCI `Commit` | ms | summary | -| `abci_query` | Duration of ABCI `Query` | ms | summary | -| `abci_begin_block` | Duration of ABCI `BeginBlock` | ms | summary | -| `abci_end_block` | Duration of ABCI `EndBlock` | ms | summary | -| `begin_blocker` | Duration of `BeginBlock` for a given module | ms | summary | -| `end_blocker` | Duration of `EndBlock` for a given module | ms | summary | -| `store_iavl_get` | Duration of an IAVL `Store#Get` call | ms | summary | -| `store_iavl_set` | Duration of an IAVL `Store#Set` call | ms | summary | -| `store_iavl_has` | Duration of an IAVL `Store#Has` call | ms | summary | -| `store_iavl_delete` | Duration of an IAVL `Store#Delete` call | ms | summary | -| `store_iavl_commit` | Duration of an IAVL `Store#Commit` call | ms | summary | -| `store_iavl_query` | Duration of an IAVL `Store#Query` call | ms | summary | -| `store_gaskv_get` | Duration of a GasKV `Store#Get` call | ms | summary | -| `store_gaskv_set` | Duration of a GasKV `Store#Set` call | ms | summary | -| `store_gaskv_has` | Duration of a GasKV `Store#Has` call | ms | summary | -| `store_gaskv_delete` | Duration of a GasKV `Store#Delete` call | ms | summary | -| `store_cachekv_get` | Duration of a CacheKV `Store#Get` call | ms | summary | -| `store_cachekv_set` | Duration of a CacheKV `Store#Set` call | ms | summary | -| `store_cachekv_write` | Duration of a CacheKV `Store#Write` call | ms | summary | -| `store_cachekv_delete` | Duration of a CacheKV `Store#Delete` call | ms | summary | - -## Next {hide} - -Learn about the [object-capability](./ocap.md) model {hide} diff --git a/docs/core/transactions.md b/docs/core/transactions.md deleted file mode 100644 index e9407c7529..0000000000 --- a/docs/core/transactions.md +++ /dev/null @@ -1,158 +0,0 @@ - - -# Transactions - -`Transactions` are objects created by end-users to trigger state changes in the application. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq} - -## Transactions - -Transactions are comprised of metadata held in [contexts](./context.md) and [`Msg`s](../building-modules/messages-and-queries.md) that trigger state changes within a module through the module's [`Msg` service](../building-modules/msg-services.md). - -When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Each of a transaction's `Msg`s must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A transaction must then be included in a block, validated, and approved by the network through the consensus process. To read more about the lifecycle of a transaction, click [here](../basics/tx-lifecycle.md). - -## Type Definition - -Transaction objects are SDK types that implement the `Tx` interface - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/types/tx_msg.go#L49-L57 - -It contains the following methods: - -- **GetMsgs:** unwraps the transaction and returns a list of its `Msg`s - one transaction may have one or multiple [`Msg`s](../building-modules/messages-and-queries.md#messages), which are defined by module developers. -- **ValidateBasic:** includes lightweight, [_stateless_](../basics/tx-lifecycle.md#types-of-checks) checks used by ABCI messages [`CheckTx`](./baseapp.md#checktx) and [`DeliverTx`](./baseapp.md#delivertx) to make sure transactions are not invalid. For example, the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth) module's `StdTx` `ValidateBasic` function checks that its transactions are signed by the correct number of signers and that the fees do not exceed what the user's maximum. Note that this function is to be distinct from the `ValidateBasic` functions for `Msg`s, which perform basic validity checks on messages only. For example, when [`runTx`](./baseapp.md#runtx) is checking a transaction created from the [`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec) module, it first runs `ValidateBasic` on each message, then runs the `auth` module AnteHandler which calls `ValidateBasic` for the transaction itself. - -As a developer, you should rarely manipulate `Tx` directly, as `Tx` is really an intermediate type used for transaction generation. Instead, developers should prefer the `TxBuilder` interface, which you can learn more about [below](#transaction-generation). - -### Signing Transactions - -Every message in a transaction must be signed by the addresses specified by its `GetSigners`. The SDK currently allows signing transactions in two different ways. - -#### `SIGN_MODE_DIRECT` (preferred) - -The most used implementation of the `Tx` interface is the Protobuf `Tx` message, which is used in `SIGN_MODE_DIRECT`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L12-L25 - -Because Protobuf serialization is not deterministic, the SDK uses an additional `TxRaw` type to denote the pinned bytes over which a transaction is signed. Any user can generate a valid `body` and `auth_info` for a transaction, and serialize these two messages using Protobuf. `TxRaw` then pins the user's exact binary representation of `body` and `auth_info`, called respectively `body_bytes` and `auth_info_bytes`. The document that is signed by all signers of the transaction is `SignDoc` (deterministically serialized using [ADR-027](../architecture/adr-027-deterministic-protobuf-serialization.md)): - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/tx.proto#L47-L64 - -Once signed by all signers, the `body_bytes`, `auth_info_bytes` and `signatures` are gathered into `TxRaw`, whose serialized bytes are broadcasted over the network. - -#### `SIGN_MODE_LEGACY_AMINO_JSON` - -The legacy implemention of the `Tx` interface is the `StdTx` struct from `x/auth`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdtx.go#L120-L130 - -The document signed by all signers is `StdSignDoc`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdsign.go#L20-L33 - -which is encoded into bytes using Amino JSON. Once all signatures are gathered into `StdTx`, `StdTx` is serialized using Amino JSON, and these bytes are broadcasted over the network. - -#### Other Sign Modes - -Other sign modes, most notably `SIGN_MODE_TEXTUAL`, are being discussed. If you wish to learn more about them, please refer to [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md). - -## Transaction Process - -The process of an end-user sending a transaction is: - -- decide on the messages to put into the transaction, -- generate the transaction using the SDK's `TxBuilder`, -- broadcast the transaction using one of the available interfaces. - -The next paragraphs will describe each of these components, in this order. - -### Messages - -::: tip -Module `Msg`s are not to be confused with [ABCI Messages](https://tendermint.com/docs/spec/abci/abci.html#messages) which define interactions between the Tendermint and application layers. -::: - -**Messages** (or `Msg`s) are module-specific objects that trigger state transitions within the scope of the module they belong to. Module developers define the messages for their module by adding methods to the Protobuf [`Msg` service](../building-modules/msg-services.md), and also implement the corresponding `MsgServer`. - -`Msg`s in a module are defined as methods in the [`Msg` service] inside each module's `tx.proto` file. Since `Msg`s are module-specific, each module needs a to process all of its message types and trigger state changes within the module's scope. This design puts more responsibility on module developers, allowing application developers to reuse common functionalities without having to implement state transition logic repetitively. To achieve this, Protobuf generates a `MsgServer` interface for each module, and the module developer needs to implement this interface. The methods on the `MsgServer` interface corresponds on how to handle each of the different `Msg`. - -To learn more about `Msg` services and how to implement `MsgServer`, click [here](../building-modules/msg-services.md). - -While messages contain the information for state transition logic, a transaction's other metadata and relevant information are stored in the `TxBuilder` and `Context`. - -### Transaction Generation - -The `TxBuilder` interface contains data closely related with the generation of transactions, which an end-user can freely set to generate the desired transaction: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/client/tx_config.go#L32-L45 - -- `Msg`s, the array of [messages](#messages) included in the transaction. -- `GasLimit`, option chosen by the users for how to calculate how much gas they will need to pay. -- `Memo`, to send with the transaction. -- `FeeAmount`, the maximum amount the user is willing to pay in fees. -- `TimeoutHeight`, block height until which the transaction is valid. -- `Signatures`, the array of signatures from all signers of the transaction. - -As there are currently two sign modes for signing transactions, there are also two implementations of `TxBuilder`: - -- [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/tx/builder.go#L19-L33) for creating transactions for `SIGN_MODE_DIRECT`, -- [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdtx_builder.go#L14-L20) for `SIGN_MODE_LEGACY_AMINO_JSON`. - -However, the two implementation of `TxBuilder` should be hidden away from end-users, as they should prefer using the overarching `TxConfig` interface: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/client/tx_config.go#L21-L30 - -`TxConfig` is an app-wide configuration for managing transactions. Most importantly, it holds the information about whether to sign each transaction with `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`. By calling `txBuilder := txConfig.NewTxBuilder()`, a new `TxBuilder` will be created with the appropriate sign mode. - -Once `TxBuilder` is correctly populated with the setters exposed above, `TxConfig` will also take care of correctly encoding the bytes (again, either using `SIGN_MODE_DIRECT` or `SIGN_MODE_LEGACY_AMINO_JSON`). Here's a pseudo-code snippet of how to generate and encode a transaction, using the `TxEncoder()` method: - -```go -txBuilder := txConfig.NewTxBuilder() -txBuilder.SetMsgs(...) // and other setters on txBuilder - -bz, err := txConfig.TxEncoder()(txBuilder.GetTx()) -// bz are bytes to be broadcasted over the network -``` - -### Broadcasting the Transaction - -Once the transaction bytes are generated, there are currently three ways of broadcasting it. - -#### CLI - -Application developers create entrypoints to the application by creating a [command-line interface](../interfaces/cli.md) and/or [REST interface](../interfaces/rest.md), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. - -For the [command-line interface](../building-modules/module-interfaces.md#cli), module developers create subcommands to add as children to the application top-level transaction command `TxCmd`. CLI commands actually bundle all the steps of transaction processing into one simple command: creating messages, generating transactions and broadcasting. For concrete examples, see the [Interacting with a Node](../run-node/interact-node.md) section. An example transaction made using CLI looks like: - -```bash -simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake -``` - -#### gRPC - -[gRPC](https://grpc.io) is introduced in Cosmos SDK 0.40 as the main component for the SDK's RPC layer. The principal usage of gRPC is in the context of modules' [`Query` services](../building-modules). However, the SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/tx/v1beta1/service.proto - -The `Tx` service exposes a handful of utility functions, such as simulating a transaction or querying a transaction, and also one method to broadcast transactions. - -Examples of broadcasting and simulating a transaction are shown [here](../run-node/txs.md#programmatically-with-go). - -#### REST - -Each gRPC method has its corresponding REST endpoint, generated using [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway). Therefore, instead of using gRPC, you can also use HTTP to broadcast the same transaction, on the `POST /lbm/tx/v1beta1/txs` endpoint. - -An example can be seen [here](../run-node/txs.md#using-rest) - -#### Tendermint RPC - -The three methods presented above are actually higher abstractions over the Tendermint RPC `/broadcast_tx_{async,sync,commit}` endpoints, documented [here](https://docs.tendermint.com/master/rpc/#/Tx). This means that you can use the Tendermint RPC endpoints directly to broadcast the transaction, if you wish so. - -## Next {hide} - -Learn about the [context](./context.md) {hide} diff --git a/docs/cosmos-sdk-image.jpg b/docs/cosmos-sdk-image.jpg deleted file mode 100755 index 9d8219317f..0000000000 Binary files a/docs/cosmos-sdk-image.jpg and /dev/null differ diff --git a/docs/ibc/README.md b/docs/ibc/README.md deleted file mode 100644 index 22061db945..0000000000 --- a/docs/ibc/README.md +++ /dev/null @@ -1,17 +0,0 @@ - - -# IBC - -This repository contains reference documentation for the IBC protocol integration and concepts: - -1. [Overview](./overview.md) -2. [Integration](./integration.md) -3. [Customization](./custom.md) -4. [Relayer](./relayer.md) - -After reading about IBC, head on to the [Building Modules -documentation](../building-modules/README.md) to learn more about the process of building modules. diff --git a/docs/ibc/custom.md b/docs/ibc/custom.md deleted file mode 100644 index 4d4c30c0ff..0000000000 --- a/docs/ibc/custom.md +++ /dev/null @@ -1,468 +0,0 @@ - - -# Customization - -Learn how to configure your application to use IBC and send data packets to other chains. {synopsis} - -This document serves as a guide for developers who want to write their own Inter-blockchain -Communication Protocol (IBC) applications for custom [use-cases](https://github.com/cosmos/ics/blob/master/ibc/4_IBC_USECASES.md). - -Due to the modular design of the IBC protocol, IBC -application developers do not need to concern themselves with the low-level details of clients, -connections, and proof verification. Nevertheless a brief explanation of the lower levels of the -stack is given so that application developers may have a high-level understanding of the IBC -protocol. Then the document goes into detail on the abstraction layer most relevant for application -developers (channels and ports), and describes how to define your own custom packets, and -`IBCModule` callbacks. - -To have your module interact over IBC you must: bind to a port(s), define your own packet data and acknolwedgement structs as well as how to encode/decode them, and implement the -`IBCModule` interface. Below is a more detailed explanation of how to write an IBC application -module correctly. - -## Pre-requisites Readings - -- [IBC Overview](./overview.md)) {prereq} -- [IBC default integration](./integration.md) {prereq} - -## Create a custom IBC application module - -### Implement `IBCModule` Interface and callbacks - -The Cosmos SDK expects all IBC modules to implement the [`IBCModule` -interface](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/05-port/types/module.go). This -interface contains all of the callbacks IBC expects modules to implement. This section will describe -the callbacks that are called during channel handshake execution. - -Here are the channel handshake callbacks that modules are expected to implement: - -```go -// Called by IBC Handler on MsgOpenInit -func (k Keeper) OnChanOpenInit(ctx sdk.Context, - order channeltypes.Order, - connectionHops []string, - portID string, - channelID string, - channelCap *capabilitytypes.Capability, - counterparty channeltypes.Counterparty, - version string, -) error { - // OpenInit must claim the channelCapability that IBC passes into the callback - if err := k.ClaimCapability(ctx, chanCap, host.ChannelCapabilityPath(portID, channelID)); err != nil { - return err - } - - // ... do custom initialization logic - - // Use above arguments to determine if we want to abort handshake - // Examples: Abort if order == UNORDERED, - // Abort if version is unsupported - err := checkArguments(args) - return err -} - -// Called by IBC Handler on MsgOpenTry -OnChanOpenTry( - ctx sdk.Context, - order channeltypes.Order, - connectionHops []string, - portID, - channelID string, - channelCap *capabilitytypes.Capability, - counterparty channeltypes.Counterparty, - version, - counterpartyVersion string, -) error { - // Module may have already claimed capability in OnChanOpenInit in the case of crossing hellos - // (ie chainA and chainB both call ChanOpenInit before one of them calls ChanOpenTry) - // If the module can already authenticate the capability then the module already owns it so we don't need to claim - // Otherwise, module does not have channel capability and we must claim it from IBC - if !k.AuthenticateCapability(ctx, chanCap, host.ChannelCapabilityPath(portID, channelID)) { - // Only claim channel capability passed back by IBC module if we do not already own it - if err := k.scopedKeeper.ClaimCapability(ctx, chanCap, host.ChannelCapabilityPath(portID, channelID)); err != nil { - return err - } - } - - // ... do custom initialization logic - - // Use above arguments to determine if we want to abort handshake - err := checkArguments(args) - return err -} - -// Called by IBC Handler on MsgOpenAck -OnChanOpenAck( - ctx sdk.Context, - portID, - channelID string, - counterpartyVersion string, -) error { - // ... do custom initialization logic - - // Use above arguments to determine if we want to abort handshake - err := checkArguments(args) - return err -} - -// Called by IBC Handler on MsgOpenConfirm -OnChanOpenConfirm( - ctx sdk.Context, - portID, - channelID string, -) error { - // ... do custom initialization logic - - // Use above arguments to determine if we want to abort handshake - err := checkArguments(args) - return err -} -``` - -The channel closing handshake will also invoke module callbacks that can return errors to abort the -closing handshake. Closing a channel is a 2-step handshake, the initiating chain calls -`ChanCloseInit` and the finalizing chain calls `ChanCloseConfirm`. - -```go -// Called by IBC Handler on MsgCloseInit -OnChanCloseInit( - ctx sdk.Context, - portID, - channelID string, -) error { - // ... do custom finalization logic - - // Use above arguments to determine if we want to abort handshake - err := checkArguments(args) - return err -} - -// Called by IBC Handler on MsgCloseConfirm -OnChanCloseConfirm( - ctx sdk.Context, - portID, - channelID string, -) error { - // ... do custom finalization logic - - // Use above arguments to determine if we want to abort handshake - err := checkArguments(args) - return err -} -``` - -#### Channel Handshake Version Negotiation - -Application modules are expected to verify versioning used during the channel handshake procedure. - -* `ChanOpenInit` callback should verify that the `MsgChanOpenInit.Version` is valid -* `ChanOpenTry` callback should verify that the `MsgChanOpenTry.Version` is valid and that `MsgChanOpenTry.CounterpartyVersion` is valid. -* `ChanOpenAck` callback should verify that the `MsgChanOpenAck.CounterpartyVersion` is valid and supported. - -Versions must be strings but can implement any versioning structure. If your application plans to -have linear releases then semantic versioning is recommended. If your application plans to release -various features in between major releases then it is advised to use the same versioning scheme -as IBC. This versioning scheme specifies a version identifier and compatible feature set with -that identifier. Valid version selection includes selecting a compatible version identifier with -a subset of features supported by your application for that version. The struct is used for this -scheme can be found in `03-connection/types`. - -Since the version type is a string, applications have the ability to do simple version verification -via string matching or they can use the already impelemented versioning system and pass the proto -encoded version into each handhshake call as necessary. - -ICS20 currently implements basic string matching with a single supported version. - -### Bind Ports - -Currently, ports must be bound on app initialization. A module may bind to ports in `InitGenesis` -like so: - -```go -func InitGenesis(ctx sdk.Context, keeper keeper.Keeper, state types.GenesisState) { - // ... other initialization logic - - // Only try to bind to port if it is not already bound, since we may already own - // port capability from capability InitGenesis - if !isBound(ctx, state.PortID) { - // module binds to desired ports on InitChain - // and claims returned capabilities - cap1 := keeper.IBCPortKeeper.BindPort(ctx, port1) - cap2 := keeper.IBCPortKeeper.BindPort(ctx, port2) - cap3 := keeper.IBCPortKeeper.BindPort(ctx, port3) - - // NOTE: The module's scoped capability keeper must be private - keeper.scopedKeeper.ClaimCapability(cap1) - keeper.scopedKeeper.ClaimCapability(cap2) - keeper.scopedKeeper.ClaimCapability(cap3) - } - - // ... more initialization logic -} -``` - -### Custom Packets - -Modules connected by a channel must agree on what application data they are sending over the -channel, as well as how they will encode/decode it. This process is not specified by IBC as it is up -to each application module to determine how to implement this agreement. However, for most -applications this will happen as a version negotiation during the channel handshake. While more -complex version negotiation is possible to implement inside the channel opening handshake, a very -simple version negotation is implemented in the [ibc-transfer module](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc-transfer/module.go). - -Thus, a module must define its a custom packet data structure, along with a well-defined way to -encode and decode it to and from `[]byte`. - -```go -// Custom packet data defined in application module -type CustomPacketData struct { - // Custom fields ... -} - -EncodePacketData(packetData CustomPacketData) []byte { - // encode packetData to bytes -} - -DecodePacketData(encoded []byte) (CustomPacketData) { - // decode from bytes to packet data -} -``` - -Then a module must encode its packet data before sending it through IBC. - -```go -// Sending custom application packet data -data := EncodePacketData(customPacketData) -packet.Data = data -IBCChannelKeeper.SendPacket(ctx, packet) -``` - -A module receiving a packet must decode the `PacketData` into a structure it expects so that it can -act on it. - -```go -// Receiving custom application packet data (in OnRecvPacket) -packetData := DecodePacketData(packet.Data) -// handle received custom packet data -``` - -#### Packet Flow Handling - -Just as IBC expected modules to implement callbacks for channel handshakes, IBC also expects modules -to implement callbacks for handling the packet flow through a channel. - -Once a module A and module B are connected to each other, relayers can start relaying packets and -acknowledgements back and forth on the channel. - -![IBC packet flow diagram](https://media.githubusercontent.com/media/cosmos/ics/master/spec/ics-004-channel-and-packet-semantics/packet-state-machine.png) - -Briefly, a successful packet flow works as follows: - -1. module A sends a packet through the IBC module -2. the packet is received by module B -3. if module B writes an acknowledgement of the packet then module A will process the - acknowledgement -4. if the packet is not successfully received before the timeout, then module A processes the - packet's timeout. - -##### Sending Packets - -Modules do not send packets through callbacks, since the modules initiate the action of sending -packets to the IBC module, as opposed to other parts of the packet flow where msgs sent to the IBC -module must trigger execution on the port-bound module through the use of callbacks. Thus, to send a -packet a module simply needs to call `SendPacket` on the `IBCChannelKeeper`. - -```go -// retrieve the dynamic capability for this channel -channelCap := scopedKeeper.GetCapability(ctx, channelCapName) -// Sending custom application packet data -data := EncodePacketData(customPacketData) -packet.Data = data -// Send packet to IBC, authenticating with channelCap -IBCChannelKeeper.SendPacket(ctx, channelCap, packet) -``` - -::: warning -In order to prevent modules from sending packets on channels they do not own, IBC expects -modules to pass in the correct channel capability for the packet's source channel. -::: - -##### Receiving Packets - -To handle receiving packets, the module must implement the `OnRecvPacket` callback. This gets -invoked by the IBC module after the packet has been proved valid and correctly processed by the IBC -keepers. Thus, the `OnRecvPacket` callback only needs to worry about making the appropriate state -changes given the packet data without worrying about whether the packet is valid or not. - -Modules may return an acknowledgement as a byte string and return it to the IBC handler. -The IBC handler will then commit this acknowledgement of the packet so that a relayer may relay the -acknowledgement back to the sender module. - -```go -OnRecvPacket( - ctx sdk.Context, - packet channeltypes.Packet, -) (res *sdk.Result, ack []byte, abort error) { - // Decode the packet data - packetData := DecodePacketData(packet.Data) - - // do application state changes based on packet data - // and return result, acknowledgement and abortErr - // Note: abortErr is only not nil if we need to abort the entire receive packet, and allow a replay of the receive. - // If the application state change failed but we do not want to replay the packet, - // simply encode this failure with relevant information in ack and return nil error - res, ack, abortErr := processPacket(ctx, packet, packetData) - - // if we need to abort the entire receive packet, return error - if abortErr != nil { - return nil, nil, abortErr - } - - // Encode the ack since IBC expects acknowledgement bytes - ackBytes := EncodeAcknowledgement(ack) - - return res, ackBytes, nil -} -``` - -::: warning -`OnRecvPacket` should **only** return an error if we want the entire receive packet execution -(including the IBC handling) to be reverted. This will allow the packet to be replayed in the case -that some mistake in the relaying caused the packet processing to fail. - -If some application-level error happened while processing the packet data, in most cases, we will -not want the packet processing to revert. Instead, we may want to encode this failure into the -acknowledgement and finish processing the packet. This will ensure the packet cannot be replayed, -and will also allow the sender module to potentially remediate the situation upon receiving the -acknowledgement. An example of this technique is in the `ibc-transfer` module's -[`OnRecvPacket`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc-transfer/module.go). -::: - -### Acknowledgements - -Modules may commit an acknowledgement upon receiving and processing a packet in the case of synchronous packet processing. -In the case where a packet is processed at some later point after the packet has been received (asynchronous execution), the acknowledgement -will be written once the packet has been processed by the application which may be well after the packet receipt. - -NOTE: Most blockchain modules will want to use the synchronous execution model in which the module processes and writes the acknowledgement -for a packet as soon as it has been received from the IBC module. - -This acknowledgement can then be relayed back to the original sender chain, which can take action -depending on the contents of the acknowledgement. - -Just as packet data was opaque to IBC, acknowledgements are similarly opaque. Modules must pass and -receive acknowledegments with the IBC modules as byte strings. - -Thus, modules must agree on how to encode/decode acknowledgements. The process of creating an -acknowledgement struct along with encoding and decoding it, is very similar to the packet data -example above. [ICS 04](https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics#acknowledgement-envelope) -specifies a recommended format for acknowledgements. This acknowledgement type can be imported from -[channel types](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel/types). - -While modules may choose arbitrary acknowledgement structs, a default acknowledgement types is provided by IBC [here](https://github.com/cosmos/cosmos-sdk/blob/master/proto/ibc/core/channel/v1/channel.proto): - -```proto -// Acknowledgement is the recommended acknowledgement format to be used by -// app-specific protocols. -// NOTE: The field numbers 21 and 22 were explicitly chosen to avoid accidental -// conflicts with other protobuf message formats used for acknowledgements. -// The first byte of any message with this format will be the non-ASCII values -// `0xaa` (result) or `0xb2` (error). Implemented as defined by ICS: -// https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics#acknowledgement-envelope -message Acknowledgement { - // response contains either a result or an error and must be non-empty - oneof response { - bytes result = 21; - string error = 22; - } -} -``` - -#### Acknowledging Packets - -After a module writes an acknowledgement, a relayer can relay back the acknowledgement to the sender module. The sender module can -then process the acknowledgement using the `OnAcknowledgementPacket` callback. The contents of the -acknowledgement is entirely upto the modules on the channel (just like the packet data); however, it -may often contain information on whether the packet was successfully processed along -with some additional data that could be useful for remediation if the packet processing failed. - -Since the modules are responsible for agreeing on an encoding/decoding standard for packet data and -acknowledgements, IBC will pass in the acknowledgements as `[]byte` to this callback. The callback -is responsible for decoding the acknowledgement and processing it. - -```go -OnAcknowledgementPacket( - ctx sdk.Context, - packet channeltypes.Packet, - acknowledgement []byte, -) (*sdk.Result, error) { - // Decode acknowledgement - ack := DecodeAcknowledgement(acknowledgement) - - // process ack - res, err := processAck(ack) - return res, err -} -``` - -#### Timeout Packets - -If the timeout for a packet is reached before the packet is successfully received or the -counterparty channel end is closed before the packet is successfully received, then the receiving -chain can no longer process it. Thus, the sending chain must process the timeout using -`OnTimeoutPacket` to handle this situation. Again the IBC module will verify that the timeout is -indeed valid, so our module only needs to implement the state machine logic for what to do once a -timeout is reached and the packet can no longer be received. - -```go -OnTimeoutPacket( - ctx sdk.Context, - packet channeltypes.Packet, -) (*sdk.Result, error) { - // do custom timeout logic -} -``` - -### Routing - -As mentioned above, modules must implement the IBC module interface (which contains both channel -handshake callbacks and packet handling callbacks). The concrete implementation of this interface -must be registered with the module name as a route on the IBC `Router`. - -```go -// app.go -func NewApp(...args) *App { -// ... - -// Create static IBC router, add module routes, then set and seal it -ibcRouter := port.NewRouter() - -ibcRouter.AddRoute(ibctransfertypes.ModuleName, transferModule) -// Note: moduleCallbacks must implement IBCModule interface -ibcRouter.AddRoute(moduleName, moduleCallbacks) - -// Setting Router will finalize all routes by sealing router -// No more routes can be added -app.IBCKeeper.SetRouter(ibcRouter) -``` - -## Working Example - -For a real working example of an IBC application, you can look through the `ibc-transfer` module -which implements everything discussed above. - -Here are the useful parts of the module to look at: - -[Binding to transfer -port](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc-transfer/genesis.go) - -[Sending transfer -packets](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc-transfer/keeper/relay.go) - -[Implementing IBC -callbacks](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc-transfer/module.go) - -## Next {hide} - -Learn about [building modules](../building-modules/intro.md) {hide} diff --git a/docs/ibc/integration.md b/docs/ibc/integration.md deleted file mode 100644 index 50bc983f9b..0000000000 --- a/docs/ibc/integration.md +++ /dev/null @@ -1,252 +0,0 @@ - - -# Integration - -Learn how to integrate IBC to your application and send data packets to other chains. {synopsis} - -This document outlines the required steps to integrate and configure the [IBC -module](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc) to your Cosmos SDK application and -send fungible token transfers to other chains. - -## Integrating the IBC module - -Integrating the IBC module to your SDK-based application is straighforward. The general changes can be summarized in the following steps: - -- Add required modules to the `module.BasicManager` -- Define additional `Keeper` fields for the new modules on the `App` type -- Add the module's `StoreKeys` and initialize their `Keepers` -- Set up corresponding routers and routes for the `ibc` and `evidence` modules -- Add the modules to the module `Manager` -- Add modules to `Begin/EndBlockers` and `InitGenesis` -- Update the module `SimulationManager` to enable simulations - -### Module `BasicManager` and `ModuleAccount` permissions - -The first step is to add the following modules to the `BasicManager`: `x/capability`, `x/ibc`, -`x/evidence` and `x/ibc-transfer`. After that, we need to grant `Minter` and `Burner` permissions to -the `ibc-transfer` `ModuleAccount` to mint and burn relayed tokens. - -```go -// app.go -var ( - - ModuleBasics = module.NewBasicManager( - // ... - capability.AppModuleBasic{}, - ibc.AppModuleBasic{}, - evidence.AppModuleBasic{}, - transfer.AppModuleBasic{}, // i.e ibc-transfer module - ) - - // module account permissions - maccPerms = map[string][]string{ - // other module accounts permissions - // ... - ibctransfertypes.ModuleName: {authtypes.Minter, authtypes.Burner}, -) -``` - -### Application fields - -Then, we need to register the `Keepers` as follows: - -```go -// app.go -type App struct { - // baseapp, keys and subspaces definitions - - // other keepers - // ... - IBCKeeper *ibckeeper.Keeper // IBC Keeper must be a pointer in the app, so we can SetRouter on it correctly - EvidenceKeeper evidencekeeper.Keeper // required to set up the client misbehaviour route - TransferKeeper ibctransferkeeper.Keeper // for cross-chain fungible token transfers - - // make scoped keepers public for test purposes - ScopedIBCKeeper capabilitykeeper.ScopedKeeper - ScopedTransferKeeper capabilitykeeper.ScopedKeeper - - /// ... - /// module and simulation manager definitions -} -``` - -### Configure the `Keepers` - -During initialization, besides initializing the IBC `Keepers` (for the `x/ibc`, and -`x/ibc-transfer` modules), we need to grant specific capabilities through the capability module -`ScopedKeepers` so that we can authenticate the object-capability permissions for each of the IBC -channels. - -```go -func NewApp(...args) *App { - // define codecs and baseapp - - // add capability keeper and ScopeToModule for ibc module - app.CapabilityKeeper = capabilitykeeper.NewKeeper(appCodec, keys[capabilitytypes.StoreKey], memKeys[capabilitytypes.MemStoreKey]) - - // grant capabilities for the ibc and ibc-transfer modules - scopedIBCKeeper := app.CapabilityKeeper.ScopeToModule(ibchost.ModuleName) - scopedTransferKeeper := app.CapabilityKeeper.ScopeToModule(ibctransfertypes.ModuleName) - - // ... other modules keepers - - // Create IBC Keeper - app.IBCKeeper = ibckeeper.NewKeeper( - appCodec, keys[ibchost.StoreKey], app.StakingKeeper, scopedIBCKeeper, - ) - - // Create Transfer Keepers - app.TransferKeeper = ibctransferkeeper.NewKeeper( - appCodec, keys[ibctransfertypes.StoreKey], - app.IBCKeeper.ChannelKeeper, &app.IBCKeeper.PortKeeper, - app.AccountKeeper, app.BankKeeper, scopedTransferKeeper, - ) - transferModule := transfer.NewAppModule(app.TransferKeeper) - - // Create evidence Keeper for to register the IBC light client misbehaviour evidence route - evidenceKeeper := evidencekeeper.NewKeeper( - appCodec, keys[evidencetypes.StoreKey], &app.StakingKeeper, app.SlashingKeeper, - ) - - // .. continues -} -``` - -### Register `Routers` - -IBC needs to know which module is bound to which port so that it can route packets to the -appropriate module and call the appropriate callbacks. The port to module name mapping is handled by -IBC's port `Keeper`. However, the mapping from module name to the relevant callbacks is accomplished -by the port -[`Router`](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc//core/05-port/types/router.go) on the -IBC module. - -Adding the module routes allows the IBC handler to call the appropriate callback when processing a -channel handshake or a packet. - -The second `Router` that is required is the evidence module router. This router handles genenal -evidence submission and routes the business logic to each registered evidence handler. In the case -of IBC, it is required to submit evidence for [light client -misbehaviour](https://github.com/cosmos/ics/tree/master/spec/ics-002-client-semantics#misbehaviour) -in order to freeze a client and prevent further data packets from being sent/received. - -Currently, a `Router` is static so it must be initialized and set correctly on app initialization. -Once the `Router` has been set, no new routes can be added. - -```go -// app.go -func NewApp(...args) *App { - // .. continuation from above - - // Create static IBC router, add ibc-tranfer module route, then set and seal it - ibcRouter := port.NewRouter() - ibcRouter.AddRoute(ibctransfertypes.ModuleName, transferModule) - // Setting Router will finalize all routes by sealing router - // No more routes can be added - app.IBCKeeper.SetRouter(ibcRouter) - - // create static Evidence routers - - evidenceRouter := evidencetypes.NewRouter(). - // add IBC ClientMisbehaviour evidence handler - AddRoute(ibcclient.RouterKey, ibcclient.HandlerClientMisbehaviour(app.IBCKeeper.ClientKeeper)) - - // Setting Router will finalize all routes by sealing router - // No more routes can be added - evidenceKeeper.SetRouter(evidenceRouter) - - // set the evidence keeper from the section above - app.EvidenceKeeper = *evidenceKeeper - - // .. continues -``` - -### Module Managers - -In order to use IBC, we need to add the new modules to the module `Manager` and to the `SimulationManager` in case your application supports [simulations](./../building-modules/simulator.md). - -```go -// app.go -func NewApp(...args) *App { - // .. continuation from above - - app.mm = module.NewManager( - // other modules - // ... - capability.NewAppModule(appCodec, *app.CapabilityKeeper), - evidence.NewAppModule(app.EvidenceKeeper), - ibc.NewAppModule(app.IBCKeeper), - transferModule, - ) - - // ... - - app.sm = module.NewSimulationManager( - // other modules - // ... - capability.NewAppModule(appCodec, *app.CapabilityKeeper), - evidence.NewAppModule(app.EvidenceKeeper), - ibc.NewAppModule(app.IBCKeeper), - transferModule, - ) - - // .. continues -``` - -### Application ABCI Ordering - -One addition from IBC is the concept of `HistoricalEntries` which are stored on the staking module. -Each entry contains the historical information for the `Header` and `ValidatorSet` of this chain which is stored -at each height during the `BeginBlock` call. The historical info is required to introspect the -past historical info at any given height in order to verify the light client `ConsensusState` during the -connection handhake. - -The IBC module also has -[`BeginBlock`](https://github.com/cosmos/cosmos-sdk/blob/master/x/ibc/core/02-client/abci.go) logic as -well. This is optional as it is only required if your application uses the [localhost -client](https://github.com/cosmos/ics/blob/master/spec/ics-009-loopback-client) to connect two -different modules from the same chain. - -::: tip -Only register the ibc module to the `SetOrderBeginBlockers` if your application will use the -localhost (_aka_ loopback) client. -::: - -```go -// app.go -func NewApp(...args) *App { - // .. continuation from above - - // add evidence, staking and ibc modules to BeginBlockers - app.mm.SetOrderBeginBlockers( - // other modules ... - evidencetypes.ModuleName, stakingtypes.ModuleName, ibchost.ModuleName, - ) - - // ... - - // NOTE: Capability module must occur first so that it can initialize any capabilities - // so that other modules that want to create or claim capabilities afterwards in InitChain - // can do so safely. - app.mm.SetOrderInitGenesis( - capabilitytypes.ModuleName, - // other modules ... - ibchost.ModuleName, evidencetypes.ModuleName, ibctransfertypes.ModuleName, - ) - - // .. continues -``` - -::: warning -**IMPORTANT**: The capability module **must** be declared first in `SetOrderInitGenesis` -::: - -That's it! You have now wired up the IBC module and are now able to send fungible tokens across -different chains. If you want to have a broader view of the changes take a look into the SDK's -[`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/master/simapp/app.go). - -## Next {hide} - -Learn about how to create [custom IBC modules](./custom.md) for your application {hide} diff --git a/docs/ibc/overview.md b/docs/ibc/overview.md deleted file mode 100644 index ff915eee8a..0000000000 --- a/docs/ibc/overview.md +++ /dev/null @@ -1,181 +0,0 @@ - - -# Overview - -Learn what IBC is, its components and use cases. {synopsis} - -## What is the Interblockchain Communication Protocol (IBC)? - -This document serves as a guide for developers who want to write their own Inter-blockchain -Communication Protocol (IBC) applications for custom [use-cases](https://github.com/cosmos/ics/blob/master/ibc/4_IBC_USECASES.md). - -Due to the modular design of the IBC protocol, IBC -application developers do not need to concern themselves with the low-level details of clients, -connections, and proof verification. Nevertheless a brief explanation of the lower levels of the -stack is given so that application developers may have a high-level understanding of the IBC -protocol. Then the document goes into detail on the abstraction layer most relevant for application -developers (channels and ports), and describes how to define your own custom packets, and -`IBCModule` callbacks. - -To have your module interact over IBC you must: bind to a port(s), define your own packet data (and -optionally acknowledgement) structs as well as how to encode/decode them, and implement the -`IBCModule` interface. Below is a more detailed explanation of how to write an IBC application -module correctly. - -## Components Overview - -### [Clients](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/02-client) - -IBC Clients are light clients (identified by a unique client-id) that track the consensus states of -other blockchains, along with the proof spec necessary to properly verify proofs against the -client's consensus state. A client may be associated with any number of connections to multiple -chains. The supported IBC clients are: - -* [Solo Machine light client](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/light-clients/06-solomachine): devices such as phones, browsers, or laptops. -* [Tendermint light client](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/light-clients/07-tendermint): The default for SDK-based chains, -* [Localhost (loopback) client](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/light-clients/09-localhost): Useful for -testing, simulation and relaying packets to modules on the same application. - -### [Connections](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/03-connection) - -Connections encapsulate two `ConnectionEnd` objects on two seperate blockchains. Each -`ConnectionEnd` is associated with a client of the other blockchain (ie counterparty blockchain). -The connection handshake is responsible for verifying that the light clients on each chain are -correct for their respective counterparties. Connections, once established, are responsible for -facilitation all cross-chain verification of IBC state. A connection may be associated with any -number of channels. - -### [Proofs](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/23-commitment) and [Paths](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/24-host) - -In IBC, blockchains do not directly pass messages to each other over the network. Instead, to -communicate, a blockchain will commit some state to a specifically defined path reserved for a -specific message type and a specific counterparty (perhaps storing a specific connectionEnd as part -of a handshake, or a packet intended to be relayed to a module on the counterparty chain). A relayer -process monitors for updates to these paths, and will relay messages, by submitting the data stored -under the path along with a proof to the counterparty chain. The paths that all IBC implementations -must use for committing IBC messages is defined in -[ICS-24](https://github.com/cosmos/ics/tree/master/spec/ics-024-host-requirements) and the proof -format that all implementations must be able to produce and verify is defined in this [ICS-23 implementation](https://github.com/confio/ics23). - -### [Capabilities](./ocap.md) - -IBC is intended to work in execution environements where modules do not necessarily trust each -other. Thus IBC must authenticate module actions on ports and channels so that only modules with the -appropriate permissions can use them. This is accomplished using [dynamic -capabilities](../architecture/adr-003-dynamic-capability-store.md). Upon binding to a port or -creating a channel for a module, IBC will return a dynamic capability that the module must claim in -order to use that port or channel. This prevents other modules from using that port or channel since -they will not own the appropriate capability. - -While the above is useful background information, IBC modules do not need to interact at all with -these lower-level abstractions. The relevant abstraction layer for IBC application developers is -that of channels and ports. IBC applications should be written as self-contained **modules**. A -module on one blockchain can thus communicate with other modules on other blockchains by sending, -receiving and acknowledging packets through channels, which are uniquely identified by the -`(channelID, portID)` tuple. A useful analogy is to consider IBC modules as internet applications on -a computer. A channel can then be conceptualized as an IP connection, with the IBC portID being -analogous to a IP port and the IBC channelID being analogous to an IP address. Thus, a single -instance of an IBC module may communicate on the same port with any number of other modules and and -IBC will correctly route all packets to the relevant module using the (channelID, portID tuple). An -IBC module may also communicate with another IBC module over multiple ports, with each -`(portID<->portID)` packet stream being sent on a different unique channel. - -### [Ports](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/05-port) - -An IBC module may bind to any number of ports. Each port must be identified by a unique `portID`. -Since IBC is designed to be secure with mutually-distrusted modules operating on the same ledger, -binding a port will return a dynamic object capability. In order to take action on a particular port -(eg open a channel with its portID), a module must provide the dynamic object capability to the IBC -handler. This prevents a malicious module from opening channels with ports it does not own. Thus, -IBC modules are responsible for claiming the capability that is returned on `BindPort`. - -### [Channels](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel) - -An IBC channel can be established between 2 IBC ports. Currently, a port is exclusively owned by a -single module. IBC packets are sent over channels. Just as IP packets contain the destination IP -address and IP port as well as the source IP address and source IP port, IBC packets will contain -the destination portID and channelID as well as the source portID and channelID. This enables IBC to -correctly route packets to the destination module, while also allowing modules receiving packets to -know the sender module. - -A channel may be `ORDERED`, in which case, packets from a sending module must be processed by the -receiving module in the order they were sent. Or a channel may be `UNORDERED`, in which case packets -from a sending module are processed in the order they arrive (may not be the order they were sent). - -Modules may choose which channels they wish to communicate over with, thus IBC expects modules to -implement callbacks that are called during the channel handshake. These callbacks may do custom -channel initialization logic, if any return an error, the channel handshake will fail. Thus, by -returning errors on callbacks, modules can programatically reject and accept channels. - -The channel handshake is a 4 step handshake. Briefly, if a given chain A wants to open a channel with -chain B using an already established connection: - -1. chain A sends a `ChanOpenInit` message to signal a channel initialization attempt with chain B. -2. chain B sends a `ChanOpenTry` message to try opening the channel on chain A. -3. chain A sends a `ChanOpenAck` message to mark its channel end status as open. -4. chain B sends a `ChanOpenConfirm` message to mark its channel end status as open. - -If all this happens successfully, the channel will be open on both sides. At each step in the handshake, the module -associated with the `ChannelEnd` will have it's callback executed for that step of the handshake. So -on `ChanOpenInit`, the module on chain A will have its callback `OnChanOpenInit` executed. - -Just as ports came with dynamic capabilites, channel initialization will return a dynamic capability -that the module **must** claim so that they can pass in a capability to authenticate channel actions -like sending packets. The channel capability is passed into the callback on the first parts of the -handshake; either `OnChanOpenInit` on the initializing chain or `OnChanOpenTry` on the other chain. - -### [Packets](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel) - -Modules communicate with each other by sending packets over IBC channels. As mentioned above, all -IBC packets contain the destination `portID` and `channelID` along with the source `portID` and -`channelID`, this allows modules to know the sender module of a given packet. IBC packets also -contain a sequence to optionally enforce ordering. IBC packets also contain a `TimeoutTimestamp` and -`TimeoutHeight`, which when non-zero, will determine the deadline before which the receiving module -must process a packet. If the timeout passes without the packet being successfully received, the -sending module can timeout the packet and take appropriate actions. - -Modules send custom application data to each other inside the `Data []byte` field of the IBC packet. -Thus, packet data is completely opaque to IBC handlers. It is incumbent on a sender module to encode -their application-specific packet information into the `Data` field of packets, and the receiver -module to decode that `Data` back to the original application data. - -### [Receipts and Timeouts](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel) - -Since IBC works over a distributed network and relies on potentially faulty relayers to relay messages between ledgers, -IBC must handle the case where a packet does not get sent to its destination in a timely manner or at all. Thus, packets must -specify a timeout height or timeout timestamp after which a packet can no longer be successfully received on the destination chain. - -If the timeout does get reached, then a proof of packet timeout can be submitted to the original chain which can then perform -application-specific logic to timeout the packet, perhaps by rolling back the packet send changes (refunding senders any locked funds, etc). - -In ORDERED channels, a timeout of a single packet in the channel will cause the channel to close. If packet sequence `n` times out, -then no packet at sequence `k > n` can be successfully received without violating the contract of ORDERED channels that packets are processed in the order that they are sent. Since ORDERED channels enforce this invariant, a proof that sequence `n` hasn't been received on the destination chain by packet `n`'s specified timeout is sufficient to timeout packet `n` and close the channel. - -In the UNORDERED case, packets may be received in any order. Thus, IBC will write a packet receipt for each sequence it has received in the UNORDERED channel. This receipt contains no information, it is simply a marker intended to signify that the UNORDERED channel has received a packet at the specified sequence. To timeout a packet on an UNORDERED channel, one must provide a proof that a packet receipt does not exist for the packet's sequence by the specified timeout. Of course, timing out a packet on an UNORDERED channel will simply trigger the application specific timeout logic for that packet, and will not close the channel. - -For this reason, most modules should use UNORDERED channels as they require less liveness guarantees to function effectively for users of that channel. - -### [Acknowledgements](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/04-channel) - -Modules may also choose to write application-specific acknowledgements upon processing a packet. This may either be done synchronously on `OnRecvPacket`, if the module processes packets as soon as they are received from IBC module. Or they may be done asynchronously if module processes packets at some later point after receiving the packet. - -Regardless, this acknowledgement data is opaque to IBC much like the packet `Data` and will be treated by IBC as a simple byte string `[]byte`. It is incumbent on receiver modules to encode their acknowledgemnet in such a way that the sender module can decode it correctly. This should be decided through version negotiation during the channel handshake. - -The acknowledgement may encode whether the packet processing succeeded or failed, along with additional information that will allow the sender module to take appropriate action. - -Once the acknowledgement has been written by the receiving chain, a relayer will relay the acknowledgement back to the original sender module which will then execute application-specific acknowledgment logic using the contents of the acknowledgement. This may involve rolling back packet-send changes in the case of a failed acknowledgement (refunding senders). - -Once an acknowledgement is received successfully on the original sender the chain, the IBC module deletes the corresponding packet commitment as it is no longer needed. - -## Further Readings and Specs - -If you want to learn more about IBC, check the following specifications: - -* [IBC specification overview](https://github.com/cosmos/ics/blob/master/ibc/README.md) -* [IBC SDK specification](../../modules/ibc) - -## Next {hide} - -Learn about how to [integrate](./integration.md) IBC to your application {hide} diff --git a/docs/ibc/relayer.md b/docs/ibc/relayer.md deleted file mode 100644 index 155121258d..0000000000 --- a/docs/ibc/relayer.md +++ /dev/null @@ -1,45 +0,0 @@ - - -# Relayer - -## Pre-requisites Readings - -- [IBC Overview](./overview.md) {prereq} -- [Events](../core/events.md) {prereq} - -## Events - -Events are emitted for every transaction processed by the base application to indicate the execution -of some logic clients may want to be aware of. This is extremely useful when relaying IBC packets. -Any message that uses IBC will emit events for the corresponding TAO logic executed as defined in -the [IBC events spec](https://github.com/cosmos/cosmos-sdk/tree/master/x/ibc/core/spec/06_events.md). - -In the SDK, it can be assumed that for every message there is an event emitted with the type `message`, -attribute key `action`, and an attribute value representing the type of message sent -(`channel_open_init` would be the attribute value for `MsgChannelOpenInit`). If a relayer queries -for transaction events, it can split message events using this event Type/Attribute Key pair. - -The Event Type `message` with the Attribute Key `module` may be emitted multiple times for a single -message due to application callbacks. It can be assumed that any TAO logic executed will result in -a module event emission with the attribute value `ibc_` (02-client emits `ibc_client`). - -### Subscribing with Tendermint - -Calling the Tendermint RPC method `Subscribe` via [Tendermint's Websocket](https://docs.tendermint.com/master/rpc/) will return events using -Tendermint's internal representation of them. Instead of receiving back a list of events as they -were emitted, Tendermint will return the type `map[string][]string` which maps a string in the -form `.` to `attribute_value`. This causes extraction of the event -ordering to be non-trivial, but still possible. - -A relayer should use the `message.action` key to extract the number of messages in the transaction -and the type of IBC transactions sent. For every IBC transaction within the string array for -`message.action`, the necessary information should be extracted from the other event fields. If -`send_packet` appears at index 2 in the value for `message.action`, a relayer will need to use the -value at index 2 of the key `send_packet.packet_sequence`. This process should be repeated for each -piece of information needed to relay a packet. - -## Example Implementations - -- [Golang Relayer](https://github.com/iqlusioninc/relayer) diff --git a/docs/intro/README.md b/docs/intro/README.md deleted file mode 100644 index 454ce66955..0000000000 --- a/docs/intro/README.md +++ /dev/null @@ -1,16 +0,0 @@ - - -# Introduction - -This folder contains introduction material on the Cosmos SDK. - -1. [Overview](./overview.md) -2. [Application-Specific Blockchains](./why-app-specific.md) -3. [Architecture of an SDK Application](./sdk-app-architecture.md) -4. [Cosmos SDK Design Overview](./sdk-design.md) - -After reading the introduction material, head over to the [basics](../basics/README.md) to learn more. \ No newline at end of file diff --git a/docs/intro/overview.md b/docs/intro/overview.md deleted file mode 100644 index b6f1ebce97..0000000000 --- a/docs/intro/overview.md +++ /dev/null @@ -1,37 +0,0 @@ - - -# High-level Overview - -## What is the SDK? - -The [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) is an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains, like the Cosmos Hub, as well as permissioned Proof-Of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**. - -The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the SDK as the npm-like framework to build secure blockchain applications on top of [Tendermint](https://github.com/tendermint/tendermint). SDK-based blockchains are built out of composable [modules](../building-modules/intro.md), most of which are open source and readily available for any developers to use. Anyone can create a module for the Cosmos-SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system, which allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [this section](../core/ocap.md). - -## What are Application-Specific Blockchains? - -One development paradigm in the blockchain world today is that of virtual-machine blockchains like Ethereum, where development generally revolves around building a decentralised applications on top of an existing blockchain as a set of smart contracts. While smart contracts can be very good for some use cases like single-use applications (e.g. ICOs), they often fall short for building complex decentralised platforms. More generally, smart contracts can be limiting in terms of flexibility, sovereignty and performance. - -Application-specific blockchains offer a radically different development paradigm than virtual-machine blockchains. An application-specific blockchain is a blockchain customized to operate a single application: developers have all the freedom to make the design decisions required for the application to run optimally. They can also provide better sovereignty, security and performance. - -Learn more about [application-specific blockchains](./why-app-specific.md). - -## Why the Cosmos SDK? - -The Cosmos SDK is the most advanced framework for building custom application-specific blockchains today. Here are a few reasons why you might want to consider building your decentralised application with the Cosmos SDK: - -- The default consensus engine available within the SDK is [Tendermint Core](https://github.com/tendermint/tendermint). Tendermint is the most (and only) mature BFT consensus engine in existence. It is widely used across the industry and is considered the gold standard consensus engine for building Proof-of-Stake systems. -- The SDK is open source and designed to make it easy to build blockchains out of composable [modules](../../x/). As the ecosystem of open source SDK modules grows, it will become increasingly easier to build complex decentralised platforms with it. -- The SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state-machines. This makes the Cosmos SDK a very secure environment to build blockchains. -- Most importantly, the Cosmos SDK has already been used to build many application-specific blockchains that are already in production. Among others, we can cite [Cosmos Hub](https://hub.cosmos.network), [IRIS Hub](https://irisnet.org), [Binance Chain](https://docs.binance.org/), [Terra](https://terra.money/) or [Kava](https://www.kava.io/). [Many more](https://cosmos.network/ecosystem) are building on the Cosmos SDK. - -## Getting started with the Cosmos SDK - -- Learn more about the [architecture of an SDK application](./sdk-app-architecture.md) -- Learn how to build an application-specific blockchain from scratch with the [SDK Tutorial](https://cosmos.network/docs/tutorial) - -## Next {hide} - -Learn about [application-specific blockchains](./why-app-specific.md) {hide} diff --git a/docs/intro/sdk-app-architecture.md b/docs/intro/sdk-app-architecture.md deleted file mode 100644 index 55ffad8a12..0000000000 --- a/docs/intro/sdk-app-architecture.md +++ /dev/null @@ -1,100 +0,0 @@ - - -# Blockchain Architecture - -## State machine - -At its core, a blockchain is a [replicated deterministic state machine](https://en.wikipedia.org/wiki/State_machine_replication). - -A state machine is a computer science concept whereby a machine can have multiple states, but only one at any given time. There is a `state`, which describes the current state of the system, and `transactions`, that trigger state transitions. - -Given a state S and a transaction T, the state machine will return a new state S'. - -``` -+--------+ +--------+ -| | | | -| S +---------------->+ S' | -| | apply(T) | | -+--------+ +--------+ -``` - -In practice, the transactions are bundled in blocks to make the process more efficient. Given a state S and a block of transactions B, the state machine will return a new state S'. - -``` -+--------+ +--------+ -| | | | -| S +----------------------------> | S' | -| | For each T in B: apply(T) | | -+--------+ +--------+ -``` - -In a blockchain context, the state machine is deterministic. This means that if a node is started at a given state and replays the same sequence of transactions, it will always end up with the same final state. - -The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state-machines with the SDK will be described more in depth in the following sections. But first, let us see how the state-machine is replicated using **Tendermint**. - -## Tendermint - -Thanks to the Cosmos SDK, developers just have to define the state machine, and [*Tendermint*](https://tendermint.com/docs/introduction/what-is-tendermint.html) will handle replication over the network for them. - - -``` - ^ +-------------------------------+ ^ - | | | | Built with Cosmos SDK - | | State-machine = Application | | - | | | v - | +-------------------------------+ - | | | ^ -Blockchain node | | Consensus | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Networking | | - | | | | - v +-------------------------------+ v -``` - - -[Tendermint](https://tendermint.com/docs/introduction/what-is-tendermint.html) is an application-agnostic engine that is responsible for handling the *networking* and *consensus* layers of a blockchain. In practice, this means that Tendermint is responsible for propagating and ordering transaction bytes. Tendermint Core relies on an eponymous Byzantine-Fault-Tolerant (BFT) algorithm to reach consensus on the order of transactions. - -The Tendermint [consensus algorithm](https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview) works with a set of special nodes called *Validators*. Validators are responsible for adding blocks of transactions to the blockchain. At any given block, there is a validator set V. A validator in V is chosen by the algorithm to be the proposer of the next block. This block is considered valid if more than two thirds of V signed a *[prevote](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)* and a *[precommit](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)* on it, and if all the transactions that it contains are valid. The validator set can be changed by rules written in the state-machine. - -## ABCI - -Tendermint passes transactions to the application through an interface called the [ABCI](https://tendermint.com/docs/spec/abci/), which the application must implement. - -``` - +---------------------+ - | | - | Application | - | | - +--------+---+--------+ - ^ | - | | ABCI - | v - +--------+---+--------+ - | | - | | - | Tendermint | - | | - | | - +---------------------+ -``` - -Note that **Tendermint only handles transaction bytes**. It has no knowledge of what these bytes mean. All Tendermint does is order these transaction bytes deterministically. Tendermint passes the bytes to the application via the ABCI, and expects a return code to inform it if the messages contained in the transactions were successfully processed or not. - -Here are the most important messages of the ABCI: - -- `CheckTx`: When a transaction is received by Tendermint Core, it is passed to the application to check if a few basic requirements are met. `CheckTx` is used to protect the mempool of full-nodes against spam transactions. A special handler called the [`AnteHandler`](../basics/gas-fees.md#antehandler) is used to execute a series of validation steps such as checking for sufficient fees and validating the signatures. If the checks are valid, the transaction is added to the [mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality) and relayed to peer nodes. Note that transactions are not processed (i.e. no modification of the state occurs) with `CheckTx` since they have not been included in a block yet. -- `DeliverTx`: When a [valid block](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation) is received by Tendermint Core, each transaction in the block is passed to the application via `DeliverTx` in order to be processed. It is during this stage that the state transitions occur. The `AnteHandler` executes again along with the actual [`Msg` service methods](../building-modules/msg-services.md) for each message in the transaction. - - `BeginBlock`/`EndBlock`: These messages are executed at the beginning and the end of each block, whether the block contains transaction or not. It is useful to trigger automatic execution of logic. Proceed with caution though, as computationally expensive loops could slow down your blockchain, or even freeze it if the loop is infinite. - -Find a more detailed view of the ABCI methods from the [Tendermint docs](https://tendermint.com/docs/spec/abci/abci.html#overview). - -Any application built on Tendermint needs to implement the ABCI interface in order to communicate with the underlying local Tendermint engine. Fortunately, you do not have to implement the ABCI interface. The Cosmos SDK provides a boilerplate implementation of it in the form of [baseapp](./sdk-design.md#baseapp). - - -## Next {hide} - -Read about the [high-level design principles of the SDK](./sdk-design.md) {hide} diff --git a/docs/intro/sdk-design.md b/docs/intro/sdk-design.md deleted file mode 100644 index d9629a3abd..0000000000 --- a/docs/intro/sdk-design.md +++ /dev/null @@ -1,95 +0,0 @@ - - -# Main Components of the Cosmos SDK - -The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions. - -Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from Tendermint via `DeliverTx`: - -1. Decode `transactions` received from the Tendermint consensus engine (remember that Tendermint only deals with `[]bytes`). -2. Extract `messages` from `transactions` and do basic sanity checks. -3. Route each message to the appropriate module so that it can be processed. -4. Commit state changes. - -## `baseapp` - -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connexion with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](../basics/app-anatomy.md#core-application-file). See an example of this from the SDK application tutorial: - -+++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go#L72-L92 - -The goal of `baseapp` is to provide a secure interface between the store and the extensible state machine while defining as little about the state machine as possible (staying true to the ABCI). - -For more on `baseapp`, please click [here](../core/baseapp.md). - -## Multistore - -The Cosmos SDK provides a [`multistore`](../core/store.md#multistore) for persisting state. The multistore allows developers to declare any number of [`KVStores`](../core/store.md#base-layer-kvstores). These `KVStores` only accept the `[]byte` type as value and therefore any custom structure needs to be marshalled using [a codec](../core/encoding.md) before being stored. - -The multistore abstraction is used to divide the state in distinct compartments, each managed by its own module. For more on the multistore, click [here](../core/store.md#multistore) - -## Modules - -The power of the Cosmos SDK lies in its modularity. SDK applications are built by aggregating a collection of interoperable modules. Each module defines a subset of the state and contains its own message/transaction processor, while the SDK is responsible for routing each message to its respective module. - -Here is a simplified view of how a transaction is processed by the application of each full-node when it is received in a valid block: - -``` - + - | - | Transaction relayed from the full-node's Tendermint engine - | to the node's application via DeliverTx - | - | - | - +---------------------v--------------------------+ - | APPLICATION | - | | - | Using baseapp's methods: Decode the Tx, | - | extract and route the message(s) | - | | - +---------------------+--------------------------+ - | - | - | - +---------------------------+ - | - | - | - | Message routed to the correct - | module to be processed - | - | -+----------------+ +---------------+ +----------------+ +------v----------+ -| | | | | | | | -| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | -| | | | | | | | -| | | | | | | Handles message,| -| | | | | | | Updates state | -| | | | | | | | -+----------------+ +---------------+ +----------------+ +------+----------+ - | - | - | - | - +--------------------------+ - | - | Return result to Tendermint - | (0=Ok, 1=Err) - v -``` - -Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities. - -SDK modules are defined in the `x/` folder of the SDK. Some core modules include: - -- `x/auth`: Used to manage accounts and signatures. -- `x/bank`: Used to enable tokens and token transfers. -- `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains. - -In addition to the already existing modules in `x/`, that anyone can use in their app, the SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://cosmos.network/docs/tutorial/keeper.html). - -## Next {hide} - -Learn more about the [anatomy of an SDK application](../basics/app-anatomy.md) {hide} diff --git a/docs/intro/why-app-specific.md b/docs/intro/why-app-specific.md deleted file mode 100644 index 5852489127..0000000000 --- a/docs/intro/why-app-specific.md +++ /dev/null @@ -1,80 +0,0 @@ - - -# Application-Specific Blockchains - -This document explains what application-specific blockchains are, and why developers would want to build one as opposed to writing Smart Contracts. {synopsis} - -## What are application-specific blockchains? - -Application-specific blockchains are blockchains customized to operate a single application. Instead of building a decentralised 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 interract with the nodes. - -``` - ^ +-------------------------------+ ^ - | | | | Built with Cosmos SDK - | | State-machine = Application | | - | | | v - | +-------------------------------+ - | | | ^ -Blockchain node | | Consensus | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Networking | | - | | | | - v +-------------------------------+ v -``` - -## What are the shortcomings of Smart Contracts? - -Virtual-machine blockchains like Ethereum addressed the demand for more programmability back in 2014. At the time, the options available for building decentralised applications were quite limited. Most developers would build on top of the complex and limited Bitcoin scripting language, or fork the Bitcoin codebase which was hard to work with and customize. - -Virtual-machine blockchains came in with a new value proposition. Their state-machine incorporates a virtual-machine that is able to interpret turing-complete programs called Smart Contracts. These Smart Contracts are very good for use cases like one-time events (e.g. ICOs), but they can fall short for building complex decentralised platforms. Here is why: - -- Smart Contracts are generally developed with specific programming languages that can be interpreted by the underlying virtual-machine. These programming languages are often immature and inherently limited by the constraints of the virtual-machine itself. For example, the Ethereum Virtual Machine does not allow developers to implement automatic execution of code. Developers are also limited to the account-based system of the EVM, and they can only choose from a limited set of functions for their cryptographic operations. These are examples, but they hint at the lack of **flexibility** that a smart contract environment often entails. -- Smart Contracts are all run by the same virtual machine. This means that they compete for resources, which can severly restrain **performance**. And even if the state-machine were to be split in multiple subsets (e.g. via sharding), Smart Contracts would still need to be interpeted by a virtual machine, which would limit performance compared to a native application implemented at state-machine level (our benchmarks show an improvement on the order of x10 in performance when the virtual-machine is removed). -- Another issue with the fact that Smart Contracts share the same underlying environment is the resulting limitation in **sovereignty**. A decentralised application is an ecosystem that involves multiple players. If the application is built on a general-purpose virtual-machine blockchain, stakeholders have very limited sovereignty over their application, and are ultimately superseded by the governance of the underlying blockchain. If there is a bug in the application, very little can be done about it. - -Application-Specific Blockchains are designed to address these shortcomings. - -## Application-Specific Blockchains Benefits - -### Flexibility - -Application-specific blockchains give maximum flexibility to developers: - -- In Cosmos blockchains, the state-machine is typically connected to the underlying consensus engine via an interface called the [ABCI](https://tendermint.com/docs/spec/abci/). This interface can be wrapped in any programming language, meaning developers can build their state-machine in the programming language of their choice. -- Developers can choose among multiple frameworks to build their state-machine. The most widely used today is the Cosmos SDK, but others exist (e.g. [Lotion](https://github.com/nomic-io/lotion), [Weave](https://github.com/iov-one/weave), ...). The choice will most of the time be done based on the programming language they want to use (Cosmos SDK and Weave are in Golang, Lotion is in Javascript, ...). -- The ABCI also allows developers to swap the consensus engine of their application-specific blockchain. Today, only Tendermint is production-ready, but in the future other consensus engines are expected to emerge. -- Even when they settle for a framework and consensus engine, developers still have the freedom to tweak them if they don't perfectly match their requirements in their pristine forms. -- Developers are free to explore the full spectrum of tradeoffs (e.g. number of validators vs transaction throughput, safety vs availability in asynchrony, ...) and design choices (DB or IAVL tree for storage, UTXO or account model, ...). -- Developers can implement automatic execution of code. In the Cosmos SDK, logic can be automatically triggered at the beginning and the end of each block. They are also free to choose the cryptographic library used in their application, as opposed to being constrained by what is made available by the underlying environment in the case of virtual-machine blockchains. - -The list above contains a few examples that show how much flexibility application-specific blockchains give to developers. The goal of Cosmos and the Cosmos SDK is to make developer tooling as generic and composable as possible, so that each part of the stack can be forked, tweaked and improved without losing compatibility. As the community grows, more alternative for each of the core building blocks will emerge, giving more options to developers. - -### Performance - -Decentralised applications built with Smart Contracts are inherently capped in performance by the underlying environment. For a decentralised application to optimise performance, it needs to be built as an application-specific blockchains. Next are some of the benefits an application-specific blockchains brings in terms of performance: - -- Developers of application-specific blockchains can choose to operate with novel consensus engine such as Tendermint BFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throuhgput. -- 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. -- Even if a virtual-machine blockchain offered application-based sharding coupled with an efficient consensus algorithm, performance would still be limited by the virtual-machine itself. The real throughput bottleneck is the state-machine, and requiring transactions to be interpreted by a virtual-machine significantly increases the computational complexity of processing them. - -### Security - -Security is hard to quantify, and greatly varies from platform to platform. That said here are some important benefits an application-specific blockchain can bring in terms of security: - -- Developers can choose proven programming languages like Golang when building their application-specific blockchains, as opposed to smart contract programming languages that are often more immature. -- Developers are not constrained by the cryptographic functions made available by the underlying virtual-machines. They can use their own custom cryptography, and rely on well-audited crypto libraries. -- Developers do not have to worry about potential bugs or exploitable mechanisms in the underlying virtual-machine, making it easier to reason about the security of the application. - -### Sovereignty - -One of the major benefits of application-specific blockchains is sovereignty. A decentralised application is an ecosystem that involves many actors: users, developers, third-party services, and more. When developers build on virtual-machine blockchain where many decentralised applications coexist, the community of the application is different than the community of the underlying blockchain, and the latter supersedes the former in the governance process. If there is a bug or if a new feature is needed, stakeholders of the application have very little leeway to upgrade the code. If the community of the underlying blockchain refuses to act, nothing can happen. - -The fundamental issue here is that the governance of the application and the governance of the network are not aligned. This issue is solved by application-specific blockchains. Because application-specific blockchains specialize to operate a single application, stakeholders the application has full control over the entire chain. This ensures the community will not be stuck if a bug is discovered, and that it has the entire freedom to choose how it is going to evolve. - -## Next {hide} - -Learn more about the [high-level architecture](./sdk-app-architecture.md) of an SDK application {hide} diff --git a/docs/kr/README.md b/docs/kr/README.md deleted file mode 100755 index 86c60314bd..0000000000 --- a/docs/kr/README.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -parent: - order: false ---- - -# 코스모스 SDK 문서에 오신 걸 환영합니다! - -::: warning -번역된 문서는 **참고용**으로 번역되었습니다. 다수의 오타, 오류가 존재할 수 있으며, 영문 업데이트보다 번역이 느리게 진행될 수 있다는 점을 인지하시기 바랍니다. - -코스모스 관련 가장 정확한 정보를 확인하시기 위해서는 영어 원문을 참고하시기 바랍니다. -::: - -## 코스모스 SDK 배우기 - -### SDK 소개 - -만약 코스모스 SDK가 처음이지만 배우고 싶으시다면 여기에서 시작하시는 것을 추천드립니다. - -### SDK 튜토리얼 - -직접 해보면서 학습하는 방식을 선호하신다면 SDK 애플리케이션 튜토리얼을 따라하실 수 있습니다. 튜토리얼은 **[SDK 기반 블록체인을](https://github.com/cosmos/sdk-application-tutorial)** 만드는 방법을 처음부터 끝까지 가르쳐 드립니다. 이 과정에서 코스모스 SDK의 기본적인 개념 또한 함께 배우실 수 있습니다. - -## 코스모스 SDK 사용하기 - -다음 항목은 실제로 작동하는 SDK 기반 블록체인에 필요한 모든 정보를 포함하고 있습니다. - ->*NOTE*: 코스모스 SDK 지원 문서의 완성도와 정확성을 높이기 위해 해당 문서는 꾸준히 업데이트 되고 있습니다. 혹시 오류나 제안사항이 있으시다면 [코스모스 포럼](https://forum.cosmos.network) 또는 [깃허브 이슈를](https://github.com/cosmos/cosmos-sdk/issues/new) 통해서 알려주시면 감사하겠습니다. - -- [인트로](./intro/README.md): 코스모스 SDK에 대한 high-level 소개 자료 -- [Gaia](https://github.com/cosmos/gaia/blob/master/docs/translations/kr/README.md): Gaia 애플리케이션(현재 코스모스 허브 명칭)에 대한 모든 문서들이 있습니다. Gaia 테스트넷에 참여하는 방법에 대한 정보 -- [클라이언트](./clients/README.md): SDK Command-Line Interface 와 SDK 라이트 클라이언트 같은 SDK 클라이언트에 관련한 문서 -- [스펙](./spec/README.md): SDK와 모듈들에 대한 스펙 정의 - -## 코스모스 허브 테스트넷 - -`gaia` 애플리케이션(코스모스 허브의 애플리케이션)을 설치하고 퍼블릭 테스트넷에 참가하고 싶으시다면 여기를 클릭해주세요. -자체적인 `gaia` 테스트넷을 운영하고 싶으시다면 **[여기](https://github.com/cosmos/gaia/blob/master/docs/translations/kr/join-testnet.md)** 를 클릭해주세요. - -자체적인 `gaia` 테스트넷 운영을 원하시는 경우 **[여기](https://github.com/cosmos/gaia/blob/master/docs/translations/kr/deploy-testnet.md)** 를 확인하세요 - -## 기여하기 - -코스모스 도큐멘테이션 또는 코드 업데이트 규칙에 관련해서는 [이 파일](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md)을 참고해주세요. diff --git a/docs/kr/clients/README.md b/docs/kr/clients/README.md deleted file mode 100755 index 5956e7464b..0000000000 --- a/docs/kr/clients/README.md +++ /dev/null @@ -1,18 +0,0 @@ -# 클라이언트 - -이 항목은 SDK 기반 블록체인을 위한 클라이언트에 대한 정보가 포함되어있습니다. - ->*참고*: 이 항목은 작업이 진행중입니다. - -## 라이트 클라이언트(Light-client) - -라이트 클라이언트는 유저가 특정 블록체인 상태 전체를 다운로드 받지 않고도 안전성이 확보될 수 있는 환경에서 블록체인 애플리케이션과 소통할 수 있게 합니다. - -- [라이트 클라이언트 개요](./lite/README.md) -- [라이트 클라이언트 서버 구동하기](./lite/getting_started.md) -- [라이트 클라이언트 스펙](./lite/specification.md) - -## 다른 클라이언트 - -- [SDK 기반 블록체인을 위한 커맨드 라인 기반 인터페이스](./cli.md) -- [서비스 제공자 문서](./service-providers.md) diff --git a/docs/kr/clients/cli.md b/docs/kr/clients/cli.md deleted file mode 100755 index fda1ef60b9..0000000000 --- a/docs/kr/clients/cli.md +++ /dev/null @@ -1,3 +0,0 @@ -# CLI - -> TODO: Rewrite this section to explain how CLI works for a generic SDK app. diff --git a/docs/kr/clients/lite/README.md b/docs/kr/clients/lite/README.md deleted file mode 100755 index 4479bd0d42..0000000000 --- a/docs/kr/clients/lite/README.md +++ /dev/null @@ -1,63 +0,0 @@ -# 라이트 클라이언트 개요 - -**코스모스 SDK 라이트 클라이언트 RPC 문서를 [여기]에서 확인하세요(https://cosmos.network/rpc/)** - -## 소개 - -라이트 클라이언트는 핸드폰 같은 클라이언트에서 블록체인 상태(state)에 대한 증거(proof)를 풀노드로부터 전달받을 수 있게 합니다. 라이트 클라이언트는 전송받은 증거에 대한 검증을 자체적으로 수행할 수 있기 때문에 풀노드를 신뢰하지 않아도 되며, 풀노드의 거짓 정보 전달을 확인할 수 있다. - -라이트 클라이언트는 대역폭(bandwidth), 컴퓨터 연산력 그리고 저장공간 측면에서 큰 리소스를 소모하지 않고도 풀노드와 동일한 보안을 제공할 수 있다. 또한 유저의 설정에 따라 모듈화 된 기능성을 제공할 수 있다. 이런 우수한 기능은 개발자들이 풀 블록체인 노드가 없이도 안전하고, 효율적이고, 사용성이 높은 모바일 애플리케이션, 웹사이트 등을 만들 수 있게 한다. - -### 라이트 클라이언트란 무엇인가 - -코스모스 SDK 라이트 클라이언트 (Gaia-lite)는 두 가지 요소로 나뉘어 있다. 첫 번째 요소는 모든 텐더민트 기반 애플리케이션들의 기본적인 컴포넌트다. 해당 컴포넌트는 헤더 체인을 따르면서 풀노드가 제공하는 증거를 신뢰할 수 있는 검증인을 통해 확인하는 방식으로 보안과 연결성 측면을 담당한다. 두 번째 요소는 코스모스 허브(`gaiad`)에 고유한 컴포넌트다. 일종의 쿼리 엔드포인트(query endpoint)로써 애플리케이션 특정 기능을 드러내는 역할을 수행한다. 애플리케이션 상태에 대한 모든 쿼리는 쿼리 엔드포인트(query endpoint)를 통해 이루어진다. 쿼리 엔드포인트를 이용하는 것에 가장 큰 장점은 애플리케이션이 리턴하는 증거를 검증할 수 있다는 것이다. - -### 하이레벨 아키텍처(High-level Architecture) - -코스모스 허브(또는 다른 존)를 위한 제삼자 클라이언트 애플리케이션을 만드려고 하는 개발자는 기본 규례적(canonical) API를 기반으로 개발을 해야 합니다. API는 여러 가지 부품으로 이루어져 있습니다. 코스모스 생태계의 모든 존은 기본적으로 ICS0(텐더민트API)를 공개해야 하나, 그 외에 모듈들은 선택 사항입니다. 모든 존은 모듈 API를 도입할 여부를 기능에 따라 선택할 권리가 있습니다. - -기본적으로 코스모스 허브는 [ICS0](https://cosmos.network/rpc/#/ICS0) (텐더민트API), [ICS1](https://cosmos.network/rpc/#/ICS1) (키API), [ICS20](https://cosmos.network/rpc/#/ICS20) (토큰API), [ICS21](https://cosmos.network/rpc/#/ICS21) (스테이킹API), -[ICS22](https://cosmos.network/rpc/#/ICS22) (거버넌스API) and [ICS23](https://cosmos.network/rpc/#/ICS23) (슬래싱API)를 도입하고 있습니다. - -![high-level](./pics/high-level.png) - -모든 애플리케이션은 Gaia-lite 클라이언트를 기반으로 운영되는 것을 원칙으로 삼습니다. Gaia-lite 외의 소프트웨어는 특정 존 API에 대한 안정성을 보장하지 않습니다. - -### 비교 - -ABCI 풀노드는 다음과 같은 항목에서 라이트 클라이언트와 다릅니다: - -|| 풀노드 | 라이트 클라이언트 | 설명| -|-| ------------- | ----- | -------------- | -| 트랜잭션 검증 및 실행|Yes|No|풀노드는 모든 트랜잭션을 검증하고 실행하지만, 라이트 클라이언트는 모든 트랜잭션을 처리하지 않습니다| -| 검증 및 블록 저장|Yes|No|풀노드는 모든 블록을 검증하고 보관하지만, 라이트 클라이언트는 블록 저장을 하지 않습니다| -| 합의 절차 참여| Yes|No|검증인 세트에 포함된 풀노드는 합의 절차에 참여하지만, 라이트 클라이언트는 절대로 합의 절차에 참여할 수 없습니다| -| 대역폭 사용량|대량|소량|풀노드는 모든 블록을 전달받기 때문에 충분한 대역폭이 확보되지 않는 경우 다른 뒤질 확률이 있습니다. 검증인 풀노드가 낮은 대역폭으로 지연되는 경우 합의 절차 전체가 늦어질 수 있습니다. 라이트 클라이언트는 로컬 호출만을 처리하기 때문에 소량의 대역폭을 사용합니다| -| 연산력 사용량|대량|소량|풀노드는 모든 트랜잭션을 처리하며 모든 블록을 검증해야 하기 때문에 대량의 컴퓨터 연산력을 사용합니다.| -| 저장 공간 사용량|대량|소량|풀노드는 모든 블록과 ABCI 상태를 저장합니다. 라이트 클라이언트는 검증인 세트와 일부 체크포인트만을 저장합니다.| -| 전력 사용량|대량|소량|풀노드는 24시간 돌아가는 고성능 머신 환경이 제공되어야 하기 때문에 대량의 전력을 소모합니다. 라이트 클라이언트의 경우 유저 애플리케이션과 동일한 환경에서 운용될 수 있습니다. 라이트 클라이언트는 모바일 기기 같은 저성능 기기에서도 사용될 수 있습니다. 또한 라이트 클라이언트는 필요에 따라 클라이언트 작동을 출 수 있기 때문에 모바일 기기 같은 저전력 소모를 필요로 하는 환경에서 이용될 수 있습니다.| -| API 제공|모든 코스모스 API|모듈 API|풀노드는 모든 코스모스 API를 지원합니다. 라이트 클라이언트는 유저 설정에 따라 모듈 API를 제공합니다.| -| 보안|높음|높음|풀노드는 자체적으로 모든 트랜잭션과 블록을 검증합니다. 라이트 클라이언트는 모든 트랜잭션을 검증하지 않지만 다른 풀노드를 통해 데이터를 전달받아 자체적인 검증을 할 수 있습니다. 풀노드와 라이트 클라이언트는 둘 다 제삼자 노드를 신뢰할 필요 없이 데이터 검증이 가능하기 때문에 높은 수준의 보안을 제공합니다| - -위 표와 같이 가이아 라이트 클라이언트는 소량의 대역폭, 연산력, 저장 공간, 전력을 가지고도 유저가 필요로 하는 모든 기능과 보안을 제공합니다. - -## 보안 유지하기 - -### 신뢰 가능한 검증인 세트 - -가이아 라이트 클라이언트의 디자인 철학은 다음과 같은 원칙을 따릅니다: - -1. **검증인 노드와 다른 풀 노드를 포함한 모든 블록체인 노드를 신뢰하지 않는다** -2. **오직 전체적인 검증인 세트(validator set) 만을 신뢰한다** - -초기에 신뢰될 수 있는 검증인 세트(통상 제네시스 파일에 있는 검증인 세트)는 신뢰 저장소(trust store)에 미리 세팅되어야 합니다. 이후, 런타임에서 라이트 클라이언트가 다른 검증인 세트를 발견하게 된다면 클라이언트는 해당 검증인 세트를 별도로 검증한 후 새로운 검증인 세트를 저장소에 보관하게 됩니다. - -![validator-set-change](./pics/validatorSetChange.png) - -### 신뢰 전파(trust propagation) - -위에 항목에 나열된 바와 같이, 라이트 클라이언트(lcd)는 신뢰할 수 있는 검증인 세트를 별도로 검증합니다. 검증인 세트는 일종의 신뢰의 기반이 되며, 이런 신뢰를 기반으로 블록 정보와 트랜잭션 정보 같은 다른 블록체인 데이터에 신뢰를 전파(propogate)하는데 이용됩니다. 신뢰 전파 아키텍처는 다음과 같습니다. - -![change-process](./pics/trustPropagate.png) - -라이트 클라이언트는 통상 신뢰 가능한 검증인 세트를 통해 모든 프리 커밋 정보와 블록 헤더 정보가 포함된 각 블록의 커밋을 검증할 수 있습니다. 이후 블록 해시 값, 데이터 해시 값 그리고 앱해시(appHash)에 대한 신뢰를 파생합니다. 머클 증거(merkle proof)와 위의 정보를 이용해 모든 트랜잭션 데이터와 ABCI의 상태(state)를 검증할 수 있게 됩니다. diff --git a/docs/kr/clients/lite/getting_started.md b/docs/kr/clients/lite/getting_started.md deleted file mode 100755 index 303d0fe132..0000000000 --- a/docs/kr/clients/lite/getting_started.md +++ /dev/null @@ -1,21 +0,0 @@ -# REST 서버 시작하기 - -REST 서버를 가동하기 위해서는 다음과 같은 파라미터 값을 정의해야 합니다: - - -| 파라미터 | 형태 | 기본 값 | 필수/선택 | 설명 | -| ----------- | --------- | ----------------------- | -------- | ---------------------------------------------------- | -| chain-id | string | null | 필수 | 연결할 체인의 chain-id | -| node | URL | "tcp://localhost:46657" | 필수 | 연결할 풀노드의 주소 | -| laddr | URL | "tcp://localhost:1317" | 필수 | REST 서버를 가동할 주소 | -| trust-store | DIRECTORY | "$HOME/.lcd" | 선택 | 체크포인트와 검증인 세트를 저장할 디렉터리 | - -예를 들어:: - -```bash -gaiacli rest-server --chain-id=test \ - --laddr=tcp://localhost:1317 \ - --node tcp://localhost:26657 -``` - -Gaia-Lite RPC에 대한 추가적인 정보를 원하시면 [Swagger 문서](https://cosmos.network/rpc/)를 확인하세요. diff --git a/docs/kr/clients/lite/pics/C2H.png b/docs/kr/clients/lite/pics/C2H.png deleted file mode 100755 index 49f7e07f32..0000000000 Binary files a/docs/kr/clients/lite/pics/C2H.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/H2C.png b/docs/kr/clients/lite/pics/H2C.png deleted file mode 100755 index 027eafcde1..0000000000 Binary files a/docs/kr/clients/lite/pics/H2C.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/MA.png b/docs/kr/clients/lite/pics/MA.png deleted file mode 100755 index ae38239628..0000000000 Binary files a/docs/kr/clients/lite/pics/MA.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/absence1.png b/docs/kr/clients/lite/pics/absence1.png deleted file mode 100755 index 70b4c9e8d2..0000000000 Binary files a/docs/kr/clients/lite/pics/absence1.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/absence2.png b/docs/kr/clients/lite/pics/absence2.png deleted file mode 100755 index 6ce5bcde31..0000000000 Binary files a/docs/kr/clients/lite/pics/absence2.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/absence3.png b/docs/kr/clients/lite/pics/absence3.png deleted file mode 100755 index d3afdc2c5f..0000000000 Binary files a/docs/kr/clients/lite/pics/absence3.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/architecture.png b/docs/kr/clients/lite/pics/architecture.png deleted file mode 100755 index 741a90c267..0000000000 Binary files a/docs/kr/clients/lite/pics/architecture.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/changeProcess.png b/docs/kr/clients/lite/pics/changeProcess.png deleted file mode 100755 index 1771c239b9..0000000000 Binary files a/docs/kr/clients/lite/pics/changeProcess.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/commitValidation.png b/docs/kr/clients/lite/pics/commitValidation.png deleted file mode 100755 index 89985bcc12..0000000000 Binary files a/docs/kr/clients/lite/pics/commitValidation.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/create-account.png b/docs/kr/clients/lite/pics/create-account.png deleted file mode 100755 index 35a249b97d..0000000000 Binary files a/docs/kr/clients/lite/pics/create-account.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/deposit.png b/docs/kr/clients/lite/pics/deposit.png deleted file mode 100755 index 1fb3acdc5a..0000000000 Binary files a/docs/kr/clients/lite/pics/deposit.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/existProof.png b/docs/kr/clients/lite/pics/existProof.png deleted file mode 100755 index ee5de0851b..0000000000 Binary files a/docs/kr/clients/lite/pics/existProof.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/high-level.png b/docs/kr/clients/lite/pics/high-level.png deleted file mode 100755 index 73a14e0d73..0000000000 Binary files a/docs/kr/clients/lite/pics/high-level.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/light-client-architecture.png b/docs/kr/clients/lite/pics/light-client-architecture.png deleted file mode 100755 index df44aeef50..0000000000 Binary files a/docs/kr/clients/lite/pics/light-client-architecture.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/loadbalanceDiagram.png b/docs/kr/clients/lite/pics/loadbalanceDiagram.png deleted file mode 100755 index 56956ee9d8..0000000000 Binary files a/docs/kr/clients/lite/pics/loadbalanceDiagram.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/simpleMerkleTree.png b/docs/kr/clients/lite/pics/simpleMerkleTree.png deleted file mode 100755 index 5c4e2b76e4..0000000000 Binary files a/docs/kr/clients/lite/pics/simpleMerkleTree.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/substoreProof.png b/docs/kr/clients/lite/pics/substoreProof.png deleted file mode 100755 index 90dadaef37..0000000000 Binary files a/docs/kr/clients/lite/pics/substoreProof.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/transfer-tokens.png b/docs/kr/clients/lite/pics/transfer-tokens.png deleted file mode 100755 index c6635a30c8..0000000000 Binary files a/docs/kr/clients/lite/pics/transfer-tokens.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/transfer.png b/docs/kr/clients/lite/pics/transfer.png deleted file mode 100755 index 7642e996cf..0000000000 Binary files a/docs/kr/clients/lite/pics/transfer.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/trustPropagate.png b/docs/kr/clients/lite/pics/trustPropagate.png deleted file mode 100755 index a743cfc721..0000000000 Binary files a/docs/kr/clients/lite/pics/trustPropagate.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/updateValidatorToHeight.png b/docs/kr/clients/lite/pics/updateValidatorToHeight.png deleted file mode 100755 index b2c9349b6b..0000000000 Binary files a/docs/kr/clients/lite/pics/updateValidatorToHeight.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/validatorSetChange.png b/docs/kr/clients/lite/pics/validatorSetChange.png deleted file mode 100755 index 16dbf39be7..0000000000 Binary files a/docs/kr/clients/lite/pics/validatorSetChange.png and /dev/null differ diff --git a/docs/kr/clients/lite/pics/withdraw.png b/docs/kr/clients/lite/pics/withdraw.png deleted file mode 100755 index 2249b5e348..0000000000 Binary files a/docs/kr/clients/lite/pics/withdraw.png and /dev/null differ diff --git a/docs/kr/clients/lite/specification.md b/docs/kr/clients/lite/specification.md deleted file mode 100755 index 6d51086b36..0000000000 --- a/docs/kr/clients/lite/specification.md +++ /dev/null @@ -1,185 +0,0 @@ -# 라이트 클라이언트 스펙 - -이 문서는 LCD(Light Client Daemon)을 사용하는 방법을 설명합니다. LCD는 모듈러 API를 지원합니다. 현재 LCD는 ICS0 (텐더민트API), ICS1 (키API)와 ICS20 (토큰API) 만을 지원하는 상태입니다. 추후에 추가 모듈을 지원할 예정입니다. - -## ABCI 상태 빌드/검증하기 - -코스모스 SDK 기반 애플리케이션은 멀티-서브스토어(multi-substore)를 이용해 저장을 합니다. 각 서브스토어는 IAVL 스토어를 응용합니다. 서브스토어는 단순한 머클 트리(Merkle tree) 형태로 정렬됩니다. 머클 트리를 만들기 위해서는 각 서브스토어의 이름, 블록 높이 그리고 스토어 루트 해시(store root hash) 필요하며, 이를 기반으로 간단한 머클 가지 노드(Merkle leaf node)를 만들 수 있습니다. 이후 가지 노드를 이용해 해시값을 머클 뿌리(Merkle root)까지 연산하게 됩니다. 단순 머클 트리(simple Merkle tree)의 루트 해시(Root hash)는 블록 헤더에 포함되는 앱 해시(AppHash)입니다. - -![Simple Merkle Tree](./pics/simpleMerkleTree.png) - -[LCD 신뢰 전파](https://github.com/irisnet/cosmos-sdk/tree/bianjie/lcd_spec/docs/spec/lcd#trust-propagation)에서 설명했던바와 같이, 앱해시는 신뢰할 수 있는 검증인 세트의 보팅파워(총 스테이킹 수량)를 검증하는 방식으로 확인할 수 있습니다. 이 절차에는 ABCI 상태에서부터 앱해시 증거를 찾으면 됩니다. 증거에는 다음과 같은 정보가 포함되어있습니다: - -* IAVL 증거 -* 섭스토어에서 앱해시까지의 증거 - -### IAVL 증거 (IAVL proof) - -증거물에는 두 가지의 종류가 있습니다: 존재 증거(existance proof)와 부재 증거(absence proof). 만약 쿼리 키가 IAVL 스토어에 존재하는 경우 키 밸류(key-value)와 존재 증거를 제공하게 됩니다. 반면, 만약 키가 존재하지 않는다면 해당 키가 존재하지 않는 것을 증명할 수 있는 부재 증거를 제공합니다. - -### IAVL 존재 증거 (IAVL Existance Proof) - -```go -type CommitID struct { - Version int64 - Hash []byte -} - -type storeCore struct { - CommitID CommitID -} - -type MultiStoreCommitID struct { - Name string - Core storeCore -} - -type proofInnerNode struct { - Height int8 - Size int64 - Version int64 - Left []byte - Right []byte -} - -type KeyExistsProof struct { - MultiStoreCommitInfo []MultiStoreCommitID //All substore commitIDs - StoreName string //Current substore name - Height int64 //The commit height of current substore - RootHash cmn.HexBytes //The root hash of this IAVL tree - Version int64 //The version of the key-value in this IAVL tree - InnerNodes []proofInnerNode //The path from to root node to key-value leaf node -} -``` - -존재 증거의 데이터 형식은 위와 같이 나열되어 있습니다. 존재 증거를 생성하고 검증하는 방식은 다음과 같습니다: - - -![Exist Proof](./pics/existProof.png) - -증거 생성 절차: - -* 루트 노드에서 IAVL 트리를 액세스 -* 방문 노드(visited node)를 InnerNodes에 기록 -* 타겟 가지 노드(leaf node)를 찾은 경우, 가지 노드 버전을 증거 버전에 할당 -* 현재 IAVL 트리 높이(IAVL tree height)를 증거 높이(proof height)에 할당 -* 현재 IAVL 트리의 루트해시(rootHash)를 증거 루트해시에 할당 -* 현재 서브스토어 이름을 증거 스토어 이름(proof StoreName)에 할당 -* db에서 멀티스토어 커밋 정보(multistore commitInfo)를 읽은 후 증거 StoreCommitInfo에 할당 - -검증 절차: - -* 키, 값 그리고 증거 버전(proof version)을 이용해 리프 노드(leaf node)를 생성 -* 리프 노드 해시값을 연산 -* 해시 값을 innerNoder의 rightHash에 할당한 후, 첫 innnerNode의 해시를 연산 -* 해시 연산 절차를 전파. 만약 위의 innerNode가 다음 innerNode의 left child(좌측 자녀)인 경우, 해당 innerNode를 다음 innerNode의 좌측 해시로 배정한다. 이 외의 경우, 위의 innerNode 해시를 다음 innerNode의 우측 해시로 배정한다. -* 마지막 innerNode의 해시값은 해당 증거의 rootHash와 동일해야 한다. 그렇지 않은 경우, 증거는 무효하다. - -### IAVL 부재 증거(IAVL Absence Proof) - -모든 IAVL 리프 노드는 각 리프노드의 키로 정렬되어있습니다. 그렇기 때문에 IAVL 트리의 전체 키 내의 목표 키 위치를 찾을 수 있습니다. 아래와 같이, 키가 좌측 키 또는 우측 키인지 확인이 가능합니다. 만약 우측 키와 좌측 키의 존재를 증명할 수 있을 경우, 인접 노드(adjecent node) 여부를 증명할 수 있는 것이며 타겟 키가 존재하지 않는다는 것을 증명하게 됩니다. - -![Absence Proof1](./pics/absence1.png) - -만약 타겟 키가 최우측 리프 노드(right most leaf node) 보다 크거나 또는 최좌측 키(left most key) 보다 작은 경우 타겟 키는 존재하지 않음을 증명합니다. - -![Absence Proof2](./pics/absence2.png)![Absence Proof3](./pics/absence3.png) - -```go -type proofLeafNode struct { - KeyBytes cmn.HexBytes - ValueBytes cmn.HexBytes - Version int64 -} - -type pathWithNode struct { - InnerNodes []proofInnerNode - Node proofLeafNode -} - -type KeyAbsentProof struct { - MultiStoreCommitInfo []MultiStoreCommitID - StoreName string - Height int64 - RootHash cmn.HexBytes - Left *pathWithNode // Proof the left key exist - Right *pathWithNode //Proof the right key exist -} -``` - -위는 부재 증거의 데이터 구조입니다. 증거를 생성하는 절차는 다음과 같습니다: - -* 루트 노드에서 IAVL 트리를 액세스 -* 전체 키 세트의 deserved index(INDEX로 표기됨)을 받는다 -* 만약 받은 인덱스의 값이 0일 경우, 우측 인덱스의 값은 0이며 좌측 노드는 존재하지 않는다 -* 만약 받은 인덱스의 값이 전체 키 세트의 크기와 동일한 경우, 좌측 노드 인덱스는 INDEX-1 이어야 하며 우측 노드는 존재하지 않는다 -* 이외의 경우, 우측 노드 인덱스는 INDEX여야 하며 좌측 노드 인덱스는 INDEX-1이다 -* 현재 IAVL 트리의 높이를 증거 높이에 할당한다 -* 현재 IAVL 트리의 rootHash를 증거 rootHash로 할당한다 -* 현재 substore 이름을 증거의 StoreName으로 할당한다 -* db에서 multistore commitInfo를 읽은 후 증거의 StoreCommitInfo에 할당한다 - -증거 검증 절차: - -* 만약 우측 노드만 존재하는 경우, 존재 증거(exist proof)를 검증하여 최좌특 노드인지 확인한다 -* 만약 우측 노드만 존재하는 경우, 존재 증거(exist proof)를 검증하여 최우측 노드인지 확인한다 -* 만약 좌측 노드와 우측 노드가 동시에 존재하는 경우, 두 노드가 인접(adjacent)한지 확인한다 - -### Substores 증거와 AppHash 증거 확인하기 - -IAVL 증거를 검증했다면 substore 증거와 AppHash를 비교하여 검증할 수 있습니다. 우선 MultiStoreCommitInfo를 반복(iterate)하여 proof StoreName을 이용해 서브스토어의 commitID를 찾을 수 있습니다. 여기에서 commitID의 해시가 RootHash의 proof와 동일하다는 것을 검증합니다. 만약 동일하지 않을 경우, 증거는 유효하지 않습니다. 이후 서브스토어 commitInfo 어레이를 서브스토어 이름의 해시 값으로 정렬합니다. 마지막으로, 모든 서브스토어 commitInfo 어레이를 기반으로 단순 머클 트리(simple Merkle tree)를 빌드하여 머클 루트 해시가 앱 해시와 동일한지 검증합니다. - - -![substore proof](./pics/substoreProof.png) - -```go -func SimpleHashFromTwoHashes(left []byte, right []byte) []byte { - var hasher = ripemd160.New() - - err := encodeByteSlice(hasher, left) - if err != nil { - panic(err) - } - - err = encodeByteSlice(hasher, right) - if err != nil { - panic(err) - } - - return hasher.Sum(nil) -} - -func SimpleHashFromHashes(hashes [][]byte) []byte { - // Recursive impl. - switch len(hashes) { - case 0: - return nil - case 1: - return hashes[0] - default: - left := SimpleHashFromHashes(hashes[:(len(hashes)+1)/2]) - right := SimpleHashFromHashes(hashes[(len(hashes)+1)/2:]) - return SimpleHashFromTwoHashes(left, right) - } -} -``` - -## 검증인 세트를 이용한 블록헤더 검증하기 - -위 항목에서는 appHash를 자주 언급합니다. 그렇다면 appHash는 어디에서 존재하는 것일까요? appHash는 블록 헤더에 존재합니다. 그렇기 때문에 특정 블록 높이의 블록헤더를 LCD가 신뢰하는 검증인 세트에 검증해야 합니다. 검증 절차는 다음과 같습니다: - -![commit verification](./pics/commitValidation.png) - -만약 신뢰 검증인 세트가 블록 헤더와 일치하지 않는 경우, 해당 블록 높이의 검증인 세트로 업데이트를 해야합니다. LCD는 검증인 세트의 변경이 보팅 파워의 1/3을 초과할 수 없다는 규칙을 따릅니다. 만약 타겟 검증인 세트가 현재 신뢰되는 검증인 세트에서 1/3 보팅파워를 초과하는 변화가 있는 경우, 타겟 검증인 세트 전에 숨겨진 검증인 세트 변경이 있었는지 확인해야 합니다. 모든 검증인 세트 변경이 이 규칙을 따를때 검증인 세트 업데이트가 이루어질 수 있습니다. - -예를 들어: - -![Update validator set to height](./pics/updateValidatorToHeight.png) - -* Update to 10000, tooMuchChangeErr -* Update to 5050, tooMuchChangeErr -* Update to 2575, Success -* Update to 5050, Success -* Update to 10000,tooMuchChangeErr -* Update to 7525, Success -* Update to 10000, Success diff --git a/docs/kr/clients/service-providers.md b/docs/kr/clients/service-providers.md deleted file mode 100755 index 2c9b5aaea2..0000000000 --- a/docs/kr/clients/service-providers.md +++ /dev/null @@ -1,114 +0,0 @@ -# 서비스 제공자(Service Providers) - -'서비스 제공자'는 코스모스 SDK 기반 블록체인(코스모스 허브도 포함됩니다)과 교류하는 서비스를 엔드유저에게 제공하는 특정 인원/기관을 뜻합니다. 이 문서는 주로 토큰 인터랙션에 대한 정보를 다룹니다. - -다음 항목은 [Light-Client](https://github.com/cosmos/cosmos-sdk/tree/master/docs/interfaces/lite) 기능을 제공하려는 월렛 개발자들에게 해당하지 않습니다. 서비스 제공자는 엔드 유저와 블록체인을 이어주는 신뢰할 수 있는 기관/개인입니다. - -## 보편적 아키텍처 설명 - -다음 세가지 항목을 고려해야 합니다: - -- 풀 노드(Full-nodes): 블록체인과의 인터랙션. -- REST 서버(Rest Server): HTTP 콜을 전달하는 역할. -- REST API: REST 서버의 활용 가능한 엔드포인트를 정의. - -## 풀노드 운영하기 - -### 설치 및 설정 - -다음은 코스모스 허브의 풀노드를 설정하고 운용하는 방법입니다. 다른 코스모스 SDK 기반 블록체인 또한 비슷한 절차를 가집니다. - -우선 [소프트웨어를 설치하세요](../getting-started/installation.md). - -이후, [풀노드를 운영하세요](../getting-started/join-testnet.md). - -### 커맨드 라인 인터페이스 - -다음은 풀노드를 이용할 수 있는 유용한 CLI 커맨드입니다. - -#### 키페어 생성하기 - -새로운 키를 생성하기 위해서는 (기본적으로 secp256k1 엘립틱 커브 기반): - -```bash -gaiacli keys add -``` - -이후 해당 키페어에 대한 비밀번호(최소 8글지)를 생성할 것을 요청받습니다. 커맨드는 다음 4개 정보를 리턴합니다: - - -- `NAME`: 키 이름 -- `ADDRESS`: 주소 (토큰 전송을 받을때 이용) -- `PUBKEY`: 퍼블릭 키 (검증인들이 사용합니다) -- `Seed phrase`: 12 단어 백업 시드키 **이 시드는 안전한 곳에 별도로 보관하셔야 합니다**. 이 시드키는 비밀번호를 잊었을 경우, 계정을 복구할때 사용됩니다. - -다음 명령어를 통해서 사용 가능한 모든 키를 확인할 수 있습니다: - -```bash -gaiacli keys list -``` - -#### 잔고 조회하기 - -해당 주소로 토큰을 받으셨다면 다음 명령어로 계정 잔고를 확인하실 수 있습니다: - -```bash -gaiacli account -``` - -*참고: 토큰이 0인 계정을 조회하실 경우 다음과 같은 에러 메시지가 표시됩니다: 'No account with address was found in the state'. 해당 에러 메시지는 정상이며 앞으로 에러 메시지 개선이 들어갈 예정입니다.* - -#### CLI로 코인 전송하기 - -다음은 CLI를 이용해 코인을 전송하는 명령어입니다: - -```bash -gaiacli send --amount=10faucetToken --chain-id= --from= --to= -``` - -플래그: -- `--amount`: `` 포맷의 코인 이름/코인 수량입니다. -- `--chain-id`: 이 플래그는 특정 체인의 ID를 설정할 수 있게 합니다. 앞으로 테스트넷 체인과 메인넷 체인은 각자 다른 아이디를 보유하게 됩니다. -- `--from`: 전송하는 계정의 키 이름. -- `--to`: 받는 계정의 주소. - -#### Help - -이 외의 기능을 이용하시려면 다음 명령어를 사용하세요: - -```bash -gaiacli -``` - -사용 가능한 모든 명령어를 표기하며, 각 명령어 별로 `--help` 플래그를 사용하여 더 자세한 정보를 확인하실 수 있습니다. - -## REST 서버 설정하기 - -REST 서버는 풀노드와 프론트엔드 사이의 중계역할을 합니다. REST 서버는 풀노드와 다른 머신에서도 운영이 가능합니다. - -REST 서버를 시작하시려면: - -```bash -gaiacli advanced rest-server --node= -``` - -플래그: -- `--node`: 플노드의 주소와 포트를 입력하시면 됩니다. 만약 풀노드와 REST 서버가 동일한 머신에서 운영될 경우 주소 값은 `tcp://localhost:26657`로 설정하시면 됩니다. -- `--laddr`: REST 서버의 주소와 포트를 정하는 플래그입니다(기본 값 `1317`). 대다수의 경우에는 포트를 정하기 위해서 사용됩니다, 이 경우 주소는 "localhost"로 입력하시면 됩니다. 포맷은 입니다. - - -### 트랜잭션 수신 모니터링 - -추천하는 수신 트랜잭션을 모니터링하는 방식은 LCD의 다음 엔드포인트를 정기적으로 쿼리하는 것입니다: - -[`/bank/balance/{account}`](https://cosmos.network/rpc/#/ICS20/get_bank_balances__address_) - -## Rest API - -REST API는 풀노드와 인터랙션이 가능한 모든 엔드포인트를 정의합니다. 다음 [링크](https://cosmos.network/rpc/)에서 확인이 가능합니다. - -API는 엔드포인트의 카테고리에 따라 ICS 스탠다드로 나뉘어집니다. 예를 들어 [ICS20](https://cosmos.network/rpc/#/ICS20/)은 토큰 인터랙션 관련 API를 정의합니다. - -서비스 제공자에게 더 많은 유연성을 제공하기 위해서 미서명 트랜잭션을 생성, [서명](https://cosmos.network/rpc/#/ICS20/post_tx_sign)과 [전달](https://cosmos.network/rpc/#/ICS20/post_tx_broadcast) 등의 다양한 API 엔드포인트가 제공됩니다. 이는 서비스 제공자가 자체 서명 메커니즘을 이용할 수 있게 합니다. - -미서명 트랜잭션을 생성하기 위해서는 (예를 들어 [코인 전송](https://cosmos.network/rpc/#/ICS20/post_bank_accounts__address__transfers))을 생성하기 위해서는 `base_req` body에서 `generate_only` 플래그를 이용하셔야 합니다. diff --git a/docs/kr/concepts/baseapp.md b/docs/kr/concepts/baseapp.md deleted file mode 100644 index ec868537b4..0000000000 --- a/docs/kr/concepts/baseapp.md +++ /dev/null @@ -1,85 +0,0 @@ -# 베이스앱(BaseApp) - -베이스앱(BaseApp)은 코스모스 SDK 애플리케이션이 텐더민트 노드와 소통할 수 있게하는 기본적 ABCI 애플리케이션의 기반을 정의합니다. - -베이스앱은 다수의 내부 컴포넌트로 구성되어있습니다. 이 중 가장 중요한 컴포넌트는 `CommitMultiStore`와 해당 컴포넌트의 내부 상태(internal state)입니다. 내부 상태는 하위 두 개의 서브스테이트(substate)로 구성되어있으며, 두 서브 스테이트는 각자 트랜잭션 실행 단계의 `CheckTx`와 `DeliverTx` 이용됩니다. 블록 커밋 단계에서는 `DeliverTx`만이 유지됩니다. - -베이스앱은 capabilities keys를 통해 스토어에 마운트 되어야 합니다. 핸들러는 키가 부여된 스토어에만 접근할 수 있습니다. 베이스앱은 모든 스토어가 정상적으로 로딩, 캐쉬 그리고 커밋되는 것을 보장합니다. 마운트 된 스토어 중 '메인(`baseApp.MainstoreKey`' 스토어는 최신 블록 헤더 정보를 보관하며, 이를 기반으로 가장 최근 상태(state)를 찾고 불러올 수 있습니다. - -베이스앱은 `AnteHandler`와 `MsgHandler` 두 가지의 핸들러 타입을 받습니다. `AnteHandler`는 논스값 확인, 서명 확인, 수수료 지불 가능 잔고 확인 등 모든 모듈에서 이용되는 트랜잭션 기능의 글로벌 유효성 검증(global validity check)을 수행합니다. `MsgHandler`의 경우 상태 변경(full state transition) 기능을 수행합니다. - -`CheckTx` 단계에서 상태 변경 기능은 `checkTxState`에만 적용되며, 값비싼 스테이트 변경 작업이 실행되기 전에 리턴을 해야합니다(관련 절차 설계는 각 개발자의 자유입니다). 또한 예상 가스 비용을 리턴해야 합니다. - -`DeliverTx` 단계에서는 상태 변경 기능이 블록체인 상태에 적용되며 트랜잭션은 완전하게 실행되어야 합니다. - -베이스앱은 핸들러에게 전달되는 컨텍스트(context)를 관리하는 역할을 합니다. 또한 `CheckTx`와 `DeliverTx`에게 할당되는 스토어와 블록헤더 정보를 제공합니다. 베이스앱은 시리얼화 포맷(serialization format)에 불가지론적(agnostic)입니다. - -## 트랜잭션 라이프 사이클(Transaction Life Cycle) - -트랜잭션은 실행 단계에서 ABCI 스펙 정의에 따라 `CheckTx`와 `DeliverTx`를 거칠 수 있습니다. `CheckTx`는 블록 제안 검증인이 실행하며 모든 풀노드의 텐더민트 멤풀에서 이용됩니다. - -`CheckTx`와 `DeliverTx`는 (정의된 경우) 애플리케이션의 안티핸들러(AnteHandler)를 실행합니다. 여기서 안티핸들러는 메시지-전(pre-message) 검증을 수행하여 계정, 서명 검증, 수수료 삭감, 수수료 수금, 시퀀스 번호 추가 등의 기능을 수행합니다. - -### CheckTx - -`CheckTx`의 실행 단계에서는 안티핸들러(AnteHandler)만이 실행됩니다. - -안티핸들러로 발생하는 상태 변경은 안티핸들러가 실패하여 중단되는 경우를 제외하고는 check-tx 상태의 `CheckTx`의 추후 콜(call)까지 지속됩니다. - -### DeliverTx - -`DeliverTx`의 실행 단계에서는 안티핸들러(AnteHandler)와 핸들러(Handler)가 함께 실행됩니다. - -`DeliverTx`의 트랜잭션 실행 절차는 `CheckTx`와 유사하게 진행됩니다. 다만, 안티핸들러로 발생하는 상태 변경은 핸들러의 프로세싱 로직이 실패하여도 지속됩니다. - -악의적 제안자(proposer)가 안티핸들러를 통과하지 못하는 트랜잭션을 발생할 수 있는 경우가 발생할 수도 있습니다. 이 경우에는 악의적 트랜잭션의 상태 변경은 버려집니다(무시됩니다). - -## 다른 ABCI 메시지 - -`CheckTx`와 `DeliverTx` 외에도 베이스앱은 다음과 같은 ABCI 메시지를 처리합니다. - -### Info -TODO complete description (추후 업데이트 예정) - -### SetOption -TODO complete description (추후 업데이트 예정) - -### Query -TODO complete description (추후 업데이트 예정) - -### InitChain -TODO complete description (추후 업데이트 예정) - -체인 시동(chain initialization) 단계에서 `InitChain`은 `CommitMultiStore`에 직접적으로 할당되어 있는 시동 로직을 실행합니다. check state와 deliver state는 정의된 ChainID로 시작됩니다. - -참고할 것은 InitChain 이후에 커밋을 실행하지 않습니다. 그렇기 때문에 블록 1의 BeginBlock은 InitChain이 시작한대로 deliver state에서 시작됩니다. - -### BeginBlock -TODO complete description (추후 업데이트 예정) - -### EndBlock -TODO complete description (추후 업데이트 예정) - -### Commit -TODO complete description (추후 업데이트 예정) - - -## 가스 관리(Gas Management) - -### 가스: InitChain - -InitChain 실행 단계에서 블록 가스 미터는 제네시스 트랜잭션을 처리하기 위하여 무한대 가스 수량을 기준으로 시작됩니다. - -또한, InitChain의 리퀘스트 메시지에는 genesis.json 파일이 정의하는 ConsensusParams가 포함되어있습니다. - - -### 가스: BeginBlock - -블록 가스 미터는 BeginBlock의 deliver state에서 리셋됩니다. 만약 베이스앱에서 최대 블록 가스가 설정되어있지 않은 경우, 가스 미터는 무한으로 설정됩니다. 최대 블록 가스가 설정되었을 경우, 가스 미터는 `ConsensusParam.BlockSize.MaxGas`를 통해 설정됩니다. - -### 가스: DeliverTx - -특정 트랜잭션이 실행되기 전, `BlockGasMeter`를 우선 확인하여 남은 가스가 있는지 확인합니다. 만약 남은 가스가 없다면 `DeliverTx`는 즉시 에러를 리턴합니다. - -트랜잭션이 처리된 후, 사용된 가스는 (설정된 가스 리밋에 따라) `BlockGasMeter`에서 차감됩니다. 만약 잔류 가스가 가스 미터의 한도를 초과할 경우, `DeliverTx`는 에러를 리턴하고 해당 트랜잭션은 커밋되지 않습니다. - diff --git a/docs/kr/concepts/store/README.md b/docs/kr/concepts/store/README.md deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/docs/kr/cosmos-docs.jpg b/docs/kr/cosmos-docs.jpg deleted file mode 100755 index 81c326e845..0000000000 Binary files a/docs/kr/cosmos-docs.jpg and /dev/null differ diff --git a/docs/kr/cosmos-sdk-image.png b/docs/kr/cosmos-sdk-image.png deleted file mode 100755 index ab9a4abc68..0000000000 Binary files a/docs/kr/cosmos-sdk-image.png and /dev/null differ diff --git a/docs/kr/intro/README.md b/docs/kr/intro/README.md deleted file mode 100755 index 2dbf83838d..0000000000 --- a/docs/kr/intro/README.md +++ /dev/null @@ -1,16 +0,0 @@ - - -# 소개 - -이 폴더에는 Cosmos-SDK에 대한 소개 자료가 포함되어 있습니다. - -1. [SDK 소개](./overview.md) -2. [애플리케이션 특화 블록체인](./why-app-specific.md) -3. [SDK 애플리케이션의 아키텍쳐](./sdk-app-architecture.md) -4. [코스모스 SDK 디자인 소개](./sdk-design.md) - -해당 기본 자료를 읽으신 후 [basics](../basics/README.md) 폴더에 있는 자료를 읽어보시는 것을 추천드립니다. \ No newline at end of file diff --git a/docs/kr/intro/ocap.md b/docs/kr/intro/ocap.md deleted file mode 100755 index ba0a2058d4..0000000000 --- a/docs/kr/intro/ocap.md +++ /dev/null @@ -1,68 +0,0 @@ -# 오브젝트-가능성 모델(Object-Capability Model) - -## 개요 - -보안을 검토하기 위해서는 특정 위협 모델(threat model)을 검토하는 것으로 시작하는 것이 좋습니다. 우리가 제시하는 모델은 다음과 같습니다: - -> 코스모스-SDK 모듈을 기반으로 만들어진 블록체인 애플리케이션이 활성화된 생태계에는 허점이 있거나 악의적인 모듈이 존재할 수 있다고 전재합니다. - -코스모스 SDK는 오브젝트-가능성 시스템의 토대가 됨으로 이런 문제점을 해결할 수 있습니다. - -> 오브젝트 가능성 시스템의 구조적 속성은 코드 디자인의 모듈화와 안정적인 캡슐화(encapsulation)를 선호합니다. -> -> 이런 구조적 속성은 오브젝트-가능 프로그램 또는 운영체제의 보안적 속성의 분석을 가능하게 합니다. 정보 플로우 속성(information flow properties) 같은 일부 속성은 특정 오브젝트의 행동을 결정하는 코드의 지식 또는 분석 없이도 오직 오브젝트 레퍼런스와 연결구조만으로 분석이 가능합니다. -> -> 그렇기 때문에, 악의적인 코드가 포함되있을 확률이 있는 새로운 오브젝트가 소개되더라도 보안적 속성은 지켜질 수 있습니다. -> -> 이런 구조적 속성은 해당 오브젝트를 통치하는 두가지 법칙에 의해 지켜질 수 있습니다: -> 1. 오브젝트 'A'는 'B'에 대한 레퍼런스를 보유하고 있을 경우에만 메시지를 전송할 수 있다. -> 2. 오브젝트 'A'가 'C'에 대한 레퍼런스를 가지고 싶다면 오브젝트 'A'는 'C'에 대한 레퍼런스가 포함된 메시지를 수신해야 한다. -> -> 이 두 법칙에 따르면 특정 오브젝트는 기존에 존재하는 레퍼런스 체인을 통해서만 다른 오브젝트에 대한 레퍼런스를 받을 수 있는 것입니다. 단순하게 설명하면 "연결성이 연결성을 불러온다"는 것입니다. - -오브젝트 가능성에 대한 소개는 [이 글(영문)](http://habitatchronicles.com/2017/05/what-are-capabilities/)을 참고하세요. - -원칙적으로 말하면, 다음과 같은 문제점 때문에 Golang은 엄격한 오브젝트 가능성을 도입하지 않는다고 볼 수 있습니다: - -- 보편적으로 "unsafe" 또는 "os" 같은 원시적 모듈(primitive module)을 임포트할 수 있음. -- 보편적으로 [모듈 vars 오버라이드(https://github.com/golang/go/issues/23161)]가 가능. -- 2개 이상의 goroutine이 illegal interface value를 만들 수 있는 data-race 허점. - -문제점 중 첫번째 문제는 임포트 감사(import audit)과 체계적인 디펜던시 버전 컨트롤 시스템(dependency version control system)을 이용하여 문제점을 사전에 찾을 수 있습니다. 다만, 두번째와 세번째 문제는 다서 불편하기는 하지만 노력을 통해서 감사(audit)가 가능합니다. - -현재로써는 [Go2에서 오브젝트 가능성 모델이 도입되는](https://github.com/golang/go/issues/23157)것을 기대하는 상태입니다. - -## 실전에서의 오브젝트 가능성 모델(Ocaps) - -Ocaps의 핵심 아이디어는 특정 일을 수행하는데 필요한 정보만을 공개하는 것입니다. - -예를 들어, 다음의 코드는 오브젝트 가능성 원칙을 위해합니다: - -```go -type AppAccount struct {...} -var account := &AppAccount{ - Address: pub.Address(), - Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)}, -} -var sumValue := externalModule.ComputeSumValue(account) -``` - -위 코드의 `ComputeSumValue` 메소드는 순수한(pure) 함수를 암시하지만, 포인터 밸류를 받아드리는 것의 암시된 가능성(implied capability)은 해당 밸류를 변경할 수 있는 가능성입니다. 서명 메소드는 그대로 포인터 밸류를 받아들이지 않고 해당 밸류의 사본을 사용하는 것이 바람직합니다. - -```go -var sumValue := externalModule.ComputeSumValue(*account) -``` - -코스모스 SDK에서 이 원칙을 응용한 것을 [gaia 앱](../gaia/app/app.go)에서 확인이 가능합니다. - -```go -// register message routes -app.Router(). - AddRoute(bank.RouterKey, bank.NewHandler(app.bankKeeper)). - AddRoute(staking.RouterKey, staking.NewHandler(app.stakingKeeper)). - AddRoute(distr.RouterKey, distr.NewHandler(app.distrKeeper)). - AddRoute(slashing.RouterKey, slashing.NewHandler(app.slashingKeeper)). - AddRoute(gov.RouterKey, gov.NewHandler(app.govKeeper)) -``` - - diff --git a/docs/kr/intro/overview.md b/docs/kr/intro/overview.md deleted file mode 100644 index 1056410c0a..0000000000 --- a/docs/kr/intro/overview.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -order: 1 ---- - -# SDK 소개 - -## 코스모스 SDK는 무엇인가? - -[코스모스 SDK](https://github.com/cosmos/cosmos-sdk)는 코스모스 허브와 같은 다수 자산(multi-asset) 퍼블릭 지분증명 블록체인과 권한증명(PoA, Proof-of-Authority) 블록체인을 만들 수 있는 오픈소스 프레임워크입니다. 코스모스 SDK를 사용하여 만들어진 블록체인은 통상 **애플리케이션 특화 블록체인(application-specific blockchain)**이라 불립니다. - -코스모스 SDK의 목적은 개발자가 간편하게 처음부터 다른 블록체인과 상호환이 가능한 블록체인을 만들 수 있게 하는 것이 목적입니다. 코스모스 SDK는 npm과 같은 프레임워크로 자리잡으며 [텐더민트](https://github.com/tendermint/tendermint) 상의 안전한 블록체인 애플리케이션을 만들 수 있게 자리잡는 것이 목표입니다. SDK 기반 블록체인은 구성적(composable) 모듈을 기반으로 만들어지며, 대다수의 모듈은 오픈 소스로 모든 개발자가 사용할 수 있습니다. 누구나 코스모스 SDK 모듈을 만들 수 있으며, 단순히 블록체인 애플리케이션에 모듈을 불러와 이미 개발된 모듈을 간편하게 사용할 수 있습니다. 또한, 코스모스 SDK는 능력성 기반(capabilities-based) 시스템으로 모듈 간 인터랙션의 보안성을 더욱 직관적으로 설계할 수 있습니다. 능력성 기반 시스템에 대해 더 알고싶으시다면 [이 항목](./ocap.md)을 참고하세요. - -## 애플리케이션 특화 블록체인은 무엇인가? - -최근 블록체인 업계의 개발 패러다임 중 하나는 이더리움과 같은 버추얼 머신(virtual-machine) 기반 블록체인입니다. 이런 시스템에서는 기존 블록체인 상위에 스마트 컨트랙트 기반의 탈중앙화 애플리케이션을 만드는 형태로 개발됩니다. 스마트 컨트랙트는 단순 애플리케이션 (예, ICO) 용도로 적합하지만, 복잡한 탈중앙화 플랫폼을 개발하는 목적에는 적합하지 않습니다. 스마트 컨트랙트는 유연성, 존엄성 그리고 성능 측면에서 한계가 존재합니다. - -애플리케이션 특화 블록체인은 기존 버추얼 머신 기반 블록체인과는 획기적으로 다른 개발 패러다임을 제공합니다. 애플리케이션 특화 블록체인은 하나의 애플리케이션을 구동하기 위해 특화되며, 개발자는 애플리케이션이 최적한 환경에서 구동될 수 있는 디자인 결정을 내릴 수 있습니다. 또한 애플리케이션 특화 블록체인은 애플리케이션 존엄성, 보안 그리고 성능 측면에서 장점을 가집니다. - -애플리케이션 특화 블록체인에 대한 더 자세한 정보는 [여기](./why-app-specific.md)를 참고하세요. - -## 왜 코스모스 SDK인가? - -코스모스 SDK는 고유 애플리케이션 특화 블록체인을 만들기 위한 가장 우수한 프레임워크입니다. 다음은 코스모스 SDK가 탈중앙화 애플리케이션을 개발하는데 제공하는 장점들입니다: - -- 코스모스 SDK가 기본적으로 제공하는 합의 엔진은 [텐더민트 코어](https://github.com/tendermint/tendermint)입니다. 텐더민트는 가장 오랜 기간 증명된 BFT 기반 컨센서스 엔진입니다. 텐더민트 코어는 업계 내의 수 많은 환경에서 지분증명 시스템을 개발하는데 사용되고 있습니다. -- 코스모스 SDK는 오픈소스이며 구성적(composable) 모듈을 기반으로 간편하게 블록체인을 만들 수 있습니다. 블록체인 생태계가 성장하며 더욱 다양한 코스모스 SDK 모듈들이 개발되고 있으며, 이런 모듈들을 기반으로 복잡한 탈중앙화 플랫폼을 개발하는 과정이 간소화됩니다. -- 코스모스 SDK는 능력성 기반(capabilities-based) 보안 아키텍쳐를 기반으로 설계되었습니다. 이런 디자인 결정은 수년간 블록체인 스테이트 머신(state machine)에 대한 고민을 기반으로 설계되었으며, 더욱 안전한 블록체인을 개발할 수 있는 환경을 제공합니다. -- 가장 중요한 것은 바로 코스모스 SDK가 실제 작동하고 있는 다수의 애플리케이션 특화 블록체인을 개발하는데 사용되고 있다는 점입니다. [코스모스 허브](https://hub.cosmos.network), [아이리스 허브](https://irisnet.org), [바이낸스 체인](https://docs.binance.org), [테라](https://terra.money), [Lino](https://lino.network) 등의 프로젝트가 코스모스 SDK 기반으로 개발되었습니다. 코스모스 기반 프로젝트 목록은 [여기](https://cosmos.network/ecosystem)에서 확인하실 수 있습니다. - -## 코스모스 SDK 입문하기 - -- [코스모스 SDK 기반 애플리케이션의 구조](./sdk-app-architecture.md)에 대해서 더 알아보세요 -- 애플리케이션 특화 블록체인을 처음부터 개발하는 방법을 [코스모스 SDK 투토리얼](https://cosmos.network/docs/tutorial)을 통해 배워보세요 diff --git a/docs/kr/intro/sdk-app-architecture.md b/docs/kr/intro/sdk-app-architecture.md deleted file mode 100755 index bb56435446..0000000000 --- a/docs/kr/intro/sdk-app-architecture.md +++ /dev/null @@ -1,100 +0,0 @@ - - - -# SDK 애플리케이션 아키텍쳐 - -## 상태 기계 (state machine) - -블록체인 애플리케이션은 근본적으로 [결정론적 복제 상태 기계(replicated deterministic state machine)](https://ko.wikipedia.org/wiki/%EC%83%81%ED%83%9C_%EA%B8%B0%EA%B3%84_%EB%B3%B5%EC%A0%9C)입니다. - -상태 기계는 특정 시점에 오직 하나의 상태를 유지하는 있는 컴퓨터 공학 개념입니다. 여기서 '상태 기계' 개념에는 시스템의 현 상태를 뜻하는 '상태(state)'가 있으며, 상태의 변경을 유발하는 -트랜잭션(transaction)'이 있습니다. - -`S` 라는 상태와 `T` 라는 트랜잭션이 있는 경우, 상태 기계는 `S'`라는 새로운 상태를 리턴합니다. - -``` -+--------+ +--------+ -| | | | -| S +---------------->+ S' | -| | (T)적용 | | -+--------+ +--------+ -``` - -실질적으로는 트랜잭션은 블록 단위로 묶여 상태 변경 과정을 더 효율적일 수 있게 합니다. `S`라는 상태와 `B`라는 트랜잭션이 있는 경우, 상태 기계는 `S'`라는 새로운 상태를 리턴합니다. - -``` -+--------+ +--------+ -| | | | -| S +----------------------------> | S' | -| | B의 T 수만큼: (T)적용 | | -+--------+ +--------+ -``` - -블록체인 시스템 개념으로 점그할때, 상태 기계는 결정론적(deterministic)입니다. 즉, 노드가 특정 상태에서 시작된 후 동일한 트랜잭션들을 반복할 경우, 결과 상태는 언제나 동일합니다. - -코스모스 SDK는 애플리케이션의 상태, 트랜잭션 형태 그리고 상태 변경 기능(state-transition function)을 정의하는데 최대한의 유연성을 제공합니다. 코스모스 SDK를 이용해 상태 기계를 만드는 과정은 이후 항목에서 다루겠습니다. 우선 이 시스템 내에서 어떻게 **텐더민트**를 사용해 '상태'가 복제되는지 알아보겠습니다. - -## 텐더민트 - -개발자는 코스모스 SDK를 사용하여 상태 기계만을 정의하면 되며, 해당 상태를 네트워크에 복제하는 기능은 [*텐더민트*](https://tendermint.com/docs/introduction/introduction.html)가 제공합니다. - - -``` - ^ +-------------------------------+ ^ - | | | | 코스모스 SDK로 개발 - | | 상태 기계 = 애플리케이션 | | - | | | v - | +-------------------------------+ - | | | ^ - 블록체인 노드 | | 컨센서스 | | - | | | | - | +-------------------------------+ | 텐더민트 코어 - | | | | - | | 네트워킹 | | - | | | | - v +-------------------------------+ v -``` - -텐더민트는 오직 블록체인의 *네트워킹*과 *합의(컨센서스)* 계층을 처리하는 애플리케이션-불가지성(application-agnostic) 엔진입니다. 실질적으로 텐더민트는 단순히 트랜잭션의 바이트를 나열하고, 해당 트랜잭션을 네트워크에 전파하는 역할만을 한는 것입니다. 텐더민트 코어는 텐더민트 비잔틴 결함 감내(BFT, Byzantine-fault tolerant) 알고리즘을 사용하여 트랜잭션 순서에 대한 합의를 합니다. - -텐더민트 합의 알고리즘은 '검증인(Validators)'이라는 특정 노드 세트를 기반으로 작동합니다. 특정 블록에는 V 검증인 세트 검증인 존재하며, 이 V 검증인 세트 안에 있는 검증인 중 하나의 검증인이 다음 블록 생성자로 알고리즘에 의해 선택됩니다. 만약 블록이 V 검증인 세트 2/3 이상의 [프리보트(prevote)](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)와 [프리커밋(precommit)](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)을 받고 내용 트랜잭션이 유효한 경우 해당 블록은 '유효(valid)'한 것으로 간주됩니다. 검증인 세트는 상태 기계에 작성된 규칙에 따라서 바뀔 수 있습니다. - -## ABCI - -텐더민트는 ABCI라를 인터페이스를 사용해 트랜잭션을 애플리케이션에게 전달합니다. 이는 어플리케이션이 반드시 구현해야하는 부분입니다. - -``` -+---------------------+ -| | -| 애플리케이션 | -| | -+--------+---+--------+ - ^ | - | | ABCI - | v -+--------+---+--------+ -| | -| | -| 텐더민트 | -| | -| | -+---------------------+ -``` - -**텐더민트는 오직 거래의 bytes 값들만 취급하지 실제 그 bytes 들이 어떤 의미를 가지고 있는지는 파악하지 않습니다.** 텐더민트가 하는 일은 이 거래 bytes 들을 결정론적으로 나열하는 것 뿐입니다. 텐더민트는 이 bytes 들을 ABCI 를 통해서 어플리케이션에 넘겨주고, 그 메세지에 담겨있는 거래들이 잘 처리되었는지 안되었는지를 확인해주는 return code 를 기다립니다. - -아래에 ABCI 의 메세지들 중 가장 중요한 것들을 나열해놓았습니다: - -- `CheckTx`: 텐더민트 코어로부터 거래를 받게 될 때, 이 거래는 어플리케이션에 넘겨져서 몇 가지 기본 요건을 충족하는지 확인합니다. `CheckTx` 는 풀노드의 mempool을 스팸행위로 부터 보호하는데 사용됩니다. "Ante Handler" 라고 불리우는 특별한 handler 는 일련의 검증 과정을 실행하는데 사용됩니다. 예를 들면, 충분한 수수료가 있는지, 그리고 서명이 유효한지 확인합니다. 만약 검사 결과가 유효한 경우 되면, 해당 거래는 [mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality)에 추가되고 피어 노드에게 전달됩니다. 참고로 트랜잭션이 블록에 추가되기 전까지는 `CheckTx` 과정이 진행되지 않습니다. (즉, 상태의 변경이 일어나지 않습니다.) - -- `DeliverTx` : 텐더민트 코어가 [유효한 블록](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation)을 전달받는 경우, 각 블록의 트래잭션은 `DeliverTx`를 통해 애플리케이션에 전달합니다. 이 단계에서 상태 변경이 일어납니다. `AnteHandler`는 트랜잭션에 포함된 각 메세지를 검증하기 위해 다시 실행됩니다. - -- `BeginBlock`/`EndBlock` : 해당 메세지는 블록내 트랜잭션 유뮤와는 별개로 블록 시작과 끝 단계에서 실행됩니다. 여기에서 로직의 자동 실행을 설정하는 것이 유용합니다. 하지만 복잡한 연산 또는 루프는 블록체인의 속도를 저하할 수 있으며, 무한 루프의 경우 블록체인을 멈출 수 있습니다. - -ABCI 메소드와 타입에 대해서 더 자세하게 싶다면, [텐더민트 문서](https://tendermint.com/docs/spec/abci/abci.html#overview)를 참고하세요. - -텐더민트 위에 구현된 모든 어플리케이션은 하위 텐더민트 엔진과 소통하기 위해 ABCI 인터페이스를 구현해야만 합니다. 물론 코스모스 SDK를 사용하는 경우, 코스모스 SDK가 [baseapp](https://cosmos.network/docs/intro/sdk-design.html#baseapp) 의 형태로 일종의 템플릿를 제공합니다. - -### 다음은 [SDK 설계 원칙에 대해서 알아보세요](https://cosmos.network/docs/intro/sdk-design.html#baseapp) diff --git a/docs/kr/intro/sdk-design.md b/docs/kr/intro/sdk-design.md deleted file mode 100644 index ef0cf63b80..0000000000 --- a/docs/kr/intro/sdk-design.md +++ /dev/null @@ -1,95 +0,0 @@ - - -# 코스모스 SDK의 주요 구성 요소 - -코스모스 SDK는 텐더민트 위에서 안전한 상태 기계를 구현하는 프레임워크입니다. 핵심적으로, 코스모스 SDK는 일종의 Go 언어로 구현된 [ABCI](./sdk-app-architecture.md#abci) 구현체 템플릿입니다. 코스모스 SDK에는 데이터를 지속하는 [`multistore`](../core/store.md#multistore)와 트래잭션을 처리하는 [`router`](../core/baseapp.md#routing)가 내장되어 있습니다. - -다음은 코스모스 SDK로 만들어진 애플리케이션에서 텐더민트에서 `DeliverTx`로 전달된 트랜잭션이 처리되는 과정을 간소화한 설명입니다: - -1. 텐더민트 컨센서스 엔진(텐더민트는 `[]bytes`만을 다룬다는 것을 참고하세요)에서 전달된 `transaction`을 디코딩 -2. `transaction`에서 `messages`를 추출한 후 기본적인 타당성 검사를 진행 -3. 각 메시지가 처리될 수 있게 올바른 모듈에게 라우팅 -4. 상태 변경 실행 - -## `baseapp` - -`baseapp`은 코스모스 SDK 애플리케이션 구현체 템플릿입니다. 하위 컨센서스 엔진과 연결을 처리하기 위한 구현체가 포함 되어있습니다. 통상, 코스모스 SDK 애플리케이션에서는 [`app.go`](../basics/app-anatomy.md#core-application-file)내에 `baseapp`을 임베딩합니다. 이에 대한 예시는 코스모스 SDK 애플리케이션 튜토리얼을 참고하세요: - -+++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go#L72-L92 - -`baseapp`의 목표는 스토어와 확장 가능한 상태 기계간의 안전한 인터페이스를 제공함과 동시에 상태 기계를 최소한으로 정의하는(ABCI 디자인 목적에 따라) 것입니다. - -`baseapp`에 대한 추가 정보는 [여기](../core/baseapp.md)를 참조하세요. - -## 멀티스토어 - -코스모스 SDK는 지속되는 상태를 위해 [`멀티스토어/multistore`](../core/store.md#multistore)를 제공합니다.멀티스토어는 개발자가 원하는 수량의 [`KVtore`](../core/store.md#base-layer-kvtores)를 선언할 수 있도록 합니다. `KVStore`는 오직 `[]byte` 타입만을 유효한 값으로 받기 때문에 자체 스트럭쳐는 [코덱](../core/encoding.md)을 사용해 마셜된 후 저장되어야 합니다. - -멀티스토어를 추상화한 이유는 상태를 구획화하기 위한 목적이 있으며, 각자 해당되는 모듈에 의해 관리됩니다. 멀티스토어 대한 추가 정보는 [여기](../core/store.md#multistore)를 확인하세요. - -## 모듈 - -코스모스 SDK의 강점은 바로 모듈성에 있습니다. SDK 기반 애플리케이션은 다수의 상호 호환되는 모듈을 모아서 개발됩니다. 각 모듈은 상태의 특정 분야를 정의하고 자체적인 메시지/트랜잭션 처리 기능을 가지고 있으며, 코스모스 SDK는 각 메시지를 해당되는 모듈에 라우팅하는 역할을 합니다. - -다음은 어떻게 트랜잭션이 각 풀노드가 유효한 블록을 받았을때 애플리케이션에 의해 처리되는지를 설명합니다: - -``` - + - | - | DeliverTx를 통해 풀노드의 텐더민트에서 - | 노드의 애플리케이션으로 전달된 트랜잭션 - | - | - | - +---------------------v--------------------------+ - | 애플리케이션 | - | | - | 베이스앱의 메서드를 사용해: Tx 디코딩, | - | 메시지 추출 후 라우팅 | - | | - +---------------------+--------------------------+ - | - | - | - +---------------------------+ - | - | - | - | 처리를 위해 올바른 - | 모듈로 라우팅된 메시지 - | - | -+----------------+ +---------------+ +----------------+ +------v----------+ -| | | | | | | | -| AUTH 모듈 | | BANK 모듈 | | STAKING 모듈 | | GOV 모듈 | -| | | | | | | | -| | | | | | | 메시지 처리, | -| | | | | | | 상태 업데이트 | -| | | | | | | | -+----------------+ +---------------+ +----------------+ +------+----------+ - | - | - | - | - +--------------------------+ - | - | 결과 값 텐더민트로 전달 - | (0=Ok, 1=Err) - v -``` - -각 모듈은 미니 상태 기계로 볼 쑤 있습니다. 개발자는 각 모듈이 처리하는 상태의 부분과 상태를 바꾸는 고유 메시지 타입을 정의해야합니다(*참고*: 메시지는 트랜잭션에서 `baseapp`을 통해 추출됩니다). 통상적으로, 각 모듈은 각자의 `KVStore`를 `multistore`에 선언하여 해당 모듈이 정의하는 상태의 부분을 지속합니다. 개발자는 본인의 모듈을 만들때 제 삼자의 모듈을 액세스해야할 수 있습니다. 코스모스-SDK는 오픈 프레임워크이기 때문에, 일부 모듈은 악성 모듈일 가능성이 존재하며 이런 인터-모듈 소통에서 보안 원칙이 존재합니다. 이런 원칙은 [오브젝트-가능성(object-capabilities)](../core/ocap.md)를 따릅니다. 실전에서는, 각 모듈이 다른 모듈의 액세스 권한 리스트를 관리하는 것이 아니라, 각 모듈이 `keeper`라는 특별 오브젝트를 구현하여 접근 가능한 권한을 사전에 정의합니다. - -SDK의 모듈은 `x/` 폴더 내에 정의되며, 핵심 모듈 중 일부는 다음과 같습니다: - -- `x/auth`: 계정과 서명 관리에 사용됨 -- `x/bank`: 토큰과 토큰 전송 기능에 사용됨 -- `x/staking` + `x/slashing`: 지분증명 블록체인을 만들기 위해 사용됨 - -모두가 본인의 앱을 만들기 위해 사용할 수 있는 `x/` 내 존재하는 모듈 외에도, 코스모스 SDK는 자체 모듈을 개발할 수 있도록합니다. 이에 대한 예시는 [이 튜토리얼](https://cosmos.network/docs/tutorial/keeper.html)을 참고하세요. - -## 다음 {hide} - -[코스모스 SDK 애플리케이션 해부학](../basics/app-anatomy.md)에 대해서 알아보세요 {hide} diff --git a/docs/kr/intro/why-app-specific.md b/docs/kr/intro/why-app-specific.md deleted file mode 100644 index e52efcd83d..0000000000 --- a/docs/kr/intro/why-app-specific.md +++ /dev/null @@ -1,80 +0,0 @@ - - -# 애플리케이션 특화 블록체인 - -이 문서는 애플리케이션 특화 블록체인(application-specific blockchain)을 정의하고, 왜 개발자들이 스마트 컨트랙트 대신 애플리케이션 특화 블록체인을 사용하는데 장점이 있는지 설명합니다. {synopsis} - -## 애플리케이션 특화 블록체인은 무엇인가? - -애플리케이션 특화 블록체인은 하나의 애플리케이션을 운영하는데 특화된 블록체인입니다. 이더리움과 같이 하나의 블록체인 플랫폼 위에서 탈중앙화 애플리케이션을 만드는 것이 아니라, 애플리케이션 특화 블록체인은 블록체인의 모든 계층을 직접 만드는 형태입니다. 즉, 풀 노드 클라이언트, 라이트 클라이언트, 필수 인터페이스(CLI, REST, 등)를 노드와 소통하도록 개발하게 됩니다 - -``` - ^ +-------------------------------+ ^ - | | | | 코스모스 SDK로 개발 - | | 상태 기계 = 애플리케이션 | | - | | | v - | +-------------------------------+ - | | | ^ - 블록체인 노드 | | 컨센서스 | | - | | | | - | +-------------------------------+ | 텐더민트 코어 - | | | | - | | 네트워킹 | | - | | | | - v +-------------------------------+ v -``` - -## 스마트 컨트랙트의 한계는 무엇인가? - -이더리움과 같은 버추얼 머신(virtual machine) 기반 블록체인은 2014년 당시 블록체인의 프로그램화에 대한 수요를 충족했습니다. 다수의 개발자는 복잡하고 한계가 있는 비트코인 스크립트 언어로 애플리케이션을 개발하거나, 수정하기 어려운 비트코인 코드 포크해야하는 어려움이 있었기 때문입니다. - -이런 시기에, 버추얼 머신 기반 블록체인은 새로운 가치 제안을 하게됩니다. 상태 기계(state machine)가 일종의 버추얼 머신을 운용하여 '스마트 컨트랙트'라는 튜링 완전한 프로그램을 실행할 수 있도록 했습니다. 이런 스마트 컨트랙트는 일시적 이벤트에 매우 적절하지만 (예, ICO) 복잡한 탈중앙화 플랫폼을 개발하는대에는 한계가 있습니다. 이유는 다음과 같습니다: - -- 스마트 컨트랙트는 통상 해당 버추얼 머신이 이해할 수 있는 특정 언어만으로만 개발될 수 있습니다. 이런 언어들은 다른 언어에 비교해 미숙한 부분이 많으며, 근본적으로 버추얼 머신의 한계에 의해 제한됩니다. 예를 들어, 이더리움 버추얼 머신(Ethereum Virtual Machine, EVM)은 개발자의 코드의 자동 실행을 허용하지 않습니다. 또한 개발자는 EVM의 계정 시스템을 사용해야 하며, 제한된 함수만으로 암호학 연산을 할 수 있습니다. 위 예시들은 통상 스마트 컨트랙트 플랫폼의 근본적인 **유연성의 부족함**을 보여줍니다. -- 모든 스마트 컨트랙트는 동일한 버추얼 머신에서 실행됩니다. 이는 근본적으로 모든 스마트 컨트랙트가 한정된 자원을 위해 경쟁해야하는 구조며 **성능**의 한계를 불러옵니다. 상태 기계가 (샤딩 같은 기술을 통해) 다수의 서브 세트(subset)로 나눈다는 가정에서도, 스마트 컨트랙트는 동일한 버추얼 머신에서 실행되어야 하기 때문에 상태 기계단에서 구현된 네이티브 애플리케이션 보다 많은 성능 제한이 있습니다(내부적인 벤치마크 테스트에 따르면, 버추얼 머신을 제거함으로 약 10배 가량의 성능 증가가 있었습니다). -- 또 다른 문제는 모든 스마트 컨트랙트가 근본적으로 동일한 환경을 공유하기 때문에 **독립성(sovereignty)**에 대한 한계가 존재합니다. 탈중앙화 애플리케이션은 다수의 이해관계자들이 존재하는 생태계입니다. 만약 애플리케이션이 범용적 버추얼 머신 블록체인에서 개발되는 경우, 애플리케이션의 이해관계자는 본인 애플리케이션에 대한 주권이 제한되며 하위 블록체인 거버넌스를 따라야합니다. 만약 애플리케이션에 버그가 존재하는 경우, 조치할 수 있는 방법이 많이 존재하지 않습니다. - -애플리케이션 특화 블록체인은 이런 한계점을 극복하기 위해 설계되었습니다. - -## 애플리케이션 특화 블록체인의 장점 - -### 유연성 - -애플리케이션 특화 블록체인은 개발자에게 최고의 유연성을 제공합니다: - -- 코스모스 블록체인의 경우, 상태 기계는 [ABCI](https://tendermint.com/docs/spec/abci/)라는 인터페이스를 통해 하위 컨센서스 엔진과 연결됩니다. 이런 인터페이스는 어떤 프로그램 언어로 구현될 수 있으며, 이는 개발자가 본인이 선호하는 프로그램 언어로 상태 기계를 구현할 수 있다는 것을 의미합니다. -- 개발자는 본인의 상태 기계를 구현하기 위해서 다수의 프레임워크 중 하나를 선택할 수 있습니다. 현재 가장 많이 사용되는 프레임워크는 코스모스 SDK이지만, 다른 프레임워크(예, [Lotion](https://github.com/nomic-io/lotion), [Weave](https://github.com/iov-one/weave), 등)의 프레임워크가 존재합니다. 통상 프레임워크는 개발자가 선호하는 언어에 따라 결정됩니다 (예, 코스모스 SDK와 Weave는 Go언어, Lotion은 자바스크립트 등). -- ABCI는 개발자가 본인의 애플리케이션 특화 블록체인의 컨센서스 엔진을 변경할 수 있게 합니다. 현재로써는 텐더민트만이 검증된 프레임워크이지만, 앞으로 더 많은 컨센서스 엔진이 존재할 것으로 예상됩니다. -- 개발자가 특정 프레임워크와 컨센서스 엔진을 선택하는 경우에도, 해당 개발자는 해당 프레임워크와 엔진을 본인이 필요하는대로 변경할 수 있는 자유가 있습니다. -- 개발자는 다수의 트레이오프(예, 검증인의 숫자 vs 트랜잭션 처리량, 안전성 vs 비동기적 환경에서의 생존성 등)와 디자인 아키텍쳐(스토리지에서 DB 또는 IAVL 트리를 사용할지, UTXO 또는 계정 모델을 사용할지)를 선택할 수 있습니다. -- 개발자는 코드의 자동 실행을 구현할 수 이습니다. 코스모스 SDK에서는 매 블록의 시작과 끝에서 로직이 자동으로 실행될 수 있게 설계할 수 있습니다. 또한 사용하는 버추얼 머신의 환경에 극한되지 않게 애플리케이션에서 사용될 암호학을 직접 선택할 수 있습니다. - -위 항목들은 애플리케이션 특화 블록체인이 개발자에게 주는 유연성의 예시를 보여줍니다. 코스모스와 코스모스 SDK의 목표는 개발자 툴링이 최대한 일반적(generic)이고 구성성(composable)있도록 만드는 것에 있기때문에, 스택의 각 컴포넌트가 포크되고, 변경되고, 개선되어도 호환성을 지킬 수 있도록 설계되었습니다. 커뮤니티가 성장할수록 코어 모듈들에 대한 대안이 나올 것으로 기대되며, 이는 개발자들에게 더 많은 선택권을 제공하게 됩니다. - -### 성능 - -스마트 컨트랙트의 형태로 구현되는 탈중앙화 애플리케이션은 하위 환경의 성능에 제한될 수밖에 없습니다. 탈중앙화 애플리케이션이 성능을 최적화하기 위해서는 애플리케이션 특화 블록체인으로 구성되어야 합니다. 다음은 애플리케이션 특화 블록체인의 성능적인 장점을 설명합니다: - -- 애플리케이션 특화 블록체인 개발자는 텐더민트 같은 새로운 컨센서스 엔진을 사용할 수 있으며, 이는 작업증명(Proof-of-work, PoW)에 비해서 상당한 성능 개선을 제공합니다. -- 애플리케이션 특화 블록체인은 하나의 애플리케이션만을 실행하기 때문에 해당 애플리케이션은 다른 애플리케이션과 스토리지와 연산력에 대한 경쟁을 하지 않습니다. 이는 연산력과 스토리지를 위해 다른 애플리케이션과 경쟁해야하는 기존 (샤딩을 도입하지 않은) 버추얼 머신 기반 블록체인 시스템과 대치합니다. -- 만약 버추얼 머신 기바의 블록체인이 애플리케이션 기반 샤딩과 효율적인 컨센서스 알고리즘을 제공한다고 해도, 애플리케이션의 성능은 버추얼 머신 자체에 의해 제한됩니다. 처리량(throughput)에 대한 한계는 상태 기계이며, 트랜잭션이 버추얼 머신을 통해 처리되어야 하는 것 자체가 트랜잭션 처리의 연산 복잡성을 인상하게 됩니다. - -### 보안 - -보안을 수치화하는 것은 쉽지 않으며, 플랫폼의 특성마다 다를 수 있습니다. 다만, 애플리케이션 특화 블록체인이 보안적으로 제공하는 특정 장점은 존재합니다: - -- 개발자는 Go 언어같은 검증된 언어로 애플리케이션 특화 블록체인을 개발할 수 있는 반면, 스마트 컨트랙트는 보통 미성숙한 언어로 개발해야 합니다. -- 개발자는 하위 버추얼 머신이 제공하는 암호학 함수를 사용해야하는 제한이 없으며, 검증된 암호학 라이브러리를 사용하거나 자체적인 암호학 알고리즘을 적용할 수 있습니다. -- 개발자는 하위 버추얼 머신에서 존재할 수 있는 버그 또는 메커니즘에 대한 걱정을 하지 않아도 되며, 애플리케이션 보안에만 집중할 수 있습니다. - -### 독립성 - -애플리케이션 특화 블록체인이 제공하는 가장 큰 장점 중 하나는 독립성(sovereignty, 존엄성)입니다. 탈중앙화 애플리케이션에는 유저, 개발자, 서비스 제공자 등 다수의 이해 관계자가 존재합니다. 개발자가 다수의 애플리케이션이 공존하는 버추얼 머신 기반 블록체인에서 본인의 애플리케이션을 개발하는 경우 본인 애플리케이션 커뮤니티와 하위 블록체인 플랫폼 커뮤니티가 다를 수 있으며, 하위 블록체인 플랫폼 커뮤니티가 애플리케이션 커뮤니티의 거버넌스를 지배하는 관계가 형성됩니다. 버그가 존재하거나 새로운 기능이 추가되는 경우, 애플리케이션의 이해관계자는 업그레이드를 실행하는데 제한되며 하위 플랫폼의 커뮤니티가 해당 과정을 받아드리지 않는 경우, 할 수 있는 것이 없게됩니다. - -여기서 근본적으로 존재하는 문제는 애플리케이션의 거버넌스와 플랫폼의 거버넌스가 일치하지 않는다는 것입니다. 애플리케이션 특화 블록체인에서는 블록체인이 한 애플리케이션을 위해 존재하기 때문에 애플리케이션의 이해관계자가 블록체인 전체에 대한 통제권을 부여받게 됩니다. 이는 커뮤니티가 버그를 발견하는 경우 조치를 할 수 있는 권한을 가질 수 있으며, 자체적으로 진화하는 방향을 정할 수도 있는 장점이 있습니다. - -## 다음 {hide} - -코스모스 SDK [애플리케이션의 구조](./sdk-app-architecture.md)에 대해 알아보세요{hide} diff --git a/docs/kr/kr-translation-progress.md b/docs/kr/kr-translation-progress.md deleted file mode 100644 index 0c962d6db5..0000000000 --- a/docs/kr/kr-translation-progress.md +++ /dev/null @@ -1,39 +0,0 @@ -# Cosmos SDK Documentation Translation (Korean) - -This document tracks the progress of the Korean translation of the official Cosmos SDK documentation. - -Documentation has been translated for **reference use only** and may contain typos, factual errors and be out-of-date with the latest english documentation. - -Please refer to the official english version of the documentation for the latest and accurate information. - - -## 코스모스 SDK 도큐멘테이션 번역 (한국어) - -이 문서는 코스모스 공식 문서의 번역 작업 트래킹을 위한 문서입니다. - -번역된 문서는 **참고용**으로 번역되었습니다. 다수의 오타, 오류가 존재할 수 있으며, 영문 업데이트보다 번역이 느리게 진행될 수 있다는 점을 인지하시기 바랍니다. - -코스모스 관련 가장 정확한 정보를 확인하시기 위해서는 영어 원문을 참고하시기 바랍니다. - - -## Progress by directory - - -### [`concepts`](../concepts/) -- Synced until commit [14ebc65](https://github.com/cosmos/cosmos-sdk/commit/14ebc65daffd63e1adf17995c103aac9380207ef#diff-f874f370376bf359320af0543de53fcf) - -### [`spec`](../spec/) -- Redacted from until completion - -### [`gaia`](../gaia/) -- Synced until commit [288df6f](https://github.com/cosmos/cosmos-sdk/commit/288df6fe69dcef8fa95aca022039f92ba1e98c11#diff-3302fe357e01f0996ddb0f10adec85f0) - -### [`intro`](../intro/) -- Synced until commit [0043912](https://github.com/cosmos/cosmos-sdk/commit/0043912548808b4cfd6ab84ec49ba73bd5f65b5b#diff-e518eaec0d99787e6f75682d54751821) - -### [`modules`](../modules/) -- Synced until commit [78a2135](https://github.com/cosmos/cosmos-sdk/commit/78a21353da978d6c2a9b711f29b3874ff9ca14ae#diff-449cc65858e8929d15f4a170950e7758) - -### [`clients`](../clients/) -- Synced until Commit [857a65d](https://github.com/cosmos/cosmos-sdk/commit/857a65dc610cd736a47980b5d4778e5123206a3d#diff-93dd988c16d20a1bce170b86ad89425a) - diff --git a/docs/kr/modules/README.md b/docs/kr/modules/README.md deleted file mode 100755 index b8915b3f5b..0000000000 --- a/docs/kr/modules/README.md +++ /dev/null @@ -1,38 +0,0 @@ -# Bank - -`x/bank` 모듈은 계정 간 코인을 이동할때 사용됩니다. - -[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/bank)를 확인하세요. - -# Stake - -`x/staking` 모듈은 코스모스 위임형 지분증명(Delegated-Proof-of-Stake) 시스템에서 사용됩니다. - -[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/staking)를 확인하세요. - -관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/staking)에서 확인하실 수 있습니다. - - -# Slashing - -`x/slashing` 모듈은 코스모스 위임형 지분증명(Delegated-Proof-of-Stake) 시스템에서 사용됩니다. - -[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/slashing)를 확인하세요. - -관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/slashing)에서 확인하실 수 있습니다. - -# Provisions - -`x/provisions` 모듈은 수수료 보상 분배와 스테이킹 인플레이션을 조정할때 사용됩니다. - -[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/distribution)를 확인하세요. - -관련 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/distribution)에서 확인하실 수 있습니다. - -# Governance - -`x/gov` 모듈은 본딩한 토큰 보유자들이 프로포절을 만들고 투표를 진행할때 사용됩니다. - -[API 문서](https://godoc.org/github.com/cosmos/cosmos-sdk/x/gov)를 확인하세요. - -관렉 스펙은 [여기](https://github.com/cosmos/cosmos-sdk/tree/master/docs/spec/governance)에서 확인하실 수 있습니다. diff --git a/docs/migrations/README.md b/docs/migrations/README.md deleted file mode 100644 index 845f661425..0000000000 --- a/docs/migrations/README.md +++ /dev/null @@ -1,13 +0,0 @@ - - -# Migrations - -This folder contains all the migration guides to update your app and modules to Cosmos v0.40 Stargate. - -1. [App and Modules Migration](./app_and_modules.md) -1. [Chain Upgrade Guide to v0.40](./chain-upgrade-guide-040.md) -1. [REST Endpoints Migration](./rest.md) diff --git a/docs/migrations/app_and_modules.md b/docs/migrations/app_and_modules.md deleted file mode 100644 index 77d7f71b9e..0000000000 --- a/docs/migrations/app_and_modules.md +++ /dev/null @@ -1,239 +0,0 @@ - - -# App and Modules Migration - -The following document describes the changes to update your app and modules from Cosmos SDK v0.39 to v0.40, -a.k.a. Stargate release. {synopsis} - -## Update Tooling - -Make sure to have the following dependencies before updating your app to v0.40: - -- Go 1.15+ -- Docker -- Node.js v12.0+ (optional, for generating Swagger docs) - -In Cosmos-SDK we manage the project using Makefile. Your own app can use a similar Makefile to the [Cosmos SDK's one](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/Makefile). More specifically, below are some _make_ commands that might be useful for your own app, related to the introduction of Protocol Buffers: - -- `proto-update-deps` - To download/update the required thirdparty `proto` definitions. -- `proto-gen` - To auto generate proto code. -- `proto-check-breaking` - To check proto breaking changes. -- `proto-format` - To format proto files. - -## Updating Modules - -This section outlines how to upgrade your module to v0.40. There is also a whole section about [building modules](../building-modules/README.md) from scratch, it might serve as a useful guide. - -### Protocol Buffers - -As outlined in our [encoding guide](../core/encoding.md), one of the most significant improvements introduced in Cosmos SDK v0.40 is Protobuf. - -The rule of thumb is that any object that needs to be serialized (into binary or JSON) must implement `proto.Message` and must be serializable into Protobuf format. The easiest way to do it is to use Protobuf type definition and `protoc` compiler to generate the structures and functions for you. In practice, the three following categories of types must be converted to Protobuf messages: - -- client-facing types: `Msg`s, query requests and responses. This is because client will send these types over the wire to your app. -- objects that are stored in state. This is because the SDK stores the binary representation of these types in state. -- genesis types. These are used when importing and exporting state snapshots during chain upgrades. - -Let's have a look at [x/auth's](../../x/auth/spec/README.md) `BaseAccount` objects, which are stored in a state. The migration looks like: - -```diff -// We were definining `MsgSend` as a Go struct in v0.39. -- // https://github.com/cosmos/cosmos-sdk/blob/v0.39.2/x/bank/internal/types/msgs.go#L12-L16 -- type BaseAccount struct { -- Address sdk.AccAddress `json:"address" yaml:"address"` -- Coins sdk.Coins `json:"coins" yaml:"coins"` -- PubKey crypto.PubKey `json:"public_key" yaml:"public_key"` -- AccountNumber uint64 `json:"account_number" yaml:"account_number"` -- Sequence uint64 `json:"sequence" yaml:"sequence"` -- } - -// And it should be converted to a Protobuf message in v0.40. -+ // https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/proto/cosmos/auth/v1beta1/auth.proto#L13-L25 -+ message BaseAccount { -+ string address = 1; -+ google.protobuf.Any pub_key = 2 -+ [(gogoproto.jsontag) = "public_key,omitempty", (gogoproto.moretags) = "yaml:\"public_key\""]; -+ uint64 account_number = 3 [(gogoproto.moretags) = "yaml:\"account_number\""]; -+ uint64 sequence = 4; -+ } -} -``` - -In general, we recommend to put all the Protobuf definitions in your module's subdirectory under a root `proto/` folder, as described in [ADR-023](../architecture/adr-023-protobuf-naming.md). This ADR also contains other useful information on naming conventions. - -You might have noticed that the `PubKey` interface in v0.39's `BaseAccount` has been transformed into an `Any`. For storing interfaces, we use Protobuf's `Any` message, which is a struct that can hold arbitrary content. Please refer to the [encoding FAQ](../core/encoding.md#faq) to learn how to handle interfaces and `Any`s. - -Once all your Protobuf messages are defined, use the `make proto-gen` command defined in the [tooling section](#tooling) to generate Go structs. These structs will be generated into `*.pb.go` files. As a quick example, here is the generated Go struct for the Protobuf BaseAccount we defined above: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/auth/types/auth.pb.go#L28-L36 - -There might be some back and forth removing old Go structs/interfaces and defining new Protobuf messages before your Go app compiles and your tests pass. - -### Create `Msg` and `Query` Services - -Cosmos SDK v0.40 uses Protobuf services to define state transitions (`Msg`s) and state queries, please read [the building modules guide on those services](../building-modules/messages-and-queries.md) for an overview. - -#### `Msg` Service - -For migrating `Msg`s, the handler pattern (inside the `handler.go` file) is deprecated. You may still keep it if you wish to support `Msg`s defined in older versions of the SDK. However, it is strongly recommended to add a `Msg` service to your Protobuf files, and each old `Msg` should be converted into a service method. Taking [x/bank's](../../x/bank/spec/README.md) `MsgSend` as an example, we have a corresponding `cosmos.bank.v1beta1.Msg/Send` service method: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/proto/cosmos/bank/v1beta1/tx.proto#L10-L31 - -A state transition is therefore modelized as a Protobuf service method, with a method request, and an (optionally empty) method response. - -After defining your `Msg` service, run the `make proto-gen` script again to generate `Msg` server interfaces. The name of this interface is simply `MsgServer`. The implementation of this interface should follow exactly the implementation of the old `Msg` handlers, which, in most cases, defers the actual state transition logic to the [keeper](../building-modules/keeper.md). You may implement a `MsgServer` directly on the keeper, or you can do it using a new struct (e.g. called `msgServer`) that references the module's keeper. - -For more information, please check our [`Msg` service guide](../building-modules/msg-services.md). - -#### `Query` Service - -For migrating state queries, the querier pattern (inside the `querier.go` file) is deprecated. You may still keep this file to support legacy queries, but it is strongly recommended to use a Protobuf `Query` service to handle state queries. - -Each query endpoint is now defined as a separate service method in the `Query` service. Still taking `x/bank` as an example, here are the queries to fetch an account's balances: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/proto/cosmos/bank/v1beta1/query.proto#L12-L23 - -Each query has its own `Request` and `Response` types. Please also note the `google.api.http` option (coming from [`grpc-gateway`](https://github.com/grpc-ecosystem/grpc-gateway)) on each service method. `grpc-gateway` is a tool that exposes `Query` service methods as REST endpoints. Adding this annotation will expose these endpoints not only as gRPC endpoints, but also as REST endpoints. An overview of gRPC versus REST can be found [here](../core/grpc_rest.md). - -After defining the `Query` Protobuf service, run the `make proto-gen` command to generate corresponding interfaces. The interface that needs to be implemented by your module is `QueryServer`. This interface can be implemented on the [keeper](../building-modules/keeper.md) directly, or on a struct (e.g. called `queryServer`) that references the module's keeper. The logic of the implementation, namely the logic that fetches data from the module's store and performs unmarshalling, can be deferred to the keeper. - -Cosmos SDK v0.40 also comes with an efficient pagination, it now uses `Prefix` stores to make queries. There are 2 helpers for pagination, [`Paginate`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/query/pagination.go#L40-L42), [`FilteredPaginate`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/query/filtered_pagination.go#L9-L17). - -For more information, please check our [`Query` service guide](../building-modules/query-services.md). - -#### Wiring up `Msg` and `Query` Services - -We added a new `RegisterServices` method that registers a module's `Msg` service and a `Query` service. It should be implemented by all modules, using a `Configurator` object: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/module.go#L99-L103 - -If you wish to expose your `Query` endpoints as REST endpoints (as proposed in the [`Query` Services paragraph](#query-services)), make sure to also implement the `RegisterGRPCGatewayRoutes` method: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/module.go#L69-L72 - -### Codec - -If you still use Amino (which is deprecated since Stargate), you must register related types using the `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)` method (previously it was called `RegisterCodec(cdc *codec.Codec)`). - -Moreover, a new `RegisterInterfaces` method has been added to the `AppModule` interface that all modules must implement. This method must register the interfaces that Protobuf messages implement, as well as the service `Msg`s used in the module. An example from x/bank is given below: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/types/codec.go#L21-L34 - -### Keeper - -The `Keeper` constructor now takes a `codec.Marshaler` instead of a concrete Amino codec. This `codec.Marshaler` is used to encode types as binary and save the bytes into the state. With an interface, you can define `codec.Marshaler` to be Amino or Protobuf on an app level, and keepers will use that encoding library to encode state. Please note that Amino is deprecated in v0.40, and we strongly recommend to use Protobuf. Internally, the SDK still uses Amino in a couple of places (legacy REST API, x/params, keyring...), but Amino is planned to be removed in a future release. - -Keeping Amino for now can be useful if you wish to update to SDK v0.40 without doing a chain upgrade with a genesis migration. This will not require updating the stores, so you can migrate to Cosmos SDK v0.40 with less effort. However, as Amino will be removed in a future release, the chain migration with genesis export/import will need to be performed then. - -Related to the keepers, each module's `AppModuleBasic` now also includes this `codec.Marshaler`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/module.go#L35-L38 - -### CLI - -Each modules may optionally expose CLI commands, and some changes are needed in these commands. - -First, `context.CLIContext` is renamed to `client.Context` and moved to `github.com/cosmos/cosmos-sdk/client`. - -Second, the global `viper` usage is removed from client and is replaced with Cobra' `cmd.Flags()`. There are two helpers to read common flags for CLI txs and queries: - -```go -clientCtx, err := client.GetClientQueryContext(cmd) -clientCtx, err := client.GetClientTxContext(cmd) -``` - -Some other flags helper functions are transformed: `flags.PostCommands(cmds ...*cobra.Command) []*cobra.Command` and `flags.GetCommands(...)` usage is now replaced by `flags.AddTxFlagsToCmd(cmd *cobra.Command)` and `flags.AddQueryFlagsToCmd(cmd *cobra.Command)` respectively. - -Moreover, new CLI commands don't take any codec as input anymore. Instead, the `clientCtx` can be retrieved from the `cmd` itself using the `GetClient{Query,Tx}Context` function above, and the codec as `clientCtx.JSONMarshaler`. - -```diff -// v0.39 -- func SendTxCmd(cdc *codec.Codec) *cobra.Command { -- cdc.MarshalJSON(...) -- } - -// v0.40 -+ func NewSendTxCmd() *cobra.Command { -+ clientCtx, err := client.GetClientTxContext(cmd) -+ clientCtx.JSONMarshaler.MarshalJSON(...) -+} -``` - -Finally, once your [`Query` services](#query-service) are wired up, the CLI commands should preferably use gRPC to communicate with the node. The gist is to create a `Query` or `Msg` client using the command's `clientCtx`, and perform the request using Protobuf's generated code. An example for querying x/bank balances is given here: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/client/cli/query.go#L66-L94 - -### Miscelleanous - -A number of other smaller breaking changes are also noteworthy. - -| Before | After | Comment | -| ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `alias.go` file | Removed | `alias` usage is removed, please see [#6311](https://github.com/cosmos/cosmos-sdk/issues/6311) for details. | -| `codec.New()` | `codec.NewLegacyAmino()` | Simple rename. | -| `DefaultGenesis()` | `DefaultGenesis(cdc codec.JSONMarshaler)` | `DefaultGenesis` takes a codec argument now | -| `ValidateGenesis()` | `ValidateGenesis(cdc codec.JSONMarshaler, config client.TxEncodingConfig, bz json.RawMessage)` | `ValidateGenesis` now requires `Marshaler`, `TxEncodingConfig`, `json.RawMessage` as input. | -| `Route() string` | `Route() sdk.Route` | For legacy handlers, return type of `Route()` method is changed from `string` to `"github.com/line/lbm-sdk/v2/types".Route`. It should return a `NewRoute()` which includes `RouterKey` and `NewHandler` as params. | -| `QuerierHandler` | `LegacyQuerierHandler` | Simple rename. | -| `InitGenesis(ctx sdk.Context, data json.RawMessage) []abci.ValidatorUpdate` | InitGenesis(ctx sdk.Context, cdc codec.JSONMarshaler, data json.RawMessage) []abci.ValidatorUpdate | `InitGenesis` now takes a codec input. | -| `ExportGenesis(ctx sdk.Context, data json.RawMessage) []abci.ValidatorUpdate` | ExportGenesis(ctx sdk.Context, cdc codec.JSONMarshaler, data json.RawMessage) []abci.ValidatorUpdate | `ExportGenesis` now takes a codec input. | - -## Updating Your App - -For a reference implementation used for demo purposes, you can refer to the SDK's [SimApp](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc6/simapp) for your app's migration. The most important changes are described in this section. - -### Creating Codecs - -With the introduction of Protobuf, each app needs to define the encoding library (Amino or Protobuf) to be used throughout the app. There is a central struct, [`EncodingConfig`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/simapp/params/encoding.go#L9-L11), which defines all information necessary for codecs. In your app, an example `EncodingConfig` with Protobuf as default codec might look like: - -```go -// MakeEncodingConfig creates an EncodingConfig -func MakeEncodingConfig() params.EncodingConfig { - amino := codec.NewLegacyAmino() - interfaceRegistry := types.NewInterfaceRegistry() - marshaler := codec.NewProtoCodec(interfaceRegistry) - txCfg := tx.NewTxConfig(marshaler, tx.DefaultSignModes) - - encodingConfig := params.EncodingConfig{ - InterfaceRegistry: interfaceRegistry, - Marshaler: marshaler, - TxConfig: txCfg, - Amino: amino, - } - std.RegisterLegacyAminoCodec(encodingConfig.Amino) - std.RegisterInterfaces(encodingConfig.InterfaceRegistry) - ModuleBasics.RegisterLegacyAminoCodec(encodingConfig.Amino) - ModuleBasics.RegisterInterfaces(encodingConfig.InterfaceRegistry) - - return encodingConfig -} -``` - -These codecs are used to populate the following fields on your app (again, we are using SimApp for demo purposes): - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/simapp/app.go#L146-L153 - -As explained in the [modules migration section](#updating-modules), some functions and structs in modules require an additional `codec.Marshaler` argument. You should pass `app.appCodec` in these cases, and this will be the default codec used throughout the app. - -### Registering Non-Module Protobuf Services - -We described in the [modules migration section](#updating-modules) `Query` and `Msg` services defined in each module. The SDK also exposes two more module-agnostic services: - -- the [Tx Service](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/proto/cosmos/tx/v1beta1/service.proto), to perform operations on transactions, -- the [Tendermint service](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/proto/cosmos/base/tendermint/v1beta1/query.proto), to have a more idiomatic interface to the [Tendermint RPC](https://docs.tendermint.com/master/rpc/). - -These services are optional, if you wish to use them, or if you wish to add more module-agnostic Protobuf services into your app, then you need to add them inside `app.go`: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/simapp/app.go#L577-L585 - -### Registering `grpc-gateway` Routes - -The exising `RegisterAPIRoutes` method on the `app` only registers [Legacy API routes](../core/grpc_rest.md#legacy-rest-api-routes). If you are using `grpc-gateway` REST endpoints as described [above](#query-service), then these endpoints need to be wired up to a HTTP server: - -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/simapp/app.go#L555-L575 - -## Next {hide} - -Learn how to perform a [chain upgrade](./chain-upgrade-guide-040.md) to 0.40. diff --git a/docs/migrations/chain-upgrade-guide-040.md b/docs/migrations/chain-upgrade-guide-040.md deleted file mode 100644 index bce8496645..0000000000 --- a/docs/migrations/chain-upgrade-guide-040.md +++ /dev/null @@ -1,162 +0,0 @@ - - -# Chain Upgrade Guide to v0.40 - -This document explains how to perform a chain upgrade from v0.39 to v0.40. {synopsis} - -## Risks - -As a validator, performing the upgrade procedure on your consensus nodes carries a heightened risk of double-signing and -being slashed: if your validator node votes for a block, and, in the same block time, restarts the upgraded node, this may lead to double-voting on a block. - -The riskiest thing a validator can do is to discover that they made a mistake and repeat the upgrade procedure again during -the network startup. If you discover a mistake in the process, the best thing to do is wait for the network to start -before correcting it. If the network is halted and you have started with a different genesis file than the expected one, -seek advice from the validator community. - -## Recovery - -- Prior to exporting the state, the validators are encouraged to take a full data snapshot at exported height. Exported - height will be determined by a governance proposal. Data backup is usually done by copying daemon home directory, - e.g.: `~/.simd` - -**Note:** we use "simd" as our app throughout this doc, be sure to replace with the name of your own binary. - -It is critically important to back-up the validator state file, e.g.: `~/.simd/data/priv_validator_state.json` file -after stopping your daemon process. This file is updated every block as your validator participates in a consensus -rounds. It is a critical file needed to prevent double-signing, in case the upgrade fails, and the previous chain needs -to be restarted. - -In the event that the upgrade does not succeed, validators and operators must downgrade back to old version of the -software and restore to their latest snapshot before restarting their nodes. - -## Upgrade procedure - -1. The procedure is to export the state from the old binary, and import it with the new binary. First, verify your old binary version (which should use `github.com/cosmos/cosmos-sdk@0.39.*`) before exporting the state. - - ```shell - simd version --long - ``` - -1. Export the state from existing chain using the old binary. - - ```shell - simd export --for-zero-height --height > v039_exported_state.json - ``` - -1. Verify the SHA256 of the (sorted) exported genesis file: - - ```shell - $ jq -S -c -M '' v039_exported_state.json | shasum -a 256 - [SHASUM_PLACEHOLDER] v039_exported_state.json - ``` - -1. Cross check the hash with other peers (other validators) in the chat rooms. - -1. Install the latest binary (which uses `github.com/cosmos/cosmos-sdk@0.40.*`). - -1. Migrate the exported state to `github.com/cosmos/cosmos-sdk@0.40.*` compatible genesis state. - - ```shell - simd migrate v0.40 v039_exported_state.json --chain-id --genesis-time > new_v040_genesis.json - ``` - - **Note:** The migrate command takes an input genesis state and migrates it to a targeted version. New `genesis-time` will be as mentioned in the governance proposal. - -1. All the necessary state changes are handled in the `simd migrate v0.40` migration command. However, Tendermint parameters are **not** handled in this command. You might need to update these parameters manually. - - In the recent versions of Tendermint, the following changes have been made: - - - `consensus_params.evidence.max_num` has been renamed to `consensus_params.evidence.max_bytes`. - - `consensus_params.evidence.max_age` has been removed, and replaced by `consensus_params.evidence.max_age_duration` and `consensus_params.evidence.max_age_num_blocks`. - - Make sure that your genesis JSON files contains the correct values specific to your chain. If the `simd migrate` errors with a message saying that the genesis file cannot be parsed, these are the fields to check first. - -1. Verify the SHA256 of the migrated genesis file with other validators to make sure there are no manual errors in the process. - - ```shell - $ jq -S -c -M '' new_v040_genesis.json | shasum -a 256 - [SHASUM_PLACEHOLDER] new_v040_genesis.json - ``` - -1. Make sure to update the genesis parameters in the new genesis if any. All these details will be generally present in - the governance proposal. - -1) If your chain is using IBC, make sure to add IBC initial genesis state to the genesis file. You can use the following command to add IBC initial genesis state to the genesis file. - - ```shell - cat new_v040_genesis.json | jq '.app_state |= . + {"ibc":{"client_genesis":{"clients":[],"clients_consensus":[],"create_localhost":false},"connection_genesis":{"connections":[],"client_connection_paths":[]},"channel_genesis":{"channels":[],"acknowledgements":[],"commitments":[],"receipts":[],"send_sequences":[],"recv_sequences":[],"ack_sequences":[]}},"transfer":{"port_id":"transfer","denom_traces":[],"params":{"send_enabled":false,"receive_enabled":false}},"capability":{"index":"1","owners":[]}}' > tmp_genesis.json && mv tmp_genesis.json new_v040_genesis.json - ``` - - **Note:** This would add IBC state with IBC's `send_enabled: false` and `receive_enabled: false`. Make sure to update them to `true` in the above command if are planning to enable IBC transactions with chain upgrade. Otherwise you can do it via a governance proposal. - -1) Reset the old state. - - **Note:** Be sure you have a complete backed up state of your node before proceeding with this step. - See Recovery for details on how to proceed. - - ```shell - simd unsafe-reset-all - ``` - -1) Move the new genesis.json to your daemon config directory. Ex - - ```shell - cp new_v040_genesis.json ~/.simd/config/genesis.json - ``` - -1) Update `~/.simd/config/app.toml` to include latest app configurations. [Here is the link](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/server/config/toml.go#L11-L164) to the default template for v0.40's `app.toml`. Make sure to - update your custom configurations as per your validator design, e.g. `gas_price`. - - Compared to v0.39, some notable updates to `app.toml` are: - - - API server is now configured to run in-process with daemon, previously it was a separate process, invoked by running rest-server - command i.e., `gaiacli rest-server`. Now it is in-process with daemon and can be enabled/disabled by API configuration: - - ```yaml - [api] - # Enable defines if the API server should be enabled. - enable = false - # Swagger defines if swagger documentation should automatically be registered. - swagger = false - ``` - - `swagger` setting refers to enabling/disabling swagger docs API, i.e, `/swagger/` API endpoint. - - - gRPC Configuration - - ```yaml - [grpc] - # Enable defines if the gRPC server should be enabled. - enable = true - # Address defines the gRPC server address to bind to. - address = "0.0.0.0:9090" - ``` - - - State Sync Configuration - - ```yaml - # State sync snapshots allow other nodes to rapidly join the network without replaying historical - # blocks, instead downloading and applying a snapshot of the application state at a given height. - [state-sync] - # snapshot-interval specifies the block interval at which local state sync snapshots are - # taken (0 to disable). Must be a multiple of pruning-keep-every. - snapshot-interval = 0 - # snapshot-keep-recent specifies the number of recent snapshots to keep and serve (0 to keep all). - snapshot-keep-recent = 2 - ``` - -1) Kill if any external `rest-server` process is running. - -1) All set now! You can (re)start your daemon to validate on the upgraded network. Make sure to check your binary version - before starting the daemon: - - ``` - simd version --long - ``` - -## Next {hide} - -Once your chain is upgraded, make sure to [update your clients' REST endpoints](./rest.md). diff --git a/docs/migrations/rest.md b/docs/migrations/rest.md deleted file mode 100644 index 85ba656579..0000000000 --- a/docs/migrations/rest.md +++ /dev/null @@ -1,101 +0,0 @@ - - -# REST Endpoints Migration - -Migrate your REST endpoints to the Stargate ones. {synopsis} - -## Deprecation of Legacy REST Endpoints - -The Cosmos SDK versions v0.39 and earlier provided REST endpoints to query the state and broadcast transactions. These endpoints are kept in Cosmos SDK v0.40 (Stargate), but they are marked as deprecated, and will be removed in v0.41. We therefore call these endpoints legacy REST endpoints. - -Some important information concerning all legacy REST endpoints: - -- Most of these endpoints are backwards-comptatible. All breaking changes are described in the next section. -- In particular, these endpoints still output Amino JSON. Cosmos v0.40 introduced Protobuf as the default encoding library throughout the codebase, but legacy REST endpoints are one of the few places where the encoding is hardcoded to Amino. For more information about Protobuf and Amino, please read our [encoding guide](../core/encoding.md). -- All legacy REST endpoints include a [HTTP deprecation header](https://tools.ietf.org/id/draft-dalal-deprecation-header-01.html) which links to this document. - -## Breaking Changes in Legacy REST Endpoints - -| Legacy REST Endpoint | Description | Breaking Change | -| ------------------------------------------------------------------------ | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `POST /txs` | Broadcast tx | Endpoint will error when trying to broadcast transactions that don't support Amino serialization (e.g. IBC txs)1. | -| `POST /txs/encode`, `POST /txs/decode` | Encode/decode Amino txs from JSON to binary | Endpoint will error when trying to encode/decode transactions that don't support Amino serialization (e.g. IBC txs)1. | -| `GET /txs/{hash}` | Query tx by hash | Endpoint will error when trying to output transactions that don't support Amino serialization (e.g. IBC txs)1. | -| `GET /txs` | Query tx by events | Endpoint will error when trying to output transactions that don't support Amino serialization (e.g. IBC txs)1. | -| `GET /gov/proposals/{id}/votes`, `GET /gov/proposals/{id}/votes/{voter}` | Gov endpoints for querying votes | All gov endpoints which return votes return int32 in the `option` field instead of string: `1=VOTE_OPTION_YES, 2=VOTE_OPTION_ABSTAIN, 3=VOTE_OPTION_NO, 4=VOTE_OPTION_NO_WITH_VETO`. | -| `GET /staking/*` | Staking query endpoints | All staking endpoints which return validators have two breaking changes. First, the validator's `consensus_pubkey` field returns an Amino-encoded struct representing an `Any` instead of a bech32-encoded string representing the pubkey. The `value` field of the `Any` is the pubkey's raw key as base64-encoded bytes. Second, the validator's `status` field now returns an int32 instead of string: `1=BOND_STATUS_UNBONDED`, `2=BOND_STATUS_UNBONDING`, `3=BOND_STATUS_BONDED`. | -| `GET /staking/validators` | Get all validators | BondStatus is now a protobuf enum instead of an int32, and JSON serialized using its protobuf name, so expect query parameters like `?status=BOND_STATUS_{BONDED,UNBONDED,UNBONDING}` as opposed to `?status={bonded,unbonded,unbonding}`. | - -1: Transactions that don't support Amino serialization are the ones that contain one or more `Msg`s that are not registered with the Amino codec. Currently in the SDK, only IBC `Msg`s fall into this case. - -## Migrating to New REST Endpoints - -Thanks to the Protocol Buffers migration in v0.40, we are able to take advantage of a vast number of gRPC tools and solutions. For most of the legacy REST endpoints, Cosmos SDK v0.40 provides new REST endpoints generated from [gRPC `Query` services](../building-modules/query-services.md) using [grpc-gateway](https://grpc-ecosystem.github.io/grpc-gateway/). We usually call them _gRPC-gateway REST endpoints_. - -Some modules expose legacy `POST` endpoints to generate unsigned transactions for their `Msg`s. These `POST` endpoints have been removed. We recommend to use [service `Msg`s](../building-modules/msg-services.md) directly, and use Protobuf to do client-side transaction generation. A guide can be found [here](../run-node/txs.md). - -| Legacy REST Endpoint | Description | New gRPC-gateway REST Endpoint | -| ------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | -| `GET /txs/{hash}` | Query tx by hash | `GET /lbm/tx/v1beta1/txs/{hash}` | -| `GET /txs` | Query tx by events | `GET /lbm/tx/v1beta1/txs` | -| `POST /txs` | Broadcast tx | `POST /lbm/tx/v1beta1/txs` | -| `POST /txs/encode` | Encodes an Amino JSON tx to an Amino binary tx | N/A, use Protobuf directly | -| `POST /txs/decode` | Decodes an Amino binary tx into an Amino JSON tx | N/A, use Protobuf directly | -| `POST /bank/*` | Create unsigned `Msg`s for bank tx | N/A, use Protobuf directly | -| `GET /bank/balances/{address}` | Get the balance of an address | `GET /cosmos/bank/v1beta1/balances/{address}` | -| `GET /bank/total` | Get the total supply of all coins | `GET /cosmos/bank/v1beta1/supply` | -| `GET /bank/total/{denom}` | Get the total supply of one coin | `GET /cosmos/bank/v1beta1/supply/{denom}` | -| `POST /distribution/delegators/{delegatorAddr}/rewards` | Withdraw all delegator rewards | N/A, use Protobuf directly | -| `POST /distribution/*` | Create unsigned `Msg`s for distribution | N/A, use Protobuf directly | -| `GET /distribution/delegators/{delegatorAddr}/rewards` | Get the total rewards balance from all delegations | `GET /cosmos/distribution/v1beta1/v1beta1/delegators/{delegator_address}/rewards` | -| `GET /distribution/delegators/{delegatorAddr}/rewards/{validatorAddr}` | Query a delegation reward | `GET /cosmos/distribution/v1beta1/delegators/{delegatorAddr}/rewards/{validatorAddr}` | -| `GET /distribution/delegators/{delegatorAddr}/withdraw_address` | Get the rewards withdrawal address | `GET /cosmos/distribution/v1beta1/delegators/{delegatorAddr}/withdraw_address` | -| `GET /distribution/validators/{validatorAddr}` | Validator distribution information | N/A | -| `GET /distribution/validators/{validatorAddr}/rewards` | Commission and outstanding rewards of a single a validator | `GET /cosmos/distribution/v1beta1/validators/{validatorAddr}/commission`
`GET /cosmos/distribution/v1beta1/validators/{validatorAddr}/outstanding_rewards` | -| `GET /distribution/validators/{validatorAddr}/outstanding_rewards` | Outstanding rewards of a single validator | `GET /cosmos/distribution/v1beta1/validators/{validatorAddr}/outstanding_rewards` | -| `GET /distribution/parameters` | Get the current distribution parameter values | `GET /cosmos/distribution/v1beta1/params` | -| `GET /distribution/community_pool` | Get the amount held in the community pool | `GET /cosmos/distribution/v1beta1/community_pool` | -| `GET /evidence/{evidence-hash}` | Get evidence by hash | `GET /cosmos/evidence/v1beta1/evidence/{evidence_hash}` | -| `GET /evidence` | Get all evidence | `GET /cosmos/evidence/v1beta1/evidence` | -| `POST /gov/*` | Create unsigned `Msg`s for gov | N/A, use Protobuf directly | -| `GET /gov/parameters/{type}` | Get government parameters | `GET /cosmos/gov/v1beta1/params/{type}` | -| `GET /gov/proposals` | Get all proposals | `GET /cosmos/gov/v1beta1/proposals` | -| `GET /gov/proposals/{proposal-id}` | Get proposal by id | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}` | -| `GET /gov/proposals/{proposal-id}/proposer` | Get proposer of a proposal | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}` (Get proposer from `Proposal` struct) | -| `GET /gov/proposals/{proposal-id}/deposits` | Get deposits of a proposal | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}/deposits` | -| `GET /gov/proposals/{proposal-id}/deposits/{depositor}` | Get depositor a of deposit | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}/deposits/{depositor}` | -| `GET /gov/proposals/{proposal-id}/tally` | Get tally of a proposal | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}/tally` | -| `GET /gov/proposals/{proposal-id}/votes` | Get votes of a proposal | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}/votes` | -| `GET /gov/proposals/{proposal-id}/votes/{vote}` | Get a particular vote | `GET /cosmos/gov/v1beta1/proposals/{proposal-id}/votes/{vote}` | -| `GET /minting/parameters` | Get parameters for minting | `GET /cosmos/minting/v1beta1/params` | -| `GET /minting/inflation` | Get minting inflation | `GET /cosmos/minting/v1beta1/inflation` | -| `GET /minting/annual-provisions` | Get minting annual provisions | `GET /cosmos/minting/v1beta1/annual_provisions` | -| `POST /slashing/*` | Create unsigned `Msg`s for slashing | N/A, use Protobuf directly | -| `GET /slashing/validators/{validatorPubKey}/signing_info` | Get validator signing info | `GET /cosmos/slashing/v1beta1/signing_infos/{cons_address}` (Use consensus address instead of pubkey) | -| `GET /slashing/signing_infos` | Get all signing infos | `GET /cosmos/slashing/v1beta1/signing_infos` | -| `GET /slashing/parameters` | Get slashing parameters | `GET /cosmos/slashing/v1beta1/params` | -| `POST /staking/*` | Create unsigned `Msg`s for staking | N/A, use Protobuf directly | -| `GET /staking/delegators/{delegatorAddr}/delegations` | Get all delegations from a delegator | `GET /cosmos/staking/v1beta1/delegations/{delegatorAddr}` | -| `GET /staking/delegators/{delegatorAddr}/unbonding_delegations` | Get all unbonding delegations from a delegator | `GET /cosmos/staking/v1beta1/delegators/{delegatorAddr}/unbonding_delegations` | -| `GET /staking/delegators/{delegatorAddr}/txs` | Get all staking txs (i.e msgs) from a delegator | Removed | -| `GET /staking/delegators/{delegatorAddr}/validators` | Query all validators that a delegator is bonded to | `GET /cosmos/staking/v1beta1/delegators/{delegatorAddr}/validators` | -| `GET /staking/delegators/{delegatorAddr}/validators/{validatorAddr}` | Query a validator that a delegator is bonded to | `GET /cosmos/staking/v1beta1/delegators/{delegatorAddr}/validators/{validatorAddr}` | -| `GET /staking/delegators/{delegatorAddr}/delegations/{validatorAddr}` | Query a delegation between a delegator and a validator | `GET /cosmos/staking/v1beta1/validators/{validatorAddr}/delegations/{delegatorAddr}` | -| `GET /staking/delegators/{delegatorAddr}/unbonding_delegations/{validatorAddr}` | Query all unbonding delegations between a delegator and a validator | `GET /cosmos/staking/v1beta1/delegators/{delegatorAddr}/unbonding_delegations/{validatorAddr}` | -| `GET /staking/redelegations` | Query redelegations | `GET /cosmos/staking/v1beta1/v1beta1/delegators/{delegator_addr}/redelegations` | -| `GET /staking/validators` | Get all validators | `GET /cosmos/staking/v1beta1/validators` | -| `GET /staking/validators/{validatorAddr}` | Get a single validator info | `GET /cosmos/staking/v1beta1/validators/{validatorAddr}` | -| `GET /staking/validators/{validatorAddr}/delegations` | Get all delegations to a validator | `GET /cosmos/staking/v1beta1/validators/{validatorAddr}/delegations` | -| `GET /staking/validators/{validatorAddr}/unbonding_delegations` | Get all unbonding delegations from a validator | `GET /cosmos/staking/v1beta1/validators/{validatorAddr}/unbonding_delegations` | -| `GET /staking/historical_info/{height}` | Get HistoricalInfo at a given height | `GET /cosmos/staking/v1beta1/historical_info/{height}` | -| `GET /staking/pool` | Get the current state of the staking pool | `GET /cosmos/staking/v1beta1/pool` | -| `GET /staking/parameters` | Get the current staking parameter values | `GET /cosmos/staking/v1beta1/params` | -| `POST /upgrade/*` | Create unsigned `Msg`s for upgrade | N/A, use Protobuf directly | -| `GET /upgrade/current` | Get the current plan | `GET /cosmos/upgrade/v1beta1/current_plan` | -| `GET /upgrade/applied_plan/{name}` | Get a previously applied plan | `GET /cosmos/upgrade/v1beta1/applied/{name}` | - -## Migrating to gRPC - -Instead of hitting REST endpoints as described in the previous paragraph, the SDK also exposes a gRPC server. Any client can use gRPC instead of REST to interact with the node. An overview of different ways to communicate with a node can be found [here](../core/grpc_rest.md), and a concrete tutorial for setting up a gRPC client [here](../run-node/txs.md#programmatically-with-go). diff --git a/docs/package-lock.json b/docs/package-lock.json deleted file mode 100644 index 552ed5d2f8..0000000000 --- a/docs/package-lock.json +++ /dev/null @@ -1,10790 +0,0 @@ -{ - "name": "docs", - "version": "1.0.0", - "lockfileVersion": 1, - "requires": true, - "dependencies": { - "@algolia/cache-browser-local-storage": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/cache-browser-local-storage/-/cache-browser-local-storage-4.8.4.tgz", - "integrity": "sha512-qSS3VMP3oMhcLrYIFveRyt3F5XB6MqWogF4Vooj8KvOvqv6jBmYwkAueSXCF5pkJEaA72VL9+9NbBpfC8ez2ww==", - "requires": { - "@algolia/cache-common": "4.8.4" - } - }, - "@algolia/cache-common": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/cache-common/-/cache-common-4.8.4.tgz", - "integrity": "sha512-5+dLmj6qFy4WOtnNQuFRfWTIIDdpUigv+dXaKMFplNPBvZHGFy3hcRjWqYzGcqaeLqcXbN8cU5r75mvrlJIxcw==" - }, - "@algolia/cache-in-memory": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/cache-in-memory/-/cache-in-memory-4.8.4.tgz", - "integrity": "sha512-PBN4YKxn/L+HjVKqUE5rtLiFKqzm4qnUoF7QvCFFmFAViCdYwZSMFVmDobstqWY3KULfsEqaeD4eU4jxZbKhEA==", - "requires": { - "@algolia/cache-common": "4.8.4" - } - }, - "@algolia/client-account": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/client-account/-/client-account-4.8.4.tgz", - "integrity": "sha512-mrsOnGV4O2b+t1CumUH72+Psw9d9qwngBEp2le7IMSceJQywQvNCyJ4B4qyoozHsIGapXfcVAOhRxqUsNQ6U6g==", - "requires": { - "@algolia/client-common": "4.8.4", - "@algolia/client-search": "4.8.4", - "@algolia/transporter": "4.8.4" - } - }, - "@algolia/client-analytics": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/client-analytics/-/client-analytics-4.8.4.tgz", - "integrity": "sha512-Xy70njSUgG/QTv5+rPjsTIzBF/bjxseS5h9SawrQGzovTosbJbu9JBlg4YwVJnYvjovzpr7S39+gPIPc8M7+Rg==", - "requires": { - "@algolia/client-common": "4.8.4", - "@algolia/client-search": "4.8.4", - "@algolia/requester-common": "4.8.4", - "@algolia/transporter": "4.8.4" - } - }, - "@algolia/client-common": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/client-common/-/client-common-4.8.4.tgz", - "integrity": "sha512-sQlRa+KWFn+D8AOEZb4kj6RE/i6DnPwVOF4AnNf9IjNB0mUUhLWw96cQN6GDx0KE4lhW67t+qR39ZuuDBgR9ww==", - "requires": { - "@algolia/requester-common": "4.8.4", - "@algolia/transporter": "4.8.4" - } - }, - "@algolia/client-recommendation": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/client-recommendation/-/client-recommendation-4.8.4.tgz", - "integrity": "sha512-CE0CVqLGWotVOaUXyU33FVD9FZ/7rqcbwFPH5MgSjVdE0B1YWVedhR0s2BNKodXLcIGVLVYfXR05CLdvOlTw+A==", - "requires": { - "@algolia/client-common": "4.8.4", - "@algolia/requester-common": "4.8.4", - "@algolia/transporter": "4.8.4" - } - }, - "@algolia/client-search": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/client-search/-/client-search-4.8.4.tgz", - "integrity": "sha512-eH2tRPnDU3tqpp0BSqP6coRRQe8fceqsupuf/1ho+Mcs5DM13mEuFmNOyPywHRlYLVPmbbCPRhDr5rB8QoN7XQ==", - "requires": { - "@algolia/client-common": "4.8.4", - "@algolia/requester-common": "4.8.4", - "@algolia/transporter": "4.8.4" - } - }, - "@algolia/logger-common": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/logger-common/-/logger-common-4.8.4.tgz", - "integrity": "sha512-6hOaFG75Onmant9adcaeCZgvPYfnif7n0H1ycbixm6/WH3SmxqPMG+CMiW8mTNTRrrAEceQVrq6tDHD8jdnOOw==" - }, - "@algolia/logger-console": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/logger-console/-/logger-console-4.8.4.tgz", - "integrity": "sha512-+9T3t/eB9vseANFz9YbFHG0cHjzVP/DVfGqzTAkeSlvMHP69JzJga9Wb0Ai6J3xXE3d4k9K+k6t+kkjCQjzEqg==", - "requires": { - "@algolia/logger-common": "4.8.4" - } - }, - "@algolia/requester-browser-xhr": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/requester-browser-xhr/-/requester-browser-xhr-4.8.4.tgz", - "integrity": "sha512-BYa8O/pht0UL2bcm0ZkLZiyC+5dHrbc6gvKIo+OgqxmDb/K4KrVo6RIof3BVpR8fgcfxQJohjNVHKXHxEUhBCQ==", - "requires": { - "@algolia/requester-common": "4.8.4" - } - }, - "@algolia/requester-common": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/requester-common/-/requester-common-4.8.4.tgz", - "integrity": "sha512-br3LXb6srfAy7F04axwExmrkPOlXCDckgTFoLFv/RT9Oo28SpoyvHqktyBovQLdzdTs+Laglf+LtOHr0iUrZJg==" - }, - "@algolia/requester-node-http": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/requester-node-http/-/requester-node-http-4.8.4.tgz", - "integrity": "sha512-o5Cc4UxYPn3IBHQSDBNFFhq1LQLv40eYvCvK0FPJ8xZkrnNXhjPvaLCu/lQTHpk/HX7DaE6fQ/KboU0OSPKevQ==", - "requires": { - "@algolia/requester-common": "4.8.4" - } - }, - "@algolia/transporter": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/@algolia/transporter/-/transporter-4.8.4.tgz", - "integrity": "sha512-EvXFYICxrr9QEO6m6awUeNOBstOxePQ2Fy0jtYlS1v9TY2P5HqKRzkxmaZjeYRBsXOImpVjgQIzTzj1Au4br2w==", - "requires": { - "@algolia/cache-common": "4.8.4", - "@algolia/logger-common": "4.8.4", - "@algolia/requester-common": "4.8.4" - } - }, - "@babel/code-frame": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/code-frame/-/code-frame-7.12.11.tgz", - "integrity": "sha512-Zt1yodBx1UcyiePMSkWnU4hPqhwq7hGi2nFL1LeA3EUl+q2LQx16MISgJ0+z7dnmgvP9QtIleuETGOiOH1RcIw==", - "requires": { - "@babel/highlight": "^7.10.4" - } - }, - "@babel/compat-data": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/compat-data/-/compat-data-7.12.7.tgz", - "integrity": "sha512-YaxPMGs/XIWtYqrdEOZOCPsVWfEoriXopnsz3/i7apYPXQ3698UFhS6dVT1KN5qOsWmVgw/FOrmQgpRaZayGsw==" - }, - "@babel/core": { - "version": "7.12.10", - "resolved": "https://registry.npmjs.org/@babel/core/-/core-7.12.10.tgz", - "integrity": "sha512-eTAlQKq65zHfkHZV0sIVODCPGVgoo1HdBlbSLi9CqOzuZanMv2ihzY+4paiKr1mH+XmYESMAmJ/dpZ68eN6d8w==", - "requires": { - "@babel/code-frame": "^7.10.4", - "@babel/generator": "^7.12.10", - "@babel/helper-module-transforms": "^7.12.1", - "@babel/helpers": "^7.12.5", - "@babel/parser": "^7.12.10", - "@babel/template": "^7.12.7", - "@babel/traverse": "^7.12.10", - "@babel/types": "^7.12.10", - "convert-source-map": "^1.7.0", - "debug": "^4.1.0", - "gensync": "^1.0.0-beta.1", - "json5": "^2.1.2", - "lodash": "^4.17.19", - "semver": "^5.4.1", - "source-map": "^0.5.0" - }, - "dependencies": { - "debug": { - "version": "4.3.1", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz", - "integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==", - "requires": { - "ms": "2.1.2" - } - }, - "json5": { - "version": "2.1.3", - "resolved": "https://registry.npmjs.org/json5/-/json5-2.1.3.tgz", - "integrity": "sha512-KXPvOm8K9IJKFM0bmdn8QXh7udDh1g/giieX0NLCaMnb4hEiVFqnop2ImTXCc5e0/oHz3LTqmHGtExn5hfMkOA==", - "requires": { - "minimist": "^1.2.5" - } - }, - "ms": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", - "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==" - }, - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - }, - "source-map": { - "version": "0.5.7", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz", - "integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=" - } - } - }, - "@babel/generator": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/generator/-/generator-7.12.11.tgz", - "integrity": "sha512-Ggg6WPOJtSi8yYQvLVjG8F/TlpWDlKx0OpS4Kt+xMQPs5OaGYWy+v1A+1TvxI6sAMGZpKWWoAQ1DaeQbImlItA==", - "requires": { - "@babel/types": "^7.12.11", - "jsesc": "^2.5.1", - "source-map": "^0.5.0" - }, - "dependencies": { - "source-map": { - "version": "0.5.7", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz", - "integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=" - } - } - }, - "@babel/helper-annotate-as-pure": { - "version": "7.12.10", - "resolved": "https://registry.npmjs.org/@babel/helper-annotate-as-pure/-/helper-annotate-as-pure-7.12.10.tgz", - "integrity": "sha512-XplmVbC1n+KY6jL8/fgLVXXUauDIB+lD5+GsQEh6F6GBF1dq1qy4DP4yXWzDKcoqXB3X58t61e85Fitoww4JVQ==", - "requires": { - "@babel/types": "^7.12.10" - } - }, - "@babel/helper-builder-binary-assignment-operator-visitor": { - "version": "7.10.4", - "resolved": "https://registry.npmjs.org/@babel/helper-builder-binary-assignment-operator-visitor/-/helper-builder-binary-assignment-operator-visitor-7.10.4.tgz", - "integrity": "sha512-L0zGlFrGWZK4PbT8AszSfLTM5sDU1+Az/En9VrdT8/LmEiJt4zXt+Jve9DCAnQcbqDhCI+29y/L93mrDzddCcg==", - "requires": { - "@babel/helper-explode-assignable-expression": "^7.10.4", - "@babel/types": "^7.10.4" - } - }, - "@babel/helper-compilation-targets": { - "version": "7.12.5", - "resolved": "https://registry.npmjs.org/@babel/helper-compilation-targets/-/helper-compilation-targets-7.12.5.tgz", - "integrity": "sha512-+qH6NrscMolUlzOYngSBMIOQpKUGPPsc61Bu5W10mg84LxZ7cmvnBHzARKbDoFxVvqqAbj6Tg6N7bSrWSPXMyw==", - "requires": { - "@babel/compat-data": "^7.12.5", - "@babel/helper-validator-option": "^7.12.1", - "browserslist": "^4.14.5", - "semver": "^5.5.0" - }, - "dependencies": { - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "@babel/helper-create-class-features-plugin": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/helper-create-class-features-plugin/-/helper-create-class-features-plugin-7.12.1.tgz", - "integrity": "sha512-hkL++rWeta/OVOBTRJc9a5Azh5mt5WgZUGAKMD8JM141YsE08K//bp1unBBieO6rUKkIPyUE0USQ30jAy3Sk1w==", - "requires": { - "@babel/helper-function-name": "^7.10.4", - "@babel/helper-member-expression-to-functions": "^7.12.1", - "@babel/helper-optimise-call-expression": "^7.10.4", - "@babel/helper-replace-supers": "^7.12.1", - "@babel/helper-split-export-declaration": "^7.10.4" - } - }, - "@babel/helper-create-regexp-features-plugin": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/helper-create-regexp-features-plugin/-/helper-create-regexp-features-plugin-7.12.7.tgz", - "integrity": "sha512-idnutvQPdpbduutvi3JVfEgcVIHooQnhvhx0Nk9isOINOIGYkZea1Pk2JlJRiUnMefrlvr0vkByATBY/mB4vjQ==", - "requires": { - "@babel/helper-annotate-as-pure": "^7.10.4", - "regexpu-core": "^4.7.1" - } - }, - "@babel/helper-define-map": { - "version": "7.10.5", - "resolved": "https://registry.npmjs.org/@babel/helper-define-map/-/helper-define-map-7.10.5.tgz", - "integrity": "sha512-fMw4kgFB720aQFXSVaXr79pjjcW5puTCM16+rECJ/plGS+zByelE8l9nCpV1GibxTnFVmUuYG9U8wYfQHdzOEQ==", - "requires": { - "@babel/helper-function-name": "^7.10.4", - "@babel/types": "^7.10.5", - "lodash": "^4.17.19" - } - }, - "@babel/helper-explode-assignable-expression": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/helper-explode-assignable-expression/-/helper-explode-assignable-expression-7.12.1.tgz", - "integrity": "sha512-dmUwH8XmlrUpVqgtZ737tK88v07l840z9j3OEhCLwKTkjlvKpfqXVIZ0wpK3aeOxspwGrf/5AP5qLx4rO3w5rA==", - "requires": { - "@babel/types": "^7.12.1" - } - }, - "@babel/helper-function-name": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/helper-function-name/-/helper-function-name-7.12.11.tgz", - "integrity": "sha512-AtQKjtYNolKNi6nNNVLQ27CP6D9oFR6bq/HPYSizlzbp7uC1M59XJe8L+0uXjbIaZaUJF99ruHqVGiKXU/7ybA==", - "requires": { - "@babel/helper-get-function-arity": "^7.12.10", - "@babel/template": "^7.12.7", - "@babel/types": "^7.12.11" - } - }, - "@babel/helper-get-function-arity": { - "version": "7.12.10", - "resolved": "https://registry.npmjs.org/@babel/helper-get-function-arity/-/helper-get-function-arity-7.12.10.tgz", - "integrity": "sha512-mm0n5BPjR06wh9mPQaDdXWDoll/j5UpCAPl1x8fS71GHm7HA6Ua2V4ylG1Ju8lvcTOietbPNNPaSilKj+pj+Ag==", - "requires": { - "@babel/types": "^7.12.10" - } - }, - "@babel/helper-hoist-variables": { - "version": "7.10.4", - "resolved": "https://registry.npmjs.org/@babel/helper-hoist-variables/-/helper-hoist-variables-7.10.4.tgz", - "integrity": "sha512-wljroF5PgCk2juF69kanHVs6vrLwIPNp6DLD+Lrl3hoQ3PpPPikaDRNFA+0t81NOoMt2DL6WW/mdU8k4k6ZzuA==", - "requires": { - "@babel/types": "^7.10.4" - } - }, - "@babel/helper-member-expression-to-functions": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/helper-member-expression-to-functions/-/helper-member-expression-to-functions-7.12.7.tgz", - "integrity": "sha512-DCsuPyeWxeHgh1Dus7APn7iza42i/qXqiFPWyBDdOFtvS581JQePsc1F/nD+fHrcswhLlRc2UpYS1NwERxZhHw==", - "requires": { - "@babel/types": "^7.12.7" - } - }, - "@babel/helper-module-imports": { - "version": "7.12.5", - "resolved": "https://registry.npmjs.org/@babel/helper-module-imports/-/helper-module-imports-7.12.5.tgz", - "integrity": "sha512-SR713Ogqg6++uexFRORf/+nPXMmWIn80TALu0uaFb+iQIUoR7bOC7zBWyzBs5b3tBBJXuyD0cRu1F15GyzjOWA==", - "requires": { - "@babel/types": "^7.12.5" - } - }, - "@babel/helper-module-transforms": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/helper-module-transforms/-/helper-module-transforms-7.12.1.tgz", - "integrity": "sha512-QQzehgFAZ2bbISiCpmVGfiGux8YVFXQ0abBic2Envhej22DVXV9nCFaS5hIQbkyo1AdGb+gNME2TSh3hYJVV/w==", - "requires": { - "@babel/helper-module-imports": "^7.12.1", - "@babel/helper-replace-supers": "^7.12.1", - "@babel/helper-simple-access": "^7.12.1", - "@babel/helper-split-export-declaration": "^7.11.0", - "@babel/helper-validator-identifier": "^7.10.4", - "@babel/template": "^7.10.4", - "@babel/traverse": "^7.12.1", - "@babel/types": "^7.12.1", - "lodash": "^4.17.19" - } - }, - "@babel/helper-optimise-call-expression": { - "version": "7.12.10", - "resolved": "https://registry.npmjs.org/@babel/helper-optimise-call-expression/-/helper-optimise-call-expression-7.12.10.tgz", - "integrity": "sha512-4tpbU0SrSTjjt65UMWSrUOPZTsgvPgGG4S8QSTNHacKzpS51IVWGDj0yCwyeZND/i+LSN2g/O63jEXEWm49sYQ==", - "requires": { - "@babel/types": "^7.12.10" - } - }, - "@babel/helper-plugin-utils": { - "version": "7.10.4", - "resolved": "https://registry.npmjs.org/@babel/helper-plugin-utils/-/helper-plugin-utils-7.10.4.tgz", - "integrity": "sha512-O4KCvQA6lLiMU9l2eawBPMf1xPP8xPfB3iEQw150hOVTqj/rfXz0ThTb4HEzqQfs2Bmo5Ay8BzxfzVtBrr9dVg==" - }, - "@babel/helper-remap-async-to-generator": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/helper-remap-async-to-generator/-/helper-remap-async-to-generator-7.12.1.tgz", - "integrity": "sha512-9d0KQCRM8clMPcDwo8SevNs+/9a8yWVVmaE80FGJcEP8N1qToREmWEGnBn8BUlJhYRFz6fqxeRL1sl5Ogsed7A==", - "requires": { - "@babel/helper-annotate-as-pure": "^7.10.4", - "@babel/helper-wrap-function": "^7.10.4", - "@babel/types": "^7.12.1" - } - }, - "@babel/helper-replace-supers": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/helper-replace-supers/-/helper-replace-supers-7.12.11.tgz", - "integrity": "sha512-q+w1cqmhL7R0FNzth/PLLp2N+scXEK/L2AHbXUyydxp828F4FEa5WcVoqui9vFRiHDQErj9Zof8azP32uGVTRA==", - "requires": { - "@babel/helper-member-expression-to-functions": "^7.12.7", - "@babel/helper-optimise-call-expression": "^7.12.10", - "@babel/traverse": "^7.12.10", - "@babel/types": "^7.12.11" - } - }, - "@babel/helper-simple-access": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/helper-simple-access/-/helper-simple-access-7.12.1.tgz", - "integrity": "sha512-OxBp7pMrjVewSSC8fXDFrHrBcJATOOFssZwv16F3/6Xtc138GHybBfPbm9kfiqQHKhYQrlamWILwlDCeyMFEaA==", - "requires": { - "@babel/types": "^7.12.1" - } - }, - "@babel/helper-skip-transparent-expression-wrappers": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/helper-skip-transparent-expression-wrappers/-/helper-skip-transparent-expression-wrappers-7.12.1.tgz", - "integrity": "sha512-Mf5AUuhG1/OCChOJ/HcADmvcHM42WJockombn8ATJG3OnyiSxBK/Mm5x78BQWvmtXZKHgbjdGL2kin/HOLlZGA==", - "requires": { - "@babel/types": "^7.12.1" - } - }, - "@babel/helper-split-export-declaration": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/helper-split-export-declaration/-/helper-split-export-declaration-7.12.11.tgz", - "integrity": "sha512-LsIVN8j48gHgwzfocYUSkO/hjYAOJqlpJEc7tGXcIm4cubjVUf8LGW6eWRyxEu7gA25q02p0rQUWoCI33HNS5g==", - "requires": { - "@babel/types": "^7.12.11" - } - }, - "@babel/helper-validator-identifier": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.12.11.tgz", - "integrity": "sha512-np/lG3uARFybkoHokJUmf1QfEvRVCPbmQeUQpKow5cQ3xWrV9i3rUHodKDJPQfTVX61qKi+UdYk8kik84n7XOw==" - }, - "@babel/helper-validator-option": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/helper-validator-option/-/helper-validator-option-7.12.11.tgz", - "integrity": "sha512-TBFCyj939mFSdeX7U7DDj32WtzYY7fDcalgq8v3fBZMNOJQNn7nOYzMaUCiPxPYfCup69mtIpqlKgMZLvQ8Xhw==" - }, - "@babel/helper-wrap-function": { - "version": "7.12.3", - "resolved": "https://registry.npmjs.org/@babel/helper-wrap-function/-/helper-wrap-function-7.12.3.tgz", - "integrity": "sha512-Cvb8IuJDln3rs6tzjW3Y8UeelAOdnpB8xtQ4sme2MSZ9wOxrbThporC0y/EtE16VAtoyEfLM404Xr1e0OOp+ow==", - "requires": { - "@babel/helper-function-name": "^7.10.4", - "@babel/template": "^7.10.4", - "@babel/traverse": "^7.10.4", - "@babel/types": "^7.10.4" - } - }, - "@babel/helpers": { - "version": "7.12.5", - "resolved": "https://registry.npmjs.org/@babel/helpers/-/helpers-7.12.5.tgz", - "integrity": "sha512-lgKGMQlKqA8meJqKsW6rUnc4MdUk35Ln0ATDqdM1a/UpARODdI4j5Y5lVfUScnSNkJcdCRAaWkspykNoFg9sJA==", - "requires": { - "@babel/template": "^7.10.4", - "@babel/traverse": "^7.12.5", - "@babel/types": "^7.12.5" - } - }, - "@babel/highlight": { - "version": "7.10.4", - "resolved": "https://registry.npmjs.org/@babel/highlight/-/highlight-7.10.4.tgz", - "integrity": "sha512-i6rgnR/YgPEQzZZnbTHHuZdlE8qyoBNalD6F+q4vAFlcMEcqmkoG+mPqJYJCo63qPf74+Y1UZsl3l6f7/RIkmA==", - "requires": { - "@babel/helper-validator-identifier": "^7.10.4", - "chalk": "^2.0.0", - "js-tokens": "^4.0.0" - } - }, - "@babel/parser": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/parser/-/parser-7.12.11.tgz", - "integrity": "sha512-N3UxG+uuF4CMYoNj8AhnbAcJF0PiuJ9KHuy1lQmkYsxTer/MAH9UBNHsBoAX/4s6NvlDD047No8mYVGGzLL4hg==" - }, - "@babel/plugin-proposal-async-generator-functions": { - "version": "7.12.12", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-async-generator-functions/-/plugin-proposal-async-generator-functions-7.12.12.tgz", - "integrity": "sha512-nrz9y0a4xmUrRq51bYkWJIO5SBZyG2ys2qinHsN0zHDHVsUaModrkpyWWWXfGqYQmOL3x9sQIcTNN/pBGpo09A==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-remap-async-to-generator": "^7.12.1", - "@babel/plugin-syntax-async-generators": "^7.8.0" - } - }, - "@babel/plugin-proposal-class-properties": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-class-properties/-/plugin-proposal-class-properties-7.12.1.tgz", - "integrity": "sha512-cKp3dlQsFsEs5CWKnN7BnSHOd0EOW8EKpEjkoz1pO2E5KzIDNV9Ros1b0CnmbVgAGXJubOYVBOGCT1OmJwOI7w==", - "requires": { - "@babel/helper-create-class-features-plugin": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-proposal-decorators": { - "version": "7.12.12", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-decorators/-/plugin-proposal-decorators-7.12.12.tgz", - "integrity": "sha512-fhkE9lJYpw2mjHelBpM2zCbaA11aov2GJs7q4cFaXNrWx0H3bW58H9Esy2rdtYOghFBEYUDRIpvlgi+ZD+AvvQ==", - "requires": { - "@babel/helper-create-class-features-plugin": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-decorators": "^7.12.1" - } - }, - "@babel/plugin-proposal-dynamic-import": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-dynamic-import/-/plugin-proposal-dynamic-import-7.12.1.tgz", - "integrity": "sha512-a4rhUSZFuq5W8/OO8H7BL5zspjnc1FLd9hlOxIK/f7qG4a0qsqk8uvF/ywgBA8/OmjsapjpvaEOYItfGG1qIvQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-dynamic-import": "^7.8.0" - } - }, - "@babel/plugin-proposal-export-namespace-from": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-export-namespace-from/-/plugin-proposal-export-namespace-from-7.12.1.tgz", - "integrity": "sha512-6CThGf0irEkzujYS5LQcjBx8j/4aQGiVv7J9+2f7pGfxqyKh3WnmVJYW3hdrQjyksErMGBPQrCnHfOtna+WLbw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-export-namespace-from": "^7.8.3" - } - }, - "@babel/plugin-proposal-json-strings": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-json-strings/-/plugin-proposal-json-strings-7.12.1.tgz", - "integrity": "sha512-GoLDUi6U9ZLzlSda2Df++VSqDJg3CG+dR0+iWsv6XRw1rEq+zwt4DirM9yrxW6XWaTpmai1cWJLMfM8qQJf+yw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-json-strings": "^7.8.0" - } - }, - "@babel/plugin-proposal-logical-assignment-operators": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-logical-assignment-operators/-/plugin-proposal-logical-assignment-operators-7.12.1.tgz", - "integrity": "sha512-k8ZmVv0JU+4gcUGeCDZOGd0lCIamU/sMtIiX3UWnUc5yzgq6YUGyEolNYD+MLYKfSzgECPcqetVcJP9Afe/aCA==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-logical-assignment-operators": "^7.10.4" - } - }, - "@babel/plugin-proposal-nullish-coalescing-operator": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-nullish-coalescing-operator/-/plugin-proposal-nullish-coalescing-operator-7.12.1.tgz", - "integrity": "sha512-nZY0ESiaQDI1y96+jk6VxMOaL4LPo/QDHBqL+SF3/vl6dHkTwHlOI8L4ZwuRBHgakRBw5zsVylel7QPbbGuYgg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-nullish-coalescing-operator": "^7.8.0" - } - }, - "@babel/plugin-proposal-numeric-separator": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-numeric-separator/-/plugin-proposal-numeric-separator-7.12.7.tgz", - "integrity": "sha512-8c+uy0qmnRTeukiGsjLGy6uVs/TFjJchGXUeBqlG4VWYOdJWkhhVPdQ3uHwbmalfJwv2JsV0qffXP4asRfL2SQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-numeric-separator": "^7.10.4" - } - }, - "@babel/plugin-proposal-object-rest-spread": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-object-rest-spread/-/plugin-proposal-object-rest-spread-7.12.1.tgz", - "integrity": "sha512-s6SowJIjzlhx8o7lsFx5zmY4At6CTtDvgNQDdPzkBQucle58A6b/TTeEBYtyDgmcXjUTM+vE8YOGHZzzbc/ioA==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-object-rest-spread": "^7.8.0", - "@babel/plugin-transform-parameters": "^7.12.1" - } - }, - "@babel/plugin-proposal-optional-catch-binding": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-optional-catch-binding/-/plugin-proposal-optional-catch-binding-7.12.1.tgz", - "integrity": "sha512-hFvIjgprh9mMw5v42sJWLI1lzU5L2sznP805zeT6rySVRA0Y18StRhDqhSxlap0oVgItRsB6WSROp4YnJTJz0g==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/plugin-syntax-optional-catch-binding": "^7.8.0" - } - }, - "@babel/plugin-proposal-optional-chaining": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-optional-chaining/-/plugin-proposal-optional-chaining-7.12.7.tgz", - "integrity": "sha512-4ovylXZ0PWmwoOvhU2vhnzVNnm88/Sm9nx7V8BPgMvAzn5zDou3/Awy0EjglyubVHasJj+XCEkr/r1X3P5elCA==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-skip-transparent-expression-wrappers": "^7.12.1", - "@babel/plugin-syntax-optional-chaining": "^7.8.0" - } - }, - "@babel/plugin-proposal-private-methods": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-private-methods/-/plugin-proposal-private-methods-7.12.1.tgz", - "integrity": "sha512-mwZ1phvH7/NHK6Kf8LP7MYDogGV+DKB1mryFOEwx5EBNQrosvIczzZFTUmWaeujd5xT6G1ELYWUz3CutMhjE1w==", - "requires": { - "@babel/helper-create-class-features-plugin": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-proposal-unicode-property-regex": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-proposal-unicode-property-regex/-/plugin-proposal-unicode-property-regex-7.12.1.tgz", - "integrity": "sha512-MYq+l+PvHuw/rKUz1at/vb6nCnQ2gmJBNaM62z0OgH7B2W1D9pvkpYtlti9bGtizNIU1K3zm4bZF9F91efVY0w==", - "requires": { - "@babel/helper-create-regexp-features-plugin": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-syntax-async-generators": { - "version": "7.8.4", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-async-generators/-/plugin-syntax-async-generators-7.8.4.tgz", - "integrity": "sha512-tycmZxkGfZaxhMRbXlPXuVFpdWlXpir2W4AMhSJgRKzk/eDlIXOhb2LHWoLpDF7TEHylV5zNhykX6KAgHJmTNw==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-class-properties": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-class-properties/-/plugin-syntax-class-properties-7.12.1.tgz", - "integrity": "sha512-U40A76x5gTwmESz+qiqssqmeEsKvcSyvtgktrm0uzcARAmM9I1jR221f6Oq+GmHrcD+LvZDag1UTOTe2fL3TeA==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-syntax-decorators": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-decorators/-/plugin-syntax-decorators-7.12.1.tgz", - "integrity": "sha512-ir9YW5daRrTYiy9UJ2TzdNIJEZu8KclVzDcfSt4iEmOtwQ4llPtWInNKJyKnVXp1vE4bbVd5S31M/im3mYMO1w==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-syntax-dynamic-import": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-dynamic-import/-/plugin-syntax-dynamic-import-7.8.3.tgz", - "integrity": "sha512-5gdGbFon+PszYzqs83S3E5mpi7/y/8M9eC90MRTZfduQOYW76ig6SOSPNe41IG5LoP3FGBn2N0RjVDSQiS94kQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-export-namespace-from": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-export-namespace-from/-/plugin-syntax-export-namespace-from-7.8.3.tgz", - "integrity": "sha512-MXf5laXo6c1IbEbegDmzGPwGNTsHZmEy6QGznu5Sh2UCWvueywb2ee+CCE4zQiZstxU9BMoQO9i6zUFSY0Kj0Q==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.3" - } - }, - "@babel/plugin-syntax-json-strings": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-json-strings/-/plugin-syntax-json-strings-7.8.3.tgz", - "integrity": "sha512-lY6kdGpWHvjoe2vk4WrAapEuBR69EMxZl+RoGRhrFGNYVK8mOPAW8VfbT/ZgrFbXlDNiiaxQnAtgVCZ6jv30EA==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-jsx": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-jsx/-/plugin-syntax-jsx-7.12.1.tgz", - "integrity": "sha512-1yRi7yAtB0ETgxdY9ti/p2TivUxJkTdhu/ZbF9MshVGqOx1TdB3b7xCXs49Fupgg50N45KcAsRP/ZqWjs9SRjg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-syntax-logical-assignment-operators": { - "version": "7.10.4", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-logical-assignment-operators/-/plugin-syntax-logical-assignment-operators-7.10.4.tgz", - "integrity": "sha512-d8waShlpFDinQ5MtvGU9xDAOzKH47+FFoney2baFIoMr952hKOLp1HR7VszoZvOsV/4+RRszNY7D17ba0te0ig==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-syntax-nullish-coalescing-operator": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-nullish-coalescing-operator/-/plugin-syntax-nullish-coalescing-operator-7.8.3.tgz", - "integrity": "sha512-aSff4zPII1u2QD7y+F8oDsz19ew4IGEJg9SVW+bqwpwtfFleiQDMdzA/R+UlWDzfnHFCxxleFT0PMIrR36XLNQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-numeric-separator": { - "version": "7.10.4", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-numeric-separator/-/plugin-syntax-numeric-separator-7.10.4.tgz", - "integrity": "sha512-9H6YdfkcK/uOnY/K7/aA2xpzaAgkQn37yzWUMRK7OaPOqOpGS1+n0H5hxT9AUw9EsSjPW8SVyMJwYRtWs3X3ug==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-syntax-object-rest-spread": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-object-rest-spread/-/plugin-syntax-object-rest-spread-7.8.3.tgz", - "integrity": "sha512-XoqMijGZb9y3y2XskN+P1wUGiVwWZ5JmoDRwx5+3GmEplNyVM2s2Dg8ILFQm8rWM48orGy5YpI5Bl8U1y7ydlA==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-optional-catch-binding": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-optional-catch-binding/-/plugin-syntax-optional-catch-binding-7.8.3.tgz", - "integrity": "sha512-6VPD0Pc1lpTqw0aKoeRTMiB+kWhAoT24PA+ksWSBrFtl5SIRVpZlwN3NNPQjehA2E/91FV3RjLWoVTglWcSV3Q==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-optional-chaining": { - "version": "7.8.3", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-optional-chaining/-/plugin-syntax-optional-chaining-7.8.3.tgz", - "integrity": "sha512-KoK9ErH1MBlCPxV0VANkXW2/dw4vlbGDrFgz8bmUsBGYkFRcbRwMh6cIJubdPrkxRwuGdtCk0v/wPTKbQgBjkg==", - "requires": { - "@babel/helper-plugin-utils": "^7.8.0" - } - }, - "@babel/plugin-syntax-top-level-await": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-syntax-top-level-await/-/plugin-syntax-top-level-await-7.12.1.tgz", - "integrity": "sha512-i7ooMZFS+a/Om0crxZodrTzNEPJHZrlMVGMTEpFAj6rYY/bKCddB0Dk/YxfPuYXOopuhKk/e1jV6h+WUU9XN3A==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-arrow-functions": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-arrow-functions/-/plugin-transform-arrow-functions-7.12.1.tgz", - "integrity": "sha512-5QB50qyN44fzzz4/qxDPQMBCTHgxg3n0xRBLJUmBlLoU/sFvxVWGZF/ZUfMVDQuJUKXaBhbupxIzIfZ6Fwk/0A==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-async-to-generator": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-async-to-generator/-/plugin-transform-async-to-generator-7.12.1.tgz", - "integrity": "sha512-SDtqoEcarK1DFlRJ1hHRY5HvJUj5kX4qmtpMAm2QnhOlyuMC4TMdCRgW6WXpv93rZeYNeLP22y8Aq2dbcDRM1A==", - "requires": { - "@babel/helper-module-imports": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-remap-async-to-generator": "^7.12.1" - } - }, - "@babel/plugin-transform-block-scoped-functions": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-block-scoped-functions/-/plugin-transform-block-scoped-functions-7.12.1.tgz", - "integrity": "sha512-5OpxfuYnSgPalRpo8EWGPzIYf0lHBWORCkj5M0oLBwHdlux9Ri36QqGW3/LR13RSVOAoUUMzoPI/jpE4ABcHoA==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-block-scoping": { - "version": "7.12.12", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-block-scoping/-/plugin-transform-block-scoping-7.12.12.tgz", - "integrity": "sha512-VOEPQ/ExOVqbukuP7BYJtI5ZxxsmegTwzZ04j1aF0dkSypGo9XpDHuOrABsJu+ie+penpSJheDJ11x1BEZNiyQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-classes": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-classes/-/plugin-transform-classes-7.12.1.tgz", - "integrity": "sha512-/74xkA7bVdzQTBeSUhLLJgYIcxw/dpEpCdRDiHgPJ3Mv6uC11UhjpOhl72CgqbBCmt1qtssCyB2xnJm1+PFjog==", - "requires": { - "@babel/helper-annotate-as-pure": "^7.10.4", - "@babel/helper-define-map": "^7.10.4", - "@babel/helper-function-name": "^7.10.4", - "@babel/helper-optimise-call-expression": "^7.10.4", - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-replace-supers": "^7.12.1", - "@babel/helper-split-export-declaration": "^7.10.4", - "globals": "^11.1.0" - } - }, - "@babel/plugin-transform-computed-properties": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-computed-properties/-/plugin-transform-computed-properties-7.12.1.tgz", - "integrity": "sha512-vVUOYpPWB7BkgUWPo4C44mUQHpTZXakEqFjbv8rQMg7TC6S6ZhGZ3otQcRH6u7+adSlE5i0sp63eMC/XGffrzg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-destructuring": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-destructuring/-/plugin-transform-destructuring-7.12.1.tgz", - "integrity": "sha512-fRMYFKuzi/rSiYb2uRLiUENJOKq4Gnl+6qOv5f8z0TZXg3llUwUhsNNwrwaT/6dUhJTzNpBr+CUvEWBtfNY1cw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-dotall-regex": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-dotall-regex/-/plugin-transform-dotall-regex-7.12.1.tgz", - "integrity": "sha512-B2pXeRKoLszfEW7J4Hg9LoFaWEbr/kzo3teWHmtFCszjRNa/b40f9mfeqZsIDLLt/FjwQ6pz/Gdlwy85xNckBA==", - "requires": { - "@babel/helper-create-regexp-features-plugin": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-duplicate-keys": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-duplicate-keys/-/plugin-transform-duplicate-keys-7.12.1.tgz", - "integrity": "sha512-iRght0T0HztAb/CazveUpUQrZY+aGKKaWXMJ4uf9YJtqxSUe09j3wteztCUDRHs+SRAL7yMuFqUsLoAKKzgXjw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-exponentiation-operator": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-exponentiation-operator/-/plugin-transform-exponentiation-operator-7.12.1.tgz", - "integrity": "sha512-7tqwy2bv48q+c1EHbXK0Zx3KXd2RVQp6OC7PbwFNt/dPTAV3Lu5sWtWuAj8owr5wqtWnqHfl2/mJlUmqkChKug==", - "requires": { - "@babel/helper-builder-binary-assignment-operator-visitor": "^7.10.4", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-for-of": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-for-of/-/plugin-transform-for-of-7.12.1.tgz", - "integrity": "sha512-Zaeq10naAsuHo7heQvyV0ptj4dlZJwZgNAtBYBnu5nNKJoW62m0zKcIEyVECrUKErkUkg6ajMy4ZfnVZciSBhg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-function-name": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-function-name/-/plugin-transform-function-name-7.12.1.tgz", - "integrity": "sha512-JF3UgJUILoFrFMEnOJLJkRHSk6LUSXLmEFsA23aR2O5CSLUxbeUX1IZ1YQ7Sn0aXb601Ncwjx73a+FVqgcljVw==", - "requires": { - "@babel/helper-function-name": "^7.10.4", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-literals": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-literals/-/plugin-transform-literals-7.12.1.tgz", - "integrity": "sha512-+PxVGA+2Ag6uGgL0A5f+9rklOnnMccwEBzwYFL3EUaKuiyVnUipyXncFcfjSkbimLrODoqki1U9XxZzTvfN7IQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-member-expression-literals": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-member-expression-literals/-/plugin-transform-member-expression-literals-7.12.1.tgz", - "integrity": "sha512-1sxePl6z9ad0gFMB9KqmYofk34flq62aqMt9NqliS/7hPEpURUCMbyHXrMPlo282iY7nAvUB1aQd5mg79UD9Jg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-modules-amd": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-amd/-/plugin-transform-modules-amd-7.12.1.tgz", - "integrity": "sha512-tDW8hMkzad5oDtzsB70HIQQRBiTKrhfgwC/KkJeGsaNFTdWhKNt/BiE8c5yj19XiGyrxpbkOfH87qkNg1YGlOQ==", - "requires": { - "@babel/helper-module-transforms": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4", - "babel-plugin-dynamic-import-node": "^2.3.3" - } - }, - "@babel/plugin-transform-modules-commonjs": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-commonjs/-/plugin-transform-modules-commonjs-7.12.1.tgz", - "integrity": "sha512-dY789wq6l0uLY8py9c1B48V8mVL5gZh/+PQ5ZPrylPYsnAvnEMjqsUXkuoDVPeVK+0VyGar+D08107LzDQ6pag==", - "requires": { - "@babel/helper-module-transforms": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-simple-access": "^7.12.1", - "babel-plugin-dynamic-import-node": "^2.3.3" - } - }, - "@babel/plugin-transform-modules-systemjs": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-systemjs/-/plugin-transform-modules-systemjs-7.12.1.tgz", - "integrity": "sha512-Hn7cVvOavVh8yvW6fLwveFqSnd7rbQN3zJvoPNyNaQSvgfKmDBO9U1YL9+PCXGRlZD9tNdWTy5ACKqMuzyn32Q==", - "requires": { - "@babel/helper-hoist-variables": "^7.10.4", - "@babel/helper-module-transforms": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-validator-identifier": "^7.10.4", - "babel-plugin-dynamic-import-node": "^2.3.3" - } - }, - "@babel/plugin-transform-modules-umd": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-modules-umd/-/plugin-transform-modules-umd-7.12.1.tgz", - "integrity": "sha512-aEIubCS0KHKM0zUos5fIoQm+AZUMt1ZvMpqz0/H5qAQ7vWylr9+PLYurT+Ic7ID/bKLd4q8hDovaG3Zch2uz5Q==", - "requires": { - "@babel/helper-module-transforms": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-named-capturing-groups-regex": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-named-capturing-groups-regex/-/plugin-transform-named-capturing-groups-regex-7.12.1.tgz", - "integrity": "sha512-tB43uQ62RHcoDp9v2Nsf+dSM8sbNodbEicbQNA53zHz8pWUhsgHSJCGpt7daXxRydjb0KnfmB+ChXOv3oADp1Q==", - "requires": { - "@babel/helper-create-regexp-features-plugin": "^7.12.1" - } - }, - "@babel/plugin-transform-new-target": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-new-target/-/plugin-transform-new-target-7.12.1.tgz", - "integrity": "sha512-+eW/VLcUL5L9IvJH7rT1sT0CzkdUTvPrXC2PXTn/7z7tXLBuKvezYbGdxD5WMRoyvyaujOq2fWoKl869heKjhw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-object-super": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-object-super/-/plugin-transform-object-super-7.12.1.tgz", - "integrity": "sha512-AvypiGJH9hsquNUn+RXVcBdeE3KHPZexWRdimhuV59cSoOt5kFBmqlByorAeUlGG2CJWd0U+4ZtNKga/TB0cAw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-replace-supers": "^7.12.1" - } - }, - "@babel/plugin-transform-parameters": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-parameters/-/plugin-transform-parameters-7.12.1.tgz", - "integrity": "sha512-xq9C5EQhdPK23ZeCdMxl8bbRnAgHFrw5EOC3KJUsSylZqdkCaFEXxGSBuTSObOpiiHHNyb82es8M1QYgfQGfNg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-property-literals": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-property-literals/-/plugin-transform-property-literals-7.12.1.tgz", - "integrity": "sha512-6MTCR/mZ1MQS+AwZLplX4cEySjCpnIF26ToWo942nqn8hXSm7McaHQNeGx/pt7suI1TWOWMfa/NgBhiqSnX0cQ==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-regenerator": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-regenerator/-/plugin-transform-regenerator-7.12.1.tgz", - "integrity": "sha512-gYrHqs5itw6i4PflFX3OdBPMQdPbF4bj2REIUxlMRUFk0/ZOAIpDFuViuxPjUL7YC8UPnf+XG7/utJvqXdPKng==", - "requires": { - "regenerator-transform": "^0.14.2" - } - }, - "@babel/plugin-transform-reserved-words": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-reserved-words/-/plugin-transform-reserved-words-7.12.1.tgz", - "integrity": "sha512-pOnUfhyPKvZpVyBHhSBoX8vfA09b7r00Pmm1sH+29ae2hMTKVmSp4Ztsr8KBKjLjx17H0eJqaRC3bR2iThM54A==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-runtime": { - "version": "7.12.10", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-runtime/-/plugin-transform-runtime-7.12.10.tgz", - "integrity": "sha512-xOrUfzPxw7+WDm9igMgQCbO3cJKymX7dFdsgRr1eu9n3KjjyU4pptIXbXPseQDquw+W+RuJEJMHKHNsPNNm3CA==", - "requires": { - "@babel/helper-module-imports": "^7.12.5", - "@babel/helper-plugin-utils": "^7.10.4", - "semver": "^5.5.1" - }, - "dependencies": { - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "@babel/plugin-transform-shorthand-properties": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-shorthand-properties/-/plugin-transform-shorthand-properties-7.12.1.tgz", - "integrity": "sha512-GFZS3c/MhX1OusqB1MZ1ct2xRzX5ppQh2JU1h2Pnfk88HtFTM+TWQqJNfwkmxtPQtb/s1tk87oENfXJlx7rSDw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-spread": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-spread/-/plugin-transform-spread-7.12.1.tgz", - "integrity": "sha512-vuLp8CP0BE18zVYjsEBZ5xoCecMK6LBMMxYzJnh01rxQRvhNhH1csMMmBfNo5tGpGO+NhdSNW2mzIvBu3K1fng==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-skip-transparent-expression-wrappers": "^7.12.1" - } - }, - "@babel/plugin-transform-sticky-regex": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-sticky-regex/-/plugin-transform-sticky-regex-7.12.7.tgz", - "integrity": "sha512-VEiqZL5N/QvDbdjfYQBhruN0HYjSPjC4XkeqW4ny/jNtH9gcbgaqBIXYEZCNnESMAGs0/K/R7oFGMhOyu/eIxg==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-template-literals": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-template-literals/-/plugin-transform-template-literals-7.12.1.tgz", - "integrity": "sha512-b4Zx3KHi+taXB1dVRBhVJtEPi9h1THCeKmae2qP0YdUHIFhVjtpqqNfxeVAa1xeHVhAy4SbHxEwx5cltAu5apw==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-typeof-symbol": { - "version": "7.12.10", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-typeof-symbol/-/plugin-transform-typeof-symbol-7.12.10.tgz", - "integrity": "sha512-JQ6H8Rnsogh//ijxspCjc21YPd3VLVoYtAwv3zQmqAt8YGYUtdo5usNhdl4b9/Vir2kPFZl6n1h0PfUz4hJhaA==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-unicode-escapes": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-unicode-escapes/-/plugin-transform-unicode-escapes-7.12.1.tgz", - "integrity": "sha512-I8gNHJLIc7GdApm7wkVnStWssPNbSRMPtgHdmH3sRM1zopz09UWPS4x5V4n1yz/MIWTVnJ9sp6IkuXdWM4w+2Q==", - "requires": { - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/plugin-transform-unicode-regex": { - "version": "7.12.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-unicode-regex/-/plugin-transform-unicode-regex-7.12.1.tgz", - "integrity": "sha512-SqH4ClNngh/zGwHZOOQMTD+e8FGWexILV+ePMyiDJttAWRh5dhDL8rcl5lSgU3Huiq6Zn6pWTMvdPAb21Dwdyg==", - "requires": { - "@babel/helper-create-regexp-features-plugin": "^7.12.1", - "@babel/helper-plugin-utils": "^7.10.4" - } - }, - "@babel/preset-env": { - "version": "7.12.11", - "resolved": "https://registry.npmjs.org/@babel/preset-env/-/preset-env-7.12.11.tgz", - "integrity": "sha512-j8Tb+KKIXKYlDBQyIOy4BLxzv1NUOwlHfZ74rvW+Z0Gp4/cI2IMDPBWAgWceGcE7aep9oL/0K9mlzlMGxA8yNw==", - "requires": { - "@babel/compat-data": "^7.12.7", - "@babel/helper-compilation-targets": "^7.12.5", - "@babel/helper-module-imports": "^7.12.5", - "@babel/helper-plugin-utils": "^7.10.4", - "@babel/helper-validator-option": "^7.12.11", - "@babel/plugin-proposal-async-generator-functions": "^7.12.1", - "@babel/plugin-proposal-class-properties": "^7.12.1", - "@babel/plugin-proposal-dynamic-import": "^7.12.1", - "@babel/plugin-proposal-export-namespace-from": "^7.12.1", - "@babel/plugin-proposal-json-strings": "^7.12.1", - "@babel/plugin-proposal-logical-assignment-operators": "^7.12.1", - "@babel/plugin-proposal-nullish-coalescing-operator": "^7.12.1", - "@babel/plugin-proposal-numeric-separator": "^7.12.7", - "@babel/plugin-proposal-object-rest-spread": "^7.12.1", - "@babel/plugin-proposal-optional-catch-binding": "^7.12.1", - "@babel/plugin-proposal-optional-chaining": "^7.12.7", - "@babel/plugin-proposal-private-methods": "^7.12.1", - "@babel/plugin-proposal-unicode-property-regex": "^7.12.1", - "@babel/plugin-syntax-async-generators": "^7.8.0", - "@babel/plugin-syntax-class-properties": "^7.12.1", - "@babel/plugin-syntax-dynamic-import": "^7.8.0", - "@babel/plugin-syntax-export-namespace-from": "^7.8.3", - "@babel/plugin-syntax-json-strings": "^7.8.0", - "@babel/plugin-syntax-logical-assignment-operators": "^7.10.4", - "@babel/plugin-syntax-nullish-coalescing-operator": "^7.8.0", - "@babel/plugin-syntax-numeric-separator": "^7.10.4", - "@babel/plugin-syntax-object-rest-spread": "^7.8.0", - "@babel/plugin-syntax-optional-catch-binding": "^7.8.0", - "@babel/plugin-syntax-optional-chaining": "^7.8.0", - "@babel/plugin-syntax-top-level-await": "^7.12.1", - "@babel/plugin-transform-arrow-functions": "^7.12.1", - "@babel/plugin-transform-async-to-generator": "^7.12.1", - "@babel/plugin-transform-block-scoped-functions": "^7.12.1", - "@babel/plugin-transform-block-scoping": "^7.12.11", - "@babel/plugin-transform-classes": "^7.12.1", - "@babel/plugin-transform-computed-properties": "^7.12.1", - "@babel/plugin-transform-destructuring": "^7.12.1", - "@babel/plugin-transform-dotall-regex": "^7.12.1", - "@babel/plugin-transform-duplicate-keys": "^7.12.1", - "@babel/plugin-transform-exponentiation-operator": "^7.12.1", - "@babel/plugin-transform-for-of": "^7.12.1", - "@babel/plugin-transform-function-name": "^7.12.1", - "@babel/plugin-transform-literals": "^7.12.1", - "@babel/plugin-transform-member-expression-literals": "^7.12.1", - "@babel/plugin-transform-modules-amd": "^7.12.1", - "@babel/plugin-transform-modules-commonjs": "^7.12.1", - "@babel/plugin-transform-modules-systemjs": "^7.12.1", - "@babel/plugin-transform-modules-umd": "^7.12.1", - "@babel/plugin-transform-named-capturing-groups-regex": "^7.12.1", - "@babel/plugin-transform-new-target": "^7.12.1", - "@babel/plugin-transform-object-super": "^7.12.1", - "@babel/plugin-transform-parameters": "^7.12.1", - "@babel/plugin-transform-property-literals": "^7.12.1", - "@babel/plugin-transform-regenerator": "^7.12.1", - "@babel/plugin-transform-reserved-words": "^7.12.1", - "@babel/plugin-transform-shorthand-properties": "^7.12.1", - "@babel/plugin-transform-spread": "^7.12.1", - "@babel/plugin-transform-sticky-regex": "^7.12.7", - "@babel/plugin-transform-template-literals": "^7.12.1", - "@babel/plugin-transform-typeof-symbol": "^7.12.10", - "@babel/plugin-transform-unicode-escapes": "^7.12.1", - "@babel/plugin-transform-unicode-regex": "^7.12.1", - "@babel/preset-modules": "^0.1.3", - "@babel/types": "^7.12.11", - "core-js-compat": "^3.8.0", - "semver": "^5.5.0" - }, - "dependencies": { - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "@babel/preset-modules": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/@babel/preset-modules/-/preset-modules-0.1.4.tgz", - "integrity": "sha512-J36NhwnfdzpmH41M1DrnkkgAqhZaqr/NBdPfQ677mLzlaXo+oDiv1deyCDtgAhz8p328otdob0Du7+xgHGZbKg==", - "requires": { - "@babel/helper-plugin-utils": "^7.0.0", - "@babel/plugin-proposal-unicode-property-regex": "^7.4.4", - "@babel/plugin-transform-dotall-regex": "^7.4.4", - "@babel/types": "^7.4.4", - "esutils": "^2.0.2" - } - }, - "@babel/runtime": { - "version": "7.12.5", - "resolved": "https://registry.npmjs.org/@babel/runtime/-/runtime-7.12.5.tgz", - "integrity": "sha512-plcc+hbExy3McchJCEQG3knOsuh3HH+Prx1P6cLIkET/0dLuQDEnrT+s27Axgc9bqfsmNUNHfscgMUdBpC9xfg==", - "requires": { - "regenerator-runtime": "^0.13.4" - }, - "dependencies": { - "regenerator-runtime": { - "version": "0.13.7", - "resolved": "https://registry.npmjs.org/regenerator-runtime/-/regenerator-runtime-0.13.7.tgz", - "integrity": "sha512-a54FxoJDIr27pgf7IgeQGxmqUNYrcV338lf/6gH456HZ/PhX+5BcwHXG9ajESmwe6WRO0tAzRUrRmNONWgkrew==" - } - } - }, - "@babel/template": { - "version": "7.12.7", - "resolved": "https://registry.npmjs.org/@babel/template/-/template-7.12.7.tgz", - "integrity": "sha512-GkDzmHS6GV7ZeXfJZ0tLRBhZcMcY0/Lnb+eEbXDBfCAcZCjrZKe6p3J4we/D24O9Y8enxWAg1cWwof59yLh2ow==", - "requires": { - "@babel/code-frame": "^7.10.4", - "@babel/parser": "^7.12.7", - "@babel/types": "^7.12.7" - } - }, - "@babel/traverse": { - "version": "7.12.12", - "resolved": "https://registry.npmjs.org/@babel/traverse/-/traverse-7.12.12.tgz", - "integrity": "sha512-s88i0X0lPy45RrLM8b9mz8RPH5FqO9G9p7ti59cToE44xFm1Q+Pjh5Gq4SXBbtb88X7Uy7pexeqRIQDDMNkL0w==", - "requires": { - "@babel/code-frame": "^7.12.11", - "@babel/generator": "^7.12.11", - "@babel/helper-function-name": "^7.12.11", - "@babel/helper-split-export-declaration": "^7.12.11", - "@babel/parser": "^7.12.11", - "@babel/types": "^7.12.12", - "debug": "^4.1.0", - "globals": "^11.1.0", - "lodash": "^4.17.19" - }, - "dependencies": { - "debug": { - "version": "4.3.1", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz", - "integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==", - "requires": { - "ms": "2.1.2" - } - }, - "ms": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", - "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==" - } - } - }, - "@babel/types": { - "version": "7.12.12", - "resolved": "https://registry.npmjs.org/@babel/types/-/types-7.12.12.tgz", - "integrity": "sha512-lnIX7piTxOH22xE7fDXDbSHg9MM1/6ORnafpJmov5rs0kX5g4BZxeXNJLXsMRiO0U5Rb8/FvMS6xlTnTHvxonQ==", - "requires": { - "@babel/helper-validator-identifier": "^7.12.11", - "lodash": "^4.17.19", - "to-fast-properties": "^2.0.0" - }, - "dependencies": { - "to-fast-properties": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/to-fast-properties/-/to-fast-properties-2.0.0.tgz", - "integrity": "sha1-3F5pjL0HkmW8c+A3doGk5Og/YW4=" - } - } - }, - "@cosmos-ui/vue": { - "version": "0.35.0", - "resolved": "https://registry.npmjs.org/@cosmos-ui/vue/-/vue-0.35.0.tgz", - "integrity": "sha512-WTCJBWSoiDckgvXWPByKkQ7ZVSf9LSMsizIAHBnsi0Zp3GOaEqPNBpgjGt2JEhpDPr7+YwyIgmqQ0S3D+Hq5iQ==", - "requires": { - "algoliasearch": "^4.1.0", - "axios": "^0.19.2", - "clipboard-copy": "^3.1.0", - "fuse.js": "^3.4.6", - "hotkeys-js": "^3.7.3", - "js-base64": "^2.5.2", - "lodash": "^4.17.15", - "markdown-it": "^10.0.0", - "prismjs": "^1.19.0", - "querystring": "^0.2.0", - "tiny-cookie": "^2.3.1", - "vue": "^2.6.10" - }, - "dependencies": { - "axios": { - "version": "0.19.2", - "resolved": "https://registry.npmjs.org/axios/-/axios-0.19.2.tgz", - "integrity": "sha512-fjgm5MvRHLhx+osE2xoekY70AhARk3a6hkN+3Io1jc00jtquGvxYlKlsFUhmUET0V5te6CcZI7lcv2Ym61mjHA==", - "requires": { - "follow-redirects": "1.5.10" - } - }, - "entities": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/entities/-/entities-2.0.3.tgz", - "integrity": "sha512-MyoZ0jgnLvB2X3Lg5HqpFmn1kybDiIfEQmKzTb5apr51Rb+T3KdmMiqa70T+bhGnyv7bQ6WMj2QMHpGMmlrUYQ==" - }, - "markdown-it": { - "version": "10.0.0", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-10.0.0.tgz", - "integrity": "sha512-YWOP1j7UbDNz+TumYP1kpwnP0aEa711cJjrAQrzd0UXlbJfc5aAq0F/PZHjiioqDC1NKgvIMX+o+9Bk7yuM2dg==", - "requires": { - "argparse": "^1.0.7", - "entities": "~2.0.0", - "linkify-it": "^2.0.0", - "mdurl": "^1.0.1", - "uc.micro": "^1.0.5" - } - } - } - }, - "@mrmlnc/readdir-enhanced": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/@mrmlnc/readdir-enhanced/-/readdir-enhanced-2.2.1.tgz", - "integrity": "sha512-bPHp6Ji8b41szTOcaP63VlnbbO5Ny6dwAATtY6JTjh5N2OLrb5Qk/Th5cRkRQhkWCt+EJsYrNB0MiL+Gpn6e3g==", - "requires": { - "call-me-maybe": "^1.0.1", - "glob-to-regexp": "^0.3.0" - } - }, - "@nodelib/fs.stat": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-1.1.3.tgz", - "integrity": "sha512-shAmDyaQC4H92APFoIaVDHCx5bStIocgvbwQyxPRrbUY20V1EYTbSDchWbuwlMG3V17cprZhA6+78JfB+3DTPw==" - }, - "@sindresorhus/is": { - "version": "0.14.0", - "resolved": "https://registry.npmjs.org/@sindresorhus/is/-/is-0.14.0.tgz", - "integrity": "sha512-9NET910DNaIPngYnLLPeg+Ogzqsi9uM4mSboU5y6p8S5DzMTVEsJZrawi+BoDNUVBa2DhJqQYUFvMDfgU062LQ==" - }, - "@szmarczak/http-timer": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/@szmarczak/http-timer/-/http-timer-1.1.2.tgz", - "integrity": "sha512-XIB2XbzHTN6ieIjfIMV9hlVcfPU26s2vafYWQcZHWXHOxiaRZYEDKEwdl129Zyg50+foYV2jCgtrqSA6qNuNSA==", - "requires": { - "defer-to-connect": "^1.0.1" - } - }, - "@types/babel-types": { - "version": "7.0.9", - "resolved": "https://registry.npmjs.org/@types/babel-types/-/babel-types-7.0.9.tgz", - "integrity": "sha512-qZLoYeXSTgQuK1h7QQS16hqLGdmqtRmN8w/rl3Au/l5x/zkHx+a4VHrHyBsi1I1vtK2oBHxSzKIu0R5p6spdOA==" - }, - "@types/babylon": { - "version": "6.16.5", - "resolved": "https://registry.npmjs.org/@types/babylon/-/babylon-6.16.5.tgz", - "integrity": "sha512-xH2e58elpj1X4ynnKp9qSnWlsRTIs6n3tgLGNfwAGHwePw0mulHQllV34n0T25uYSu1k0hRKkWXF890B1yS47w==", - "requires": { - "@types/babel-types": "*" - } - }, - "@types/glob": { - "version": "7.1.3", - "resolved": "https://registry.npmjs.org/@types/glob/-/glob-7.1.3.tgz", - "integrity": "sha512-SEYeGAIQIQX8NN6LDKprLjbrd5dARM5EXsd8GI/A5l0apYI1fGMWgPHSe4ZKL4eozlAyI+doUE9XbYS4xCkQ1w==", - "requires": { - "@types/minimatch": "*", - "@types/node": "*" - } - }, - "@types/json-schema": { - "version": "7.0.7", - "resolved": "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.7.tgz", - "integrity": "sha512-cxWFQVseBm6O9Gbw1IWb8r6OS4OhSt3hPZLkFApLjM8TEXROBuQGLAH2i2gZpcXdLBIrpXuTDhH7Vbm1iXmNGA==" - }, - "@types/minimatch": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/@types/minimatch/-/minimatch-3.0.3.tgz", - "integrity": "sha512-tHq6qdbT9U1IRSGf14CL0pUlULksvY9OZ+5eEgl1N7t+OA3tGvNpxJCzuKQlsNgCVwbAs670L1vcVQi8j9HjnA==" - }, - "@types/node": { - "version": "14.14.22", - "resolved": "https://registry.npmjs.org/@types/node/-/node-14.14.22.tgz", - "integrity": "sha512-g+f/qj/cNcqKkc3tFqlXOYjrmZA+jNBiDzbP3kH+B+otKFqAdPgVTGP1IeKRdMml/aE69as5S4FqtxAbl+LaMw==" - }, - "@types/q": { - "version": "1.5.4", - "resolved": "https://registry.npmjs.org/@types/q/-/q-1.5.4.tgz", - "integrity": "sha512-1HcDas8SEj4z1Wc696tH56G8OlRaH/sqZOynNNB+HF0WOeXPaxTtbYzJY2oEfiUxjSKjhCKr+MvR7dCHcEelug==" - }, - "@vue/babel-helper-vue-jsx-merge-props": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/@vue/babel-helper-vue-jsx-merge-props/-/babel-helper-vue-jsx-merge-props-1.2.1.tgz", - "integrity": "sha512-QOi5OW45e2R20VygMSNhyQHvpdUwQZqGPc748JLGCYEy+yp8fNFNdbNIGAgZmi9e+2JHPd6i6idRuqivyicIkA==" - }, - "@vue/babel-helper-vue-transform-on": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/@vue/babel-helper-vue-transform-on/-/babel-helper-vue-transform-on-1.0.2.tgz", - "integrity": "sha512-hz4R8tS5jMn8lDq6iD+yWL6XNB699pGIVLk7WSJnn1dbpjaazsjZQkieJoRX6gW5zpYSCFqQ7jUquPNY65tQYA==" - }, - "@vue/babel-plugin-jsx": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/@vue/babel-plugin-jsx/-/babel-plugin-jsx-1.0.2.tgz", - "integrity": "sha512-1uZlQCLCeuqJgDYLCmg3qfsvTVtOQiXh278ES4bvPTYYbv2Bi/rElLETK6AdjI9xxzyTUf5n1QEiH8Xxz0eZrg==", - "requires": { - "@babel/helper-module-imports": "^7.0.0", - "@babel/plugin-syntax-jsx": "^7.0.0", - "@babel/template": "^7.0.0", - "@babel/traverse": "^7.0.0", - "@babel/types": "^7.0.0", - "@vue/babel-helper-vue-transform-on": "^1.0.2", - "camelcase": "^6.0.0", - "html-tags": "^3.1.0", - "svg-tags": "^1.0.0" - }, - "dependencies": { - "camelcase": { - "version": "6.2.0", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-6.2.0.tgz", - "integrity": "sha512-c7wVvbw3f37nuobQNtgsgG9POC9qMbNuMQmTCqZv23b6MIz0fcYpBiOlv9gEN/hdLdnZTDQhg6e9Dq5M1vKvfg==" - } - } - }, - "@vue/babel-plugin-transform-vue-jsx": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/@vue/babel-plugin-transform-vue-jsx/-/babel-plugin-transform-vue-jsx-1.2.1.tgz", - "integrity": "sha512-HJuqwACYehQwh1fNT8f4kyzqlNMpBuUK4rSiSES5D4QsYncv5fxFsLyrxFPG2ksO7t5WP+Vgix6tt6yKClwPzA==", - "requires": { - "@babel/helper-module-imports": "^7.0.0", - "@babel/plugin-syntax-jsx": "^7.2.0", - "@vue/babel-helper-vue-jsx-merge-props": "^1.2.1", - "html-tags": "^2.0.0", - "lodash.kebabcase": "^4.1.1", - "svg-tags": "^1.0.0" - }, - "dependencies": { - "html-tags": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/html-tags/-/html-tags-2.0.0.tgz", - "integrity": "sha1-ELMKOGCF9Dzt41PMj6fLDe7qZos=" - } - } - }, - "@vue/babel-preset-app": { - "version": "4.5.11", - "resolved": "https://registry.npmjs.org/@vue/babel-preset-app/-/babel-preset-app-4.5.11.tgz", - "integrity": "sha512-9VoFlm/9vhynKNGM+HA7qBsoQSUEnuG5i5kcFI9vTLLrh8A0fxrwUyVLLppO6T1sAZ6vrKdQFnEkjL+RkRAwWQ==", - "requires": { - "@babel/core": "^7.11.0", - "@babel/helper-compilation-targets": "^7.9.6", - "@babel/helper-module-imports": "^7.8.3", - "@babel/plugin-proposal-class-properties": "^7.8.3", - "@babel/plugin-proposal-decorators": "^7.8.3", - "@babel/plugin-syntax-dynamic-import": "^7.8.3", - "@babel/plugin-syntax-jsx": "^7.8.3", - "@babel/plugin-transform-runtime": "^7.11.0", - "@babel/preset-env": "^7.11.0", - "@babel/runtime": "^7.11.0", - "@vue/babel-plugin-jsx": "^1.0.0-0", - "@vue/babel-preset-jsx": "^1.1.2", - "babel-plugin-dynamic-import-node": "^2.3.3", - "core-js": "^3.6.5", - "core-js-compat": "^3.6.5", - "semver": "^6.1.0" - }, - "dependencies": { - "core-js": { - "version": "3.8.3", - "resolved": "https://registry.npmjs.org/core-js/-/core-js-3.8.3.tgz", - "integrity": "sha512-KPYXeVZYemC2TkNEkX/01I+7yd+nX3KddKwZ1Ww7SKWdI2wQprSgLmrTddT8nw92AjEklTsPBoSdQBhbI1bQ6Q==" - } - } - }, - "@vue/babel-preset-jsx": { - "version": "1.2.4", - "resolved": "https://registry.npmjs.org/@vue/babel-preset-jsx/-/babel-preset-jsx-1.2.4.tgz", - "integrity": "sha512-oRVnmN2a77bYDJzeGSt92AuHXbkIxbf/XXSE3klINnh9AXBmVS1DGa1f0d+dDYpLfsAKElMnqKTQfKn7obcL4w==", - "requires": { - "@vue/babel-helper-vue-jsx-merge-props": "^1.2.1", - "@vue/babel-plugin-transform-vue-jsx": "^1.2.1", - "@vue/babel-sugar-composition-api-inject-h": "^1.2.1", - "@vue/babel-sugar-composition-api-render-instance": "^1.2.4", - "@vue/babel-sugar-functional-vue": "^1.2.2", - "@vue/babel-sugar-inject-h": "^1.2.2", - "@vue/babel-sugar-v-model": "^1.2.3", - "@vue/babel-sugar-v-on": "^1.2.3" - } - }, - "@vue/babel-sugar-composition-api-inject-h": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/@vue/babel-sugar-composition-api-inject-h/-/babel-sugar-composition-api-inject-h-1.2.1.tgz", - "integrity": "sha512-4B3L5Z2G+7s+9Bwbf+zPIifkFNcKth7fQwekVbnOA3cr3Pq71q71goWr97sk4/yyzH8phfe5ODVzEjX7HU7ItQ==", - "requires": { - "@babel/plugin-syntax-jsx": "^7.2.0" - } - }, - "@vue/babel-sugar-composition-api-render-instance": { - "version": "1.2.4", - "resolved": "https://registry.npmjs.org/@vue/babel-sugar-composition-api-render-instance/-/babel-sugar-composition-api-render-instance-1.2.4.tgz", - "integrity": "sha512-joha4PZznQMsxQYXtR3MnTgCASC9u3zt9KfBxIeuI5g2gscpTsSKRDzWQt4aqNIpx6cv8On7/m6zmmovlNsG7Q==", - "requires": { - "@babel/plugin-syntax-jsx": "^7.2.0" - } - }, - "@vue/babel-sugar-functional-vue": { - "version": "1.2.2", - "resolved": "https://registry.npmjs.org/@vue/babel-sugar-functional-vue/-/babel-sugar-functional-vue-1.2.2.tgz", - "integrity": "sha512-JvbgGn1bjCLByIAU1VOoepHQ1vFsroSA/QkzdiSs657V79q6OwEWLCQtQnEXD/rLTA8rRit4rMOhFpbjRFm82w==", - "requires": { - "@babel/plugin-syntax-jsx": "^7.2.0" - } - }, - "@vue/babel-sugar-inject-h": { - "version": "1.2.2", - "resolved": "https://registry.npmjs.org/@vue/babel-sugar-inject-h/-/babel-sugar-inject-h-1.2.2.tgz", - "integrity": "sha512-y8vTo00oRkzQTgufeotjCLPAvlhnpSkcHFEp60+LJUwygGcd5Chrpn5480AQp/thrxVm8m2ifAk0LyFel9oCnw==", - "requires": { - "@babel/plugin-syntax-jsx": "^7.2.0" - } - }, - "@vue/babel-sugar-v-model": { - "version": "1.2.3", - "resolved": "https://registry.npmjs.org/@vue/babel-sugar-v-model/-/babel-sugar-v-model-1.2.3.tgz", - "integrity": "sha512-A2jxx87mySr/ulAsSSyYE8un6SIH0NWHiLaCWpodPCVOlQVODCaSpiR4+IMsmBr73haG+oeCuSvMOM+ttWUqRQ==", - "requires": { - "@babel/plugin-syntax-jsx": "^7.2.0", - "@vue/babel-helper-vue-jsx-merge-props": "^1.2.1", - "@vue/babel-plugin-transform-vue-jsx": "^1.2.1", - "camelcase": "^5.0.0", - "html-tags": "^2.0.0", - "svg-tags": "^1.0.0" - }, - "dependencies": { - "camelcase": { - "version": "5.3.1", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-5.3.1.tgz", - "integrity": "sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==" - }, - "html-tags": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/html-tags/-/html-tags-2.0.0.tgz", - "integrity": "sha1-ELMKOGCF9Dzt41PMj6fLDe7qZos=" - } - } - }, - "@vue/babel-sugar-v-on": { - "version": "1.2.3", - "resolved": "https://registry.npmjs.org/@vue/babel-sugar-v-on/-/babel-sugar-v-on-1.2.3.tgz", - "integrity": "sha512-kt12VJdz/37D3N3eglBywV8GStKNUhNrsxChXIV+o0MwVXORYuhDTHJRKPgLJRb/EY3vM2aRFQdxJBp9CLikjw==", - "requires": { - "@babel/plugin-syntax-jsx": "^7.2.0", - "@vue/babel-plugin-transform-vue-jsx": "^1.2.1", - "camelcase": "^5.0.0" - }, - "dependencies": { - "camelcase": { - "version": "5.3.1", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-5.3.1.tgz", - "integrity": "sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==" - } - } - }, - "@vue/component-compiler-utils": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/@vue/component-compiler-utils/-/component-compiler-utils-3.2.0.tgz", - "integrity": "sha512-lejBLa7xAMsfiZfNp7Kv51zOzifnb29FwdnMLa96z26kXErPFioSf9BMcePVIQ6/Gc6/mC0UrPpxAWIHyae0vw==", - "requires": { - "consolidate": "^0.15.1", - "hash-sum": "^1.0.2", - "lru-cache": "^4.1.2", - "merge-source-map": "^1.1.0", - "postcss": "^7.0.14", - "postcss-selector-parser": "^6.0.2", - "prettier": "^1.18.2", - "source-map": "~0.6.1", - "vue-template-es2015-compiler": "^1.9.0" - }, - "dependencies": { - "lru-cache": { - "version": "4.1.5", - "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-4.1.5.tgz", - "integrity": "sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==", - "requires": { - "pseudomap": "^1.0.2", - "yallist": "^2.1.2" - } - }, - "yallist": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/yallist/-/yallist-2.1.2.tgz", - "integrity": "sha1-HBH5IY8HYImkfdUS+TxmmaaoHVI=" - } - } - }, - "@vuepress/core": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/core/-/core-1.8.0.tgz", - "integrity": "sha512-DrHx3gXa5rUDdvjcUHhmZg1DccMwc3kiYpgtbKCuJpHksz9eAVuOxbcy/b6TGRbbY4Q5EA2Fs3kI9hvPjYdCrQ==", - "requires": { - "@babel/core": "^7.8.4", - "@vue/babel-preset-app": "^4.1.2", - "@vuepress/markdown": "1.8.0", - "@vuepress/markdown-loader": "1.8.0", - "@vuepress/plugin-last-updated": "1.8.0", - "@vuepress/plugin-register-components": "1.8.0", - "@vuepress/shared-utils": "1.8.0", - "autoprefixer": "^9.5.1", - "babel-loader": "^8.0.4", - "cache-loader": "^3.0.0", - "chokidar": "^2.0.3", - "connect-history-api-fallback": "^1.5.0", - "copy-webpack-plugin": "^5.0.2", - "core-js": "^3.6.4", - "cross-spawn": "^6.0.5", - "css-loader": "^2.1.1", - "file-loader": "^3.0.1", - "js-yaml": "^3.13.1", - "lru-cache": "^5.1.1", - "mini-css-extract-plugin": "0.6.0", - "optimize-css-assets-webpack-plugin": "^5.0.1", - "portfinder": "^1.0.13", - "postcss-loader": "^3.0.0", - "postcss-safe-parser": "^4.0.1", - "toml": "^3.0.0", - "url-loader": "^1.0.1", - "vue": "^2.6.10", - "vue-loader": "^15.7.1", - "vue-router": "^3.4.5", - "vue-server-renderer": "^2.6.10", - "vue-template-compiler": "^2.6.10", - "vuepress-html-webpack-plugin": "^3.2.0", - "vuepress-plugin-container": "^2.0.2", - "webpack": "^4.8.1", - "webpack-chain": "^6.0.0", - "webpack-dev-server": "^3.5.1", - "webpack-merge": "^4.1.2", - "webpackbar": "3.2.0" - }, - "dependencies": { - "core-js": { - "version": "3.8.3", - "resolved": "https://registry.npmjs.org/core-js/-/core-js-3.8.3.tgz", - "integrity": "sha512-KPYXeVZYemC2TkNEkX/01I+7yd+nX3KddKwZ1Ww7SKWdI2wQprSgLmrTddT8nw92AjEklTsPBoSdQBhbI1bQ6Q==" - } - } - }, - "@vuepress/markdown": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/markdown/-/markdown-1.8.0.tgz", - "integrity": "sha512-f2yhoIHTD6gaPeLLidkxuytKGQCT6Gopm0fpyKZwfFZaWWz5+RPPGevq5UTmTb+5vvO2Li44HJc1EV7QONOw9Q==", - "requires": { - "@vuepress/shared-utils": "1.8.0", - "markdown-it": "^8.4.1", - "markdown-it-anchor": "^5.0.2", - "markdown-it-chain": "^1.3.0", - "markdown-it-emoji": "^1.4.0", - "markdown-it-table-of-contents": "^0.4.0", - "prismjs": "^1.13.0" - }, - "dependencies": { - "entities": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/entities/-/entities-1.1.2.tgz", - "integrity": "sha512-f2LZMYl1Fzu7YSBKg+RoROelpOaNrcGmE9AZubeDfrCEia483oW4MI4VyFd5VNHIgQ/7qm1I0wUHK1eJnn2y2w==" - }, - "markdown-it": { - "version": "8.4.2", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-8.4.2.tgz", - "integrity": "sha512-GcRz3AWTqSUphY3vsUqQSFMbgR38a4Lh3GWlHRh/7MRwz8mcu9n2IO7HOh+bXHrR9kOPDl5RNCaEsrneb+xhHQ==", - "requires": { - "argparse": "^1.0.7", - "entities": "~1.1.1", - "linkify-it": "^2.0.0", - "mdurl": "^1.0.1", - "uc.micro": "^1.0.5" - } - } - } - }, - "@vuepress/markdown-loader": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/markdown-loader/-/markdown-loader-1.8.0.tgz", - "integrity": "sha512-ykYTNe4mC/0CxyEfyM9+oYJqFvOMZWw5qiNZVfg2t+Ip8nVR2pFhQ6fJe07Pbtc59eT4awKSEd8/kcjhTpfeZA==", - "requires": { - "@vuepress/markdown": "1.8.0", - "loader-utils": "^1.1.0", - "lru-cache": "^5.1.1" - } - }, - "@vuepress/plugin-active-header-links": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/plugin-active-header-links/-/plugin-active-header-links-1.8.0.tgz", - "integrity": "sha512-0SqdkJLJSQqhPTgGccu/ev5zRCfeKKMkyPnUMJYsQe4zGhSosmwLcfB7LDo/VLqLhRipipzBnONESr12OgI4SQ==", - "requires": { - "lodash.debounce": "^4.0.8" - } - }, - "@vuepress/plugin-google-analytics": { - "version": "1.7.1", - "resolved": "https://registry.npmjs.org/@vuepress/plugin-google-analytics/-/plugin-google-analytics-1.7.1.tgz", - "integrity": "sha512-27fQzRMsqGYpMf+ruyhsdfLv/n6z6b6LutFLE/pH66Itlh6ox9ew31x0pqYBbWIC/a4lBfXYUwFvi+DEvlb1EQ==" - }, - "@vuepress/plugin-last-updated": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/plugin-last-updated/-/plugin-last-updated-1.8.0.tgz", - "integrity": "sha512-fBwtlffAabpTTalUMPSaJy/5fp3WpIA1FdWOfFcQ12X6179tupZB8fnueNsVJGBvGcdw8fbyzh5C9yKAq9lR/w==", - "requires": { - "cross-spawn": "^6.0.5" - } - }, - "@vuepress/plugin-nprogress": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/plugin-nprogress/-/plugin-nprogress-1.8.0.tgz", - "integrity": "sha512-JmjeJKKWhbF/8z+EnY8BCWHoHKhUWfqXjXOfV+xifITl6BJlf53I/jLFpX7Sij8Whe+SKjH7kNvc+hioUdwJQw==", - "requires": { - "nprogress": "^0.2.0" - } - }, - "@vuepress/plugin-register-components": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/plugin-register-components/-/plugin-register-components-1.8.0.tgz", - "integrity": "sha512-ztafaAxn7XFS4F8z51d+QQB6DNAUG54wBSdfKydfnHbAYgtxoALzPlJW7FKQdxvZKxqGrJa9e4rkoZsat13KRQ==", - "requires": { - "@vuepress/shared-utils": "1.8.0" - } - }, - "@vuepress/plugin-search": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/plugin-search/-/plugin-search-1.8.0.tgz", - "integrity": "sha512-LlOCPg7JJ3I9WEpiBU8vCEFp6I5sa3OBu6SFHk+uK9iyKHwJYdRs4VK9x+igG40Rt/OIDRDo3c9SbLX/E/kqeA==" - }, - "@vuepress/shared-utils": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/shared-utils/-/shared-utils-1.8.0.tgz", - "integrity": "sha512-CVNMiYBntQyb4CuyS4KzmglDqsuBpj8V4QMzL9gCSoMv0VmwKx05fZedu+r0G5OcxYN4qjnu99yl9G6zWhOU9w==", - "requires": { - "chalk": "^2.3.2", - "escape-html": "^1.0.3", - "fs-extra": "^7.0.1", - "globby": "^9.2.0", - "gray-matter": "^4.0.1", - "hash-sum": "^1.0.2", - "semver": "^6.0.0", - "toml": "^3.0.0", - "upath": "^1.1.0" - } - }, - "@vuepress/theme-default": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/@vuepress/theme-default/-/theme-default-1.8.0.tgz", - "integrity": "sha512-CueCaANfICFbLnEL78YxSjgCHXL7mkgQI/cfyEHBgxlr247cYJQ+9IFDQIS0fJNuzHdLRy9UFUvVrCu6go8PUg==", - "requires": { - "@vuepress/plugin-active-header-links": "1.8.0", - "@vuepress/plugin-nprogress": "1.8.0", - "@vuepress/plugin-search": "1.8.0", - "docsearch.js": "^2.5.2", - "lodash": "^4.17.15", - "stylus": "^0.54.8", - "stylus-loader": "^3.0.2", - "vuepress-plugin-container": "^2.0.2", - "vuepress-plugin-smooth-scroll": "^0.0.3" - } - }, - "@webassemblyjs/ast": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/ast/-/ast-1.9.0.tgz", - "integrity": "sha512-C6wW5L+b7ogSDVqymbkkvuW9kruN//YisMED04xzeBBqjHa2FYnmvOlS6Xj68xWQRgWvI9cIglsjFowH/RJyEA==", - "requires": { - "@webassemblyjs/helper-module-context": "1.9.0", - "@webassemblyjs/helper-wasm-bytecode": "1.9.0", - "@webassemblyjs/wast-parser": "1.9.0" - } - }, - "@webassemblyjs/floating-point-hex-parser": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/floating-point-hex-parser/-/floating-point-hex-parser-1.9.0.tgz", - "integrity": "sha512-TG5qcFsS8QB4g4MhrxK5TqfdNe7Ey/7YL/xN+36rRjl/BlGE/NcBvJcqsRgCP6Z92mRE+7N50pRIi8SmKUbcQA==" - }, - "@webassemblyjs/helper-api-error": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-api-error/-/helper-api-error-1.9.0.tgz", - "integrity": "sha512-NcMLjoFMXpsASZFxJ5h2HZRcEhDkvnNFOAKneP5RbKRzaWJN36NC4jqQHKwStIhGXu5mUWlUUk7ygdtrO8lbmw==" - }, - "@webassemblyjs/helper-buffer": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-buffer/-/helper-buffer-1.9.0.tgz", - "integrity": "sha512-qZol43oqhq6yBPx7YM3m9Bv7WMV9Eevj6kMi6InKOuZxhw+q9hOkvq5e/PpKSiLfyetpaBnogSbNCfBwyB00CA==" - }, - "@webassemblyjs/helper-code-frame": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-code-frame/-/helper-code-frame-1.9.0.tgz", - "integrity": "sha512-ERCYdJBkD9Vu4vtjUYe8LZruWuNIToYq/ME22igL+2vj2dQ2OOujIZr3MEFvfEaqKoVqpsFKAGsRdBSBjrIvZA==", - "requires": { - "@webassemblyjs/wast-printer": "1.9.0" - } - }, - "@webassemblyjs/helper-fsm": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-fsm/-/helper-fsm-1.9.0.tgz", - "integrity": "sha512-OPRowhGbshCb5PxJ8LocpdX9Kl0uB4XsAjl6jH/dWKlk/mzsANvhwbiULsaiqT5GZGT9qinTICdj6PLuM5gslw==" - }, - "@webassemblyjs/helper-module-context": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-module-context/-/helper-module-context-1.9.0.tgz", - "integrity": "sha512-MJCW8iGC08tMk2enck1aPW+BE5Cw8/7ph/VGZxwyvGbJwjktKkDK7vy7gAmMDx88D7mhDTCNKAW5tED+gZ0W8g==", - "requires": { - "@webassemblyjs/ast": "1.9.0" - } - }, - "@webassemblyjs/helper-wasm-bytecode": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-wasm-bytecode/-/helper-wasm-bytecode-1.9.0.tgz", - "integrity": "sha512-R7FStIzyNcd7xKxCZH5lE0Bqy+hGTwS3LJjuv1ZVxd9O7eHCedSdrId/hMOd20I+v8wDXEn+bjfKDLzTepoaUw==" - }, - "@webassemblyjs/helper-wasm-section": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/helper-wasm-section/-/helper-wasm-section-1.9.0.tgz", - "integrity": "sha512-XnMB8l3ek4tvrKUUku+IVaXNHz2YsJyOOmz+MMkZvh8h1uSJpSen6vYnw3IoQ7WwEuAhL8Efjms1ZWjqh2agvw==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/helper-buffer": "1.9.0", - "@webassemblyjs/helper-wasm-bytecode": "1.9.0", - "@webassemblyjs/wasm-gen": "1.9.0" - } - }, - "@webassemblyjs/ieee754": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/ieee754/-/ieee754-1.9.0.tgz", - "integrity": "sha512-dcX8JuYU/gvymzIHc9DgxTzUUTLexWwt8uCTWP3otys596io0L5aW02Gb1RjYpx2+0Jus1h4ZFqjla7umFniTg==", - "requires": { - "@xtuc/ieee754": "^1.2.0" - } - }, - "@webassemblyjs/leb128": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/leb128/-/leb128-1.9.0.tgz", - "integrity": "sha512-ENVzM5VwV1ojs9jam6vPys97B/S65YQtv/aanqnU7D8aSoHFX8GyhGg0CMfyKNIHBuAVjy3tlzd5QMMINa7wpw==", - "requires": { - "@xtuc/long": "4.2.2" - } - }, - "@webassemblyjs/utf8": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/utf8/-/utf8-1.9.0.tgz", - "integrity": "sha512-GZbQlWtopBTP0u7cHrEx+73yZKrQoBMpwkGEIqlacljhXCkVM1kMQge/Mf+csMJAjEdSwhOyLAS0AoR3AG5P8w==" - }, - "@webassemblyjs/wasm-edit": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-edit/-/wasm-edit-1.9.0.tgz", - "integrity": "sha512-FgHzBm80uwz5M8WKnMTn6j/sVbqilPdQXTWraSjBwFXSYGirpkSWE2R9Qvz9tNiTKQvoKILpCuTjBKzOIm0nxw==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/helper-buffer": "1.9.0", - "@webassemblyjs/helper-wasm-bytecode": "1.9.0", - "@webassemblyjs/helper-wasm-section": "1.9.0", - "@webassemblyjs/wasm-gen": "1.9.0", - "@webassemblyjs/wasm-opt": "1.9.0", - "@webassemblyjs/wasm-parser": "1.9.0", - "@webassemblyjs/wast-printer": "1.9.0" - } - }, - "@webassemblyjs/wasm-gen": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-gen/-/wasm-gen-1.9.0.tgz", - "integrity": "sha512-cPE3o44YzOOHvlsb4+E9qSqjc9Qf9Na1OO/BHFy4OI91XDE14MjFN4lTMezzaIWdPqHnsTodGGNP+iRSYfGkjA==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/helper-wasm-bytecode": "1.9.0", - "@webassemblyjs/ieee754": "1.9.0", - "@webassemblyjs/leb128": "1.9.0", - "@webassemblyjs/utf8": "1.9.0" - } - }, - "@webassemblyjs/wasm-opt": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-opt/-/wasm-opt-1.9.0.tgz", - "integrity": "sha512-Qkjgm6Anhm+OMbIL0iokO7meajkzQD71ioelnfPEj6r4eOFuqm4YC3VBPqXjFyyNwowzbMD+hizmprP/Fwkl2A==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/helper-buffer": "1.9.0", - "@webassemblyjs/wasm-gen": "1.9.0", - "@webassemblyjs/wasm-parser": "1.9.0" - } - }, - "@webassemblyjs/wasm-parser": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/wasm-parser/-/wasm-parser-1.9.0.tgz", - "integrity": "sha512-9+wkMowR2AmdSWQzsPEjFU7njh8HTO5MqO8vjwEHuM+AMHioNqSBONRdr0NQQ3dVQrzp0s8lTcYqzUdb7YgELA==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/helper-api-error": "1.9.0", - "@webassemblyjs/helper-wasm-bytecode": "1.9.0", - "@webassemblyjs/ieee754": "1.9.0", - "@webassemblyjs/leb128": "1.9.0", - "@webassemblyjs/utf8": "1.9.0" - } - }, - "@webassemblyjs/wast-parser": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/wast-parser/-/wast-parser-1.9.0.tgz", - "integrity": "sha512-qsqSAP3QQ3LyZjNC/0jBJ/ToSxfYJ8kYyuiGvtn/8MK89VrNEfwj7BPQzJVHi0jGTRK2dGdJ5PRqhtjzoww+bw==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/floating-point-hex-parser": "1.9.0", - "@webassemblyjs/helper-api-error": "1.9.0", - "@webassemblyjs/helper-code-frame": "1.9.0", - "@webassemblyjs/helper-fsm": "1.9.0", - "@xtuc/long": "4.2.2" - } - }, - "@webassemblyjs/wast-printer": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/@webassemblyjs/wast-printer/-/wast-printer-1.9.0.tgz", - "integrity": "sha512-2J0nE95rHXHyQ24cWjMKJ1tqB/ds8z/cyeOZxJhcb+rW+SQASVjuznUSmdz5GpVJTzU8JkhYut0D3siFDD6wsA==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/wast-parser": "1.9.0", - "@xtuc/long": "4.2.2" - } - }, - "@xtuc/ieee754": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/@xtuc/ieee754/-/ieee754-1.2.0.tgz", - "integrity": "sha512-DX8nKgqcGwsc0eJSqYt5lwP4DH5FlHnmuWWBRy7X0NcaGR0ZtuyeESgMwTYVEtxmsNGY+qit4QYT/MIYTOTPeA==" - }, - "@xtuc/long": { - "version": "4.2.2", - "resolved": "https://registry.npmjs.org/@xtuc/long/-/long-4.2.2.tgz", - "integrity": "sha512-NuHqBY1PB/D8xU6s/thBgOAiAP7HOYDQ32+BFZILJ8ivkUkAHQnWfn6WhL79Owj1qmUnoN/YPhktdIoucipkAQ==" - }, - "abbrev": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz", - "integrity": "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q==" - }, - "accepts": { - "version": "1.3.7", - "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.7.tgz", - "integrity": "sha512-Il80Qs2WjYlJIBNzNkK6KYqlVMTbZLXgHx2oT0pU/fjRHyEp+PEfEPY0R3WCwAGVOtauxh1hOxNgIf5bv7dQpA==", - "requires": { - "mime-types": "~2.1.24", - "negotiator": "0.6.2" - } - }, - "acorn": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/acorn/-/acorn-3.3.0.tgz", - "integrity": "sha1-ReN/s56No/JbruP/U2niu18iAXo=" - }, - "acorn-globals": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/acorn-globals/-/acorn-globals-3.1.0.tgz", - "integrity": "sha1-/YJw9x+7SZawBPqIDuXUZXOnMb8=", - "requires": { - "acorn": "^4.0.4" - }, - "dependencies": { - "acorn": { - "version": "4.0.13", - "resolved": "https://registry.npmjs.org/acorn/-/acorn-4.0.13.tgz", - "integrity": "sha1-EFSVrlNh1pe9GVyCUZLhrX8lN4c=" - } - } - }, - "agentkeepalive": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/agentkeepalive/-/agentkeepalive-2.2.0.tgz", - "integrity": "sha1-xdG9SxKQCPEWPyNvhuX66iAm4u8=" - }, - "ajv": { - "version": "6.12.6", - "resolved": "https://registry.npmjs.org/ajv/-/ajv-6.12.6.tgz", - "integrity": "sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==", - "requires": { - "fast-deep-equal": "^3.1.1", - "fast-json-stable-stringify": "^2.0.0", - "json-schema-traverse": "^0.4.1", - "uri-js": "^4.2.2" - } - }, - "ajv-errors": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/ajv-errors/-/ajv-errors-1.0.1.tgz", - "integrity": "sha512-DCRfO/4nQ+89p/RK43i8Ezd41EqdGIU4ld7nGF8OQ14oc/we5rEntLCUa7+jrn3nn83BosfwZA0wb4pon2o8iQ==" - }, - "ajv-keywords": { - "version": "3.5.2", - "resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-3.5.2.tgz", - "integrity": "sha512-5p6WTN0DdTGVQk6VjcEju19IgaHudalcfabD7yhDGeA6bcQnmL+CpveLJq/3hvfwd1aof6L386Ougkx6RfyMIQ==" - }, - "algoliasearch": { - "version": "4.8.4", - "resolved": "https://registry.npmjs.org/algoliasearch/-/algoliasearch-4.8.4.tgz", - "integrity": "sha512-QbXpFvBKj/QhKWE7xBoqaWOWyw7ni6W6THSuFJHOcADRrInhjFCBYjrv+YsIhv9huCepKXWpfV4UJup9BslVhQ==", - "requires": { - "@algolia/cache-browser-local-storage": "4.8.4", - "@algolia/cache-common": "4.8.4", - "@algolia/cache-in-memory": "4.8.4", - "@algolia/client-account": "4.8.4", - "@algolia/client-analytics": "4.8.4", - "@algolia/client-common": "4.8.4", - "@algolia/client-recommendation": "4.8.4", - "@algolia/client-search": "4.8.4", - "@algolia/logger-common": "4.8.4", - "@algolia/logger-console": "4.8.4", - "@algolia/requester-browser-xhr": "4.8.4", - "@algolia/requester-common": "4.8.4", - "@algolia/requester-node-http": "4.8.4", - "@algolia/transporter": "4.8.4" - } - }, - "align-text": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/align-text/-/align-text-0.1.4.tgz", - "integrity": "sha1-DNkKVhCT810KmSVsIrcGlDP60Rc=", - "requires": { - "kind-of": "^3.0.2", - "longest": "^1.0.1", - "repeat-string": "^1.5.2" - }, - "dependencies": { - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "alphanum-sort": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/alphanum-sort/-/alphanum-sort-1.0.2.tgz", - "integrity": "sha1-l6ERlkmyEa0zaR2fn0hqjsn74KM=" - }, - "ansi-align": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/ansi-align/-/ansi-align-3.0.0.tgz", - "integrity": "sha512-ZpClVKqXN3RGBmKibdfWzqCY4lnjEuoNzU5T0oEFpfd/z5qJHVarukridD4juLO2FXMiwUQxr9WqQtaYa8XRYw==", - "requires": { - "string-width": "^3.0.0" - } - }, - "ansi-colors": { - "version": "3.2.4", - "resolved": "https://registry.npmjs.org/ansi-colors/-/ansi-colors-3.2.4.tgz", - "integrity": "sha512-hHUXGagefjN2iRrID63xckIvotOXOojhQKWIPUZ4mNUZ9nLZW+7FMNoE1lOkEhNWYsx/7ysGIuJYCiMAA9FnrA==" - }, - "ansi-escapes": { - "version": "4.3.1", - "resolved": "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-4.3.1.tgz", - "integrity": "sha512-JWF7ocqNrp8u9oqpgV+wH5ftbt+cfvv+PTjOvKLT3AdYly/LmORARfEVT1iyjwN+4MqE5UmVKoAdIBqeoCHgLA==", - "requires": { - "type-fest": "^0.11.0" - } - }, - "ansi-html": { - "version": "0.0.7", - "resolved": "https://registry.npmjs.org/ansi-html/-/ansi-html-0.0.7.tgz", - "integrity": "sha1-gTWEAhliqenm/QOflA0S9WynhZ4=" - }, - "ansi-regex": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-2.1.1.tgz", - "integrity": "sha1-w7M6te42DYbg5ijwRorn7yfWVN8=" - }, - "ansi-styles": { - "version": "3.2.1", - "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-3.2.1.tgz", - "integrity": "sha512-VT0ZI6kZRdTh8YyJw3SMbYm/u+NqfsAxEpWO0Pf9sq8/e94WxxOpPKx9FR1FlyCtOVDNOQ+8ntlqFxiRc+r5qA==", - "requires": { - "color-convert": "^1.9.0" - } - }, - "anymatch": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-2.0.0.tgz", - "integrity": "sha512-5teOsQWABXHHBFP9y3skS5P3d/WfWXpv3FUpy+LorMrNYaT9pI4oLMQX7jzQ2KklNpGpWHzdCXTDT2Y3XGlZBw==", - "requires": { - "micromatch": "^3.1.4", - "normalize-path": "^2.1.1" - }, - "dependencies": { - "normalize-path": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-2.1.1.tgz", - "integrity": "sha1-GrKLVW4Zg2Oowab35vogE3/mrtk=", - "requires": { - "remove-trailing-separator": "^1.0.1" - } - } - } - }, - "aproba": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/aproba/-/aproba-1.2.0.tgz", - "integrity": "sha512-Y9J6ZjXtoYh8RnXVCMOU/ttDmk1aBjunq9vO0ta5x85WDQiQfUF9sIPBITdbiiIVcBo03Hi3jMxigBtsddlXRw==" - }, - "argparse": { - "version": "1.0.10", - "resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz", - "integrity": "sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==", - "requires": { - "sprintf-js": "~1.0.2" - } - }, - "arr-diff": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/arr-diff/-/arr-diff-4.0.0.tgz", - "integrity": "sha1-1kYQdP6/7HHn4VI1dhoyml3HxSA=" - }, - "arr-flatten": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/arr-flatten/-/arr-flatten-1.1.0.tgz", - "integrity": "sha512-L3hKV5R/p5o81R7O02IGnwpDmkp6E982XhtbuwSe3O4qOtMMMtodicASA1Cny2U+aCXcNpml+m4dPsvsJ3jatg==" - }, - "arr-union": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/arr-union/-/arr-union-3.1.0.tgz", - "integrity": "sha1-45sJrqne+Gao8gbiiK9jkZuuOcQ=" - }, - "array-flatten": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/array-flatten/-/array-flatten-2.1.2.tgz", - "integrity": "sha512-hNfzcOV8W4NdualtqBFPyVO+54DSJuZGY9qT4pRroB6S9e3iiido2ISIC5h9R2sPJ8H3FHCIiEnsv1lPXO3KtQ==" - }, - "array-union": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/array-union/-/array-union-1.0.2.tgz", - "integrity": "sha1-mjRBDk9OPaI96jdb5b5w8kd47Dk=", - "requires": { - "array-uniq": "^1.0.1" - } - }, - "array-uniq": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/array-uniq/-/array-uniq-1.0.3.tgz", - "integrity": "sha1-r2rId6Jcx/dOBYiUdThY39sk/bY=" - }, - "array-unique": { - "version": "0.3.2", - "resolved": "https://registry.npmjs.org/array-unique/-/array-unique-0.3.2.tgz", - "integrity": "sha1-qJS3XUvE9s1nnvMkSp/Y9Gri1Cg=" - }, - "asap": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/asap/-/asap-2.0.6.tgz", - "integrity": "sha1-5QNHYR1+aQlDIIu9r+vLwvuGbUY=" - }, - "asn1": { - "version": "0.2.4", - "resolved": "https://registry.npmjs.org/asn1/-/asn1-0.2.4.tgz", - "integrity": "sha512-jxwzQpLQjSmWXgwaCZE9Nz+glAG01yF1QnWgbhGwHI5A6FRIEY6IVqtHhIepHqI7/kyEyQEagBC5mBEFlIYvdg==", - "requires": { - "safer-buffer": "~2.1.0" - } - }, - "asn1.js": { - "version": "5.4.1", - "resolved": "https://registry.npmjs.org/asn1.js/-/asn1.js-5.4.1.tgz", - "integrity": "sha512-+I//4cYPccV8LdmBLiX8CYvf9Sp3vQsrqu2QNXRcrbiWvcx/UdlFiqUJJzxRQxgsZmvhXhn4cSKeSmoFjVdupA==", - "requires": { - "bn.js": "^4.0.0", - "inherits": "^2.0.1", - "minimalistic-assert": "^1.0.0", - "safer-buffer": "^2.1.0" - }, - "dependencies": { - "bn.js": { - "version": "4.11.9", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-4.11.9.tgz", - "integrity": "sha512-E6QoYqCKZfgatHTdHzs1RRKP7ip4vvm+EyRUeE2RF0NblwVvb0p6jSVeNTOFxPn26QXN2o6SMfNxKp6kU8zQaw==" - } - } - }, - "assert": { - "version": "1.5.0", - "resolved": "https://registry.npmjs.org/assert/-/assert-1.5.0.tgz", - "integrity": "sha512-EDsgawzwoun2CZkCgtxJbv392v4nbk9XDD06zI+kQYoBM/3RBWLlEyJARDOmhAAosBjWACEkKL6S+lIZtcAubA==", - "requires": { - "object-assign": "^4.1.1", - "util": "0.10.3" - }, - "dependencies": { - "inherits": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.1.tgz", - "integrity": "sha1-sX0I0ya0Qj5Wjv9xn5GwscvfafE=" - }, - "util": { - "version": "0.10.3", - "resolved": "https://registry.npmjs.org/util/-/util-0.10.3.tgz", - "integrity": "sha1-evsa/lCAUkZInj23/g7TeTNqwPk=", - "requires": { - "inherits": "2.0.1" - } - } - } - }, - "assert-plus": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/assert-plus/-/assert-plus-1.0.0.tgz", - "integrity": "sha1-8S4PPF13sLHN2RRpQuTpbB5N1SU=" - }, - "assign-symbols": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/assign-symbols/-/assign-symbols-1.0.0.tgz", - "integrity": "sha1-WWZ/QfrdTyDMvCu5a41Pf3jsA2c=" - }, - "async": { - "version": "2.6.3", - "resolved": "https://registry.npmjs.org/async/-/async-2.6.3.tgz", - "integrity": "sha512-zflvls11DCy+dQWzTW2dzuilv8Z5X/pjfmZOWba6TNIVDm+2UDaJmXSOXlasHKfNBs8oo3M0aT50fDEWfKZjXg==", - "requires": { - "lodash": "^4.17.14" - } - }, - "async-each": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/async-each/-/async-each-1.0.3.tgz", - "integrity": "sha512-z/WhQ5FPySLdvREByI2vZiTWwCnF0moMJ1hK9YQwDTHKh6I7/uSckMetoRGb5UBZPC1z0jlw+n/XCgjeH7y1AQ==" - }, - "async-limiter": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/async-limiter/-/async-limiter-1.0.1.tgz", - "integrity": "sha512-csOlWGAcRFJaI6m+F2WKdnMKr4HhdhFVBk0H/QbJFMCr+uO2kwohwXQPxw/9OCxp05r5ghVBFSyioixx3gfkNQ==" - }, - "asynckit": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/asynckit/-/asynckit-0.4.0.tgz", - "integrity": "sha1-x57Zf380y48robyXkLzDZkdLS3k=" - }, - "atob": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/atob/-/atob-2.1.2.tgz", - "integrity": "sha512-Wm6ukoaOGJi/73p/cl2GvLjTI5JM1k/O14isD73YML8StrH/7/lRFgmg8nICZgD3bZZvjwCGxtMOD3wWNAu8cg==" - }, - "autocomplete.js": { - "version": "0.36.0", - "resolved": "https://registry.npmjs.org/autocomplete.js/-/autocomplete.js-0.36.0.tgz", - "integrity": "sha512-jEwUXnVMeCHHutUt10i/8ZiRaCb0Wo+ZyKxeGsYwBDtw6EJHqEeDrq4UwZRD8YBSvp3g6klP678il2eeiVXN2Q==", - "requires": { - "immediate": "^3.2.3" - } - }, - "autoprefixer": { - "version": "9.8.6", - "resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-9.8.6.tgz", - "integrity": "sha512-XrvP4VVHdRBCdX1S3WXVD8+RyG9qeb1D5Sn1DeLiG2xfSpzellk5k54xbUERJ3M5DggQxes39UGOTP8CFrEGbg==", - "requires": { - "browserslist": "^4.12.0", - "caniuse-lite": "^1.0.30001109", - "colorette": "^1.2.1", - "normalize-range": "^0.1.2", - "num2fraction": "^1.2.2", - "postcss": "^7.0.32", - "postcss-value-parser": "^4.1.0" - } - }, - "aws-sign2": { - "version": "0.7.0", - "resolved": "https://registry.npmjs.org/aws-sign2/-/aws-sign2-0.7.0.tgz", - "integrity": "sha1-tG6JCTSpWR8tL2+G1+ap8bP+dqg=" - }, - "aws4": { - "version": "1.11.0", - "resolved": "https://registry.npmjs.org/aws4/-/aws4-1.11.0.tgz", - "integrity": "sha512-xh1Rl34h6Fi1DC2WWKfxUTVqRsNnr6LsKz2+hfwDxQJWmrx8+c7ylaqBMcHfl1U1r2dsifOvKX3LQuLNZ+XSvA==" - }, - "axios": { - "version": "0.21.1", - "resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz", - "integrity": "sha512-dKQiRHxGD9PPRIUNIWvZhPTPpl1rf/OxTYKsqKUDjBwYylTvV7SjSHJb9ratfyzM6wCdLCOYLzs73qpg5c4iGA==", - "requires": { - "follow-redirects": "^1.10.0" - }, - "dependencies": { - "follow-redirects": { - "version": "1.13.1", - "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.13.1.tgz", - "integrity": "sha512-SSG5xmZh1mkPGyKzjZP8zLjltIfpW32Y5QpdNJyjcfGxK3qo3NDDkZOZSFiGn1A6SclQxY9GzEwAHQ3dmYRWpg==" - } - } - }, - "babel-loader": { - "version": "8.2.2", - "resolved": "https://registry.npmjs.org/babel-loader/-/babel-loader-8.2.2.tgz", - "integrity": "sha512-JvTd0/D889PQBtUXJ2PXaKU/pjZDMtHA9V2ecm+eNRmmBCMR09a+fmpGTNwnJtFmFl5Ei7Vy47LjBb+L0wQ99g==", - "requires": { - "find-cache-dir": "^3.3.1", - "loader-utils": "^1.4.0", - "make-dir": "^3.1.0", - "schema-utils": "^2.6.5" - } - }, - "babel-plugin-dynamic-import-node": { - "version": "2.3.3", - "resolved": "https://registry.npmjs.org/babel-plugin-dynamic-import-node/-/babel-plugin-dynamic-import-node-2.3.3.tgz", - "integrity": "sha512-jZVI+s9Zg3IqA/kdi0i6UDCybUI3aSBLnglhYbSSjKlV7yF1F/5LWv8MakQmvYpnbJDS6fcBL2KzHSxNCMtWSQ==", - "requires": { - "object.assign": "^4.1.0" - } - }, - "babel-runtime": { - "version": "6.26.0", - "resolved": "https://registry.npmjs.org/babel-runtime/-/babel-runtime-6.26.0.tgz", - "integrity": "sha1-llxwWGaOgrVde/4E/yM3vItWR/4=", - "requires": { - "core-js": "^2.4.0", - "regenerator-runtime": "^0.11.0" - } - }, - "babel-types": { - "version": "6.26.0", - "resolved": "https://registry.npmjs.org/babel-types/-/babel-types-6.26.0.tgz", - "integrity": "sha1-o7Bz+Uq0nrb6Vc1lInozQ4BjJJc=", - "requires": { - "babel-runtime": "^6.26.0", - "esutils": "^2.0.2", - "lodash": "^4.17.4", - "to-fast-properties": "^1.0.3" - } - }, - "babylon": { - "version": "6.18.0", - "resolved": "https://registry.npmjs.org/babylon/-/babylon-6.18.0.tgz", - "integrity": "sha512-q/UEjfGJ2Cm3oKV71DJz9d25TPnq5rhBVL2Q4fA5wcC3jcrdn7+SssEybFIxwAvvP+YCsCYNKughoF33GxgycQ==" - }, - "balanced-match": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-1.0.0.tgz", - "integrity": "sha1-ibTRmasr7kneFk6gK4nORi1xt2c=" - }, - "base": { - "version": "0.11.2", - "resolved": "https://registry.npmjs.org/base/-/base-0.11.2.tgz", - "integrity": "sha512-5T6P4xPgpp0YDFvSWwEZ4NoE3aM4QBQXDzmVbraCkFj8zHM+mba8SyqB5DbZWyR7mYHo6Y7BdQo3MoA4m0TeQg==", - "requires": { - "cache-base": "^1.0.1", - "class-utils": "^0.3.5", - "component-emitter": "^1.2.1", - "define-property": "^1.0.0", - "isobject": "^3.0.1", - "mixin-deep": "^1.2.0", - "pascalcase": "^0.1.1" - }, - "dependencies": { - "define-property": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-1.0.0.tgz", - "integrity": "sha1-dp66rz9KY6rTr56NMEybvnm/sOY=", - "requires": { - "is-descriptor": "^1.0.0" - } - }, - "is-accessor-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz", - "integrity": "sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-data-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-data-descriptor/-/is-data-descriptor-1.0.0.tgz", - "integrity": "sha512-jbRXy1FmtAoCjQkVmIVYwuuqDFUbaOeDjmed1tOGPrsMhtJA4rD9tkgA0F1qJ3gRFRXcHYVkdeaP50Q5rE/jLQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-descriptor": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-descriptor/-/is-descriptor-1.0.2.tgz", - "integrity": "sha512-2eis5WqQGV7peooDyLmNEPUrps9+SXX5c9pL3xEB+4e9HnGuDa7mB7kHxHw4CbqS9k1T2hOH3miL8n8WtiYVtg==", - "requires": { - "is-accessor-descriptor": "^1.0.0", - "is-data-descriptor": "^1.0.0", - "kind-of": "^6.0.2" - } - } - } - }, - "base64-js": { - "version": "1.5.1", - "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.5.1.tgz", - "integrity": "sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==" - }, - "batch": { - "version": "0.6.1", - "resolved": "https://registry.npmjs.org/batch/-/batch-0.6.1.tgz", - "integrity": "sha1-3DQxT05nkxgJP8dgJyUl+UvyXBY=" - }, - "bcrypt-pbkdf": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/bcrypt-pbkdf/-/bcrypt-pbkdf-1.0.2.tgz", - "integrity": "sha1-pDAdOJtqQ/m2f/PKEaP2Y342Dp4=", - "requires": { - "tweetnacl": "^0.14.3" - } - }, - "big.js": { - "version": "5.2.2", - "resolved": "https://registry.npmjs.org/big.js/-/big.js-5.2.2.tgz", - "integrity": "sha512-vyL2OymJxmarO8gxMr0mhChsO9QGwhynfuu4+MHTAW6czfq9humCB7rKpUjDd9YUiDPU4mzpyupFSvOClAwbmQ==" - }, - "binary-extensions": { - "version": "1.13.1", - "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-1.13.1.tgz", - "integrity": "sha512-Un7MIEDdUC5gNpcGDV97op1Ywk748MpHcFTHoYs6qnj1Z3j7I53VG3nwZhKzoBZmbdRNnb6WRdFlwl7tSDuZGw==" - }, - "bindings": { - "version": "1.5.0", - "resolved": "https://registry.npmjs.org/bindings/-/bindings-1.5.0.tgz", - "integrity": "sha512-p2q/t/mhvuOj/UeLlV6566GD/guowlr0hHxClI0W9m7MWYkL1F0hLo+0Aexs9HSPCtR1SXQ0TD3MMKrXZajbiQ==", - "optional": true, - "requires": { - "file-uri-to-path": "1.0.0" - } - }, - "bluebird": { - "version": "3.7.2", - "resolved": "https://registry.npmjs.org/bluebird/-/bluebird-3.7.2.tgz", - "integrity": "sha512-XpNj6GDQzdfW+r2Wnn7xiSAd7TM3jzkxGXBGTtWKuSXv1xUV+azxAm8jdWZN06QTQk+2N2XB9jRDkvbmQmcRtg==" - }, - "bn.js": { - "version": "5.1.3", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-5.1.3.tgz", - "integrity": "sha512-GkTiFpjFtUzU9CbMeJ5iazkCzGL3jrhzerzZIuqLABjbwRaFt33I9tUdSNryIptM+RxDet6OKm2WnLXzW51KsQ==" - }, - "body-parser": { - "version": "1.19.0", - "resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.19.0.tgz", - "integrity": "sha512-dhEPs72UPbDnAQJ9ZKMNTP6ptJaionhP5cBb541nXPlW60Jepo9RV/a4fX4XWW9CuFNK22krhrj1+rgzifNCsw==", - "requires": { - "bytes": "3.1.0", - "content-type": "~1.0.4", - "debug": "2.6.9", - "depd": "~1.1.2", - "http-errors": "1.7.2", - "iconv-lite": "0.4.24", - "on-finished": "~2.3.0", - "qs": "6.7.0", - "raw-body": "2.4.0", - "type-is": "~1.6.17" - }, - "dependencies": { - "bytes": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.0.tgz", - "integrity": "sha512-zauLjrfCG+xvoyaqLoV8bLVXXNGC4JqlxFCutSDWA6fJrTo2ZuvLYTqZ7aHBLZSMOopbzwv8f+wZcVzfVTI2Dg==" - }, - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - } - } - }, - "bonjour": { - "version": "3.5.0", - "resolved": "https://registry.npmjs.org/bonjour/-/bonjour-3.5.0.tgz", - "integrity": "sha1-jokKGD2O6aI5OzhExpGkK897yfU=", - "requires": { - "array-flatten": "^2.1.0", - "deep-equal": "^1.0.1", - "dns-equal": "^1.0.0", - "dns-txt": "^2.0.2", - "multicast-dns": "^6.0.1", - "multicast-dns-service-types": "^1.1.0" - } - }, - "boolbase": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/boolbase/-/boolbase-1.0.0.tgz", - "integrity": "sha1-aN/1++YMUes3cl6p4+0xDcwed24=" - }, - "boxen": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/boxen/-/boxen-4.2.0.tgz", - "integrity": "sha512-eB4uT9RGzg2odpER62bBwSLvUeGC+WbRjjyyFhGsKnc8wp/m0+hQsMUvUe3H2V0D5vw0nBdO1hCJoZo5mKeuIQ==", - "requires": { - "ansi-align": "^3.0.0", - "camelcase": "^5.3.1", - "chalk": "^3.0.0", - "cli-boxes": "^2.2.0", - "string-width": "^4.1.0", - "term-size": "^2.1.0", - "type-fest": "^0.8.1", - "widest-line": "^3.1.0" - }, - "dependencies": { - "ansi-regex": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.0.tgz", - "integrity": "sha512-bY6fj56OUQ0hU1KjFNDQuJFezqKdrAyFdIevADiqrWHwSlbmBNMHp5ak2f40Pm8JTFyM2mqxkG6ngkHO11f/lg==" - }, - "ansi-styles": { - "version": "4.3.0", - "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz", - "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==", - "requires": { - "color-convert": "^2.0.1" - } - }, - "camelcase": { - "version": "5.3.1", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-5.3.1.tgz", - "integrity": "sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==" - }, - "chalk": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/chalk/-/chalk-3.0.0.tgz", - "integrity": "sha512-4D3B6Wf41KOYRFdszmDqMCGq5VV/uMAB273JILmO+3jAlh8X4qDtdtgCR3fxtbLEMzSx22QdhnDcJvu2u1fVwg==", - "requires": { - "ansi-styles": "^4.1.0", - "supports-color": "^7.1.0" - } - }, - "color-convert": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", - "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", - "requires": { - "color-name": "~1.1.4" - } - }, - "color-name": { - "version": "1.1.4", - "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", - "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==" - }, - "emoji-regex": { - "version": "8.0.0", - "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", - "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==" - }, - "has-flag": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz", - "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==" - }, - "is-fullwidth-code-point": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", - "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==" - }, - "string-width": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.0.tgz", - "integrity": "sha512-zUz5JD+tgqtuDjMhwIg5uFVV3dtqZ9yQJlZVfq4I01/K5Paj5UHj7VyrQOJvzawSVlKpObApbfD0Ed6yJc+1eg==", - "requires": { - "emoji-regex": "^8.0.0", - "is-fullwidth-code-point": "^3.0.0", - "strip-ansi": "^6.0.0" - } - }, - "strip-ansi": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.0.tgz", - "integrity": "sha512-AuvKTrTfQNYNIctbR1K/YGTR1756GycPsg7b9bdV9Duqur4gv6aKqHXah67Z8ImS7WEz5QVcOtlfW2rZEugt6w==", - "requires": { - "ansi-regex": "^5.0.0" - } - }, - "supports-color": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz", - "integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==", - "requires": { - "has-flag": "^4.0.0" - } - }, - "type-fest": { - "version": "0.8.1", - "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.8.1.tgz", - "integrity": "sha512-4dbzIzqvjtgiM5rw1k5rEHtBANKmdudhGyBEajN01fEyhaAIhsoKNy6y7+IN93IfpFtwY9iqi7kD+xwKhQsNJA==" - } - } - }, - "brace-expansion": { - "version": "1.1.11", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.11.tgz", - "integrity": "sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==", - "requires": { - "balanced-match": "^1.0.0", - "concat-map": "0.0.1" - } - }, - "braces": { - "version": "2.3.2", - "resolved": "https://registry.npmjs.org/braces/-/braces-2.3.2.tgz", - "integrity": "sha512-aNdbnj9P8PjdXU4ybaWLK2IF3jc/EoDYbC7AazW6to3TRsfXxscC9UXOB5iDiEQrkyIbWp2SLQda4+QAa7nc3w==", - "requires": { - "arr-flatten": "^1.1.0", - "array-unique": "^0.3.2", - "extend-shallow": "^2.0.1", - "fill-range": "^4.0.0", - "isobject": "^3.0.1", - "repeat-element": "^1.1.2", - "snapdragon": "^0.8.1", - "snapdragon-node": "^2.0.1", - "split-string": "^3.0.2", - "to-regex": "^3.0.1" - } - }, - "brorand": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/brorand/-/brorand-1.1.0.tgz", - "integrity": "sha1-EsJe/kCkXjwyPrhnWgoM5XsiNx8=" - }, - "browserify-aes": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/browserify-aes/-/browserify-aes-1.2.0.tgz", - "integrity": "sha512-+7CHXqGuspUn/Sl5aO7Ea0xWGAtETPXNSAjHo48JfLdPWcMng33Xe4znFvQweqc/uzk5zSOI3H52CYnjCfb5hA==", - "requires": { - "buffer-xor": "^1.0.3", - "cipher-base": "^1.0.0", - "create-hash": "^1.1.0", - "evp_bytestokey": "^1.0.3", - "inherits": "^2.0.1", - "safe-buffer": "^5.0.1" - } - }, - "browserify-cipher": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/browserify-cipher/-/browserify-cipher-1.0.1.tgz", - "integrity": "sha512-sPhkz0ARKbf4rRQt2hTpAHqn47X3llLkUGn+xEJzLjwY8LRs2p0v7ljvI5EyoRO/mexrNunNECisZs+gw2zz1w==", - "requires": { - "browserify-aes": "^1.0.4", - "browserify-des": "^1.0.0", - "evp_bytestokey": "^1.0.0" - } - }, - "browserify-des": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/browserify-des/-/browserify-des-1.0.2.tgz", - "integrity": "sha512-BioO1xf3hFwz4kc6iBhI3ieDFompMhrMlnDFC4/0/vd5MokpuAc3R+LYbwTA9A5Yc9pq9UYPqffKpW2ObuwX5A==", - "requires": { - "cipher-base": "^1.0.1", - "des.js": "^1.0.0", - "inherits": "^2.0.1", - "safe-buffer": "^5.1.2" - } - }, - "browserify-rsa": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/browserify-rsa/-/browserify-rsa-4.1.0.tgz", - "integrity": "sha512-AdEER0Hkspgno2aR97SAf6vi0y0k8NuOpGnVH3O99rcA5Q6sh8QxcngtHuJ6uXwnfAXNM4Gn1Gb7/MV1+Ymbog==", - "requires": { - "bn.js": "^5.0.0", - "randombytes": "^2.0.1" - } - }, - "browserify-sign": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/browserify-sign/-/browserify-sign-4.2.1.tgz", - "integrity": "sha512-/vrA5fguVAKKAVTNJjgSm1tRQDHUU6DbwO9IROu/0WAzC8PKhucDSh18J0RMvVeHAn5puMd+QHC2erPRNf8lmg==", - "requires": { - "bn.js": "^5.1.1", - "browserify-rsa": "^4.0.1", - "create-hash": "^1.2.0", - "create-hmac": "^1.1.7", - "elliptic": "^6.5.3", - "inherits": "^2.0.4", - "parse-asn1": "^5.1.5", - "readable-stream": "^3.6.0", - "safe-buffer": "^5.2.0" - }, - "dependencies": { - "readable-stream": { - "version": "3.6.0", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.0.tgz", - "integrity": "sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==", - "requires": { - "inherits": "^2.0.3", - "string_decoder": "^1.1.1", - "util-deprecate": "^1.0.1" - } - }, - "safe-buffer": { - "version": "5.2.1", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", - "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==" - } - } - }, - "browserify-zlib": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/browserify-zlib/-/browserify-zlib-0.2.0.tgz", - "integrity": "sha512-Z942RysHXmJrhqk88FmKBVq/v5tqmSkDz7p54G/MGyjMnCFFnC79XWNbg+Vta8W6Wb2qtSZTSxIGkJrRpCFEiA==", - "requires": { - "pako": "~1.0.5" - } - }, - "browserslist": { - "version": "4.16.1", - "resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.16.1.tgz", - "integrity": "sha512-UXhDrwqsNcpTYJBTZsbGATDxZbiVDsx6UjpmRUmtnP10pr8wAYr5LgFoEFw9ixriQH2mv/NX2SfGzE/o8GndLA==", - "requires": { - "caniuse-lite": "^1.0.30001173", - "colorette": "^1.2.1", - "electron-to-chromium": "^1.3.634", - "escalade": "^3.1.1", - "node-releases": "^1.1.69" - } - }, - "buffer": { - "version": "4.9.2", - "resolved": "https://registry.npmjs.org/buffer/-/buffer-4.9.2.tgz", - "integrity": "sha512-xq+q3SRMOxGivLhBNaUdC64hDTQwejJ+H0T/NB1XMtTVEwNTrfFF3gAxiyW0Bu/xWEGhjVKgUcMhCrUy2+uCWg==", - "requires": { - "base64-js": "^1.0.2", - "ieee754": "^1.1.4", - "isarray": "^1.0.0" - } - }, - "buffer-from": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/buffer-from/-/buffer-from-1.1.1.tgz", - "integrity": "sha512-MQcXEUbCKtEo7bhqEs6560Hyd4XaovZlO/k9V3hjVUF/zwW7KBVdSK4gIt/bzwS9MbR5qob+F5jusZsb0YQK2A==" - }, - "buffer-indexof": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/buffer-indexof/-/buffer-indexof-1.1.1.tgz", - "integrity": "sha512-4/rOEg86jivtPTeOUUT61jJO1Ya1TrR/OkqCSZDyq84WJh3LuuiphBYJN+fm5xufIk4XAFcEwte/8WzC8If/1g==" - }, - "buffer-json": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/buffer-json/-/buffer-json-2.0.0.tgz", - "integrity": "sha512-+jjPFVqyfF1esi9fvfUs3NqM0pH1ziZ36VP4hmA/y/Ssfo/5w5xHKfTw9BwQjoJ1w/oVtpLomqwUHKdefGyuHw==" - }, - "buffer-xor": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/buffer-xor/-/buffer-xor-1.0.3.tgz", - "integrity": "sha1-JuYe0UIvtw3ULm42cp7VHYVf6Nk=" - }, - "builtin-status-codes": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/builtin-status-codes/-/builtin-status-codes-3.0.0.tgz", - "integrity": "sha1-hZgoeOIbmOHGZCXgPQF0eI9Wnug=" - }, - "bytes": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.0.0.tgz", - "integrity": "sha1-0ygVQE1olpn4Wk6k+odV3ROpYEg=" - }, - "cac": { - "version": "6.7.1", - "resolved": "https://registry.npmjs.org/cac/-/cac-6.7.1.tgz", - "integrity": "sha512-LfGt47+ugCY65W4yUEyxnZKd/tJSBJD/gUAxQGiQjH7yqdhbaX2XN0Rli4+0W0DJiDONmYeh0TlJxMtXGZspIg==" - }, - "cacache": { - "version": "12.0.4", - "resolved": "https://registry.npmjs.org/cacache/-/cacache-12.0.4.tgz", - "integrity": "sha512-a0tMB40oefvuInr4Cwb3GerbL9xTj1D5yg0T5xrjGCGyfvbxseIXX7BAO/u/hIXdafzOI5JC3wDwHyf24buOAQ==", - "requires": { - "bluebird": "^3.5.5", - "chownr": "^1.1.1", - "figgy-pudding": "^3.5.1", - "glob": "^7.1.4", - "graceful-fs": "^4.1.15", - "infer-owner": "^1.0.3", - "lru-cache": "^5.1.1", - "mississippi": "^3.0.0", - "mkdirp": "^0.5.1", - "move-concurrently": "^1.0.1", - "promise-inflight": "^1.0.1", - "rimraf": "^2.6.3", - "ssri": "^6.0.1", - "unique-filename": "^1.1.1", - "y18n": "^4.0.0" - }, - "dependencies": { - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - } - } - }, - "cache-base": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/cache-base/-/cache-base-1.0.1.tgz", - "integrity": "sha512-AKcdTnFSWATd5/GCPRxr2ChwIJ85CeyrEyjRHlKxQ56d4XJMGym0uAiKn0xbLOGOl3+yRpOTi484dVCEc5AUzQ==", - "requires": { - "collection-visit": "^1.0.0", - "component-emitter": "^1.2.1", - "get-value": "^2.0.6", - "has-value": "^1.0.0", - "isobject": "^3.0.1", - "set-value": "^2.0.0", - "to-object-path": "^0.3.0", - "union-value": "^1.0.0", - "unset-value": "^1.0.0" - } - }, - "cache-loader": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/cache-loader/-/cache-loader-3.0.1.tgz", - "integrity": "sha512-HzJIvGiGqYsFUrMjAJNDbVZoG7qQA+vy9AIoKs7s9DscNfki0I589mf2w6/tW+kkFH3zyiknoWV5Jdynu6b/zw==", - "requires": { - "buffer-json": "^2.0.0", - "find-cache-dir": "^2.1.0", - "loader-utils": "^1.2.3", - "mkdirp": "^0.5.1", - "neo-async": "^2.6.1", - "schema-utils": "^1.0.0" - }, - "dependencies": { - "find-cache-dir": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/find-cache-dir/-/find-cache-dir-2.1.0.tgz", - "integrity": "sha512-Tq6PixE0w/VMFfCgbONnkiQIVol/JJL7nRMi20fqzA4NRs9AfeqMGeRdPi3wIhYkxjeBaWh2rxwapn5Tu3IqOQ==", - "requires": { - "commondir": "^1.0.1", - "make-dir": "^2.0.0", - "pkg-dir": "^3.0.0" - } - }, - "find-up": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/find-up/-/find-up-3.0.0.tgz", - "integrity": "sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==", - "requires": { - "locate-path": "^3.0.0" - } - }, - "locate-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-3.0.0.tgz", - "integrity": "sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==", - "requires": { - "p-locate": "^3.0.0", - "path-exists": "^3.0.0" - } - }, - "make-dir": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/make-dir/-/make-dir-2.1.0.tgz", - "integrity": "sha512-LS9X+dc8KLxXCb8dni79fLIIUA5VyZoyjSMCwTluaXA0o27cCK0bhXkpgw+sTXVpPy/lSO57ilRixqk0vDmtRA==", - "requires": { - "pify": "^4.0.1", - "semver": "^5.6.0" - } - }, - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - }, - "p-locate": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-3.0.0.tgz", - "integrity": "sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==", - "requires": { - "p-limit": "^2.0.0" - } - }, - "path-exists": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-3.0.0.tgz", - "integrity": "sha1-zg6+ql94yxiSXqfYENe1mwEP1RU=" - }, - "pkg-dir": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-3.0.0.tgz", - "integrity": "sha512-/E57AYkoeQ25qkxMj5PBOVgF8Kiu/h7cYS30Z5+R7WaiCCBfLq58ZI/dSeaEKb9WVJV5n/03QwrN3IeWIFllvw==", - "requires": { - "find-up": "^3.0.0" - } - }, - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - }, - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "cacheable-request": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/cacheable-request/-/cacheable-request-6.1.0.tgz", - "integrity": "sha512-Oj3cAGPCqOZX7Rz64Uny2GYAZNliQSqfbePrgAQ1wKAihYmCUnraBtJtKcGR4xz7wF+LoJC+ssFZvv5BgF9Igg==", - "requires": { - "clone-response": "^1.0.2", - "get-stream": "^5.1.0", - "http-cache-semantics": "^4.0.0", - "keyv": "^3.0.0", - "lowercase-keys": "^2.0.0", - "normalize-url": "^4.1.0", - "responselike": "^1.0.2" - }, - "dependencies": { - "get-stream": { - "version": "5.2.0", - "resolved": "https://registry.npmjs.org/get-stream/-/get-stream-5.2.0.tgz", - "integrity": "sha512-nBF+F1rAZVCu/p7rjzgA+Yb4lfYXrpl7a6VmJrU8wF9I1CKvP/QwPNZHnOlwbTkY6dvtFIzFMSyQXbLoTQPRpA==", - "requires": { - "pump": "^3.0.0" - } - }, - "lowercase-keys": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/lowercase-keys/-/lowercase-keys-2.0.0.tgz", - "integrity": "sha512-tqNXrS78oMOE73NMxK4EMLQsQowWf8jKooH9g7xPavRT706R6bkQJ6DY2Te7QukaZsulxa30wQ7bk0pm4XiHmA==" - }, - "normalize-url": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/normalize-url/-/normalize-url-4.5.0.tgz", - "integrity": "sha512-2s47yzUxdexf1OhyRi4Em83iQk0aPvwTddtFz4hnSSw9dCEsLEGf6SwIO8ss/19S9iBb5sJaOuTvTGDeZI00BQ==" - } - } - }, - "call-bind": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/call-bind/-/call-bind-1.0.2.tgz", - "integrity": "sha512-7O+FbCihrB5WGbFYesctwmTKae6rOiIzmz1icreWJ+0aA7LJfuqhEso2T9ncpcFtzMQtzXf2QGGueWJGTYsqrA==", - "requires": { - "function-bind": "^1.1.1", - "get-intrinsic": "^1.0.2" - } - }, - "call-me-maybe": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/call-me-maybe/-/call-me-maybe-1.0.1.tgz", - "integrity": "sha1-JtII6onje1y95gJQoV8DHBak1ms=" - }, - "caller-callsite": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/caller-callsite/-/caller-callsite-2.0.0.tgz", - "integrity": "sha1-hH4PzgoiN1CpoCfFSzNzGtMVQTQ=", - "requires": { - "callsites": "^2.0.0" - } - }, - "caller-path": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/caller-path/-/caller-path-2.0.0.tgz", - "integrity": "sha1-Ro+DBE42mrIBD6xfBs7uFbsssfQ=", - "requires": { - "caller-callsite": "^2.0.0" - } - }, - "callsites": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/callsites/-/callsites-2.0.0.tgz", - "integrity": "sha1-BuuE8A7qQT2oav/vrL/7Ngk7PFA=" - }, - "camel-case": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/camel-case/-/camel-case-3.0.0.tgz", - "integrity": "sha1-yjw2iKTpzzpM2nd9xNy8cTJJz3M=", - "requires": { - "no-case": "^2.2.0", - "upper-case": "^1.1.1" - } - }, - "camelcase": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-1.2.1.tgz", - "integrity": "sha1-m7UwTS4LVmmLLHWLCKPqqdqlijk=" - }, - "caniuse-api": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/caniuse-api/-/caniuse-api-3.0.0.tgz", - "integrity": "sha512-bsTwuIg/BZZK/vreVTYYbSWoe2F+71P7K5QGEX+pT250DZbfU1MQ5prOKpPR+LL6uWKK3KMwMCAS74QB3Um1uw==", - "requires": { - "browserslist": "^4.0.0", - "caniuse-lite": "^1.0.0", - "lodash.memoize": "^4.1.2", - "lodash.uniq": "^4.5.0" - } - }, - "caniuse-lite": { - "version": "1.0.30001179", - "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001179.tgz", - "integrity": "sha512-blMmO0QQujuUWZKyVrD1msR4WNDAqb/UPO1Sw2WWsQ7deoM5bJiicKnWJ1Y0NS/aGINSnKPIWBMw5luX+NDUCA==" - }, - "caseless": { - "version": "0.12.0", - "resolved": "https://registry.npmjs.org/caseless/-/caseless-0.12.0.tgz", - "integrity": "sha1-G2gcIf+EAzyCZUMJBolCDRhxUdw=" - }, - "center-align": { - "version": "0.1.3", - "resolved": "https://registry.npmjs.org/center-align/-/center-align-0.1.3.tgz", - "integrity": "sha1-qg0yYptu6XIgBBHL1EYckHvCt60=", - "requires": { - "align-text": "^0.1.3", - "lazy-cache": "^1.0.3" - } - }, - "chalk": { - "version": "2.4.2", - "resolved": "https://registry.npmjs.org/chalk/-/chalk-2.4.2.tgz", - "integrity": "sha512-Mti+f9lpJNcwF4tWV8/OrTTtF1gZi+f8FqlyAdouralcFWFQWF2+NgCHShjkCb+IFBLq9buZwE1xckQU4peSuQ==", - "requires": { - "ansi-styles": "^3.2.1", - "escape-string-regexp": "^1.0.5", - "supports-color": "^5.3.0" - } - }, - "character-parser": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/character-parser/-/character-parser-2.2.0.tgz", - "integrity": "sha1-x84o821LzZdE5f/CxfzeHHMmH8A=", - "requires": { - "is-regex": "^1.0.3" - } - }, - "cheerio": { - "version": "1.0.0-rc.5", - "resolved": "https://registry.npmjs.org/cheerio/-/cheerio-1.0.0-rc.5.tgz", - "integrity": "sha512-yoqps/VCaZgN4pfXtenwHROTp8NG6/Hlt4Jpz2FEP0ZJQ+ZUkVDd0hAPDNKhj3nakpfPt/CNs57yEtxD1bXQiw==", - "requires": { - "cheerio-select-tmp": "^0.1.0", - "dom-serializer": "~1.2.0", - "domhandler": "^4.0.0", - "entities": "~2.1.0", - "htmlparser2": "^6.0.0", - "parse5": "^6.0.0", - "parse5-htmlparser2-tree-adapter": "^6.0.0" - } - }, - "cheerio-select-tmp": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/cheerio-select-tmp/-/cheerio-select-tmp-0.1.1.tgz", - "integrity": "sha512-YYs5JvbpU19VYJyj+F7oYrIE2BOll1/hRU7rEy/5+v9BzkSo3bK81iAeeQEMI92vRIxz677m72UmJUiVwwgjfQ==", - "requires": { - "css-select": "^3.1.2", - "css-what": "^4.0.0", - "domelementtype": "^2.1.0", - "domhandler": "^4.0.0", - "domutils": "^2.4.4" - } - }, - "chokidar": { - "version": "2.1.8", - "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-2.1.8.tgz", - "integrity": "sha512-ZmZUazfOzf0Nve7duiCKD23PFSCs4JPoYyccjUFF3aQkQadqBhfzhjkwBH2mNOG9cTBwhamM37EIsIkZw3nRgg==", - "requires": { - "anymatch": "^2.0.0", - "async-each": "^1.0.1", - "braces": "^2.3.2", - "fsevents": "^1.2.7", - "glob-parent": "^3.1.0", - "inherits": "^2.0.3", - "is-binary-path": "^1.0.0", - "is-glob": "^4.0.0", - "normalize-path": "^3.0.0", - "path-is-absolute": "^1.0.0", - "readdirp": "^2.2.1", - "upath": "^1.1.1" - } - }, - "chownr": { - "version": "1.1.4", - "resolved": "https://registry.npmjs.org/chownr/-/chownr-1.1.4.tgz", - "integrity": "sha512-jJ0bqzaylmJtVnNgzTeSOs8DPavpbYgEr/b0YL8/2GO3xJEhInFmhKMUnEJQjZumK7KXGFhUy89PrsJWlakBVg==" - }, - "chrome-trace-event": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/chrome-trace-event/-/chrome-trace-event-1.0.2.tgz", - "integrity": "sha512-9e/zx1jw7B4CO+c/RXoCsfg/x1AfUBioy4owYH0bJprEYAx5hRFLRhWBqHAG57D0ZM4H7vxbP7bPe0VwhQRYDQ==", - "requires": { - "tslib": "^1.9.0" - } - }, - "ci-info": { - "version": "1.6.0", - "resolved": "https://registry.npmjs.org/ci-info/-/ci-info-1.6.0.tgz", - "integrity": "sha512-vsGdkwSCDpWmP80ncATX7iea5DWQemg1UgCW5J8tqjU3lYw4FBYuj89J0CTVomA7BEfvSZd84GmHko+MxFQU2A==" - }, - "cipher-base": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/cipher-base/-/cipher-base-1.0.4.tgz", - "integrity": "sha512-Kkht5ye6ZGmwv40uUDZztayT2ThLQGfnj/T71N/XzeZeo3nf8foyW7zGTsPYkEya3m5f3cAypH+qe7YOrM1U2Q==", - "requires": { - "inherits": "^2.0.1", - "safe-buffer": "^5.0.1" - } - }, - "class-utils": { - "version": "0.3.6", - "resolved": "https://registry.npmjs.org/class-utils/-/class-utils-0.3.6.tgz", - "integrity": "sha512-qOhPa/Fj7s6TY8H8esGu5QNpMMQxz79h+urzrNYN6mn+9BnxlDGf5QZ+XeCDsxSjPqsSR56XOZOJmpeurnLMeg==", - "requires": { - "arr-union": "^3.1.0", - "define-property": "^0.2.5", - "isobject": "^3.0.0", - "static-extend": "^0.1.1" - }, - "dependencies": { - "define-property": { - "version": "0.2.5", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-0.2.5.tgz", - "integrity": "sha1-w1se+RjsPJkPmlvFe+BKrOxcgRY=", - "requires": { - "is-descriptor": "^0.1.0" - } - } - } - }, - "clean-css": { - "version": "4.2.3", - "resolved": "https://registry.npmjs.org/clean-css/-/clean-css-4.2.3.tgz", - "integrity": "sha512-VcMWDN54ZN/DS+g58HYL5/n4Zrqe8vHJpGA8KdgUXFU4fuP/aHNw8eld9SyEIyabIMJX/0RaY/fplOo5hYLSFA==", - "requires": { - "source-map": "~0.6.0" - } - }, - "cli-boxes": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/cli-boxes/-/cli-boxes-2.2.1.tgz", - "integrity": "sha512-y4coMcylgSCdVinjiDBuR8PCC2bLjyGTwEmPb9NHR/QaNU6EUOXcTY/s6VjGMD6ENSEaeQYHCY0GNGS5jfMwPw==" - }, - "clipboard": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/clipboard/-/clipboard-2.0.6.tgz", - "integrity": "sha512-g5zbiixBRk/wyKakSwCKd7vQXDjFnAMGHoEyBogG/bw9kTD9GvdAvaoRR1ALcEzt3pVKxZR0pViekPMIS0QyGg==", - "optional": true, - "requires": { - "good-listener": "^1.2.2", - "select": "^1.1.2", - "tiny-emitter": "^2.0.0" - } - }, - "clipboard-copy": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/clipboard-copy/-/clipboard-copy-3.2.0.tgz", - "integrity": "sha512-vooFaGFL6ulEP1liiaWFBmmfuPm3cY3y7T9eB83ZTnYc/oFeAKsq3NcDrOkBC8XaauEE8zHQwI7k0+JSYiVQSQ==" - }, - "cliui": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/cliui/-/cliui-2.1.0.tgz", - "integrity": "sha1-S0dXYP+AJkx2LDoXGQMukcf+oNE=", - "requires": { - "center-align": "^0.1.1", - "right-align": "^0.1.1", - "wordwrap": "0.0.2" - } - }, - "clone-response": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/clone-response/-/clone-response-1.0.2.tgz", - "integrity": "sha1-0dyXOSAxTfZ/vrlCI7TuNQI56Ws=", - "requires": { - "mimic-response": "^1.0.0" - } - }, - "coa": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/coa/-/coa-2.0.2.tgz", - "integrity": "sha512-q5/jG+YQnSy4nRTV4F7lPepBJZ8qBNJJDBuJdoejDyLXgmL7IEo+Le2JDZudFTFt7mrCqIRaSjws4ygRCTCAXA==", - "requires": { - "@types/q": "^1.5.1", - "chalk": "^2.4.1", - "q": "^1.1.2" - } - }, - "collection-visit": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/collection-visit/-/collection-visit-1.0.0.tgz", - "integrity": "sha1-S8A3PBZLwykbTTaMgpzxqApZ3KA=", - "requires": { - "map-visit": "^1.0.0", - "object-visit": "^1.0.0" - } - }, - "color": { - "version": "3.1.3", - "resolved": "https://registry.npmjs.org/color/-/color-3.1.3.tgz", - "integrity": "sha512-xgXAcTHa2HeFCGLE9Xs/R82hujGtu9Jd9x4NW3T34+OMs7VoPsjwzRczKHvTAHeJwWFwX5j15+MgAppE8ztObQ==", - "requires": { - "color-convert": "^1.9.1", - "color-string": "^1.5.4" - } - }, - "color-convert": { - "version": "1.9.3", - "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-1.9.3.tgz", - "integrity": "sha512-QfAUtd+vFdAtFQcC8CCyYt1fYWxSqAiK2cSD6zDB8N3cpsEBAvRxp9zOGg6G/SHHJYAT88/az/IuDGALsNVbGg==", - "requires": { - "color-name": "1.1.3" - } - }, - "color-name": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.3.tgz", - "integrity": "sha1-p9BVi9icQveV3UIyj3QIMcpTvCU=" - }, - "color-string": { - "version": "1.5.4", - "resolved": "https://registry.npmjs.org/color-string/-/color-string-1.5.4.tgz", - "integrity": "sha512-57yF5yt8Xa3czSEW1jfQDE79Idk0+AkN/4KWad6tbdxUmAs3MvjxlWSWD4deYytcRfoZ9nhKyFl1kj5tBvidbw==", - "requires": { - "color-name": "^1.0.0", - "simple-swizzle": "^0.2.2" - } - }, - "colorette": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/colorette/-/colorette-1.2.1.tgz", - "integrity": "sha512-puCDz0CzydiSYOrnXpz/PKd69zRrribezjtE9yd4zvytoRc8+RY/KJPvtPFKZS3E3wP6neGyMe0vOTlHO5L3Pw==" - }, - "combined-stream": { - "version": "1.0.8", - "resolved": "https://registry.npmjs.org/combined-stream/-/combined-stream-1.0.8.tgz", - "integrity": "sha512-FQN4MRfuJeHf7cBbBMJFXhKSDq+2kAArBlmRBvcvFE5BB1HZKXtSFASDhdlz9zOYwxh8lDdnvmMOe/+5cdoEdg==", - "requires": { - "delayed-stream": "~1.0.0" - } - }, - "commander": { - "version": "2.17.1", - "resolved": "https://registry.npmjs.org/commander/-/commander-2.17.1.tgz", - "integrity": "sha512-wPMUt6FnH2yzG95SA6mzjQOEKUU3aLaDEmzs1ti+1E9h+CsrZghRlqEM/EJ4KscsQVG8uNN4uVreUeT8+drlgg==" - }, - "commondir": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/commondir/-/commondir-1.0.1.tgz", - "integrity": "sha1-3dgA2gxmEnOTzKWVDqloo6rxJTs=" - }, - "component-emitter": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/component-emitter/-/component-emitter-1.3.0.tgz", - "integrity": "sha512-Rd3se6QB+sO1TwqZjscQrurpEPIfO0/yYnSin6Q/rD3mOutHvUrCAhJub3r90uNb+SESBuE0QYoB90YdfatsRg==" - }, - "compressible": { - "version": "2.0.18", - "resolved": "https://registry.npmjs.org/compressible/-/compressible-2.0.18.tgz", - "integrity": "sha512-AF3r7P5dWxL8MxyITRMlORQNaOA2IkAFaTr4k7BUumjPtRpGDTZpl0Pb1XCO6JeDCBdp126Cgs9sMxqSjgYyRg==", - "requires": { - "mime-db": ">= 1.43.0 < 2" - } - }, - "compression": { - "version": "1.7.4", - "resolved": "https://registry.npmjs.org/compression/-/compression-1.7.4.tgz", - "integrity": "sha512-jaSIDzP9pZVS4ZfQ+TzvtiWhdpFhE2RDHz8QJkpX9SIpLq88VueF5jJw6t+6CUQcAoA6t+x89MLrWAqpfDE8iQ==", - "requires": { - "accepts": "~1.3.5", - "bytes": "3.0.0", - "compressible": "~2.0.16", - "debug": "2.6.9", - "on-headers": "~1.0.2", - "safe-buffer": "5.1.2", - "vary": "~1.1.2" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - } - } - }, - "concat-map": { - "version": "0.0.1", - "resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz", - "integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=" - }, - "concat-stream": { - "version": "1.6.2", - "resolved": "https://registry.npmjs.org/concat-stream/-/concat-stream-1.6.2.tgz", - "integrity": "sha512-27HBghJxjiZtIk3Ycvn/4kbJk/1uZuJFfuPEns6LaEvpvG1f0hTea8lilrouyo9mVc2GWdcEZ8OLoGmSADlrCw==", - "requires": { - "buffer-from": "^1.0.0", - "inherits": "^2.0.3", - "readable-stream": "^2.2.2", - "typedarray": "^0.0.6" - } - }, - "configstore": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/configstore/-/configstore-5.0.1.tgz", - "integrity": "sha512-aMKprgk5YhBNyH25hj8wGt2+D52Sw1DRRIzqBwLp2Ya9mFmY8KPvvtvmna8SxVR9JMZ4kzMD68N22vlaRpkeFA==", - "requires": { - "dot-prop": "^5.2.0", - "graceful-fs": "^4.1.2", - "make-dir": "^3.0.0", - "unique-string": "^2.0.0", - "write-file-atomic": "^3.0.0", - "xdg-basedir": "^4.0.0" - } - }, - "connect-history-api-fallback": { - "version": "1.6.0", - "resolved": "https://registry.npmjs.org/connect-history-api-fallback/-/connect-history-api-fallback-1.6.0.tgz", - "integrity": "sha512-e54B99q/OUoH64zYYRf3HBP5z24G38h5D3qXu23JGRoigpX5Ss4r9ZnDk3g0Z8uQC2x2lPaJ+UlWBc1ZWBWdLg==" - }, - "consola": { - "version": "2.15.0", - "resolved": "https://registry.npmjs.org/consola/-/consola-2.15.0.tgz", - "integrity": "sha512-vlcSGgdYS26mPf7qNi+dCisbhiyDnrN1zaRbw3CSuc2wGOMEGGPsp46PdRG5gqXwgtJfjxDkxRNAgRPr1B77vQ==" - }, - "console-browserify": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/console-browserify/-/console-browserify-1.2.0.tgz", - "integrity": "sha512-ZMkYO/LkF17QvCPqM0gxw8yUzigAOZOSWSHg91FH6orS7vcEj5dVZTidN2fQ14yBSdg97RqhSNwLUXInd52OTA==" - }, - "consolidate": { - "version": "0.15.1", - "resolved": "https://registry.npmjs.org/consolidate/-/consolidate-0.15.1.tgz", - "integrity": "sha512-DW46nrsMJgy9kqAbPt5rKaCr7uFtpo4mSUvLHIUbJEjm0vo+aY5QLwBUq3FK4tRnJr/X0Psc0C4jf/h+HtXSMw==", - "requires": { - "bluebird": "^3.1.1" - } - }, - "constantinople": { - "version": "3.1.2", - "resolved": "https://registry.npmjs.org/constantinople/-/constantinople-3.1.2.tgz", - "integrity": "sha512-yePcBqEFhLOqSBtwYOGGS1exHo/s1xjekXiinh4itpNQGCu4KA1euPh1fg07N2wMITZXQkBz75Ntdt1ctGZouw==", - "requires": { - "@types/babel-types": "^7.0.0", - "@types/babylon": "^6.16.2", - "babel-types": "^6.26.0", - "babylon": "^6.18.0" - } - }, - "constants-browserify": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/constants-browserify/-/constants-browserify-1.0.0.tgz", - "integrity": "sha1-wguW2MYXdIqvHBYCF2DNJ/y4y3U=" - }, - "content-disposition": { - "version": "0.5.3", - "resolved": "https://registry.npmjs.org/content-disposition/-/content-disposition-0.5.3.tgz", - "integrity": "sha512-ExO0774ikEObIAEV9kDo50o+79VCUdEB6n6lzKgGwupcVeRlhrj3qGAfwq8G6uBJjkqLrhT0qEYFcWng8z1z0g==", - "requires": { - "safe-buffer": "5.1.2" - } - }, - "content-type": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/content-type/-/content-type-1.0.4.tgz", - "integrity": "sha512-hIP3EEPs8tB9AT1L+NUqtwOAps4mk2Zob89MWXMHjHWg9milF/j4osnnQLXBCBFBk/tvIG/tUc9mOUJiPBhPXA==" - }, - "convert-source-map": { - "version": "1.7.0", - "resolved": "https://registry.npmjs.org/convert-source-map/-/convert-source-map-1.7.0.tgz", - "integrity": "sha512-4FJkXzKXEDB1snCFZlLP4gpC3JILicCpGbzG9f9G7tGqGCzETQ2hWPrcinA9oU4wtf2biUaEH5065UnMeR33oA==", - "requires": { - "safe-buffer": "~5.1.1" - } - }, - "cookie": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/cookie/-/cookie-0.4.0.tgz", - "integrity": "sha512-+Hp8fLp57wnUSt0tY0tHEXh4voZRDnoIrZPqlo3DPiI4y9lwg/jqx+1Om94/W6ZaPDOUbnjOt/99w66zk+l1Xg==" - }, - "cookie-signature": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.6.tgz", - "integrity": "sha1-4wOogrNCzD7oylE6eZmXNNqzriw=" - }, - "copy-concurrently": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/copy-concurrently/-/copy-concurrently-1.0.5.tgz", - "integrity": "sha512-f2domd9fsVDFtaFcbaRZuYXwtdmnzqbADSwhSWYxYB/Q8zsdUUFMXVRwXGDMWmbEzAn1kdRrtI1T/KTFOL4X2A==", - "requires": { - "aproba": "^1.1.1", - "fs-write-stream-atomic": "^1.0.8", - "iferr": "^0.1.5", - "mkdirp": "^0.5.1", - "rimraf": "^2.5.4", - "run-queue": "^1.0.0" - }, - "dependencies": { - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - } - } - }, - "copy-descriptor": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/copy-descriptor/-/copy-descriptor-0.1.1.tgz", - "integrity": "sha1-Z29us8OZl8LuGsOpJP1hJHSPV40=" - }, - "copy-webpack-plugin": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/copy-webpack-plugin/-/copy-webpack-plugin-5.1.2.tgz", - "integrity": "sha512-Uh7crJAco3AjBvgAy9Z75CjK8IG+gxaErro71THQ+vv/bl4HaQcpkexAY8KVW/T6D2W2IRr+couF/knIRkZMIQ==", - "requires": { - "cacache": "^12.0.3", - "find-cache-dir": "^2.1.0", - "glob-parent": "^3.1.0", - "globby": "^7.1.1", - "is-glob": "^4.0.1", - "loader-utils": "^1.2.3", - "minimatch": "^3.0.4", - "normalize-path": "^3.0.0", - "p-limit": "^2.2.1", - "schema-utils": "^1.0.0", - "serialize-javascript": "^4.0.0", - "webpack-log": "^2.0.0" - }, - "dependencies": { - "find-cache-dir": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/find-cache-dir/-/find-cache-dir-2.1.0.tgz", - "integrity": "sha512-Tq6PixE0w/VMFfCgbONnkiQIVol/JJL7nRMi20fqzA4NRs9AfeqMGeRdPi3wIhYkxjeBaWh2rxwapn5Tu3IqOQ==", - "requires": { - "commondir": "^1.0.1", - "make-dir": "^2.0.0", - "pkg-dir": "^3.0.0" - } - }, - "find-up": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/find-up/-/find-up-3.0.0.tgz", - "integrity": "sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==", - "requires": { - "locate-path": "^3.0.0" - } - }, - "globby": { - "version": "7.1.1", - "resolved": "https://registry.npmjs.org/globby/-/globby-7.1.1.tgz", - "integrity": "sha1-+yzP+UAfhgCUXfral0QMypcrhoA=", - "requires": { - "array-union": "^1.0.1", - "dir-glob": "^2.0.0", - "glob": "^7.1.2", - "ignore": "^3.3.5", - "pify": "^3.0.0", - "slash": "^1.0.0" - }, - "dependencies": { - "pify": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pify/-/pify-3.0.0.tgz", - "integrity": "sha1-5aSs0sEB/fPZpNB/DbxNtJ3SgXY=" - } - } - }, - "ignore": { - "version": "3.3.10", - "resolved": "https://registry.npmjs.org/ignore/-/ignore-3.3.10.tgz", - "integrity": "sha512-Pgs951kaMm5GXP7MOvxERINe3gsaVjUWFm+UZPSq9xYriQAksyhg0csnS0KXSNRD5NmNdapXEpjxG49+AKh/ug==" - }, - "locate-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-3.0.0.tgz", - "integrity": "sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==", - "requires": { - "p-locate": "^3.0.0", - "path-exists": "^3.0.0" - } - }, - "make-dir": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/make-dir/-/make-dir-2.1.0.tgz", - "integrity": "sha512-LS9X+dc8KLxXCb8dni79fLIIUA5VyZoyjSMCwTluaXA0o27cCK0bhXkpgw+sTXVpPy/lSO57ilRixqk0vDmtRA==", - "requires": { - "pify": "^4.0.1", - "semver": "^5.6.0" - } - }, - "p-locate": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-3.0.0.tgz", - "integrity": "sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==", - "requires": { - "p-limit": "^2.0.0" - } - }, - "path-exists": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-3.0.0.tgz", - "integrity": "sha1-zg6+ql94yxiSXqfYENe1mwEP1RU=" - }, - "pkg-dir": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-3.0.0.tgz", - "integrity": "sha512-/E57AYkoeQ25qkxMj5PBOVgF8Kiu/h7cYS30Z5+R7WaiCCBfLq58ZI/dSeaEKb9WVJV5n/03QwrN3IeWIFllvw==", - "requires": { - "find-up": "^3.0.0" - } - }, - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - }, - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - }, - "slash": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/slash/-/slash-1.0.0.tgz", - "integrity": "sha1-xB8vbDn8FtHNF61LXYlhFK5HDVU=" - } - } - }, - "core-js": { - "version": "2.6.12", - "resolved": "https://registry.npmjs.org/core-js/-/core-js-2.6.12.tgz", - "integrity": "sha512-Kb2wC0fvsWfQrgk8HU5lW6U/Lcs8+9aaYcy4ZFc6DDlo4nZ7n70dEgE5rtR0oG6ufKDUnrwfWL1mXR5ljDatrQ==" - }, - "core-js-compat": { - "version": "3.8.3", - "resolved": "https://registry.npmjs.org/core-js-compat/-/core-js-compat-3.8.3.tgz", - "integrity": "sha512-1sCb0wBXnBIL16pfFG1Gkvei6UzvKyTNYpiC41yrdjEv0UoJoq9E/abTMzyYJ6JpTkAj15dLjbqifIzEBDVvog==", - "requires": { - "browserslist": "^4.16.1", - "semver": "7.0.0" - }, - "dependencies": { - "semver": { - "version": "7.0.0", - "resolved": "https://registry.npmjs.org/semver/-/semver-7.0.0.tgz", - "integrity": "sha512-+GB6zVA9LWh6zovYQLALHwv5rb2PHGlJi3lfiqIHxR0uuwCgefcOJc59v9fv1w8GbStwxuuqqAjI9NMAOOgq1A==" - } - } - }, - "core-util-is": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.2.tgz", - "integrity": "sha1-tf1UIgqivFq1eqtxQMlAdUUDwac=" - }, - "cosmiconfig": { - "version": "5.2.1", - "resolved": "https://registry.npmjs.org/cosmiconfig/-/cosmiconfig-5.2.1.tgz", - "integrity": "sha512-H65gsXo1SKjf8zmrJ67eJk8aIRKV5ff2D4uKZIBZShbhGSpEmsQOPW/SKMKYhSTrqR7ufy6RP69rPogdaPh/kA==", - "requires": { - "import-fresh": "^2.0.0", - "is-directory": "^0.3.1", - "js-yaml": "^3.13.1", - "parse-json": "^4.0.0" - } - }, - "create-ecdh": { - "version": "4.0.4", - "resolved": "https://registry.npmjs.org/create-ecdh/-/create-ecdh-4.0.4.tgz", - "integrity": "sha512-mf+TCx8wWc9VpuxfP2ht0iSISLZnt0JgWlrOKZiNqyUZWnjIaCIVNQArMHnCZKfEYRg6IM7A+NeJoN8gf/Ws0A==", - "requires": { - "bn.js": "^4.1.0", - "elliptic": "^6.5.3" - }, - "dependencies": { - "bn.js": { - "version": "4.11.9", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-4.11.9.tgz", - "integrity": "sha512-E6QoYqCKZfgatHTdHzs1RRKP7ip4vvm+EyRUeE2RF0NblwVvb0p6jSVeNTOFxPn26QXN2o6SMfNxKp6kU8zQaw==" - } - } - }, - "create-hash": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/create-hash/-/create-hash-1.2.0.tgz", - "integrity": "sha512-z00bCGNHDG8mHAkP7CtT1qVu+bFQUPjYq/4Iv3C3kWjTFV10zIjfSoeqXo9Asws8gwSHDGj/hl2u4OGIjapeCg==", - "requires": { - "cipher-base": "^1.0.1", - "inherits": "^2.0.1", - "md5.js": "^1.3.4", - "ripemd160": "^2.0.1", - "sha.js": "^2.4.0" - } - }, - "create-hmac": { - "version": "1.1.7", - "resolved": "https://registry.npmjs.org/create-hmac/-/create-hmac-1.1.7.tgz", - "integrity": "sha512-MJG9liiZ+ogc4TzUwuvbER1JRdgvUFSB5+VR/g5h82fGaIRWMWddtKBHi7/sVhfjQZ6SehlyhvQYrcYkaUIpLg==", - "requires": { - "cipher-base": "^1.0.3", - "create-hash": "^1.1.0", - "inherits": "^2.0.1", - "ripemd160": "^2.0.0", - "safe-buffer": "^5.0.1", - "sha.js": "^2.4.8" - } - }, - "cross-spawn": { - "version": "6.0.5", - "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-6.0.5.tgz", - "integrity": "sha512-eTVLrBSt7fjbDygz805pMnstIs2VTBNkRm0qxZd+M7A5XDdxVRWO5MxGBXZhjY4cqLYLdtrGqRf8mBPmzwSpWQ==", - "requires": { - "nice-try": "^1.0.4", - "path-key": "^2.0.1", - "semver": "^5.5.0", - "shebang-command": "^1.2.0", - "which": "^1.2.9" - }, - "dependencies": { - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "crypto-browserify": { - "version": "3.12.0", - "resolved": "https://registry.npmjs.org/crypto-browserify/-/crypto-browserify-3.12.0.tgz", - "integrity": "sha512-fz4spIh+znjO2VjL+IdhEpRJ3YN6sMzITSBijk6FK2UvTqruSQW+/cCZTSNsMiZNvUeq0CqurF+dAbyiGOY6Wg==", - "requires": { - "browserify-cipher": "^1.0.0", - "browserify-sign": "^4.0.0", - "create-ecdh": "^4.0.0", - "create-hash": "^1.1.0", - "create-hmac": "^1.1.0", - "diffie-hellman": "^5.0.0", - "inherits": "^2.0.1", - "pbkdf2": "^3.0.3", - "public-encrypt": "^4.0.0", - "randombytes": "^2.0.0", - "randomfill": "^1.0.3" - } - }, - "crypto-random-string": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/crypto-random-string/-/crypto-random-string-2.0.0.tgz", - "integrity": "sha512-v1plID3y9r/lPhviJ1wrXpLeyUIGAZ2SHNYTEapm7/8A9nLPoyvVp3RK/EPFqn5kEznyWgYZNsRtYYIWbuG8KA==" - }, - "css": { - "version": "2.2.4", - "resolved": "https://registry.npmjs.org/css/-/css-2.2.4.tgz", - "integrity": "sha512-oUnjmWpy0niI3x/mPL8dVEI1l7MnG3+HHyRPHf+YFSbK+svOhXpmSOcDURUh2aOCgl2grzrOPt1nHLuCVFULLw==", - "requires": { - "inherits": "^2.0.3", - "source-map": "^0.6.1", - "source-map-resolve": "^0.5.2", - "urix": "^0.1.0" - } - }, - "css-color-names": { - "version": "0.0.4", - "resolved": "https://registry.npmjs.org/css-color-names/-/css-color-names-0.0.4.tgz", - "integrity": "sha1-gIrcLnnPhHOAabZGyyDsJ762KeA=" - }, - "css-declaration-sorter": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/css-declaration-sorter/-/css-declaration-sorter-4.0.1.tgz", - "integrity": "sha512-BcxQSKTSEEQUftYpBVnsH4SF05NTuBokb19/sBt6asXGKZ/6VP7PLG1CBCkFDYOnhXhPh0jMhO6xZ71oYHXHBA==", - "requires": { - "postcss": "^7.0.1", - "timsort": "^0.3.0" - } - }, - "css-loader": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/css-loader/-/css-loader-2.1.1.tgz", - "integrity": "sha512-OcKJU/lt232vl1P9EEDamhoO9iKY3tIjY5GU+XDLblAykTdgs6Ux9P1hTHve8nFKy5KPpOXOsVI/hIwi3841+w==", - "requires": { - "camelcase": "^5.2.0", - "icss-utils": "^4.1.0", - "loader-utils": "^1.2.3", - "normalize-path": "^3.0.0", - "postcss": "^7.0.14", - "postcss-modules-extract-imports": "^2.0.0", - "postcss-modules-local-by-default": "^2.0.6", - "postcss-modules-scope": "^2.1.0", - "postcss-modules-values": "^2.0.0", - "postcss-value-parser": "^3.3.0", - "schema-utils": "^1.0.0" - }, - "dependencies": { - "camelcase": { - "version": "5.3.1", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-5.3.1.tgz", - "integrity": "sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==" - }, - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - }, - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - } - } - }, - "css-parse": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/css-parse/-/css-parse-2.0.0.tgz", - "integrity": "sha1-pGjuZnwW2BzPBcWMONKpfHgNv9Q=", - "requires": { - "css": "^2.0.0" - } - }, - "css-select": { - "version": "3.1.2", - "resolved": "https://registry.npmjs.org/css-select/-/css-select-3.1.2.tgz", - "integrity": "sha512-qmss1EihSuBNWNNhHjxzxSfJoFBM/lERB/Q4EnsJQQC62R2evJDW481091oAdOr9uh46/0n4nrg0It5cAnj1RA==", - "requires": { - "boolbase": "^1.0.0", - "css-what": "^4.0.0", - "domhandler": "^4.0.0", - "domutils": "^2.4.3", - "nth-check": "^2.0.0" - } - }, - "css-select-base-adapter": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/css-select-base-adapter/-/css-select-base-adapter-0.1.1.tgz", - "integrity": "sha512-jQVeeRG70QI08vSTwf1jHxp74JoZsr2XSgETae8/xC8ovSnL2WF87GTLO86Sbwdt2lK4Umg4HnnwMO4YF3Ce7w==" - }, - "css-tree": { - "version": "1.0.0-alpha.37", - "resolved": "https://registry.npmjs.org/css-tree/-/css-tree-1.0.0-alpha.37.tgz", - "integrity": "sha512-DMxWJg0rnz7UgxKT0Q1HU/L9BeJI0M6ksor0OgqOnF+aRCDWg/N2641HmVyU9KVIu0OVVWOb2IpC9A+BJRnejg==", - "requires": { - "mdn-data": "2.0.4", - "source-map": "^0.6.1" - } - }, - "css-what": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/css-what/-/css-what-4.0.0.tgz", - "integrity": "sha512-teijzG7kwYfNVsUh2H/YN62xW3KK9YhXEgSlbxMlcyjPNvdKJqFx5lrwlJgoFP1ZHlB89iGDlo/JyshKeRhv5A==" - }, - "cssesc": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/cssesc/-/cssesc-3.0.0.tgz", - "integrity": "sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==" - }, - "cssnano": { - "version": "4.1.10", - "resolved": "https://registry.npmjs.org/cssnano/-/cssnano-4.1.10.tgz", - "integrity": "sha512-5wny+F6H4/8RgNlaqab4ktc3e0/blKutmq8yNlBFXA//nSFFAqAngjNVRzUvCgYROULmZZUoosL/KSoZo5aUaQ==", - "requires": { - "cosmiconfig": "^5.0.0", - "cssnano-preset-default": "^4.0.7", - "is-resolvable": "^1.0.0", - "postcss": "^7.0.0" - } - }, - "cssnano-preset-default": { - "version": "4.0.7", - "resolved": "https://registry.npmjs.org/cssnano-preset-default/-/cssnano-preset-default-4.0.7.tgz", - "integrity": "sha512-x0YHHx2h6p0fCl1zY9L9roD7rnlltugGu7zXSKQx6k2rYw0Hi3IqxcoAGF7u9Q5w1nt7vK0ulxV8Lo+EvllGsA==", - "requires": { - "css-declaration-sorter": "^4.0.1", - "cssnano-util-raw-cache": "^4.0.1", - "postcss": "^7.0.0", - "postcss-calc": "^7.0.1", - "postcss-colormin": "^4.0.3", - "postcss-convert-values": "^4.0.1", - "postcss-discard-comments": "^4.0.2", - "postcss-discard-duplicates": "^4.0.2", - "postcss-discard-empty": "^4.0.1", - "postcss-discard-overridden": "^4.0.1", - "postcss-merge-longhand": "^4.0.11", - "postcss-merge-rules": "^4.0.3", - "postcss-minify-font-values": "^4.0.2", - "postcss-minify-gradients": "^4.0.2", - "postcss-minify-params": "^4.0.2", - "postcss-minify-selectors": "^4.0.2", - "postcss-normalize-charset": "^4.0.1", - "postcss-normalize-display-values": "^4.0.2", - "postcss-normalize-positions": "^4.0.2", - "postcss-normalize-repeat-style": "^4.0.2", - "postcss-normalize-string": "^4.0.2", - "postcss-normalize-timing-functions": "^4.0.2", - "postcss-normalize-unicode": "^4.0.1", - "postcss-normalize-url": "^4.0.1", - "postcss-normalize-whitespace": "^4.0.2", - "postcss-ordered-values": "^4.1.2", - "postcss-reduce-initial": "^4.0.3", - "postcss-reduce-transforms": "^4.0.2", - "postcss-svgo": "^4.0.2", - "postcss-unique-selectors": "^4.0.1" - } - }, - "cssnano-util-get-arguments": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/cssnano-util-get-arguments/-/cssnano-util-get-arguments-4.0.0.tgz", - "integrity": "sha1-7ToIKZ8h11dBsg87gfGU7UnMFQ8=" - }, - "cssnano-util-get-match": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/cssnano-util-get-match/-/cssnano-util-get-match-4.0.0.tgz", - "integrity": "sha1-wOTKB/U4a7F+xeUiULT1lhNlFW0=" - }, - "cssnano-util-raw-cache": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/cssnano-util-raw-cache/-/cssnano-util-raw-cache-4.0.1.tgz", - "integrity": "sha512-qLuYtWK2b2Dy55I8ZX3ky1Z16WYsx544Q0UWViebptpwn/xDBmog2TLg4f+DBMg1rJ6JDWtn96WHbOKDWt1WQA==", - "requires": { - "postcss": "^7.0.0" - } - }, - "cssnano-util-same-parent": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/cssnano-util-same-parent/-/cssnano-util-same-parent-4.0.1.tgz", - "integrity": "sha512-WcKx5OY+KoSIAxBW6UBBRay1U6vkYheCdjyVNDm85zt5K9mHoGOfsOsqIszfAqrQQFIIKgjh2+FDgIj/zsl21Q==" - }, - "csso": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/csso/-/csso-4.2.0.tgz", - "integrity": "sha512-wvlcdIbf6pwKEk7vHj8/Bkc0B4ylXZruLvOgs9doS5eOsOpuodOV2zJChSpkp+pRpYQLQMeF04nr3Z68Sta9jA==", - "requires": { - "css-tree": "^1.1.2" - }, - "dependencies": { - "css-tree": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/css-tree/-/css-tree-1.1.2.tgz", - "integrity": "sha512-wCoWush5Aeo48GLhfHPbmvZs59Z+M7k5+B1xDnXbdWNcEF423DoFdqSWE0PM5aNk5nI5cp1q7ms36zGApY/sKQ==", - "requires": { - "mdn-data": "2.0.14", - "source-map": "^0.6.1" - } - }, - "mdn-data": { - "version": "2.0.14", - "resolved": "https://registry.npmjs.org/mdn-data/-/mdn-data-2.0.14.tgz", - "integrity": "sha512-dn6wd0uw5GsdswPFfsgMp5NSB0/aDe6fK94YJV/AJDYXL6HVLWBsxeq7js7Ad+mU2K9LAlwpk6kN2D5mwCPVow==" - } - } - }, - "cyclist": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/cyclist/-/cyclist-1.0.1.tgz", - "integrity": "sha1-WW6WmP0MgOEgOMK4LW6xs1tiJNk=" - }, - "dashdash": { - "version": "1.14.1", - "resolved": "https://registry.npmjs.org/dashdash/-/dashdash-1.14.1.tgz", - "integrity": "sha1-hTz6D3y+L+1d4gMmuN1YEDX24vA=", - "requires": { - "assert-plus": "^1.0.0" - } - }, - "de-indent": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/de-indent/-/de-indent-1.0.2.tgz", - "integrity": "sha1-sgOOhG3DO6pXlhKNCAS0VbjB4h0=" - }, - "debug": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/debug/-/debug-3.1.0.tgz", - "integrity": "sha512-OX8XqP7/1a9cqkxYw2yXss15f26NKWBpDXQd0/uK/KPqdQhxbPa994hnzjcE2VqQpDslf55723cKPUOGSmMY3g==", - "requires": { - "ms": "2.0.0" - } - }, - "decamelize": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/decamelize/-/decamelize-1.2.0.tgz", - "integrity": "sha1-9lNNFRSCabIDUue+4m9QH5oZEpA=" - }, - "decode-uri-component": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/decode-uri-component/-/decode-uri-component-0.2.0.tgz", - "integrity": "sha1-6zkTMzRYd1y4TNGh+uBiEGu4dUU=" - }, - "decompress-response": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/decompress-response/-/decompress-response-3.3.0.tgz", - "integrity": "sha1-gKTdMjdIOEv6JICDYirt7Jgq3/M=", - "requires": { - "mimic-response": "^1.0.0" - } - }, - "deep-equal": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/deep-equal/-/deep-equal-1.1.1.tgz", - "integrity": "sha512-yd9c5AdiqVcR+JjcwUQb9DkhJc8ngNr0MahEBGvDiJw8puWab2yZlh+nkasOnZP+EGTAP6rRp2JzJhJZzvNF8g==", - "requires": { - "is-arguments": "^1.0.4", - "is-date-object": "^1.0.1", - "is-regex": "^1.0.4", - "object-is": "^1.0.1", - "object-keys": "^1.1.1", - "regexp.prototype.flags": "^1.2.0" - } - }, - "deep-extend": { - "version": "0.6.0", - "resolved": "https://registry.npmjs.org/deep-extend/-/deep-extend-0.6.0.tgz", - "integrity": "sha512-LOHxIOaPYdHlJRtCQfDIVZtfw/ufM8+rVj649RIHzcm/vGwQRXFt6OPqIFWsm2XEMrNIEtWR64sY1LEKD2vAOA==" - }, - "deepmerge": { - "version": "1.5.2", - "resolved": "https://registry.npmjs.org/deepmerge/-/deepmerge-1.5.2.tgz", - "integrity": "sha512-95k0GDqvBjZavkuvzx/YqVLv/6YYa17fz6ILMSf7neqQITCPbnfEnQvEgMPNjH4kgobe7+WIL0yJEHku+H3qtQ==" - }, - "default-gateway": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/default-gateway/-/default-gateway-4.2.0.tgz", - "integrity": "sha512-h6sMrVB1VMWVrW13mSc6ia/DwYYw5MN6+exNu1OaJeFac5aSAvwM7lZ0NVfTABuSkQelr4h5oebg3KB1XPdjgA==", - "requires": { - "execa": "^1.0.0", - "ip-regex": "^2.1.0" - } - }, - "defer-to-connect": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/defer-to-connect/-/defer-to-connect-1.1.3.tgz", - "integrity": "sha512-0ISdNousHvZT2EiFlZeZAHBUvSxmKswVCEf8hW7KWgG4a8MVEu/3Vb6uWYozkjylyCxe0JBIiRB1jV45S70WVQ==" - }, - "define-properties": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/define-properties/-/define-properties-1.1.3.tgz", - "integrity": "sha512-3MqfYKj2lLzdMSf8ZIZE/V+Zuy+BgD6f164e8K2w7dgnpKArBDerGYpM46IYYcjnkdPNMjPk9A6VFB8+3SKlXQ==", - "requires": { - "object-keys": "^1.0.12" - } - }, - "define-property": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-2.0.2.tgz", - "integrity": "sha512-jwK2UV4cnPpbcG7+VRARKTZPUWowwXA8bzH5NP6ud0oeAxyYPuGZUAC7hMugpCdz4BeSZl2Dl9k66CHJ/46ZYQ==", - "requires": { - "is-descriptor": "^1.0.2", - "isobject": "^3.0.1" - }, - "dependencies": { - "is-accessor-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz", - "integrity": "sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-data-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-data-descriptor/-/is-data-descriptor-1.0.0.tgz", - "integrity": "sha512-jbRXy1FmtAoCjQkVmIVYwuuqDFUbaOeDjmed1tOGPrsMhtJA4rD9tkgA0F1qJ3gRFRXcHYVkdeaP50Q5rE/jLQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-descriptor": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-descriptor/-/is-descriptor-1.0.2.tgz", - "integrity": "sha512-2eis5WqQGV7peooDyLmNEPUrps9+SXX5c9pL3xEB+4e9HnGuDa7mB7kHxHw4CbqS9k1T2hOH3miL8n8WtiYVtg==", - "requires": { - "is-accessor-descriptor": "^1.0.0", - "is-data-descriptor": "^1.0.0", - "kind-of": "^6.0.2" - } - } - } - }, - "del": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/del/-/del-4.1.1.tgz", - "integrity": "sha512-QwGuEUouP2kVwQenAsOof5Fv8K9t3D8Ca8NxcXKrIpEHjTXK5J2nXLdP+ALI1cgv8wj7KuwBhTwBkOZSJKM5XQ==", - "requires": { - "@types/glob": "^7.1.1", - "globby": "^6.1.0", - "is-path-cwd": "^2.0.0", - "is-path-in-cwd": "^2.0.0", - "p-map": "^2.0.0", - "pify": "^4.0.1", - "rimraf": "^2.6.3" - }, - "dependencies": { - "globby": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/globby/-/globby-6.1.0.tgz", - "integrity": "sha1-9abXDoOV4hyFj7BInWTfAkJNUGw=", - "requires": { - "array-union": "^1.0.1", - "glob": "^7.0.3", - "object-assign": "^4.0.1", - "pify": "^2.0.0", - "pinkie-promise": "^2.0.0" - }, - "dependencies": { - "pify": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz", - "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=" - } - } - } - } - }, - "delayed-stream": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/delayed-stream/-/delayed-stream-1.0.0.tgz", - "integrity": "sha1-3zrhmayt+31ECqrgsp4icrJOxhk=" - }, - "delegate": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/delegate/-/delegate-3.2.0.tgz", - "integrity": "sha512-IofjkYBZaZivn0V8nnsMJGBr4jVLxHDheKSW88PyxS5QC4Vo9ZbZVvhzlSxY87fVq3STR6r+4cGepyHkcWOQSw==", - "optional": true - }, - "depd": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/depd/-/depd-1.1.2.tgz", - "integrity": "sha1-m81S4UwJd2PnSbJ0xDRu0uVgtak=" - }, - "des.js": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/des.js/-/des.js-1.0.1.tgz", - "integrity": "sha512-Q0I4pfFrv2VPd34/vfLrFOoRmlYj3OV50i7fskps1jZWK1kApMWWT9G6RRUeYedLcBDIhnSDaUvJMb3AhUlaEA==", - "requires": { - "inherits": "^2.0.1", - "minimalistic-assert": "^1.0.0" - } - }, - "destroy": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/destroy/-/destroy-1.0.4.tgz", - "integrity": "sha1-l4hXRCxEdJ5CBmE+N5RiBYJqvYA=" - }, - "detect-node": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/detect-node/-/detect-node-2.0.4.tgz", - "integrity": "sha512-ZIzRpLJrOj7jjP2miAtgqIfmzbxa4ZOr5jJc601zklsfEx9oTzmmj2nVpIPRpNlRTIh8lc1kyViIY7BWSGNmKw==" - }, - "diffie-hellman": { - "version": "5.0.3", - "resolved": "https://registry.npmjs.org/diffie-hellman/-/diffie-hellman-5.0.3.tgz", - "integrity": "sha512-kqag/Nl+f3GwyK25fhUMYj81BUOrZ9IuJsjIcDE5icNM9FJHAVm3VcUDxdLPoQtTuUylWm6ZIknYJwwaPxsUzg==", - "requires": { - "bn.js": "^4.1.0", - "miller-rabin": "^4.0.0", - "randombytes": "^2.0.0" - }, - "dependencies": { - "bn.js": { - "version": "4.11.9", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-4.11.9.tgz", - "integrity": "sha512-E6QoYqCKZfgatHTdHzs1RRKP7ip4vvm+EyRUeE2RF0NblwVvb0p6jSVeNTOFxPn26QXN2o6SMfNxKp6kU8zQaw==" - } - } - }, - "dir-glob": { - "version": "2.2.2", - "resolved": "https://registry.npmjs.org/dir-glob/-/dir-glob-2.2.2.tgz", - "integrity": "sha512-f9LBi5QWzIW3I6e//uxZoLBlUt9kcp66qo0sSCxL6YZKc75R1c4MFCoe/LaZiBGmgujvQdxc5Bn3QhfyvK5Hsw==", - "requires": { - "path-type": "^3.0.0" - } - }, - "dns-equal": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/dns-equal/-/dns-equal-1.0.0.tgz", - "integrity": "sha1-s55/HabrCnW6nBcySzR1PEfgZU0=" - }, - "dns-packet": { - "version": "1.3.1", - "resolved": "https://registry.npmjs.org/dns-packet/-/dns-packet-1.3.1.tgz", - "integrity": "sha512-0UxfQkMhYAUaZI+xrNZOz/as5KgDU0M/fQ9b6SpkyLbk3GEswDi6PADJVaYJradtRVsRIlF1zLyOodbcTCDzUg==", - "requires": { - "ip": "^1.1.0", - "safe-buffer": "^5.0.1" - } - }, - "dns-txt": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/dns-txt/-/dns-txt-2.0.2.tgz", - "integrity": "sha1-uR2Ab10nGI5Ks+fRB9iBocxGQrY=", - "requires": { - "buffer-indexof": "^1.0.0" - } - }, - "docsearch.js": { - "version": "2.6.3", - "resolved": "https://registry.npmjs.org/docsearch.js/-/docsearch.js-2.6.3.tgz", - "integrity": "sha512-GN+MBozuyz664ycpZY0ecdQE0ND/LSgJKhTLA0/v3arIS3S1Rpf2OJz6A35ReMsm91V5apcmzr5/kM84cvUg+A==", - "requires": { - "algoliasearch": "^3.24.5", - "autocomplete.js": "0.36.0", - "hogan.js": "^3.0.2", - "request": "^2.87.0", - "stack-utils": "^1.0.1", - "to-factory": "^1.0.0", - "zepto": "^1.2.0" - }, - "dependencies": { - "algoliasearch": { - "version": "3.35.1", - "resolved": "https://registry.npmjs.org/algoliasearch/-/algoliasearch-3.35.1.tgz", - "integrity": "sha512-K4yKVhaHkXfJ/xcUnil04xiSrB8B8yHZoFEhWNpXg23eiCnqvTZw1tn/SqvdsANlYHLJlKl0qi3I/Q2Sqo7LwQ==", - "requires": { - "agentkeepalive": "^2.2.0", - "debug": "^2.6.9", - "envify": "^4.0.0", - "es6-promise": "^4.1.0", - "events": "^1.1.0", - "foreach": "^2.0.5", - "global": "^4.3.2", - "inherits": "^2.0.1", - "isarray": "^2.0.1", - "load-script": "^1.0.0", - "object-keys": "^1.0.11", - "querystring-es3": "^0.2.1", - "reduce": "^1.0.1", - "semver": "^5.1.0", - "tunnel-agent": "^0.6.0" - } - }, - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - }, - "events": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/events/-/events-1.1.1.tgz", - "integrity": "sha1-nr23Y1rQmccNzEwqH1AEKI6L2SQ=" - }, - "isarray": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/isarray/-/isarray-2.0.5.tgz", - "integrity": "sha512-xHjhDr3cNBK0BzdUJSPXZntQUx/mwMS5Rw4A7lPJ90XGAO6ISP/ePDNuo0vhqOZU+UD5JoodwCAAoZQd3FeAKw==" - }, - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "doctypes": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/doctypes/-/doctypes-1.1.0.tgz", - "integrity": "sha1-6oCxBqh1OHdOijpKWv4pPeSJ4Kk=" - }, - "dom-converter": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/dom-converter/-/dom-converter-0.2.0.tgz", - "integrity": "sha512-gd3ypIPfOMr9h5jIKq8E3sHOTCjeirnl0WK5ZdS1AW0Odt0b1PaWaHdJ4Qk4klv+YB9aJBS7mESXjFoDQPu6DA==", - "requires": { - "utila": "~0.4" - } - }, - "dom-serializer": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-1.2.0.tgz", - "integrity": "sha512-n6kZFH/KlCrqs/1GHMOd5i2fd/beQHuehKdWvNNffbGHTr/almdhuVvTVFb3V7fglz+nC50fFusu3lY33h12pA==", - "requires": { - "domelementtype": "^2.0.1", - "domhandler": "^4.0.0", - "entities": "^2.0.0" - } - }, - "dom-walk": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/dom-walk/-/dom-walk-0.1.2.tgz", - "integrity": "sha512-6QvTW9mrGeIegrFXdtQi9pk7O/nSK6lSdXW2eqUspN5LWD7UTji2Fqw5V2YLjBpHEoU9Xl/eUWNpDeZvoyOv2w==" - }, - "domain-browser": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/domain-browser/-/domain-browser-1.2.0.tgz", - "integrity": "sha512-jnjyiM6eRyZl2H+W8Q/zLMA481hzi0eszAaBUzIVnmYVDBbnLxVNnfu1HgEBvCbL+71FrxMl3E6lpKH7Ge3OXA==" - }, - "domelementtype": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.1.0.tgz", - "integrity": "sha512-LsTgx/L5VpD+Q8lmsXSHW2WpA+eBlZ9HPf3erD1IoPF00/3JKHZ3BknUVA2QGDNu69ZNmyFmCWBSO45XjYKC5w==" - }, - "domhandler": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-4.0.0.tgz", - "integrity": "sha512-KPTbnGQ1JeEMQyO1iYXoagsI6so/C96HZiFyByU3T6iAzpXn8EGEvct6unm1ZGoed8ByO2oirxgwxBmqKF9haA==", - "requires": { - "domelementtype": "^2.1.0" - } - }, - "domutils": { - "version": "2.4.4", - "resolved": "https://registry.npmjs.org/domutils/-/domutils-2.4.4.tgz", - "integrity": "sha512-jBC0vOsECI4OMdD0GC9mGn7NXPLb+Qt6KW1YDQzeQYRUFKmNG8lh7mO5HiELfr+lLQE7loDVI4QcAxV80HS+RA==", - "requires": { - "dom-serializer": "^1.0.1", - "domelementtype": "^2.0.1", - "domhandler": "^4.0.0" - } - }, - "dot-prop": { - "version": "5.3.0", - "resolved": "https://registry.npmjs.org/dot-prop/-/dot-prop-5.3.0.tgz", - "integrity": "sha512-QM8q3zDe58hqUqjraQOmzZ1LIH9SWQJTlEKCH4kJ2oQvLZk7RbQXvtDM2XEq3fwkV9CCvvH4LA0AV+ogFsBM2Q==", - "requires": { - "is-obj": "^2.0.0" - } - }, - "duplexer3": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/duplexer3/-/duplexer3-0.1.4.tgz", - "integrity": "sha1-7gHdHKwO08vH/b6jfcCo8c4ALOI=" - }, - "duplexify": { - "version": "3.7.1", - "resolved": "https://registry.npmjs.org/duplexify/-/duplexify-3.7.1.tgz", - "integrity": "sha512-07z8uv2wMyS51kKhD1KsdXJg5WQ6t93RneqRxUHnskXVtlYYkLqM0gqStQZ3pj073g687jPCHrqNfCzawLYh5g==", - "requires": { - "end-of-stream": "^1.0.0", - "inherits": "^2.0.1", - "readable-stream": "^2.0.0", - "stream-shift": "^1.0.0" - } - }, - "ecc-jsbn": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/ecc-jsbn/-/ecc-jsbn-0.1.2.tgz", - "integrity": "sha1-OoOpBOVDUyh4dMVkt1SThoSamMk=", - "requires": { - "jsbn": "~0.1.0", - "safer-buffer": "^2.1.0" - } - }, - "ee-first": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz", - "integrity": "sha1-WQxhFWsK4vTwJVcyoViyZrxWsh0=" - }, - "electron-to-chromium": { - "version": "1.3.643", - "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.3.643.tgz", - "integrity": "sha512-TGomM4gj8adt/uqRgPbu9F0yhUVAR1deww5X0fvbQgpGr9suSMjLgc4IwQ9YKGkp1t03cDbZum20OfAkiTYjAg==" - }, - "elliptic": { - "version": "6.5.3", - "resolved": "https://registry.npmjs.org/elliptic/-/elliptic-6.5.3.tgz", - "integrity": "sha512-IMqzv5wNQf+E6aHeIqATs0tOLeOTwj1QKbRcS3jBbYkl5oLAserA8yJTT7/VyHUYG91PRmPyeQDObKLPpeS4dw==", - "requires": { - "bn.js": "^4.4.0", - "brorand": "^1.0.1", - "hash.js": "^1.0.0", - "hmac-drbg": "^1.0.0", - "inherits": "^2.0.1", - "minimalistic-assert": "^1.0.0", - "minimalistic-crypto-utils": "^1.0.0" - }, - "dependencies": { - "bn.js": { - "version": "4.11.9", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-4.11.9.tgz", - "integrity": "sha512-E6QoYqCKZfgatHTdHzs1RRKP7ip4vvm+EyRUeE2RF0NblwVvb0p6jSVeNTOFxPn26QXN2o6SMfNxKp6kU8zQaw==" - } - } - }, - "emoji-regex": { - "version": "7.0.3", - "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-7.0.3.tgz", - "integrity": "sha512-CwBLREIQ7LvYFB0WyRvwhq5N5qPhc6PMjD6bYggFlI5YyDgl+0vxq5VHbMOFqLg7hfWzmu8T5Z1QofhmTIhItA==" - }, - "emojis-list": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/emojis-list/-/emojis-list-3.0.0.tgz", - "integrity": "sha512-/kyM18EfinwXZbno9FyUGeFh87KC8HRQBQGildHZbEuRyWFOmv1U10o9BBp8XVZDVNNuQKyIGIu5ZYAAXJ0V2Q==" - }, - "encodeurl": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/encodeurl/-/encodeurl-1.0.2.tgz", - "integrity": "sha1-rT/0yG7C0CkyL1oCw6mmBslbP1k=" - }, - "end-of-stream": { - "version": "1.4.4", - "resolved": "https://registry.npmjs.org/end-of-stream/-/end-of-stream-1.4.4.tgz", - "integrity": "sha512-+uw1inIHVPQoaVuHzRyXd21icM+cnt4CzD5rW+NC1wjOUSTOs+Te7FOv7AhN7vS9x/oIyhLP5PR1H+phQAHu5Q==", - "requires": { - "once": "^1.4.0" - } - }, - "enhanced-resolve": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/enhanced-resolve/-/enhanced-resolve-4.5.0.tgz", - "integrity": "sha512-Nv9m36S/vxpsI+Hc4/ZGRs0n9mXqSWGGq49zxb/cJfPAQMbUtttJAlNPS4AQzaBdw/pKskw5bMbekT/Y7W/Wlg==", - "requires": { - "graceful-fs": "^4.1.2", - "memory-fs": "^0.5.0", - "tapable": "^1.0.0" - }, - "dependencies": { - "memory-fs": { - "version": "0.5.0", - "resolved": "https://registry.npmjs.org/memory-fs/-/memory-fs-0.5.0.tgz", - "integrity": "sha512-jA0rdU5KoQMC0e6ppoNRtpp6vjFq6+NY7r8hywnC7V+1Xj/MtHwGIbB1QaK/dunyjWteJzmkpd7ooeWg10T7GA==", - "requires": { - "errno": "^0.1.3", - "readable-stream": "^2.0.1" - } - } - } - }, - "entities": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/entities/-/entities-2.1.0.tgz", - "integrity": "sha512-hCx1oky9PFrJ611mf0ifBLBRW8lUUVRlFolb5gWRfIELabBlbp9xZvrqZLZAs+NxFnbfQoeGd8wDkygjg7U85w==" - }, - "envify": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/envify/-/envify-4.1.0.tgz", - "integrity": "sha512-IKRVVoAYr4pIx4yIWNsz9mOsboxlNXiu7TNBnem/K/uTHdkyzXWDzHCK7UTolqBbgaBz0tQHsD3YNls0uIIjiw==", - "requires": { - "esprima": "^4.0.0", - "through": "~2.3.4" - } - }, - "envinfo": { - "version": "7.7.3", - "resolved": "https://registry.npmjs.org/envinfo/-/envinfo-7.7.3.tgz", - "integrity": "sha512-46+j5QxbPWza0PB1i15nZx0xQ4I/EfQxg9J8Had3b408SV63nEtor2e+oiY63amTo9KTuh2a3XLObNwduxYwwA==" - }, - "errno": { - "version": "0.1.8", - "resolved": "https://registry.npmjs.org/errno/-/errno-0.1.8.tgz", - "integrity": "sha512-dJ6oBr5SQ1VSd9qkk7ByRgb/1SH4JZjCHSW/mr63/QcXO9zLVxvJ6Oy13nio03rxpSnVDDjFor75SjVeZWPW/A==", - "requires": { - "prr": "~1.0.1" - } - }, - "error-ex": { - "version": "1.3.2", - "resolved": "https://registry.npmjs.org/error-ex/-/error-ex-1.3.2.tgz", - "integrity": "sha512-7dFHNmqeFSEt2ZBsCriorKnn3Z2pj+fd9kmI6QoWw4//DL+icEBfc0U7qJCisqrTsKTjw4fNFy2pW9OqStD84g==", - "requires": { - "is-arrayish": "^0.2.1" - } - }, - "es-abstract": { - "version": "1.18.0-next.2", - "resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.18.0-next.2.tgz", - "integrity": "sha512-Ih4ZMFHEtZupnUh6497zEL4y2+w8+1ljnCyaTa+adcoafI1GOvMwFlDjBLfWR7y9VLfrjRJe9ocuHY1PSR9jjw==", - "requires": { - "call-bind": "^1.0.2", - "es-to-primitive": "^1.2.1", - "function-bind": "^1.1.1", - "get-intrinsic": "^1.0.2", - "has": "^1.0.3", - "has-symbols": "^1.0.1", - "is-callable": "^1.2.2", - "is-negative-zero": "^2.0.1", - "is-regex": "^1.1.1", - "object-inspect": "^1.9.0", - "object-keys": "^1.1.1", - "object.assign": "^4.1.2", - "string.prototype.trimend": "^1.0.3", - "string.prototype.trimstart": "^1.0.3" - } - }, - "es-to-primitive": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/es-to-primitive/-/es-to-primitive-1.2.1.tgz", - "integrity": "sha512-QCOllgZJtaUo9miYBcLChTUaHNjJF3PYs1VidD7AwiEj1kYxKeQTctLAezAOH5ZKRH0g2IgPn6KwB4IT8iRpvA==", - "requires": { - "is-callable": "^1.1.4", - "is-date-object": "^1.0.1", - "is-symbol": "^1.0.2" - } - }, - "es6-promise": { - "version": "4.2.8", - "resolved": "https://registry.npmjs.org/es6-promise/-/es6-promise-4.2.8.tgz", - "integrity": "sha512-HJDGx5daxeIvxdBxvG2cb9g4tEvwIk3i8+nhX0yGrYmZUzbkdg8QbDevheDB8gd0//uPj4c1EQua8Q+MViT0/w==" - }, - "escalade": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.1.1.tgz", - "integrity": "sha512-k0er2gUkLf8O0zKJiAhmkTnJlTvINGv7ygDNPbeIsX/TJjGJZHuh9B2UxbsaEkmlEo9MfhrSzmhIlhRlI2GXnw==" - }, - "escape-goat": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/escape-goat/-/escape-goat-2.1.1.tgz", - "integrity": "sha512-8/uIhbG12Csjy2JEW7D9pHbreaVaS/OpN3ycnyvElTdwM5n6GY6W6e2IPemfvGZeUMqZ9A/3GqIZMgKnBhAw/Q==" - }, - "escape-html": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/escape-html/-/escape-html-1.0.3.tgz", - "integrity": "sha1-Aljq5NPQwJdN4cFpGI7wBR0dGYg=" - }, - "escape-string-regexp": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz", - "integrity": "sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=" - }, - "eslint-scope": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/eslint-scope/-/eslint-scope-4.0.3.tgz", - "integrity": "sha512-p7VutNr1O/QrxysMo3E45FjYDTeXBy0iTltPFNSqKAIfjDSXC+4dj+qfyuD8bfAXrW/y6lW3O76VaYNPKfpKrg==", - "requires": { - "esrecurse": "^4.1.0", - "estraverse": "^4.1.1" - } - }, - "esm": { - "version": "3.2.25", - "resolved": "https://registry.npmjs.org/esm/-/esm-3.2.25.tgz", - "integrity": "sha512-U1suiZ2oDVWv4zPO56S0NcR5QriEahGtdN2OR6FiOG4WJvcjBVFB0qI4+eKoWFH483PKGuLuu6V8Z4T5g63UVA==" - }, - "esprima": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz", - "integrity": "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A==" - }, - "esrecurse": { - "version": "4.3.0", - "resolved": "https://registry.npmjs.org/esrecurse/-/esrecurse-4.3.0.tgz", - "integrity": "sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==", - "requires": { - "estraverse": "^5.2.0" - }, - "dependencies": { - "estraverse": { - "version": "5.2.0", - "resolved": "https://registry.npmjs.org/estraverse/-/estraverse-5.2.0.tgz", - "integrity": "sha512-BxbNGGNm0RyRYvUdHpIwv9IWzeM9XClbOxwoATuFdOE7ZE6wHL+HQ5T8hoPM+zHvmKzzsEqhgy0GrQ5X13afiQ==" - } - } - }, - "estraverse": { - "version": "4.3.0", - "resolved": "https://registry.npmjs.org/estraverse/-/estraverse-4.3.0.tgz", - "integrity": "sha512-39nnKffWz8xN1BU/2c79n9nB9HDzo0niYUqx6xyqUnyoAnQyyWpOTdZEeiCch8BBu515t4wp9ZmgVfVhn9EBpw==" - }, - "esutils": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/esutils/-/esutils-2.0.3.tgz", - "integrity": "sha512-kVscqXk4OCp68SZ0dkgEKVi6/8ij300KBWTJq32P/dYeWTSwK41WyTxalN1eRmA5Z9UU/LX9D7FWSmV9SAYx6g==" - }, - "etag": { - "version": "1.8.1", - "resolved": "https://registry.npmjs.org/etag/-/etag-1.8.1.tgz", - "integrity": "sha1-Qa4u62XvpiJorr/qg6x9eSmbCIc=" - }, - "eventemitter3": { - "version": "4.0.7", - "resolved": "https://registry.npmjs.org/eventemitter3/-/eventemitter3-4.0.7.tgz", - "integrity": "sha512-8guHBZCwKnFhYdHr2ysuRWErTwhoN2X8XELRlrRwpmfeY2jjuUN4taQMsULKUVo1K4DvZl+0pgfyoysHxvmvEw==" - }, - "events": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/events/-/events-3.2.0.tgz", - "integrity": "sha512-/46HWwbfCX2xTawVfkKLGxMifJYQBWMwY1mjywRtb4c9x8l5NP3KoJtnIOiL1hfdRkIuYhETxQlo62IF8tcnlg==" - }, - "eventsource": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/eventsource/-/eventsource-1.0.7.tgz", - "integrity": "sha512-4Ln17+vVT0k8aWq+t/bF5arcS3EpT9gYtW66EPacdj/mAFevznsnyoHLPy2BA8gbIQeIHoPsvwmfBftfcG//BQ==", - "requires": { - "original": "^1.0.0" - } - }, - "evp_bytestokey": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/evp_bytestokey/-/evp_bytestokey-1.0.3.tgz", - "integrity": "sha512-/f2Go4TognH/KvCISP7OUsHn85hT9nUkxxA9BEWxFn+Oj9o8ZNLm/40hdlgSLyuOimsrTKLUMEorQexp/aPQeA==", - "requires": { - "md5.js": "^1.3.4", - "safe-buffer": "^5.1.1" - } - }, - "execa": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/execa/-/execa-1.0.0.tgz", - "integrity": "sha512-adbxcyWV46qiHyvSp50TKt05tB4tK3HcmF7/nxfAdhnox83seTDbwnaqKO4sXRy7roHAIFqJP/Rw/AuEbX61LA==", - "requires": { - "cross-spawn": "^6.0.0", - "get-stream": "^4.0.0", - "is-stream": "^1.1.0", - "npm-run-path": "^2.0.0", - "p-finally": "^1.0.0", - "signal-exit": "^3.0.0", - "strip-eof": "^1.0.0" - } - }, - "expand-brackets": { - "version": "2.1.4", - "resolved": "https://registry.npmjs.org/expand-brackets/-/expand-brackets-2.1.4.tgz", - "integrity": "sha1-t3c14xXOMPa27/D4OwQVGiJEliI=", - "requires": { - "debug": "^2.3.3", - "define-property": "^0.2.5", - "extend-shallow": "^2.0.1", - "posix-character-classes": "^0.1.0", - "regex-not": "^1.0.0", - "snapdragon": "^0.8.1", - "to-regex": "^3.0.1" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - }, - "define-property": { - "version": "0.2.5", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-0.2.5.tgz", - "integrity": "sha1-w1se+RjsPJkPmlvFe+BKrOxcgRY=", - "requires": { - "is-descriptor": "^0.1.0" - } - } - } - }, - "express": { - "version": "4.17.1", - "resolved": "https://registry.npmjs.org/express/-/express-4.17.1.tgz", - "integrity": "sha512-mHJ9O79RqluphRrcw2X/GTh3k9tVv8YcoyY4Kkh4WDMUYKRZUq0h1o0w2rrrxBqM7VoeUVqgb27xlEMXTnYt4g==", - "requires": { - "accepts": "~1.3.7", - "array-flatten": "1.1.1", - "body-parser": "1.19.0", - "content-disposition": "0.5.3", - "content-type": "~1.0.4", - "cookie": "0.4.0", - "cookie-signature": "1.0.6", - "debug": "2.6.9", - "depd": "~1.1.2", - "encodeurl": "~1.0.2", - "escape-html": "~1.0.3", - "etag": "~1.8.1", - "finalhandler": "~1.1.2", - "fresh": "0.5.2", - "merge-descriptors": "1.0.1", - "methods": "~1.1.2", - "on-finished": "~2.3.0", - "parseurl": "~1.3.3", - "path-to-regexp": "0.1.7", - "proxy-addr": "~2.0.5", - "qs": "6.7.0", - "range-parser": "~1.2.1", - "safe-buffer": "5.1.2", - "send": "0.17.1", - "serve-static": "1.14.1", - "setprototypeof": "1.1.1", - "statuses": "~1.5.0", - "type-is": "~1.6.18", - "utils-merge": "1.0.1", - "vary": "~1.1.2" - }, - "dependencies": { - "array-flatten": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/array-flatten/-/array-flatten-1.1.1.tgz", - "integrity": "sha1-ml9pkFGx5wczKPKgCJaLZOopVdI=" - }, - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - } - } - }, - "extend": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/extend/-/extend-3.0.2.tgz", - "integrity": "sha512-fjquC59cD7CyW6urNXK0FBufkZcoiGG80wTuPujX590cB5Ttln20E2UB4S/WARVqhXffZl2LNgS+gQdPIIim/g==" - }, - "extend-shallow": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-2.0.1.tgz", - "integrity": "sha1-Ua99YUrZqfYQ6huvu5idaxxWiQ8=", - "requires": { - "is-extendable": "^0.1.0" - } - }, - "extglob": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/extglob/-/extglob-2.0.4.tgz", - "integrity": "sha512-Nmb6QXkELsuBr24CJSkilo6UHHgbekK5UiZgfE6UHD3Eb27YC6oD+bhcT+tJ6cl8dmsgdQxnWlcry8ksBIBLpw==", - "requires": { - "array-unique": "^0.3.2", - "define-property": "^1.0.0", - "expand-brackets": "^2.1.4", - "extend-shallow": "^2.0.1", - "fragment-cache": "^0.2.1", - "regex-not": "^1.0.0", - "snapdragon": "^0.8.1", - "to-regex": "^3.0.1" - }, - "dependencies": { - "define-property": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-1.0.0.tgz", - "integrity": "sha1-dp66rz9KY6rTr56NMEybvnm/sOY=", - "requires": { - "is-descriptor": "^1.0.0" - } - }, - "is-accessor-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz", - "integrity": "sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-data-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-data-descriptor/-/is-data-descriptor-1.0.0.tgz", - "integrity": "sha512-jbRXy1FmtAoCjQkVmIVYwuuqDFUbaOeDjmed1tOGPrsMhtJA4rD9tkgA0F1qJ3gRFRXcHYVkdeaP50Q5rE/jLQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-descriptor": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-descriptor/-/is-descriptor-1.0.2.tgz", - "integrity": "sha512-2eis5WqQGV7peooDyLmNEPUrps9+SXX5c9pL3xEB+4e9HnGuDa7mB7kHxHw4CbqS9k1T2hOH3miL8n8WtiYVtg==", - "requires": { - "is-accessor-descriptor": "^1.0.0", - "is-data-descriptor": "^1.0.0", - "kind-of": "^6.0.2" - } - } - } - }, - "extsprintf": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/extsprintf/-/extsprintf-1.3.0.tgz", - "integrity": "sha1-lpGEQOMEGnpBT4xS48V06zw+HgU=" - }, - "fast-deep-equal": { - "version": "3.1.3", - "resolved": "https://registry.npmjs.org/fast-deep-equal/-/fast-deep-equal-3.1.3.tgz", - "integrity": "sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==" - }, - "fast-glob": { - "version": "2.2.7", - "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-2.2.7.tgz", - "integrity": "sha512-g1KuQwHOZAmOZMuBtHdxDtju+T2RT8jgCC9aANsbpdiDDTSnjgfuVsIBNKbUeJI3oKMRExcfNDtJl4OhbffMsw==", - "requires": { - "@mrmlnc/readdir-enhanced": "^2.2.1", - "@nodelib/fs.stat": "^1.1.2", - "glob-parent": "^3.1.0", - "is-glob": "^4.0.0", - "merge2": "^1.2.3", - "micromatch": "^3.1.10" - } - }, - "fast-json-stable-stringify": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/fast-json-stable-stringify/-/fast-json-stable-stringify-2.1.0.tgz", - "integrity": "sha512-lhd/wF+Lk98HZoTCtlVraHtfh5XYijIjalXck7saUtuanSDyLMxnHhSXEDJqHxD7msR8D0uCmqlkwjCV8xvwHw==" - }, - "faye-websocket": { - "version": "0.11.3", - "resolved": "https://registry.npmjs.org/faye-websocket/-/faye-websocket-0.11.3.tgz", - "integrity": "sha512-D2y4bovYpzziGgbHYtGCMjlJM36vAl/y+xUyn1C+FVx8szd1E+86KwVw6XvYSzOP8iMpm1X0I4xJD+QtUb36OA==", - "requires": { - "websocket-driver": ">=0.5.1" - } - }, - "figgy-pudding": { - "version": "3.5.2", - "resolved": "https://registry.npmjs.org/figgy-pudding/-/figgy-pudding-3.5.2.tgz", - "integrity": "sha512-0btnI/H8f2pavGMN8w40mlSKOfTK2SVJmBfBeVIj3kNw0swwgzyRq0d5TJVOwodFmtvpPeWPN/MCcfuWF0Ezbw==" - }, - "figures": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/figures/-/figures-3.2.0.tgz", - "integrity": "sha512-yaduQFRKLXYOGgEn6AZau90j3ggSOyiqXU0F9JZfeXYhNa+Jk4X+s45A2zg5jns87GAFa34BBm2kXw4XpNcbdg==", - "requires": { - "escape-string-regexp": "^1.0.5" - } - }, - "file-loader": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/file-loader/-/file-loader-3.0.1.tgz", - "integrity": "sha512-4sNIOXgtH/9WZq4NvlfU3Opn5ynUsqBwSLyM+I7UOwdGigTBYfVVQEwe/msZNX/j4pCJTIM14Fsw66Svo1oVrw==", - "requires": { - "loader-utils": "^1.0.2", - "schema-utils": "^1.0.0" - }, - "dependencies": { - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - } - } - }, - "file-uri-to-path": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/file-uri-to-path/-/file-uri-to-path-1.0.0.tgz", - "integrity": "sha512-0Zt+s3L7Vf1biwWZ29aARiVYLx7iMGnEUl9x33fbB/j3jR81u/O2LbqK+Bm1CDSNDKVtJ/YjwY7TUd5SkeLQLw==", - "optional": true - }, - "fill-range": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-4.0.0.tgz", - "integrity": "sha1-1USBHUKPmOsGpj3EAtJAPDKMOPc=", - "requires": { - "extend-shallow": "^2.0.1", - "is-number": "^3.0.0", - "repeat-string": "^1.6.1", - "to-regex-range": "^2.1.0" - } - }, - "finalhandler": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/finalhandler/-/finalhandler-1.1.2.tgz", - "integrity": "sha512-aAWcW57uxVNrQZqFXjITpW3sIUQmHGG3qSb9mUah9MgMC4NeWhNOlNjXEYq3HjRAvL6arUviZGGJsBg6z0zsWA==", - "requires": { - "debug": "2.6.9", - "encodeurl": "~1.0.2", - "escape-html": "~1.0.3", - "on-finished": "~2.3.0", - "parseurl": "~1.3.3", - "statuses": "~1.5.0", - "unpipe": "~1.0.0" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - } - } - }, - "find-cache-dir": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/find-cache-dir/-/find-cache-dir-3.3.1.tgz", - "integrity": "sha512-t2GDMt3oGC/v+BMwzmllWDuJF/xcDtE5j/fCGbqDD7OLuJkj0cfh1YSA5VKPvwMeLFLNDBkwOKZ2X85jGLVftQ==", - "requires": { - "commondir": "^1.0.1", - "make-dir": "^3.0.2", - "pkg-dir": "^4.1.0" - } - }, - "find-up": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/find-up/-/find-up-4.1.0.tgz", - "integrity": "sha512-PpOwAdQ/YlXQ2vj8a3h8IipDuYRi3wceVQQGYWxNINccq40Anw7BlsEXCMbt1Zt+OLA6Fq9suIpIWD0OsnISlw==", - "requires": { - "locate-path": "^5.0.0", - "path-exists": "^4.0.0" - } - }, - "flush-write-stream": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/flush-write-stream/-/flush-write-stream-1.1.1.tgz", - "integrity": "sha512-3Z4XhFZ3992uIq0XOqb9AreonueSYphE6oYbpt5+3u06JWklbsPkNv3ZKkP9Bz/r+1MWCaMoSQ28P85+1Yc77w==", - "requires": { - "inherits": "^2.0.3", - "readable-stream": "^2.3.6" - } - }, - "follow-redirects": { - "version": "1.5.10", - "resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.5.10.tgz", - "integrity": "sha512-0V5l4Cizzvqt5D44aTXbFZz+FtyXV1vrDN6qrelxtfYQKW0KO0W2T/hkE8xvGa/540LkZlkaUjO4ailYTFtHVQ==", - "requires": { - "debug": "=3.1.0" - } - }, - "for-in": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/for-in/-/for-in-1.0.2.tgz", - "integrity": "sha1-gQaNKVqBQuwKxybG4iAMMPttXoA=" - }, - "foreach": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/foreach/-/foreach-2.0.5.tgz", - "integrity": "sha1-C+4AUBiusmDQo6865ljdATbsG5k=" - }, - "forever-agent": { - "version": "0.6.1", - "resolved": "https://registry.npmjs.org/forever-agent/-/forever-agent-0.6.1.tgz", - "integrity": "sha1-+8cfDEGt6zf5bFd60e1C2P2sypE=" - }, - "form-data": { - "version": "2.3.3", - "resolved": "https://registry.npmjs.org/form-data/-/form-data-2.3.3.tgz", - "integrity": "sha512-1lLKB2Mu3aGP1Q/2eCOx0fNbRMe7XdwktwOruhfqqd0rIJWwN4Dh+E3hrPSlDCXnSR7UtZ1N38rVXm+6+MEhJQ==", - "requires": { - "asynckit": "^0.4.0", - "combined-stream": "^1.0.6", - "mime-types": "^2.1.12" - } - }, - "forwarded": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/forwarded/-/forwarded-0.1.2.tgz", - "integrity": "sha1-mMI9qxF1ZXuMBXPozszZGw/xjIQ=" - }, - "fragment-cache": { - "version": "0.2.1", - "resolved": "https://registry.npmjs.org/fragment-cache/-/fragment-cache-0.2.1.tgz", - "integrity": "sha1-QpD60n8T6Jvn8zeZxrxaCr//DRk=", - "requires": { - "map-cache": "^0.2.2" - } - }, - "fresh": { - "version": "0.5.2", - "resolved": "https://registry.npmjs.org/fresh/-/fresh-0.5.2.tgz", - "integrity": "sha1-PYyt2Q2XZWn6g1qx+OSyOhBWBac=" - }, - "from2": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/from2/-/from2-2.3.0.tgz", - "integrity": "sha1-i/tVAr3kpNNs/e6gB/zKIdfjgq8=", - "requires": { - "inherits": "^2.0.1", - "readable-stream": "^2.0.0" - } - }, - "fs-extra": { - "version": "7.0.1", - "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-7.0.1.tgz", - "integrity": "sha512-YJDaCJZEnBmcbw13fvdAM9AwNOJwOzrE4pqMqBq5nFiEqXUqHwlK4B+3pUw6JNvfSPtX05xFHtYy/1ni01eGCw==", - "requires": { - "graceful-fs": "^4.1.2", - "jsonfile": "^4.0.0", - "universalify": "^0.1.0" - } - }, - "fs-write-stream-atomic": { - "version": "1.0.10", - "resolved": "https://registry.npmjs.org/fs-write-stream-atomic/-/fs-write-stream-atomic-1.0.10.tgz", - "integrity": "sha1-tH31NJPvkR33VzHnCp3tAYnbQMk=", - "requires": { - "graceful-fs": "^4.1.2", - "iferr": "^0.1.5", - "imurmurhash": "^0.1.4", - "readable-stream": "1 || 2" - } - }, - "fs.realpath": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz", - "integrity": "sha1-FQStJSMVjKpA20onh8sBQRmU6k8=" - }, - "fsevents": { - "version": "1.2.13", - "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-1.2.13.tgz", - "integrity": "sha512-oWb1Z6mkHIskLzEJ/XWX0srkpkTQ7vaopMQkyaEIoq0fmtFVxOthb8cCxeT+p3ynTdkk/RZwbgG4brR5BeWECw==", - "optional": true, - "requires": { - "bindings": "^1.5.0", - "nan": "^2.12.1" - } - }, - "function-bind": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/function-bind/-/function-bind-1.1.1.tgz", - "integrity": "sha512-yIovAzMX49sF8Yl58fSCWJ5svSLuaibPxXQJFLmBObTuCr0Mf1KiPopGM9NiFjiYBCbfaa2Fh6breQ6ANVTI0A==" - }, - "fuse.js": { - "version": "3.6.1", - "resolved": "https://registry.npmjs.org/fuse.js/-/fuse.js-3.6.1.tgz", - "integrity": "sha512-hT9yh/tiinkmirKrlv4KWOjztdoZo1mx9Qh4KvWqC7isoXwdUY3PNWUxceF4/qO9R6riA2C29jdTOeQOIROjgw==" - }, - "gensync": { - "version": "1.0.0-beta.2", - "resolved": "https://registry.npmjs.org/gensync/-/gensync-1.0.0-beta.2.tgz", - "integrity": "sha512-3hN7NaskYvMDLQY55gnW3NQ+mesEAepTqlg+VEbj7zzqEMBVNhzcGYYeqFo/TlYz6eQiFcp1HcsCZO+nGgS8zg==" - }, - "get-caller-file": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz", - "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==" - }, - "get-intrinsic": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/get-intrinsic/-/get-intrinsic-1.0.2.tgz", - "integrity": "sha512-aeX0vrFm21ILl3+JpFFRNe9aUvp6VFZb2/CTbgLb8j75kOhvoNYjt9d8KA/tJG4gSo8nzEDedRl0h7vDmBYRVg==", - "requires": { - "function-bind": "^1.1.1", - "has": "^1.0.3", - "has-symbols": "^1.0.1" - } - }, - "get-stream": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/get-stream/-/get-stream-4.1.0.tgz", - "integrity": "sha512-GMat4EJ5161kIy2HevLlr4luNjBgvmj413KaQA7jt4V8B4RDsfpHk7WQ9GVqfYyyx8OS/L66Kox+rJRNklLK7w==", - "requires": { - "pump": "^3.0.0" - } - }, - "get-value": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/get-value/-/get-value-2.0.6.tgz", - "integrity": "sha1-3BXKHGcjh8p2vTesCjlbogQqLCg=" - }, - "getpass": { - "version": "0.1.7", - "resolved": "https://registry.npmjs.org/getpass/-/getpass-0.1.7.tgz", - "integrity": "sha1-Xv+OPmhNVprkyysSgmBOi6YhSfo=", - "requires": { - "assert-plus": "^1.0.0" - } - }, - "glob": { - "version": "7.1.6", - "resolved": "https://registry.npmjs.org/glob/-/glob-7.1.6.tgz", - "integrity": "sha512-LwaxwyZ72Lk7vZINtNNrywX0ZuLyStrdDtabefZKAY5ZGJhVtgdznluResxNmPitE0SAO+O26sWTHeKSI2wMBA==", - "requires": { - "fs.realpath": "^1.0.0", - "inflight": "^1.0.4", - "inherits": "2", - "minimatch": "^3.0.4", - "once": "^1.3.0", - "path-is-absolute": "^1.0.0" - } - }, - "glob-parent": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-3.1.0.tgz", - "integrity": "sha1-nmr2KZ2NO9K9QEMIMr0RPfkGxa4=", - "requires": { - "is-glob": "^3.1.0", - "path-dirname": "^1.0.0" - }, - "dependencies": { - "is-glob": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-3.1.0.tgz", - "integrity": "sha1-e6WuJCF4BKxwcHuWkiVnSGzD6Eo=", - "requires": { - "is-extglob": "^2.1.0" - } - } - } - }, - "glob-to-regexp": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/glob-to-regexp/-/glob-to-regexp-0.3.0.tgz", - "integrity": "sha1-jFoUlNIGbFcMw7/kSWF1rMTVAqs=" - }, - "global": { - "version": "4.4.0", - "resolved": "https://registry.npmjs.org/global/-/global-4.4.0.tgz", - "integrity": "sha512-wv/LAoHdRE3BeTGz53FAamhGlPLhlssK45usmGFThIi4XqnBmjKQ16u+RNbP7WvigRZDxUsM0J3gcQ5yicaL0w==", - "requires": { - "min-document": "^2.19.0", - "process": "^0.11.10" - } - }, - "global-dirs": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/global-dirs/-/global-dirs-2.1.0.tgz", - "integrity": "sha512-MG6kdOUh/xBnyo9cJFeIKkLEc1AyFq42QTU4XiX51i2NEdxLxLWXIjEjmqKeSuKR7pAZjTqUVoT2b2huxVLgYQ==", - "requires": { - "ini": "1.3.7" - } - }, - "globals": { - "version": "11.12.0", - "resolved": "https://registry.npmjs.org/globals/-/globals-11.12.0.tgz", - "integrity": "sha512-WOBp/EEGUiIsJSp7wcv/y6MO+lV9UoncWqxuFfm8eBwzWNgyfBd6Gz+IeKQ9jCmyhoH99g15M3T+QaVHFjizVA==" - }, - "globby": { - "version": "9.2.0", - "resolved": "https://registry.npmjs.org/globby/-/globby-9.2.0.tgz", - "integrity": "sha512-ollPHROa5mcxDEkwg6bPt3QbEf4pDQSNtd6JPL1YvOvAo/7/0VAm9TccUeoTmarjPw4pfUthSCqcyfNB1I3ZSg==", - "requires": { - "@types/glob": "^7.1.1", - "array-union": "^1.0.2", - "dir-glob": "^2.2.2", - "fast-glob": "^2.2.6", - "glob": "^7.1.3", - "ignore": "^4.0.3", - "pify": "^4.0.1", - "slash": "^2.0.0" - } - }, - "good-listener": { - "version": "1.2.2", - "resolved": "https://registry.npmjs.org/good-listener/-/good-listener-1.2.2.tgz", - "integrity": "sha1-1TswzfkxPf+33JoNR3CWqm0UXFA=", - "optional": true, - "requires": { - "delegate": "^3.1.2" - } - }, - "got": { - "version": "9.6.0", - "resolved": "https://registry.npmjs.org/got/-/got-9.6.0.tgz", - "integrity": "sha512-R7eWptXuGYxwijs0eV+v3o6+XH1IqVK8dJOEecQfTmkncw9AV4dcw/Dhxi8MdlqPthxxpZyizMzyg8RTmEsG+Q==", - "requires": { - "@sindresorhus/is": "^0.14.0", - "@szmarczak/http-timer": "^1.1.2", - "cacheable-request": "^6.0.0", - "decompress-response": "^3.3.0", - "duplexer3": "^0.1.4", - "get-stream": "^4.1.0", - "lowercase-keys": "^1.0.1", - "mimic-response": "^1.0.1", - "p-cancelable": "^1.0.0", - "to-readable-stream": "^1.0.0", - "url-parse-lax": "^3.0.0" - } - }, - "graceful-fs": { - "version": "4.2.4", - "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.4.tgz", - "integrity": "sha512-WjKPNJF79dtJAVniUlGGWHYGz2jWxT6VhN/4m1NdkbZ2nOsEF+cI1Edgql5zCRhs/VsQYRvrXctxktVXZUkixw==" - }, - "gray-matter": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/gray-matter/-/gray-matter-4.0.2.tgz", - "integrity": "sha512-7hB/+LxrOjq/dd8APlK0r24uL/67w7SkYnfwhNFwg/VDIGWGmduTDYf3WNstLW2fbbmRwrDGCVSJ2isuf2+4Hw==", - "requires": { - "js-yaml": "^3.11.0", - "kind-of": "^6.0.2", - "section-matter": "^1.0.0", - "strip-bom-string": "^1.0.0" - } - }, - "handle-thing": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/handle-thing/-/handle-thing-2.0.1.tgz", - "integrity": "sha512-9Qn4yBxelxoh2Ow62nP+Ka/kMnOXRi8BXnRaUwezLNhqelnN49xKz4F/dPP8OYLxLxq6JDtZb2i9XznUQbNPTg==" - }, - "har-schema": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/har-schema/-/har-schema-2.0.0.tgz", - "integrity": "sha1-qUwiJOvKwEeCoNkDVSHyRzW37JI=" - }, - "har-validator": { - "version": "5.1.5", - "resolved": "https://registry.npmjs.org/har-validator/-/har-validator-5.1.5.tgz", - "integrity": "sha512-nmT2T0lljbxdQZfspsno9hgrG3Uir6Ks5afism62poxqBM6sDnMEuPmzTq8XN0OEwqKLLdh1jQI3qyE66Nzb3w==", - "requires": { - "ajv": "^6.12.3", - "har-schema": "^2.0.0" - } - }, - "has": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/has/-/has-1.0.3.tgz", - "integrity": "sha512-f2dvO0VU6Oej7RkWJGrehjbzMAjFp5/VKPp5tTpWIV4JHHZK1/BxbFRtf/siA2SWTe09caDmVtYYzWEIbBS4zw==", - "requires": { - "function-bind": "^1.1.1" - } - }, - "has-ansi": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/has-ansi/-/has-ansi-2.0.0.tgz", - "integrity": "sha1-NPUEnOHs3ysGSa8+8k5F7TVBbZE=", - "requires": { - "ansi-regex": "^2.0.0" - } - }, - "has-flag": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-3.0.0.tgz", - "integrity": "sha1-tdRU3CGZriJWmfNGfloH87lVuv0=" - }, - "has-symbols": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/has-symbols/-/has-symbols-1.0.1.tgz", - "integrity": "sha512-PLcsoqu++dmEIZB+6totNFKq/7Do+Z0u4oT0zKOJNl3lYK6vGwwu2hjHs+68OEZbTjiUE9bgOABXbP/GvrS0Kg==" - }, - "has-value": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/has-value/-/has-value-1.0.0.tgz", - "integrity": "sha1-GLKB2lhbHFxR3vJMkw7SmgvmsXc=", - "requires": { - "get-value": "^2.0.6", - "has-values": "^1.0.0", - "isobject": "^3.0.0" - } - }, - "has-values": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/has-values/-/has-values-1.0.0.tgz", - "integrity": "sha1-lbC2P+whRmGab+V/51Yo1aOe/k8=", - "requires": { - "is-number": "^3.0.0", - "kind-of": "^4.0.0" - }, - "dependencies": { - "kind-of": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-4.0.0.tgz", - "integrity": "sha1-IIE989cSkosgc3hpGkUGb65y3Vc=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "has-yarn": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/has-yarn/-/has-yarn-2.1.0.tgz", - "integrity": "sha512-UqBRqi4ju7T+TqGNdqAO0PaSVGsDGJUBQvk9eUWNGRY1CFGDzYhLWoM7JQEemnlvVcv/YEmc2wNW8BC24EnUsw==" - }, - "hash-base": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/hash-base/-/hash-base-3.1.0.tgz", - "integrity": "sha512-1nmYp/rhMDiE7AYkDw+lLwlAzz0AntGIe51F3RfFfEqyQ3feY2eI/NcwC6umIQVOASPMsWJLJScWKSSvzL9IVA==", - "requires": { - "inherits": "^2.0.4", - "readable-stream": "^3.6.0", - "safe-buffer": "^5.2.0" - }, - "dependencies": { - "readable-stream": { - "version": "3.6.0", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.0.tgz", - "integrity": "sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==", - "requires": { - "inherits": "^2.0.3", - "string_decoder": "^1.1.1", - "util-deprecate": "^1.0.1" - } - }, - "safe-buffer": { - "version": "5.2.1", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz", - "integrity": "sha512-rp3So07KcdmmKbGvgaNxQSJr7bGVSVk5S9Eq1F+ppbRo70+YeaDxkw5Dd8NPN+GD6bjnYm2VuPuCXmpuYvmCXQ==" - } - } - }, - "hash-sum": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/hash-sum/-/hash-sum-1.0.2.tgz", - "integrity": "sha1-M7QHd3VMZDJXPBIMw4CLvRDUfwQ=" - }, - "hash.js": { - "version": "1.1.7", - "resolved": "https://registry.npmjs.org/hash.js/-/hash.js-1.1.7.tgz", - "integrity": "sha512-taOaskGt4z4SOANNseOviYDvjEJinIkRgmp7LbKP2YTTmVxWBl87s/uzK9r+44BclBSp2X7K1hqeNfz9JbBeXA==", - "requires": { - "inherits": "^2.0.3", - "minimalistic-assert": "^1.0.1" - } - }, - "he": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/he/-/he-1.2.0.tgz", - "integrity": "sha512-F/1DnUGPopORZi0ni+CvrCgHQ5FyEAHRLSApuYWMmrbSwoN2Mn/7k+Gl38gJnR7yyDZk6WLXwiGod1JOWNDKGw==" - }, - "hex-color-regex": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/hex-color-regex/-/hex-color-regex-1.1.0.tgz", - "integrity": "sha512-l9sfDFsuqtOqKDsQdqrMRk0U85RZc0RtOR9yPI7mRVOa4FsR/BVnZ0shmQRM96Ji99kYZP/7hn1cedc1+ApsTQ==" - }, - "hmac-drbg": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/hmac-drbg/-/hmac-drbg-1.0.1.tgz", - "integrity": "sha1-0nRXAQJabHdabFRXk+1QL8DGSaE=", - "requires": { - "hash.js": "^1.0.3", - "minimalistic-assert": "^1.0.0", - "minimalistic-crypto-utils": "^1.0.1" - } - }, - "hogan.js": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/hogan.js/-/hogan.js-3.0.2.tgz", - "integrity": "sha1-TNnhq9QpQUbnZ55B14mHMrAse/0=", - "requires": { - "mkdirp": "0.3.0", - "nopt": "1.0.10" - }, - "dependencies": { - "mkdirp": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.3.0.tgz", - "integrity": "sha1-G79asbqCevI1dRQ0kEJkVfSB/h4=" - } - } - }, - "hotkeys-js": { - "version": "3.8.1", - "resolved": "https://registry.npmjs.org/hotkeys-js/-/hotkeys-js-3.8.1.tgz", - "integrity": "sha512-YlhVQtyG9f1b7GhtzdhR0Pl+cImD1ZrKI6zYUa7QLd0zuThiL7RzZ+ANJyy7z+kmcCpNYBf5PjBa3CjiQ5PFpw==" - }, - "hpack.js": { - "version": "2.1.6", - "resolved": "https://registry.npmjs.org/hpack.js/-/hpack.js-2.1.6.tgz", - "integrity": "sha1-h3dMCUnlE/QuhFdbPEVoH63ioLI=", - "requires": { - "inherits": "^2.0.1", - "obuf": "^1.0.0", - "readable-stream": "^2.0.1", - "wbuf": "^1.1.0" - } - }, - "hsl-regex": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/hsl-regex/-/hsl-regex-1.0.0.tgz", - "integrity": "sha1-1JMwx4ntgZ4nakwNJy3/owsY/m4=" - }, - "hsla-regex": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/hsla-regex/-/hsla-regex-1.0.0.tgz", - "integrity": "sha1-wc56MWjIxmFAM6S194d/OyJfnDg=" - }, - "html-comment-regex": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/html-comment-regex/-/html-comment-regex-1.1.2.tgz", - "integrity": "sha512-P+M65QY2JQ5Y0G9KKdlDpo0zK+/OHptU5AaBwUfAIDJZk1MYf32Frm84EcOytfJE0t5JvkAnKlmjsXDnWzCJmQ==" - }, - "html-entities": { - "version": "1.4.0", - "resolved": "https://registry.npmjs.org/html-entities/-/html-entities-1.4.0.tgz", - "integrity": "sha512-8nxjcBcd8wovbeKx7h3wTji4e6+rhaVuPNpMqwWgnHh+N9ToqsCs6XztWRBPQ+UtzsoMAdKZtUENoVzU/EMtZA==" - }, - "html-minifier": { - "version": "3.5.21", - "resolved": "https://registry.npmjs.org/html-minifier/-/html-minifier-3.5.21.tgz", - "integrity": "sha512-LKUKwuJDhxNa3uf/LPR/KVjm/l3rBqtYeCOAekvG8F1vItxMUpueGd94i/asDDr8/1u7InxzFA5EeGjhhG5mMA==", - "requires": { - "camel-case": "3.0.x", - "clean-css": "4.2.x", - "commander": "2.17.x", - "he": "1.2.x", - "param-case": "2.1.x", - "relateurl": "0.2.x", - "uglify-js": "3.4.x" - }, - "dependencies": { - "uglify-js": { - "version": "3.4.10", - "resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-3.4.10.tgz", - "integrity": "sha512-Y2VsbPVs0FIshJztycsO2SfPk7/KAF/T72qzv9u5EpQ4kB2hQoHlhNQTsNyy6ul7lQtqJN/AoWeS23OzEiEFxw==", - "requires": { - "commander": "~2.19.0", - "source-map": "~0.6.1" - }, - "dependencies": { - "commander": { - "version": "2.19.0", - "resolved": "https://registry.npmjs.org/commander/-/commander-2.19.0.tgz", - "integrity": "sha512-6tvAOO+D6OENvRAh524Dh9jcfKTYDQAqvqezbCW82xj5X0pSrcpxtvRKHLG0yBY6SD7PSDrJaj+0AiOcKVd1Xg==" - } - } - } - } - }, - "html-tags": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/html-tags/-/html-tags-3.1.0.tgz", - "integrity": "sha512-1qYz89hW3lFDEazhjW0yVAV87lw8lVkrJocr72XmBkMKsoSVJCQx3W8BXsC7hO2qAt8BoVjYjtAcZ9perqGnNg==" - }, - "htmlparser2": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-6.0.0.tgz", - "integrity": "sha512-numTQtDZMoh78zJpaNdJ9MXb2cv5G3jwUoe3dMQODubZvLoGvTE/Ofp6sHvH8OGKcN/8A47pGLi/k58xHP/Tfw==", - "requires": { - "domelementtype": "^2.0.1", - "domhandler": "^4.0.0", - "domutils": "^2.4.4", - "entities": "^2.0.0" - } - }, - "http-cache-semantics": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/http-cache-semantics/-/http-cache-semantics-4.1.0.tgz", - "integrity": "sha512-carPklcUh7ROWRK7Cv27RPtdhYhUsela/ue5/jKzjegVvXDqM2ILE9Q2BGn9JZJh1g87cp56su/FgQSzcWS8cQ==" - }, - "http-deceiver": { - "version": "1.2.7", - "resolved": "https://registry.npmjs.org/http-deceiver/-/http-deceiver-1.2.7.tgz", - "integrity": "sha1-+nFolEq5pRnTN8sL7HKE3D5yPYc=" - }, - "http-errors": { - "version": "1.7.2", - "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.7.2.tgz", - "integrity": "sha512-uUQBt3H/cSIVfch6i1EuPNy/YsRSOUBXTVfZ+yR7Zjez3qjBz6i9+i4zjNaoqcoFVI4lQJ5plg63TvGfRSDCRg==", - "requires": { - "depd": "~1.1.2", - "inherits": "2.0.3", - "setprototypeof": "1.1.1", - "statuses": ">= 1.5.0 < 2", - "toidentifier": "1.0.0" - }, - "dependencies": { - "inherits": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz", - "integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=" - } - } - }, - "http-parser-js": { - "version": "0.5.3", - "resolved": "https://registry.npmjs.org/http-parser-js/-/http-parser-js-0.5.3.tgz", - "integrity": "sha512-t7hjvef/5HEK7RWTdUzVUhl8zkEu+LlaE0IYzdMuvbSDipxBRpOn4Uhw8ZyECEa808iVT8XCjzo6xmYt4CiLZg==" - }, - "http-proxy": { - "version": "1.18.1", - "resolved": "https://registry.npmjs.org/http-proxy/-/http-proxy-1.18.1.tgz", - "integrity": "sha512-7mz/721AbnJwIVbnaSv1Cz3Am0ZLT/UBwkC92VlxhXv/k/BBQfM2fXElQNC27BVGr0uwUpplYPQM9LnaBMR5NQ==", - "requires": { - "eventemitter3": "^4.0.0", - "follow-redirects": "^1.0.0", - "requires-port": "^1.0.0" - } - }, - "http-proxy-middleware": { - "version": "0.19.1", - "resolved": "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-0.19.1.tgz", - "integrity": "sha512-yHYTgWMQO8VvwNS22eLLloAkvungsKdKTLO8AJlftYIKNfJr3GK3zK0ZCfzDDGUBttdGc8xFy1mCitvNKQtC3Q==", - "requires": { - "http-proxy": "^1.17.0", - "is-glob": "^4.0.0", - "lodash": "^4.17.11", - "micromatch": "^3.1.10" - } - }, - "http-signature": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/http-signature/-/http-signature-1.2.0.tgz", - "integrity": "sha1-muzZJRFHcvPZW2WmCruPfBj7rOE=", - "requires": { - "assert-plus": "^1.0.0", - "jsprim": "^1.2.2", - "sshpk": "^1.7.0" - } - }, - "https-browserify": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/https-browserify/-/https-browserify-1.0.0.tgz", - "integrity": "sha1-7AbBDgo0wPL68Zn3/X/Hj//QPHM=" - }, - "iconv-lite": { - "version": "0.4.24", - "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.24.tgz", - "integrity": "sha512-v3MXnZAcvnywkTUEZomIActle7RXXeedOR31wwl7VlyoXO4Qi9arvSenNQWne1TcRwhCL1HwLI21bEqdpj8/rA==", - "requires": { - "safer-buffer": ">= 2.1.2 < 3" - } - }, - "icss-replace-symbols": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/icss-replace-symbols/-/icss-replace-symbols-1.1.0.tgz", - "integrity": "sha1-Bupvg2ead0njhs/h/oEq5dsiPe0=" - }, - "icss-utils": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/icss-utils/-/icss-utils-4.1.1.tgz", - "integrity": "sha512-4aFq7wvWyMHKgxsH8QQtGpvbASCf+eM3wPRLI6R+MgAnTCZ6STYsRvttLvRWK0Nfif5piF394St3HeJDaljGPA==", - "requires": { - "postcss": "^7.0.14" - } - }, - "ieee754": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.2.1.tgz", - "integrity": "sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==" - }, - "iferr": { - "version": "0.1.5", - "resolved": "https://registry.npmjs.org/iferr/-/iferr-0.1.5.tgz", - "integrity": "sha1-xg7taebY/bazEEofy8ocGS3FtQE=" - }, - "ignore": { - "version": "4.0.6", - "resolved": "https://registry.npmjs.org/ignore/-/ignore-4.0.6.tgz", - "integrity": "sha512-cyFDKrqc/YdcWFniJhzI42+AzS+gNwmUzOSFcRCQYwySuBBBy/KjuxWLZ/FHEH6Moq1NizMOBWyTcv8O4OZIMg==" - }, - "immediate": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/immediate/-/immediate-3.3.0.tgz", - "integrity": "sha512-HR7EVodfFUdQCTIeySw+WDRFJlPcLOJbXfwwZ7Oom6tjsvZ3bOkCDJHehQC3nxJrv7+f9XecwazynjU8e4Vw3Q==" - }, - "import-cwd": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/import-cwd/-/import-cwd-2.1.0.tgz", - "integrity": "sha1-qmzzbnInYShcs3HsZRn1PiQ1sKk=", - "requires": { - "import-from": "^2.1.0" - } - }, - "import-fresh": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/import-fresh/-/import-fresh-2.0.0.tgz", - "integrity": "sha1-2BNVwVYS04bGH53dOSLUMEgipUY=", - "requires": { - "caller-path": "^2.0.0", - "resolve-from": "^3.0.0" - } - }, - "import-from": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/import-from/-/import-from-2.1.0.tgz", - "integrity": "sha1-M1238qev/VOqpHHUuAId7ja387E=", - "requires": { - "resolve-from": "^3.0.0" - } - }, - "import-lazy": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/import-lazy/-/import-lazy-2.1.0.tgz", - "integrity": "sha1-BWmOPUXIjo1+nZLLBYTnfwlvPkM=" - }, - "import-local": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/import-local/-/import-local-2.0.0.tgz", - "integrity": "sha512-b6s04m3O+s3CGSbqDIyP4R6aAwAeYlVq9+WUWep6iHa8ETRf9yei1U48C5MmfJmV9AiLYYBKPMq/W+/WRpQmCQ==", - "requires": { - "pkg-dir": "^3.0.0", - "resolve-cwd": "^2.0.0" - }, - "dependencies": { - "find-up": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/find-up/-/find-up-3.0.0.tgz", - "integrity": "sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==", - "requires": { - "locate-path": "^3.0.0" - } - }, - "locate-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-3.0.0.tgz", - "integrity": "sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==", - "requires": { - "p-locate": "^3.0.0", - "path-exists": "^3.0.0" - } - }, - "p-locate": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-3.0.0.tgz", - "integrity": "sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==", - "requires": { - "p-limit": "^2.0.0" - } - }, - "path-exists": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-3.0.0.tgz", - "integrity": "sha1-zg6+ql94yxiSXqfYENe1mwEP1RU=" - }, - "pkg-dir": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-3.0.0.tgz", - "integrity": "sha512-/E57AYkoeQ25qkxMj5PBOVgF8Kiu/h7cYS30Z5+R7WaiCCBfLq58ZI/dSeaEKb9WVJV5n/03QwrN3IeWIFllvw==", - "requires": { - "find-up": "^3.0.0" - } - } - } - }, - "imurmurhash": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/imurmurhash/-/imurmurhash-0.1.4.tgz", - "integrity": "sha1-khi5srkoojixPcT7a21XbyMUU+o=" - }, - "indexes-of": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/indexes-of/-/indexes-of-1.0.1.tgz", - "integrity": "sha1-8w9xbI4r00bHtn0985FVZqfAVgc=" - }, - "infer-owner": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/infer-owner/-/infer-owner-1.0.4.tgz", - "integrity": "sha512-IClj+Xz94+d7irH5qRyfJonOdfTzuDaifE6ZPWfx0N0+/ATZCbuTPq2prFl526urkQd90WyUKIh1DfBQ2hMz9A==" - }, - "inflight": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz", - "integrity": "sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=", - "requires": { - "once": "^1.3.0", - "wrappy": "1" - } - }, - "inherits": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.4.tgz", - "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==" - }, - "ini": { - "version": "1.3.7", - "resolved": "https://registry.npmjs.org/ini/-/ini-1.3.7.tgz", - "integrity": "sha512-iKpRpXP+CrP2jyrxvg1kMUpXDyRUFDWurxbnVT1vQPx+Wz9uCYsMIqYuSBLV+PAaZG/d7kRLKRFc9oDMsH+mFQ==" - }, - "internal-ip": { - "version": "4.3.0", - "resolved": "https://registry.npmjs.org/internal-ip/-/internal-ip-4.3.0.tgz", - "integrity": "sha512-S1zBo1D6zcsyuC6PMmY5+55YMILQ9av8lotMx447Bq6SAgo/sDK6y6uUKmuYhW7eacnIhFfsPmCNYdDzsnnDCg==", - "requires": { - "default-gateway": "^4.2.0", - "ipaddr.js": "^1.9.0" - } - }, - "ip": { - "version": "1.1.5", - "resolved": "https://registry.npmjs.org/ip/-/ip-1.1.5.tgz", - "integrity": "sha1-vd7XARQpCCjAoDnnLvJfWq7ENUo=" - }, - "ip-regex": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/ip-regex/-/ip-regex-2.1.0.tgz", - "integrity": "sha1-+ni/XS5pE8kRzp+BnuUUa7bYROk=" - }, - "ipaddr.js": { - "version": "1.9.1", - "resolved": "https://registry.npmjs.org/ipaddr.js/-/ipaddr.js-1.9.1.tgz", - "integrity": "sha512-0KI/607xoxSToH7GjN1FfSbLoU0+btTicjsQSWQlh/hZykN8KpmMf7uYwPW3R+akZ6R/w18ZlXSHBYXiYUPO3g==" - }, - "is-absolute-url": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/is-absolute-url/-/is-absolute-url-2.1.0.tgz", - "integrity": "sha1-UFMN+4T8yap9vnhS6Do3uTufKqY=" - }, - "is-accessor-descriptor": { - "version": "0.1.6", - "resolved": "https://registry.npmjs.org/is-accessor-descriptor/-/is-accessor-descriptor-0.1.6.tgz", - "integrity": "sha1-qeEss66Nh2cn7u84Q/igiXtcmNY=", - "requires": { - "kind-of": "^3.0.2" - }, - "dependencies": { - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "is-arguments": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/is-arguments/-/is-arguments-1.1.0.tgz", - "integrity": "sha512-1Ij4lOMPl/xB5kBDn7I+b2ttPMKa8szhEIrXDuXQD/oe3HJLTLhqhgGspwgyGd6MOywBUqVvYicF72lkgDnIHg==", - "requires": { - "call-bind": "^1.0.0" - } - }, - "is-arrayish": { - "version": "0.2.1", - "resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.2.1.tgz", - "integrity": "sha1-d8mYQFJ6qOyxqLppe4BkWnqSap0=" - }, - "is-binary-path": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-1.0.1.tgz", - "integrity": "sha1-dfFmQrSA8YenEcgUFh/TpKdlWJg=", - "requires": { - "binary-extensions": "^1.0.0" - } - }, - "is-buffer": { - "version": "1.1.6", - "resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-1.1.6.tgz", - "integrity": "sha512-NcdALwpXkTm5Zvvbk7owOUSvVvBKDgKP5/ewfXEznmQFfs4ZRmanOeKBTjRVjka3QFoN6XJ+9F3USqfHqTaU5w==" - }, - "is-callable": { - "version": "1.2.2", - "resolved": "https://registry.npmjs.org/is-callable/-/is-callable-1.2.2.tgz", - "integrity": "sha512-dnMqspv5nU3LoewK2N/y7KLtxtakvTuaCsU9FU50/QDmdbHNy/4/JuRtMHqRU22o3q+W89YQndQEeCVwK+3qrA==" - }, - "is-ci": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/is-ci/-/is-ci-2.0.0.tgz", - "integrity": "sha512-YfJT7rkpQB0updsdHLGWrvhBJfcfzNNawYDNIyQXJz0IViGf75O8EBPKSdvw2rF+LGCsX4FZ8tcr3b19LcZq4w==", - "requires": { - "ci-info": "^2.0.0" - }, - "dependencies": { - "ci-info": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/ci-info/-/ci-info-2.0.0.tgz", - "integrity": "sha512-5tK7EtrZ0N+OLFMthtqOj4fI2Jeb88C4CAZPu25LDVUgXJ0A3Js4PMGqrn0JU1W0Mh1/Z8wZzYPxqUrXeBboCQ==" - } - } - }, - "is-color-stop": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/is-color-stop/-/is-color-stop-1.1.0.tgz", - "integrity": "sha1-z/9HGu5N1cnhWFmPvhKWe1za00U=", - "requires": { - "css-color-names": "^0.0.4", - "hex-color-regex": "^1.1.0", - "hsl-regex": "^1.0.0", - "hsla-regex": "^1.0.0", - "rgb-regex": "^1.0.1", - "rgba-regex": "^1.0.0" - } - }, - "is-core-module": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/is-core-module/-/is-core-module-2.2.0.tgz", - "integrity": "sha512-XRAfAdyyY5F5cOXn7hYQDqh2Xmii+DEfIcQGxK/uNwMHhIkPWO0g8msXcbzLe+MpGoR951MlqM/2iIlU4vKDdQ==", - "requires": { - "has": "^1.0.3" - } - }, - "is-data-descriptor": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/is-data-descriptor/-/is-data-descriptor-0.1.4.tgz", - "integrity": "sha1-C17mSDiOLIYCgueT8YVv7D8wG1Y=", - "requires": { - "kind-of": "^3.0.2" - }, - "dependencies": { - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "is-date-object": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-date-object/-/is-date-object-1.0.2.tgz", - "integrity": "sha512-USlDT524woQ08aoZFzh3/Z6ch9Y/EWXEHQ/AaRN0SkKq4t2Jw2R2339tSXmwuVoY7LLlBCbOIlx2myP/L5zk0g==" - }, - "is-descriptor": { - "version": "0.1.6", - "resolved": "https://registry.npmjs.org/is-descriptor/-/is-descriptor-0.1.6.tgz", - "integrity": "sha512-avDYr0SB3DwO9zsMov0gKCESFYqCnE4hq/4z3TdUlukEy5t9C0YRq7HLrsN52NAcqXKaepeCD0n+B0arnVG3Hg==", - "requires": { - "is-accessor-descriptor": "^0.1.6", - "is-data-descriptor": "^0.1.4", - "kind-of": "^5.0.0" - }, - "dependencies": { - "kind-of": { - "version": "5.1.0", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-5.1.0.tgz", - "integrity": "sha512-NGEErnH6F2vUuXDh+OlbcKW7/wOcfdRHaZ7VWtqCztfHri/++YKmP51OdWeGPuqCOba6kk2OTe5d02VmTB80Pw==" - } - } - }, - "is-directory": { - "version": "0.3.1", - "resolved": "https://registry.npmjs.org/is-directory/-/is-directory-0.3.1.tgz", - "integrity": "sha1-YTObbyR1/Hcv2cnYP1yFddwVSuE=" - }, - "is-expression": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/is-expression/-/is-expression-3.0.0.tgz", - "integrity": "sha1-Oayqa+f9HzRx3ELHQW5hwkMXrJ8=", - "requires": { - "acorn": "~4.0.2", - "object-assign": "^4.0.1" - }, - "dependencies": { - "acorn": { - "version": "4.0.13", - "resolved": "https://registry.npmjs.org/acorn/-/acorn-4.0.13.tgz", - "integrity": "sha1-EFSVrlNh1pe9GVyCUZLhrX8lN4c=" - } - } - }, - "is-extendable": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-0.1.1.tgz", - "integrity": "sha1-YrEQ4omkcUGOPsNqYX1HLjAd/Ik=" - }, - "is-extglob": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz", - "integrity": "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=" - }, - "is-fullwidth-code-point": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz", - "integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8=" - }, - "is-glob": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.1.tgz", - "integrity": "sha512-5G0tKtBTFImOqDnLB2hG6Bp2qcKEFduo4tZu9MT/H6NQv/ghhy30o55ufafxJ/LdH79LLs2Kfrn85TLKyA7BUg==", - "requires": { - "is-extglob": "^2.1.1" - } - }, - "is-installed-globally": { - "version": "0.3.2", - "resolved": "https://registry.npmjs.org/is-installed-globally/-/is-installed-globally-0.3.2.tgz", - "integrity": "sha512-wZ8x1js7Ia0kecP/CHM/3ABkAmujX7WPvQk6uu3Fly/Mk44pySulQpnHG46OMjHGXApINnV4QhY3SWnECO2z5g==", - "requires": { - "global-dirs": "^2.0.1", - "is-path-inside": "^3.0.1" - }, - "dependencies": { - "is-path-inside": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/is-path-inside/-/is-path-inside-3.0.2.tgz", - "integrity": "sha512-/2UGPSgmtqwo1ktx8NDHjuPwZWmHhO+gj0f93EkhLB5RgW9RZevWYYlIkS6zePc6U2WpOdQYIwHe9YC4DWEBVg==" - } - } - }, - "is-negative-zero": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/is-negative-zero/-/is-negative-zero-2.0.1.tgz", - "integrity": "sha512-2z6JzQvZRa9A2Y7xC6dQQm4FSTSTNWjKIYYTt4246eMTJmIo0Q+ZyOsU66X8lxK1AbB92dFeglPLrhwpeRKO6w==" - }, - "is-npm": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/is-npm/-/is-npm-4.0.0.tgz", - "integrity": "sha512-96ECIfh9xtDDlPylNPXhzjsykHsMJZ18ASpaWzQyBr4YRTcVjUvzaHayDAES2oU/3KpljhHUjtSRNiDwi0F0ig==" - }, - "is-number": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/is-number/-/is-number-3.0.0.tgz", - "integrity": "sha1-JP1iAaR4LPUFYcgQJ2r8fRLXEZU=", - "requires": { - "kind-of": "^3.0.2" - }, - "dependencies": { - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "is-obj": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/is-obj/-/is-obj-2.0.0.tgz", - "integrity": "sha512-drqDG3cbczxxEJRoOXcOjtdp1J/lyp1mNn0xaznRs8+muBhgQcrnbspox5X5fOw0HnMnbfDzvnEMEtqDEJEo8w==" - }, - "is-path-cwd": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/is-path-cwd/-/is-path-cwd-2.2.0.tgz", - "integrity": "sha512-w942bTcih8fdJPJmQHFzkS76NEP8Kzzvmw92cXsazb8intwLqPibPPdXf4ANdKV3rYMuuQYGIWtvz9JilB3NFQ==" - }, - "is-path-in-cwd": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/is-path-in-cwd/-/is-path-in-cwd-2.1.0.tgz", - "integrity": "sha512-rNocXHgipO+rvnP6dk3zI20RpOtrAM/kzbB258Uw5BWr3TpXi861yzjo16Dn4hUox07iw5AyeMLHWsujkjzvRQ==", - "requires": { - "is-path-inside": "^2.1.0" - } - }, - "is-path-inside": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/is-path-inside/-/is-path-inside-2.1.0.tgz", - "integrity": "sha512-wiyhTzfDWsvwAW53OBWF5zuvaOGlZ6PwYxAbPVDhpm+gM09xKQGjBq/8uYN12aDvMxnAnq3dxTyoSoRNmg5YFg==", - "requires": { - "path-is-inside": "^1.0.2" - } - }, - "is-plain-obj": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/is-plain-obj/-/is-plain-obj-1.1.0.tgz", - "integrity": "sha1-caUMhCnfync8kqOQpKA7OfzVHT4=" - }, - "is-plain-object": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/is-plain-object/-/is-plain-object-2.0.4.tgz", - "integrity": "sha512-h5PpgXkWitc38BBMYawTYMWJHFZJVnBquFE57xFpjB8pJFiF6gZ+bU+WyI/yqXiFR5mdLsgYNaPe8uao6Uv9Og==", - "requires": { - "isobject": "^3.0.1" - } - }, - "is-promise": { - "version": "2.2.2", - "resolved": "https://registry.npmjs.org/is-promise/-/is-promise-2.2.2.tgz", - "integrity": "sha512-+lP4/6lKUBfQjZ2pdxThZvLUAafmZb8OAxFb8XXtiQmS35INgr85hdOGoEs124ez1FCnZJt6jau/T+alh58QFQ==" - }, - "is-regex": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/is-regex/-/is-regex-1.1.1.tgz", - "integrity": "sha512-1+QkEcxiLlB7VEyFtyBg94e08OAsvq7FUBgApTq/w2ymCLyKJgDPsybBENVtA7XCQEgEXxKPonG+mvYRxh/LIg==", - "requires": { - "has-symbols": "^1.0.1" - } - }, - "is-resolvable": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/is-resolvable/-/is-resolvable-1.1.0.tgz", - "integrity": "sha512-qgDYXFSR5WvEfuS5dMj6oTMEbrrSaM0CrFk2Yiq/gXnBvD9pMa2jGXxyhGLfvhZpuMZe18CJpFxAt3CRs42NMg==" - }, - "is-stream": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/is-stream/-/is-stream-1.1.0.tgz", - "integrity": "sha1-EtSj3U5o4Lec6428hBc66A2RykQ=" - }, - "is-svg": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/is-svg/-/is-svg-3.0.0.tgz", - "integrity": "sha512-gi4iHK53LR2ujhLVVj+37Ykh9GLqYHX6JOVXbLAucaG/Cqw9xwdFOjDM2qeifLs1sF1npXXFvDu0r5HNgCMrzQ==", - "requires": { - "html-comment-regex": "^1.1.0" - } - }, - "is-symbol": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/is-symbol/-/is-symbol-1.0.3.tgz", - "integrity": "sha512-OwijhaRSgqvhm/0ZdAcXNZt9lYdKFpcRDT5ULUuYXPoT794UNOdU+gpT6Rzo7b4V2HUl/op6GqY894AZwv9faQ==", - "requires": { - "has-symbols": "^1.0.1" - } - }, - "is-typedarray": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-typedarray/-/is-typedarray-1.0.0.tgz", - "integrity": "sha1-5HnICFjfDBsR3dppQPlgEfzaSpo=" - }, - "is-windows": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-windows/-/is-windows-1.0.2.tgz", - "integrity": "sha512-eXK1UInq2bPmjyX6e3VHIzMLobc4J94i4AWn+Hpq3OU5KkrRC96OAcR3PRJ/pGu6m8TRnBHP9dkXQVsT/COVIA==" - }, - "is-wsl": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/is-wsl/-/is-wsl-1.1.0.tgz", - "integrity": "sha1-HxbkqiKwTRM2tmGIpmrzxgDDpm0=" - }, - "is-yarn-global": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/is-yarn-global/-/is-yarn-global-0.3.0.tgz", - "integrity": "sha512-VjSeb/lHmkoyd8ryPVIKvOCn4D1koMqY+vqyjjUfc3xyKtP4dYOxM44sZrnqQSzSds3xyOrUTLTC9LVCVgLngw==" - }, - "isarray": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/isarray/-/isarray-1.0.0.tgz", - "integrity": "sha1-u5NdSFgsuhaMBoNJV6VKPgcSTxE=" - }, - "isexe": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz", - "integrity": "sha1-6PvzdNxVb/iUehDcsFctYz8s+hA=" - }, - "isobject": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/isobject/-/isobject-3.0.1.tgz", - "integrity": "sha1-TkMekrEalzFjaqH5yNHMvP2reN8=" - }, - "isstream": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/isstream/-/isstream-0.1.2.tgz", - "integrity": "sha1-R+Y/evVa+m+S4VAOaQ64uFKcCZo=" - }, - "javascript-stringify": { - "version": "1.6.0", - "resolved": "https://registry.npmjs.org/javascript-stringify/-/javascript-stringify-1.6.0.tgz", - "integrity": "sha1-FC0RHzpuPa6PSpr9d9RYVbWpzOM=" - }, - "js-base64": { - "version": "2.6.4", - "resolved": "https://registry.npmjs.org/js-base64/-/js-base64-2.6.4.tgz", - "integrity": "sha512-pZe//GGmwJndub7ZghVHz7vjb2LgC1m8B07Au3eYqeqv9emhESByMXxaEgkUkEqJe87oBbSniGYoQNIBklc7IQ==" - }, - "js-stringify": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/js-stringify/-/js-stringify-1.0.2.tgz", - "integrity": "sha1-Fzb939lyTyijaCrcYjCufk6Weds=" - }, - "js-tokens": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/js-tokens/-/js-tokens-4.0.0.tgz", - "integrity": "sha512-RdJUflcE3cUzKiMqQgsCu06FPu9UdIJO0beYbPhHN4k6apgJtifcoCtT9bcxOpYBtpD2kCM6Sbzg4CausW/PKQ==" - }, - "js-yaml": { - "version": "3.14.1", - "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.1.tgz", - "integrity": "sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g==", - "requires": { - "argparse": "^1.0.7", - "esprima": "^4.0.0" - } - }, - "jsbn": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/jsbn/-/jsbn-0.1.1.tgz", - "integrity": "sha1-peZUwuWi3rXyAdls77yoDA7y9RM=" - }, - "jsesc": { - "version": "2.5.2", - "resolved": "https://registry.npmjs.org/jsesc/-/jsesc-2.5.2.tgz", - "integrity": "sha512-OYu7XEzjkCQ3C5Ps3QIZsQfNpqoJyZZA99wd9aWd05NCtC5pWOkShK2mkL6HXQR6/Cy2lbNdPlZBpuQHXE63gA==" - }, - "json-buffer": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/json-buffer/-/json-buffer-3.0.0.tgz", - "integrity": "sha1-Wx85evx11ne96Lz8Dkfh+aPZqJg=" - }, - "json-parse-better-errors": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/json-parse-better-errors/-/json-parse-better-errors-1.0.2.tgz", - "integrity": "sha512-mrqyZKfX5EhL7hvqcV6WG1yYjnjeuYDzDhhcAAUrq8Po85NBQBJP+ZDUT75qZQ98IkUoBqdkExkukOU7Ts2wrw==" - }, - "json-schema": { - "version": "0.2.3", - "resolved": "https://registry.npmjs.org/json-schema/-/json-schema-0.2.3.tgz", - "integrity": "sha1-tIDIkuWaLwWVTOcnvT8qTogvnhM=" - }, - "json-schema-traverse": { - "version": "0.4.1", - "resolved": "https://registry.npmjs.org/json-schema-traverse/-/json-schema-traverse-0.4.1.tgz", - "integrity": "sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==" - }, - "json-stringify-safe": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/json-stringify-safe/-/json-stringify-safe-5.0.1.tgz", - "integrity": "sha1-Epai1Y/UXxmg9s4B1lcB4sc1tus=" - }, - "json3": { - "version": "3.3.3", - "resolved": "https://registry.npmjs.org/json3/-/json3-3.3.3.tgz", - "integrity": "sha512-c7/8mbUsKigAbLkD5B010BK4D9LZm7A1pNItkEwiUZRpIN66exu/e7YQWysGun+TRKaJp8MhemM+VkfWv42aCA==" - }, - "json5": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/json5/-/json5-1.0.1.tgz", - "integrity": "sha512-aKS4WQjPenRxiQsC93MNfjx+nbF4PAdYzmd/1JIj8HYzqfbu86beTuNgXDzPknWk0n0uARlyewZo4s++ES36Ow==", - "requires": { - "minimist": "^1.2.0" - } - }, - "jsonfile": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-4.0.0.tgz", - "integrity": "sha1-h3Gq4HmbZAdrdmQPygWPnBDjPss=", - "requires": { - "graceful-fs": "^4.1.6" - } - }, - "jsonp": { - "version": "0.2.1", - "resolved": "https://registry.npmjs.org/jsonp/-/jsonp-0.2.1.tgz", - "integrity": "sha1-pltPoPEL2nGaBUQep7lMVfPhW64=", - "requires": { - "debug": "^2.1.3" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - } - } - }, - "jsprim": { - "version": "1.4.1", - "resolved": "https://registry.npmjs.org/jsprim/-/jsprim-1.4.1.tgz", - "integrity": "sha1-MT5mvB5cwG5Di8G3SZwuXFastqI=", - "requires": { - "assert-plus": "1.0.0", - "extsprintf": "1.3.0", - "json-schema": "0.2.3", - "verror": "1.10.0" - } - }, - "jstransformer": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/jstransformer/-/jstransformer-1.0.0.tgz", - "integrity": "sha1-7Yvwkh4vPx7U1cGkT2hwntJHIsM=", - "requires": { - "is-promise": "^2.0.0", - "promise": "^7.0.1" - } - }, - "keyv": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/keyv/-/keyv-3.1.0.tgz", - "integrity": "sha512-9ykJ/46SN/9KPM/sichzQ7OvXyGDYKGTaDlKMGCAlg2UK8KRy4jb0d8sFc+0Tt0YYnThq8X2RZgCg74RPxgcVA==", - "requires": { - "json-buffer": "3.0.0" - } - }, - "killable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/killable/-/killable-1.0.1.tgz", - "integrity": "sha512-LzqtLKlUwirEUyl/nicirVmNiPvYs7l5n8wOPP7fyJVpUPkvCnW/vuiXGpylGUlnPDnB7311rARzAt3Mhswpjg==" - }, - "kind-of": { - "version": "6.0.3", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-6.0.3.tgz", - "integrity": "sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==" - }, - "last-call-webpack-plugin": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/last-call-webpack-plugin/-/last-call-webpack-plugin-3.0.0.tgz", - "integrity": "sha512-7KI2l2GIZa9p2spzPIVZBYyNKkN+e/SQPpnjlTiPhdbDW3F86tdKKELxKpzJ5sgU19wQWsACULZmpTPYHeWO5w==", - "requires": { - "lodash": "^4.17.5", - "webpack-sources": "^1.1.0" - } - }, - "latest-version": { - "version": "5.1.0", - "resolved": "https://registry.npmjs.org/latest-version/-/latest-version-5.1.0.tgz", - "integrity": "sha512-weT+r0kTkRQdCdYCNtkMwWXQTMEswKrFBkm4ckQOMVhhqhIMI1UT2hMj+1iigIhgSZm5gTmrRXBNoGUgaTY1xA==", - "requires": { - "package-json": "^6.3.0" - } - }, - "lazy-cache": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/lazy-cache/-/lazy-cache-1.0.4.tgz", - "integrity": "sha1-odePw6UEdMuAhF07O24dpJpEbo4=" - }, - "linkify-it": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-2.2.0.tgz", - "integrity": "sha512-GnAl/knGn+i1U/wjBz3akz2stz+HrHLsxMwHQGofCDfPvlf+gDKN58UtfmUquTY4/MXeE2x7k19KQmeoZi94Iw==", - "requires": { - "uc.micro": "^1.0.1" - } - }, - "load-script": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/load-script/-/load-script-1.0.0.tgz", - "integrity": "sha1-BJGTngvuVkPuSUp+PaPSuscMbKQ=" - }, - "loader-runner": { - "version": "2.4.0", - "resolved": "https://registry.npmjs.org/loader-runner/-/loader-runner-2.4.0.tgz", - "integrity": "sha512-Jsmr89RcXGIwivFY21FcRrisYZfvLMTWx5kOLc+JTxtpBOG6xML0vzbc6SEQG2FO9/4Fc3wW4LVcB5DmGflaRw==" - }, - "loader-utils": { - "version": "1.4.0", - "resolved": "https://registry.npmjs.org/loader-utils/-/loader-utils-1.4.0.tgz", - "integrity": "sha512-qH0WSMBtn/oHuwjy/NucEgbx5dbxxnxup9s4PVXJUDHZBQY+s0NWA9rJf53RBnQZxfch7euUui7hpoAPvALZdA==", - "requires": { - "big.js": "^5.2.2", - "emojis-list": "^3.0.0", - "json5": "^1.0.1" - } - }, - "locate-path": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-5.0.0.tgz", - "integrity": "sha512-t7hw9pI+WvuwNJXwk5zVHpyhIqzg2qTlklJOf0mVxGSbe3Fp2VieZcduNYjaLDoy6p9uGpQEGWG87WpMKlNq8g==", - "requires": { - "p-locate": "^4.1.0" - } - }, - "lodash": { - "version": "4.17.20", - "resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.20.tgz", - "integrity": "sha512-PlhdFcillOINfeV7Ni6oF1TAEayyZBoZ8bcshTHqOYJYlrqzRK5hagpagky5o4HfCzzd1TRkXPMFq6cKk9rGmA==" - }, - "lodash._reinterpolate": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/lodash._reinterpolate/-/lodash._reinterpolate-3.0.0.tgz", - "integrity": "sha1-DM8tiRZq8Ds2Y8eWU4t1rG4RTZ0=" - }, - "lodash.chunk": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/lodash.chunk/-/lodash.chunk-4.2.0.tgz", - "integrity": "sha1-ZuXOH3btJ7QwPYxlEujRIW6BBrw=" - }, - "lodash.clonedeep": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/lodash.clonedeep/-/lodash.clonedeep-4.5.0.tgz", - "integrity": "sha1-4j8/nE+Pvd6HJSnBBxhXoIblzO8=" - }, - "lodash.debounce": { - "version": "4.0.8", - "resolved": "https://registry.npmjs.org/lodash.debounce/-/lodash.debounce-4.0.8.tgz", - "integrity": "sha1-gteb/zCmfEAF/9XiUVMArZyk168=" - }, - "lodash.kebabcase": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/lodash.kebabcase/-/lodash.kebabcase-4.1.1.tgz", - "integrity": "sha1-hImxyw0p/4gZXM7KRI/21swpXDY=" - }, - "lodash.memoize": { - "version": "4.1.2", - "resolved": "https://registry.npmjs.org/lodash.memoize/-/lodash.memoize-4.1.2.tgz", - "integrity": "sha1-vMbEmkKihA7Zl/Mj6tpezRguC/4=" - }, - "lodash.padstart": { - "version": "4.6.1", - "resolved": "https://registry.npmjs.org/lodash.padstart/-/lodash.padstart-4.6.1.tgz", - "integrity": "sha1-0uPuv/DZ05rVD1y9G1KnvOa7YRs=" - }, - "lodash.sortby": { - "version": "4.7.0", - "resolved": "https://registry.npmjs.org/lodash.sortby/-/lodash.sortby-4.7.0.tgz", - "integrity": "sha1-7dFMgk4sycHgsKG0K7UhBRakJDg=" - }, - "lodash.template": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/lodash.template/-/lodash.template-4.5.0.tgz", - "integrity": "sha512-84vYFxIkmidUiFxidA/KjjH9pAycqW+h980j7Fuz5qxRtO9pgB7MDFTdys1N7A5mcucRiDyEq4fusljItR1T/A==", - "requires": { - "lodash._reinterpolate": "^3.0.0", - "lodash.templatesettings": "^4.0.0" - } - }, - "lodash.templatesettings": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/lodash.templatesettings/-/lodash.templatesettings-4.2.0.tgz", - "integrity": "sha512-stgLz+i3Aa9mZgnjr/O+v9ruKZsPsndy7qPZOchbqk2cnTU1ZaldKK+v7m54WoKIyxiuMZTKT2H81F8BeAc3ZQ==", - "requires": { - "lodash._reinterpolate": "^3.0.0" - } - }, - "lodash.uniq": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/lodash.uniq/-/lodash.uniq-4.5.0.tgz", - "integrity": "sha1-0CJTc662Uq3BvILklFM5qEJ1R3M=" - }, - "loglevel": { - "version": "1.7.1", - "resolved": "https://registry.npmjs.org/loglevel/-/loglevel-1.7.1.tgz", - "integrity": "sha512-Hesni4s5UkWkwCGJMQGAh71PaLUmKFM60dHvq0zi/vDhhrzuk+4GgNbTXJ12YYQJn6ZKBDNIjYcuQGKudvqrIw==" - }, - "longest": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/longest/-/longest-1.0.1.tgz", - "integrity": "sha1-MKCy2jj3N3DoKUoNIuZiXtd9AJc=" - }, - "lower-case": { - "version": "1.1.4", - "resolved": "https://registry.npmjs.org/lower-case/-/lower-case-1.1.4.tgz", - "integrity": "sha1-miyr0bno4K6ZOkv31YdcOcQujqw=" - }, - "lowercase-keys": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/lowercase-keys/-/lowercase-keys-1.0.1.tgz", - "integrity": "sha512-G2Lj61tXDnVFFOi8VZds+SoQjtQC3dgokKdDG2mTm1tx4m50NUHBOZSBwQQHyy0V12A0JTG4icfZQH+xPyh8VA==" - }, - "lru-cache": { - "version": "5.1.1", - "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-5.1.1.tgz", - "integrity": "sha512-KpNARQA3Iwv+jTA0utUVVbrh+Jlrr1Fv0e56GGzAFOXN7dk/FviaDW8LHmK52DlcH4WP2n6gI8vN1aesBFgo9w==", - "requires": { - "yallist": "^3.0.2" - } - }, - "make-dir": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/make-dir/-/make-dir-3.1.0.tgz", - "integrity": "sha512-g3FeP20LNwhALb/6Cz6Dd4F2ngze0jz7tbzrD2wAV+o9FeNHe4rL+yK2md0J/fiSf1sa1ADhXqi5+oVwOM/eGw==", - "requires": { - "semver": "^6.0.0" - } - }, - "map-cache": { - "version": "0.2.2", - "resolved": "https://registry.npmjs.org/map-cache/-/map-cache-0.2.2.tgz", - "integrity": "sha1-wyq9C9ZSXZsFFkW7TyasXcmKDb8=" - }, - "map-visit": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/map-visit/-/map-visit-1.0.0.tgz", - "integrity": "sha1-7Nyo8TFE5mDxtb1B8S80edmN+48=", - "requires": { - "object-visit": "^1.0.0" - } - }, - "markdown-it": { - "version": "12.0.4", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-12.0.4.tgz", - "integrity": "sha512-34RwOXZT8kyuOJy25oJNJoulO8L0bTHYWXcdZBYZqFnjIy3NgjeoM3FmPXIOFQ26/lSHYMr8oc62B6adxXcb3Q==", - "requires": { - "argparse": "^2.0.1", - "entities": "~2.1.0", - "linkify-it": "^3.0.1", - "mdurl": "^1.0.1", - "uc.micro": "^1.0.5" - }, - "dependencies": { - "argparse": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", - "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==" - }, - "linkify-it": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-3.0.2.tgz", - "integrity": "sha512-gDBO4aHNZS6coiZCKVhSNh43F9ioIL4JwRjLZPkoLIY4yZFwg264Y5lu2x6rb1Js42Gh6Yqm2f6L2AJcnkzinQ==", - "requires": { - "uc.micro": "^1.0.1" - } - } - } - }, - "markdown-it-anchor": { - "version": "5.3.0", - "resolved": "https://registry.npmjs.org/markdown-it-anchor/-/markdown-it-anchor-5.3.0.tgz", - "integrity": "sha512-/V1MnLL/rgJ3jkMWo84UR+K+jF1cxNG1a+KwqeXqTIJ+jtA8aWSHuigx8lTzauiIjBDbwF3NcWQMotd0Dm39jA==" - }, - "markdown-it-attrs": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/markdown-it-attrs/-/markdown-it-attrs-3.0.3.tgz", - "integrity": "sha512-cLnICU2t61skNCr4Wih/sdza+UbQcqJGZwvqAypnbWA284nzDm+Gpc90iaRk/JjsIy4emag5v3s0rXFhFBWhCA==" - }, - "markdown-it-chain": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/markdown-it-chain/-/markdown-it-chain-1.3.0.tgz", - "integrity": "sha512-XClV8I1TKy8L2qsT9iX3qiV+50ZtcInGXI80CA+DP62sMs7hXlyV/RM3hfwy5O3Ad0sJm9xIwQELgANfESo8mQ==", - "requires": { - "webpack-chain": "^4.9.0" - }, - "dependencies": { - "webpack-chain": { - "version": "4.12.1", - "resolved": "https://registry.npmjs.org/webpack-chain/-/webpack-chain-4.12.1.tgz", - "integrity": "sha512-BCfKo2YkDe2ByqkEWe1Rw+zko4LsyS75LVr29C6xIrxAg9JHJ4pl8kaIZ396SUSNp6b4815dRZPSTAS8LlURRQ==", - "requires": { - "deepmerge": "^1.5.2", - "javascript-stringify": "^1.6.0" - } - } - } - }, - "markdown-it-container": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/markdown-it-container/-/markdown-it-container-2.0.0.tgz", - "integrity": "sha1-ABm0P9Au7+zi8ZYKKJX7qBpARpU=" - }, - "markdown-it-emoji": { - "version": "1.4.0", - "resolved": "https://registry.npmjs.org/markdown-it-emoji/-/markdown-it-emoji-1.4.0.tgz", - "integrity": "sha1-m+4OmpkKljupbfaYDE/dsF37Tcw=" - }, - "markdown-it-table-of-contents": { - "version": "0.4.4", - "resolved": "https://registry.npmjs.org/markdown-it-table-of-contents/-/markdown-it-table-of-contents-0.4.4.tgz", - "integrity": "sha512-TAIHTHPwa9+ltKvKPWulm/beozQU41Ab+FIefRaQV1NRnpzwcV9QOe6wXQS5WLivm5Q/nlo0rl6laGkMDZE7Gw==" - }, - "md5.js": { - "version": "1.3.5", - "resolved": "https://registry.npmjs.org/md5.js/-/md5.js-1.3.5.tgz", - "integrity": "sha512-xitP+WxNPcTTOgnTJcrhM0xvdPepipPSf3I8EIpGKeFLjt3PlJLIDG3u8EX53ZIubkb+5U2+3rELYpEhHhzdkg==", - "requires": { - "hash-base": "^3.0.0", - "inherits": "^2.0.1", - "safe-buffer": "^5.1.2" - } - }, - "mdn-data": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/mdn-data/-/mdn-data-2.0.4.tgz", - "integrity": "sha512-iV3XNKw06j5Q7mi6h+9vbx23Tv7JkjEVgKHW4pimwyDGWm0OIQntJJ+u1C6mg6mK1EaTv42XQ7w76yuzH7M2cA==" - }, - "mdurl": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-1.0.1.tgz", - "integrity": "sha1-/oWy7HWlkDfyrf7BAP1sYBdhFS4=" - }, - "media-typer": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz", - "integrity": "sha1-hxDXrwqmJvj/+hzgAWhUUmMlV0g=" - }, - "memory-fs": { - "version": "0.4.1", - "resolved": "https://registry.npmjs.org/memory-fs/-/memory-fs-0.4.1.tgz", - "integrity": "sha1-OpoguEYlI+RHz7x+i7gO1me/xVI=", - "requires": { - "errno": "^0.1.3", - "readable-stream": "^2.0.1" - } - }, - "merge-descriptors": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/merge-descriptors/-/merge-descriptors-1.0.1.tgz", - "integrity": "sha1-sAqqVW3YtEVoFQ7J0blT8/kMu2E=" - }, - "merge-source-map": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/merge-source-map/-/merge-source-map-1.1.0.tgz", - "integrity": "sha512-Qkcp7P2ygktpMPh2mCQZaf3jhN6D3Z/qVZHSdWvQ+2Ef5HgRAPBO57A77+ENm0CPx2+1Ce/MYKi3ymqdfuqibw==", - "requires": { - "source-map": "^0.6.1" - } - }, - "merge2": { - "version": "1.4.1", - "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz", - "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==" - }, - "methods": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/methods/-/methods-1.1.2.tgz", - "integrity": "sha1-VSmk1nZUE07cxSZmVoNbD4Ua/O4=" - }, - "micromatch": { - "version": "3.1.10", - "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-3.1.10.tgz", - "integrity": "sha512-MWikgl9n9M3w+bpsY3He8L+w9eF9338xRl8IAO5viDizwSzziFEyUzo2xrrloB64ADbTf8uA8vRqqttDTOmccg==", - "requires": { - "arr-diff": "^4.0.0", - "array-unique": "^0.3.2", - "braces": "^2.3.1", - "define-property": "^2.0.2", - "extend-shallow": "^3.0.2", - "extglob": "^2.0.4", - "fragment-cache": "^0.2.1", - "kind-of": "^6.0.2", - "nanomatch": "^1.2.9", - "object.pick": "^1.3.0", - "regex-not": "^1.0.0", - "snapdragon": "^0.8.1", - "to-regex": "^3.0.2" - }, - "dependencies": { - "extend-shallow": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-3.0.2.tgz", - "integrity": "sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=", - "requires": { - "assign-symbols": "^1.0.0", - "is-extendable": "^1.0.1" - } - }, - "is-extendable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz", - "integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==", - "requires": { - "is-plain-object": "^2.0.4" - } - } - } - }, - "miller-rabin": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/miller-rabin/-/miller-rabin-4.0.1.tgz", - "integrity": "sha512-115fLhvZVqWwHPbClyntxEVfVDfl9DLLTuJvq3g2O/Oxi8AiNouAHvDSzHS0viUJc+V5vm3eq91Xwqn9dp4jRA==", - "requires": { - "bn.js": "^4.0.0", - "brorand": "^1.0.1" - }, - "dependencies": { - "bn.js": { - "version": "4.11.9", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-4.11.9.tgz", - "integrity": "sha512-E6QoYqCKZfgatHTdHzs1RRKP7ip4vvm+EyRUeE2RF0NblwVvb0p6jSVeNTOFxPn26QXN2o6SMfNxKp6kU8zQaw==" - } - } - }, - "mime": { - "version": "2.5.0", - "resolved": "https://registry.npmjs.org/mime/-/mime-2.5.0.tgz", - "integrity": "sha512-ft3WayFSFUVBuJj7BMLKAQcSlItKtfjsKDDsii3rqFDAZ7t11zRe8ASw/GlmivGwVUYtwkQrxiGGpL6gFvB0ag==" - }, - "mime-db": { - "version": "1.45.0", - "resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.45.0.tgz", - "integrity": "sha512-CkqLUxUk15hofLoLyljJSrukZi8mAtgd+yE5uO4tqRZsdsAJKv0O+rFMhVDRJgozy+yG6md5KwuXhD4ocIoP+w==" - }, - "mime-types": { - "version": "2.1.28", - "resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.28.tgz", - "integrity": "sha512-0TO2yJ5YHYr7M2zzT7gDU1tbwHxEUWBCLt0lscSNpcdAfFyJOVEpRYNS7EXVcTLNj/25QO8gulHC5JtTzSE2UQ==", - "requires": { - "mime-db": "1.45.0" - } - }, - "mimic-response": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/mimic-response/-/mimic-response-1.0.1.tgz", - "integrity": "sha512-j5EctnkH7amfV/q5Hgmoal1g2QHFJRraOtmx0JpIqkxhBhI/lJSl1nMpQ45hVarwNETOoWEimndZ4QK0RHxuxQ==" - }, - "min-document": { - "version": "2.19.0", - "resolved": "https://registry.npmjs.org/min-document/-/min-document-2.19.0.tgz", - "integrity": "sha1-e9KC4/WELtKVu3SM3Z8f+iyCRoU=", - "requires": { - "dom-walk": "^0.1.0" - } - }, - "mini-css-extract-plugin": { - "version": "0.6.0", - "resolved": "https://registry.npmjs.org/mini-css-extract-plugin/-/mini-css-extract-plugin-0.6.0.tgz", - "integrity": "sha512-79q5P7YGI6rdnVyIAV4NXpBQJFWdkzJxCim3Kog4078fM0piAaFlwocqbejdWtLW1cEzCexPrh6EdyFsPgVdAw==", - "requires": { - "loader-utils": "^1.1.0", - "normalize-url": "^2.0.1", - "schema-utils": "^1.0.0", - "webpack-sources": "^1.1.0" - }, - "dependencies": { - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - } - } - }, - "minimalistic-assert": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/minimalistic-assert/-/minimalistic-assert-1.0.1.tgz", - "integrity": "sha512-UtJcAD4yEaGtjPezWuO9wC4nwUnVH/8/Im3yEHQP4b67cXlD/Qr9hdITCU1xDbSEXg2XKNaP8jsReV7vQd00/A==" - }, - "minimalistic-crypto-utils": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/minimalistic-crypto-utils/-/minimalistic-crypto-utils-1.0.1.tgz", - "integrity": "sha1-9sAMHAsIIkblxNmd+4x8CDsrWCo=" - }, - "minimatch": { - "version": "3.0.4", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz", - "integrity": "sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==", - "requires": { - "brace-expansion": "^1.1.7" - } - }, - "minimist": { - "version": "1.2.5", - "resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.5.tgz", - "integrity": "sha512-FM9nNUYrRBAELZQT3xeZQ7fmMOBg6nWNmJKTcgsJeaLstP/UODVpGsr5OhXhhXg6f+qtJ8uiZ+PUxkDWcgIXLw==" - }, - "mississippi": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/mississippi/-/mississippi-3.0.0.tgz", - "integrity": "sha512-x471SsVjUtBRtcvd4BzKE9kFC+/2TeWgKCgw0bZcw1b9l2X3QX5vCWgF+KaZaYm87Ss//rHnWryupDrgLvmSkA==", - "requires": { - "concat-stream": "^1.5.0", - "duplexify": "^3.4.2", - "end-of-stream": "^1.1.0", - "flush-write-stream": "^1.0.0", - "from2": "^2.1.0", - "parallel-transform": "^1.1.0", - "pump": "^3.0.0", - "pumpify": "^1.3.3", - "stream-each": "^1.1.0", - "through2": "^2.0.0" - } - }, - "mixin-deep": { - "version": "1.3.2", - "resolved": "https://registry.npmjs.org/mixin-deep/-/mixin-deep-1.3.2.tgz", - "integrity": "sha512-WRoDn//mXBiJ1H40rqa3vH0toePwSsGb45iInWlTySa+Uu4k3tYUSxa2v1KqAiLtvlrSzaExqS1gtk96A9zvEA==", - "requires": { - "for-in": "^1.0.2", - "is-extendable": "^1.0.1" - }, - "dependencies": { - "is-extendable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz", - "integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==", - "requires": { - "is-plain-object": "^2.0.4" - } - } - } - }, - "mkdirp": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-1.0.4.tgz", - "integrity": "sha512-vVqVZQyf3WLx2Shd0qJ9xuvqgAyKPLAiqITEtqW0oIUjzo3PePDd6fW9iFz30ef7Ysp/oiWqbhszeGWW2T6Gzw==" - }, - "move-concurrently": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/move-concurrently/-/move-concurrently-1.0.1.tgz", - "integrity": "sha1-viwAX9oy4LKa8fBdfEszIUxwH5I=", - "requires": { - "aproba": "^1.1.1", - "copy-concurrently": "^1.0.0", - "fs-write-stream-atomic": "^1.0.8", - "mkdirp": "^0.5.1", - "rimraf": "^2.5.4", - "run-queue": "^1.0.3" - }, - "dependencies": { - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - } - } - }, - "ms": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz", - "integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=" - }, - "multicast-dns": { - "version": "6.2.3", - "resolved": "https://registry.npmjs.org/multicast-dns/-/multicast-dns-6.2.3.tgz", - "integrity": "sha512-ji6J5enbMyGRHIAkAOu3WdV8nggqviKCEKtXcOqfphZZtQrmHKycfynJ2V7eVPUA4NhJ6V7Wf4TmGbTwKE9B6g==", - "requires": { - "dns-packet": "^1.3.1", - "thunky": "^1.0.2" - } - }, - "multicast-dns-service-types": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/multicast-dns-service-types/-/multicast-dns-service-types-1.1.0.tgz", - "integrity": "sha1-iZ8R2WhuXgXLkbNdXw5jt3PPyQE=" - }, - "nan": { - "version": "2.14.2", - "resolved": "https://registry.npmjs.org/nan/-/nan-2.14.2.tgz", - "integrity": "sha512-M2ufzIiINKCuDfBSAUr1vWQ+vuVcA9kqx8JJUsbQi6yf1uGRyb7HfpdfUr5qLXf3B/t8dPvcjhKMmlfnP47EzQ==", - "optional": true - }, - "nanomatch": { - "version": "1.2.13", - "resolved": "https://registry.npmjs.org/nanomatch/-/nanomatch-1.2.13.tgz", - "integrity": "sha512-fpoe2T0RbHwBTBUOftAfBPaDEi06ufaUai0mE6Yn1kacc3SnTErfb/h+X94VXzI64rKFHYImXSvdwGGCmwOqCA==", - "requires": { - "arr-diff": "^4.0.0", - "array-unique": "^0.3.2", - "define-property": "^2.0.2", - "extend-shallow": "^3.0.2", - "fragment-cache": "^0.2.1", - "is-windows": "^1.0.2", - "kind-of": "^6.0.2", - "object.pick": "^1.3.0", - "regex-not": "^1.0.0", - "snapdragon": "^0.8.1", - "to-regex": "^3.0.1" - }, - "dependencies": { - "extend-shallow": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-3.0.2.tgz", - "integrity": "sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=", - "requires": { - "assign-symbols": "^1.0.0", - "is-extendable": "^1.0.1" - } - }, - "is-extendable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz", - "integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==", - "requires": { - "is-plain-object": "^2.0.4" - } - } - } - }, - "negotiator": { - "version": "0.6.2", - "resolved": "https://registry.npmjs.org/negotiator/-/negotiator-0.6.2.tgz", - "integrity": "sha512-hZXc7K2e+PgeI1eDBe/10Ard4ekbfrrqG8Ep+8Jmf4JID2bNg7NvCPOZN+kfF574pFQI7mum2AUqDidoKqcTOw==" - }, - "neo-async": { - "version": "2.6.2", - "resolved": "https://registry.npmjs.org/neo-async/-/neo-async-2.6.2.tgz", - "integrity": "sha512-Yd3UES5mWCSqR+qNT93S3UoYUkqAZ9lLg8a7g9rimsWmYGK8cVToA4/sF3RrshdyV3sAGMXVUmpMYOw+dLpOuw==" - }, - "nice-try": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/nice-try/-/nice-try-1.0.5.tgz", - "integrity": "sha512-1nh45deeb5olNY7eX82BkPO7SSxR5SSYJiPTrTdFUVYwAl8CKMA5N9PjTYkHiRjisVcxcQ1HXdLhx2qxxJzLNQ==" - }, - "no-case": { - "version": "2.3.2", - "resolved": "https://registry.npmjs.org/no-case/-/no-case-2.3.2.tgz", - "integrity": "sha512-rmTZ9kz+f3rCvK2TD1Ue/oZlns7OGoIWP4fc3llxxRXlOkHKoWPPWJOfFYpITabSow43QJbRIoHQXtt10VldyQ==", - "requires": { - "lower-case": "^1.1.1" - } - }, - "node-forge": { - "version": "0.10.0", - "resolved": "https://registry.npmjs.org/node-forge/-/node-forge-0.10.0.tgz", - "integrity": "sha512-PPmu8eEeG9saEUvI97fm4OYxXVB6bFvyNTyiUOBichBpFG8A1Ljw3bY62+5oOjDEMHRnd0Y7HQ+x7uzxOzC6JA==" - }, - "node-libs-browser": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/node-libs-browser/-/node-libs-browser-2.2.1.tgz", - "integrity": "sha512-h/zcD8H9kaDZ9ALUWwlBUDo6TKF8a7qBSCSEGfjTVIYeqsioSKaAX+BN7NgiMGp6iSIXZ3PxgCu8KS3b71YK5Q==", - "requires": { - "assert": "^1.1.1", - "browserify-zlib": "^0.2.0", - "buffer": "^4.3.0", - "console-browserify": "^1.1.0", - "constants-browserify": "^1.0.0", - "crypto-browserify": "^3.11.0", - "domain-browser": "^1.1.1", - "events": "^3.0.0", - "https-browserify": "^1.0.0", - "os-browserify": "^0.3.0", - "path-browserify": "0.0.1", - "process": "^0.11.10", - "punycode": "^1.2.4", - "querystring-es3": "^0.2.0", - "readable-stream": "^2.3.3", - "stream-browserify": "^2.0.1", - "stream-http": "^2.7.2", - "string_decoder": "^1.0.0", - "timers-browserify": "^2.0.4", - "tty-browserify": "0.0.0", - "url": "^0.11.0", - "util": "^0.11.0", - "vm-browserify": "^1.0.1" - }, - "dependencies": { - "punycode": { - "version": "1.4.1", - "resolved": "https://registry.npmjs.org/punycode/-/punycode-1.4.1.tgz", - "integrity": "sha1-wNWmOycYgArY4esPpSachN1BhF4=" - } - } - }, - "node-releases": { - "version": "1.1.70", - "resolved": "https://registry.npmjs.org/node-releases/-/node-releases-1.1.70.tgz", - "integrity": "sha512-Slf2s69+2/uAD79pVVQo8uSiC34+g8GWY8UH2Qtqv34ZfhYrxpYpfzs9Js9d6O0mbDmALuxaTlplnBTnSELcrw==" - }, - "nopt": { - "version": "1.0.10", - "resolved": "https://registry.npmjs.org/nopt/-/nopt-1.0.10.tgz", - "integrity": "sha1-bd0hvSoxQXuScn3Vhfim83YI6+4=", - "requires": { - "abbrev": "1" - } - }, - "normalize-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz", - "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==" - }, - "normalize-range": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz", - "integrity": "sha1-LRDAa9/TEuqXd2laTShDlFa3WUI=" - }, - "normalize-url": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/normalize-url/-/normalize-url-2.0.1.tgz", - "integrity": "sha512-D6MUW4K/VzoJ4rJ01JFKxDrtY1v9wrgzCX5f2qj/lzH1m/lW6MhUZFKerVsnyjOhOsYzI9Kqqak+10l4LvLpMw==", - "requires": { - "prepend-http": "^2.0.0", - "query-string": "^5.0.1", - "sort-keys": "^2.0.0" - } - }, - "npm-run-path": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/npm-run-path/-/npm-run-path-2.0.2.tgz", - "integrity": "sha1-NakjLfo11wZ7TLLd8jV7GHFTbF8=", - "requires": { - "path-key": "^2.0.0" - } - }, - "nprogress": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/nprogress/-/nprogress-0.2.0.tgz", - "integrity": "sha1-y480xTIT2JVyP8urkH6UIq28r7E=" - }, - "nth-check": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/nth-check/-/nth-check-2.0.0.tgz", - "integrity": "sha512-i4sc/Kj8htBrAiH1viZ0TgU8Y5XqCaV/FziYK6TBczxmeKm3AEFWqqF3195yKudrarqy7Zu80Ra5dobFjn9X/Q==", - "requires": { - "boolbase": "^1.0.0" - } - }, - "num2fraction": { - "version": "1.2.2", - "resolved": "https://registry.npmjs.org/num2fraction/-/num2fraction-1.2.2.tgz", - "integrity": "sha1-b2gragJ6Tp3fpFZM0lidHU5mnt4=" - }, - "oauth-sign": { - "version": "0.9.0", - "resolved": "https://registry.npmjs.org/oauth-sign/-/oauth-sign-0.9.0.tgz", - "integrity": "sha512-fexhUFFPTGV8ybAtSIGbV6gOkSv8UtRbDBnAyLQw4QPKkgNlsH2ByPGtMUqdWkos6YCRmAqViwgZrJc/mRDzZQ==" - }, - "object-assign": { - "version": "4.1.1", - "resolved": "https://registry.npmjs.org/object-assign/-/object-assign-4.1.1.tgz", - "integrity": "sha1-IQmtx5ZYh8/AXLvUQsrIv7s2CGM=" - }, - "object-copy": { - "version": "0.1.0", - "resolved": "https://registry.npmjs.org/object-copy/-/object-copy-0.1.0.tgz", - "integrity": "sha1-fn2Fi3gb18mRpBupde04EnVOmYw=", - "requires": { - "copy-descriptor": "^0.1.0", - "define-property": "^0.2.5", - "kind-of": "^3.0.3" - }, - "dependencies": { - "define-property": { - "version": "0.2.5", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-0.2.5.tgz", - "integrity": "sha1-w1se+RjsPJkPmlvFe+BKrOxcgRY=", - "requires": { - "is-descriptor": "^0.1.0" - } - }, - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "object-inspect": { - "version": "1.9.0", - "resolved": "https://registry.npmjs.org/object-inspect/-/object-inspect-1.9.0.tgz", - "integrity": "sha512-i3Bp9iTqwhaLZBxGkRfo5ZbE07BQRT7MGu8+nNgwW9ItGp1TzCTw2DLEoWwjClxBjOFI/hWljTAmYGCEwmtnOw==" - }, - "object-is": { - "version": "1.1.4", - "resolved": "https://registry.npmjs.org/object-is/-/object-is-1.1.4.tgz", - "integrity": "sha512-1ZvAZ4wlF7IyPVOcE1Omikt7UpaFlOQq0HlSti+ZvDH3UiD2brwGMwDbyV43jao2bKJ+4+WdPJHSd7kgzKYVqg==", - "requires": { - "call-bind": "^1.0.0", - "define-properties": "^1.1.3" - } - }, - "object-keys": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/object-keys/-/object-keys-1.1.1.tgz", - "integrity": "sha512-NuAESUOUMrlIXOfHKzD6bpPu3tYt3xvjNdRIQ+FeT0lNb4K8WR70CaDxhuNguS2XG+GjkyMwOzsN5ZktImfhLA==" - }, - "object-visit": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/object-visit/-/object-visit-1.0.1.tgz", - "integrity": "sha1-95xEk68MU3e1n+OdOV5BBC3QRbs=", - "requires": { - "isobject": "^3.0.0" - } - }, - "object.assign": { - "version": "4.1.2", - "resolved": "https://registry.npmjs.org/object.assign/-/object.assign-4.1.2.tgz", - "integrity": "sha512-ixT2L5THXsApyiUPYKmW+2EHpXXe5Ii3M+f4e+aJFAHao5amFRW6J0OO6c/LU8Be47utCx2GL89hxGB6XSmKuQ==", - "requires": { - "call-bind": "^1.0.0", - "define-properties": "^1.1.3", - "has-symbols": "^1.0.1", - "object-keys": "^1.1.1" - } - }, - "object.getownpropertydescriptors": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/object.getownpropertydescriptors/-/object.getownpropertydescriptors-2.1.1.tgz", - "integrity": "sha512-6DtXgZ/lIZ9hqx4GtZETobXLR/ZLaa0aqV0kzbn80Rf8Z2e/XFnhA0I7p07N2wH8bBBltr2xQPi6sbKWAY2Eng==", - "requires": { - "call-bind": "^1.0.0", - "define-properties": "^1.1.3", - "es-abstract": "^1.18.0-next.1" - } - }, - "object.pick": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/object.pick/-/object.pick-1.3.0.tgz", - "integrity": "sha1-h6EKxMFpS9Lhy/U1kaZhQftd10c=", - "requires": { - "isobject": "^3.0.1" - } - }, - "object.values": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/object.values/-/object.values-1.1.2.tgz", - "integrity": "sha512-MYC0jvJopr8EK6dPBiO8Nb9mvjdypOachO5REGk6MXzujbBrAisKo3HmdEI6kZDL6fC31Mwee/5YbtMebixeag==", - "requires": { - "call-bind": "^1.0.0", - "define-properties": "^1.1.3", - "es-abstract": "^1.18.0-next.1", - "has": "^1.0.3" - } - }, - "obuf": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/obuf/-/obuf-1.1.2.tgz", - "integrity": "sha512-PX1wu0AmAdPqOL1mWhqmlOd8kOIZQwGZw6rh7uby9fTc5lhaOWFLX3I6R1hrF9k3zUY40e6igsLGkDXK92LJNg==" - }, - "on-finished": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/on-finished/-/on-finished-2.3.0.tgz", - "integrity": "sha1-IPEzZIGwg811M3mSoWlxqi2QaUc=", - "requires": { - "ee-first": "1.1.1" - } - }, - "on-headers": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/on-headers/-/on-headers-1.0.2.tgz", - "integrity": "sha512-pZAE+FJLoyITytdqK0U5s+FIpjN0JP3OzFi/u8Rx+EV5/W+JTWGXG8xFzevE7AjBfDqHv/8vL8qQsIhHnqRkrA==" - }, - "once": { - "version": "1.4.0", - "resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz", - "integrity": "sha1-WDsap3WWHUsROsF9nFC6753Xa9E=", - "requires": { - "wrappy": "1" - } - }, - "opencollective-postinstall": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/opencollective-postinstall/-/opencollective-postinstall-2.0.3.tgz", - "integrity": "sha512-8AV/sCtuzUeTo8gQK5qDZzARrulB3egtLzFgteqB2tcT4Mw7B8Kt7JcDHmltjz6FOAHsvTevk70gZEbhM4ZS9Q==" - }, - "opn": { - "version": "5.5.0", - "resolved": "https://registry.npmjs.org/opn/-/opn-5.5.0.tgz", - "integrity": "sha512-PqHpggC9bLV0VeWcdKhkpxY+3JTzetLSqTCWL/z/tFIbI6G8JCjondXklT1JinczLz2Xib62sSp0T/gKT4KksA==", - "requires": { - "is-wsl": "^1.1.0" - } - }, - "optimize-css-assets-webpack-plugin": { - "version": "5.0.4", - "resolved": "https://registry.npmjs.org/optimize-css-assets-webpack-plugin/-/optimize-css-assets-webpack-plugin-5.0.4.tgz", - "integrity": "sha512-wqd6FdI2a5/FdoiCNNkEvLeA//lHHfG24Ln2Xm2qqdIk4aOlsR18jwpyOihqQ8849W3qu2DX8fOYxpvTMj+93A==", - "requires": { - "cssnano": "^4.1.10", - "last-call-webpack-plugin": "^3.0.0" - } - }, - "original": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/original/-/original-1.0.2.tgz", - "integrity": "sha512-hyBVl6iqqUOJ8FqRe+l/gS8H+kKYjrEndd5Pm1MfBtsEKA038HkkdbAl/72EAXGyonD/PFsvmVG+EvcIpliMBg==", - "requires": { - "url-parse": "^1.4.3" - } - }, - "os-browserify": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/os-browserify/-/os-browserify-0.3.0.tgz", - "integrity": "sha1-hUNzx/XCMVkU/Jv8a9gjj92h7Cc=" - }, - "p-cancelable": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/p-cancelable/-/p-cancelable-1.1.0.tgz", - "integrity": "sha512-s73XxOZ4zpt1edZYZzvhqFa6uvQc1vwUa0K0BdtIZgQMAJj9IbebH+JkgKZc9h+B05PKHLOTl4ajG1BmNrVZlw==" - }, - "p-finally": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/p-finally/-/p-finally-1.0.0.tgz", - "integrity": "sha1-P7z7FbiZpEEjs0ttzBi3JDNqLK4=" - }, - "p-limit": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/p-limit/-/p-limit-2.3.0.tgz", - "integrity": "sha512-//88mFWSJx8lxCzwdAABTJL2MyWB12+eIY7MDL2SqLmAkeKU9qxRvWuSyTjm3FUmpBEMuFfckAIqEaVGUDxb6w==", - "requires": { - "p-try": "^2.0.0" - } - }, - "p-locate": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-4.1.0.tgz", - "integrity": "sha512-R79ZZ/0wAxKGu3oYMlz8jy/kbhsNrS7SKZ7PxEHBgJ5+F2mtFW2fK2cOtBh1cHYkQsbzFV7I+EoRKe6Yt0oK7A==", - "requires": { - "p-limit": "^2.2.0" - } - }, - "p-map": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/p-map/-/p-map-2.1.0.tgz", - "integrity": "sha512-y3b8Kpd8OAN444hxfBbFfj1FY/RjtTd8tzYwhUqNYXx0fXx2iX4maP4Qr6qhIKbQXI02wTLAda4fYUbDagTUFw==" - }, - "p-retry": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/p-retry/-/p-retry-3.0.1.tgz", - "integrity": "sha512-XE6G4+YTTkT2a0UWb2kjZe8xNwf8bIbnqpc/IS/idOBVhyves0mK5OJgeocjx7q5pvX/6m23xuzVPYT1uGM73w==", - "requires": { - "retry": "^0.12.0" - } - }, - "p-try": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/p-try/-/p-try-2.2.0.tgz", - "integrity": "sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==" - }, - "package-json": { - "version": "6.5.0", - "resolved": "https://registry.npmjs.org/package-json/-/package-json-6.5.0.tgz", - "integrity": "sha512-k3bdm2n25tkyxcjSKzB5x8kfVxlMdgsbPr0GkZcwHsLpba6cBjqCt1KlcChKEvxHIcTB1FVMuwoijZ26xex5MQ==", - "requires": { - "got": "^9.6.0", - "registry-auth-token": "^4.0.0", - "registry-url": "^5.0.0", - "semver": "^6.2.0" - } - }, - "pako": { - "version": "1.0.11", - "resolved": "https://registry.npmjs.org/pako/-/pako-1.0.11.tgz", - "integrity": "sha512-4hLB8Py4zZce5s4yd9XzopqwVv/yGNhV1Bl8NTmCq1763HeK2+EwVTv+leGeL13Dnh2wfbqowVPXCIO0z4taYw==" - }, - "parallel-transform": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/parallel-transform/-/parallel-transform-1.2.0.tgz", - "integrity": "sha512-P2vSmIu38uIlvdcU7fDkyrxj33gTUy/ABO5ZUbGowxNCopBq/OoD42bP4UmMrJoPyk4Uqf0mu3mtWBhHCZD8yg==", - "requires": { - "cyclist": "^1.0.1", - "inherits": "^2.0.3", - "readable-stream": "^2.1.5" - } - }, - "param-case": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/param-case/-/param-case-2.1.1.tgz", - "integrity": "sha1-35T9jPZTHs915r75oIWPvHK+Ikc=", - "requires": { - "no-case": "^2.2.0" - } - }, - "parse-asn1": { - "version": "5.1.6", - "resolved": "https://registry.npmjs.org/parse-asn1/-/parse-asn1-5.1.6.tgz", - "integrity": "sha512-RnZRo1EPU6JBnra2vGHj0yhp6ebyjBZpmUCLHWiFhxlzvBCCpAuZ7elsBp1PVAbQN0/04VD/19rfzlBSwLstMw==", - "requires": { - "asn1.js": "^5.2.0", - "browserify-aes": "^1.0.0", - "evp_bytestokey": "^1.0.0", - "pbkdf2": "^3.0.3", - "safe-buffer": "^5.1.1" - } - }, - "parse-json": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/parse-json/-/parse-json-4.0.0.tgz", - "integrity": "sha1-vjX1Qlvh9/bHRxhPmKeIy5lHfuA=", - "requires": { - "error-ex": "^1.3.1", - "json-parse-better-errors": "^1.0.1" - } - }, - "parse5": { - "version": "6.0.1", - "resolved": "https://registry.npmjs.org/parse5/-/parse5-6.0.1.tgz", - "integrity": "sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==" - }, - "parse5-htmlparser2-tree-adapter": { - "version": "6.0.1", - "resolved": "https://registry.npmjs.org/parse5-htmlparser2-tree-adapter/-/parse5-htmlparser2-tree-adapter-6.0.1.tgz", - "integrity": "sha512-qPuWvbLgvDGilKc5BoicRovlT4MtYT6JfJyBOMDsKoiT+GiuP5qyrPCnR9HcPECIJJmZh5jRndyNThnhhb/vlA==", - "requires": { - "parse5": "^6.0.1" - } - }, - "parseurl": { - "version": "1.3.3", - "resolved": "https://registry.npmjs.org/parseurl/-/parseurl-1.3.3.tgz", - "integrity": "sha512-CiyeOxFT/JZyN5m0z9PfXw4SCBJ6Sygz1Dpl0wqjlhDEGGBP1GnsUVEL0p63hoG1fcj3fHynXi9NYO4nWOL+qQ==" - }, - "pascalcase": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/pascalcase/-/pascalcase-0.1.1.tgz", - "integrity": "sha1-s2PlXoAGym/iF4TS2yK9FdeRfxQ=" - }, - "path-browserify": { - "version": "0.0.1", - "resolved": "https://registry.npmjs.org/path-browserify/-/path-browserify-0.0.1.tgz", - "integrity": "sha512-BapA40NHICOS+USX9SN4tyhq+A2RrN/Ws5F0Z5aMHDp98Fl86lX8Oti8B7uN93L4Ifv4fHOEA+pQw87gmMO/lQ==" - }, - "path-dirname": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/path-dirname/-/path-dirname-1.0.2.tgz", - "integrity": "sha1-zDPSTVJeCZpTiMAzbG4yuRYGCeA=" - }, - "path-exists": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz", - "integrity": "sha512-ak9Qy5Q7jYb2Wwcey5Fpvg2KoAc/ZIhLSLOSBmRmygPsGwkVVt0fZa0qrtMz+m6tJTAHfZQ8FnmB4MG4LWy7/w==" - }, - "path-is-absolute": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz", - "integrity": "sha1-F0uSaHNVNP+8es5r9TpanhtcX18=" - }, - "path-is-inside": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/path-is-inside/-/path-is-inside-1.0.2.tgz", - "integrity": "sha1-NlQX3t5EQw0cEa9hAn+s8HS9/FM=" - }, - "path-key": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/path-key/-/path-key-2.0.1.tgz", - "integrity": "sha1-QRyttXTFoUDTpLGRDUDYDMn0C0A=" - }, - "path-parse": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/path-parse/-/path-parse-1.0.6.tgz", - "integrity": "sha512-GSmOT2EbHrINBf9SR7CDELwlJ8AENk3Qn7OikK4nFYAu3Ote2+JYNVvkpAEQm3/TLNEJFD/xZJjzyxg3KBWOzw==" - }, - "path-to-regexp": { - "version": "0.1.7", - "resolved": "https://registry.npmjs.org/path-to-regexp/-/path-to-regexp-0.1.7.tgz", - "integrity": "sha1-32BBeABfUi8V60SQ5yR6G/qmf4w=" - }, - "path-type": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/path-type/-/path-type-3.0.0.tgz", - "integrity": "sha512-T2ZUsdZFHgA3u4e5PfPbjd7HDDpxPnQb5jN0SrDsjNSuVXHJqtwTnWqG0B1jZrgmJ/7lj1EmVIByWt1gxGkWvg==", - "requires": { - "pify": "^3.0.0" - }, - "dependencies": { - "pify": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pify/-/pify-3.0.0.tgz", - "integrity": "sha1-5aSs0sEB/fPZpNB/DbxNtJ3SgXY=" - } - } - }, - "pbkdf2": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/pbkdf2/-/pbkdf2-3.1.1.tgz", - "integrity": "sha512-4Ejy1OPxi9f2tt1rRV7Go7zmfDQ+ZectEQz3VGUQhgq62HtIRPDyG/JtnwIxs6x3uNMwo2V7q1fMvKjb+Tnpqg==", - "requires": { - "create-hash": "^1.1.2", - "create-hmac": "^1.1.4", - "ripemd160": "^2.0.1", - "safe-buffer": "^5.0.1", - "sha.js": "^2.4.8" - } - }, - "performance-now": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/performance-now/-/performance-now-2.1.0.tgz", - "integrity": "sha1-Ywn04OX6kT7BxpMHrjZLSzd8nns=" - }, - "picomatch": { - "version": "2.2.2", - "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.2.2.tgz", - "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg==", - "optional": true - }, - "pify": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/pify/-/pify-4.0.1.tgz", - "integrity": "sha512-uB80kBFb/tfd68bVleG9T5GGsGPjJrLAUpR5PZIrhBnIaRTQRjqdJSsIKkOP6OAIFbj7GOrcudc5pNjZ+geV2g==" - }, - "pinkie": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/pinkie/-/pinkie-2.0.4.tgz", - "integrity": "sha1-clVrgM+g1IqXToDnckjoDtT3+HA=" - }, - "pinkie-promise": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/pinkie-promise/-/pinkie-promise-2.0.1.tgz", - "integrity": "sha1-ITXW36ejWMBprJsXh3YogihFD/o=", - "requires": { - "pinkie": "^2.0.0" - } - }, - "pkg-dir": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-4.2.0.tgz", - "integrity": "sha512-HRDzbaKjC+AOWVXxAU/x54COGeIv9eb+6CkDSQoNTt4XyWoIJvuPsXizxu/Fr23EiekbtZwmh1IcIG/l/a10GQ==", - "requires": { - "find-up": "^4.0.0" - } - }, - "portfinder": { - "version": "1.0.28", - "resolved": "https://registry.npmjs.org/portfinder/-/portfinder-1.0.28.tgz", - "integrity": "sha512-Se+2isanIcEqf2XMHjyUKskczxbPH7dQnlMjXX6+dybayyHvAf/TCgyMRlzf/B6QDhAEFOGes0pzRo3by4AbMA==", - "requires": { - "async": "^2.6.2", - "debug": "^3.1.1", - "mkdirp": "^0.5.5" - }, - "dependencies": { - "debug": { - "version": "3.2.7", - "resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz", - "integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==", - "requires": { - "ms": "^2.1.1" - } - }, - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - }, - "ms": { - "version": "2.1.3", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", - "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==" - } - } - }, - "posix-character-classes": { - "version": "0.1.1", - "resolved": "https://registry.npmjs.org/posix-character-classes/-/posix-character-classes-0.1.1.tgz", - "integrity": "sha1-AerA/jta9xoqbAL+q7jB/vfgDqs=" - }, - "postcss": { - "version": "7.0.35", - "resolved": "https://registry.npmjs.org/postcss/-/postcss-7.0.35.tgz", - "integrity": "sha512-3QT8bBJeX/S5zKTTjTCIjRF3If4avAT6kqxcASlTWEtAFCb9NH0OUxNDfgZSWdP5fJnBYCMEWkIFfWeugjzYMg==", - "requires": { - "chalk": "^2.4.2", - "source-map": "^0.6.1", - "supports-color": "^6.1.0" - }, - "dependencies": { - "supports-color": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-6.1.0.tgz", - "integrity": "sha512-qe1jfm1Mg7Nq/NSh6XE24gPXROEVsWHxC1LIx//XNlD9iw7YZQGjZNjYN7xGaEG6iKdA8EtNFW6R0gjnVXp+wQ==", - "requires": { - "has-flag": "^3.0.0" - } - } - } - }, - "postcss-calc": { - "version": "7.0.5", - "resolved": "https://registry.npmjs.org/postcss-calc/-/postcss-calc-7.0.5.tgz", - "integrity": "sha512-1tKHutbGtLtEZF6PT4JSihCHfIVldU72mZ8SdZHIYriIZ9fh9k9aWSppaT8rHsyI3dX+KSR+W+Ix9BMY3AODrg==", - "requires": { - "postcss": "^7.0.27", - "postcss-selector-parser": "^6.0.2", - "postcss-value-parser": "^4.0.2" - } - }, - "postcss-colormin": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/postcss-colormin/-/postcss-colormin-4.0.3.tgz", - "integrity": "sha512-WyQFAdDZpExQh32j0U0feWisZ0dmOtPl44qYmJKkq9xFWY3p+4qnRzCHeNrkeRhwPHz9bQ3mo0/yVkaply0MNw==", - "requires": { - "browserslist": "^4.0.0", - "color": "^3.0.0", - "has": "^1.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-convert-values": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-convert-values/-/postcss-convert-values-4.0.1.tgz", - "integrity": "sha512-Kisdo1y77KUC0Jmn0OXU/COOJbzM8cImvw1ZFsBgBgMgb1iL23Zs/LXRe3r+EZqM3vGYKdQ2YJVQ5VkJI+zEJQ==", - "requires": { - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-discard-comments": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-discard-comments/-/postcss-discard-comments-4.0.2.tgz", - "integrity": "sha512-RJutN259iuRf3IW7GZyLM5Sw4GLTOH8FmsXBnv8Ab/Tc2k4SR4qbV4DNbyyY4+Sjo362SyDmW2DQ7lBSChrpkg==", - "requires": { - "postcss": "^7.0.0" - } - }, - "postcss-discard-duplicates": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-discard-duplicates/-/postcss-discard-duplicates-4.0.2.tgz", - "integrity": "sha512-ZNQfR1gPNAiXZhgENFfEglF93pciw0WxMkJeVmw8eF+JZBbMD7jp6C67GqJAXVZP2BWbOztKfbsdmMp/k8c6oQ==", - "requires": { - "postcss": "^7.0.0" - } - }, - "postcss-discard-empty": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-discard-empty/-/postcss-discard-empty-4.0.1.tgz", - "integrity": "sha512-B9miTzbznhDjTfjvipfHoqbWKwd0Mj+/fL5s1QOz06wufguil+Xheo4XpOnc4NqKYBCNqqEzgPv2aPBIJLox0w==", - "requires": { - "postcss": "^7.0.0" - } - }, - "postcss-discard-overridden": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-discard-overridden/-/postcss-discard-overridden-4.0.1.tgz", - "integrity": "sha512-IYY2bEDD7g1XM1IDEsUT4//iEYCxAmP5oDSFMVU/JVvT7gh+l4fmjciLqGgwjdWpQIdb0Che2VX00QObS5+cTg==", - "requires": { - "postcss": "^7.0.0" - } - }, - "postcss-load-config": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-2.1.2.tgz", - "integrity": "sha512-/rDeGV6vMUo3mwJZmeHfEDvwnTKKqQ0S7OHUi/kJvvtx3aWtyWG2/0ZWnzCt2keEclwN6Tf0DST2v9kITdOKYw==", - "requires": { - "cosmiconfig": "^5.0.0", - "import-cwd": "^2.0.0" - } - }, - "postcss-loader": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/postcss-loader/-/postcss-loader-3.0.0.tgz", - "integrity": "sha512-cLWoDEY5OwHcAjDnkyRQzAXfs2jrKjXpO/HQFcc5b5u/r7aa471wdmChmwfnv7x2u840iat/wi0lQ5nbRgSkUA==", - "requires": { - "loader-utils": "^1.1.0", - "postcss": "^7.0.0", - "postcss-load-config": "^2.0.0", - "schema-utils": "^1.0.0" - }, - "dependencies": { - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - } - } - }, - "postcss-merge-longhand": { - "version": "4.0.11", - "resolved": "https://registry.npmjs.org/postcss-merge-longhand/-/postcss-merge-longhand-4.0.11.tgz", - "integrity": "sha512-alx/zmoeXvJjp7L4mxEMjh8lxVlDFX1gqWHzaaQewwMZiVhLo42TEClKaeHbRf6J7j82ZOdTJ808RtN0ZOZwvw==", - "requires": { - "css-color-names": "0.0.4", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0", - "stylehacks": "^4.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-merge-rules": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/postcss-merge-rules/-/postcss-merge-rules-4.0.3.tgz", - "integrity": "sha512-U7e3r1SbvYzO0Jr3UT/zKBVgYYyhAz0aitvGIYOYK5CPmkNih+WDSsS5tvPrJ8YMQYlEMvsZIiqmn7HdFUaeEQ==", - "requires": { - "browserslist": "^4.0.0", - "caniuse-api": "^3.0.0", - "cssnano-util-same-parent": "^4.0.0", - "postcss": "^7.0.0", - "postcss-selector-parser": "^3.0.0", - "vendors": "^1.0.0" - }, - "dependencies": { - "postcss-selector-parser": { - "version": "3.1.2", - "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-3.1.2.tgz", - "integrity": "sha512-h7fJ/5uWuRVyOtkO45pnt1Ih40CEleeyCHzipqAZO2e5H20g25Y48uYnFUiShvY4rZWNJ/Bib/KVPmanaCtOhA==", - "requires": { - "dot-prop": "^5.2.0", - "indexes-of": "^1.0.1", - "uniq": "^1.0.1" - } - } - } - }, - "postcss-minify-font-values": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-minify-font-values/-/postcss-minify-font-values-4.0.2.tgz", - "integrity": "sha512-j85oO6OnRU9zPf04+PZv1LYIYOprWm6IA6zkXkrJXyRveDEuQggG6tvoy8ir8ZwjLxLuGfNkCZEQG7zan+Hbtg==", - "requires": { - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-minify-gradients": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-minify-gradients/-/postcss-minify-gradients-4.0.2.tgz", - "integrity": "sha512-qKPfwlONdcf/AndP1U8SJ/uzIJtowHlMaSioKzebAXSG4iJthlWC9iSWznQcX4f66gIWX44RSA841HTHj3wK+Q==", - "requires": { - "cssnano-util-get-arguments": "^4.0.0", - "is-color-stop": "^1.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-minify-params": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-minify-params/-/postcss-minify-params-4.0.2.tgz", - "integrity": "sha512-G7eWyzEx0xL4/wiBBJxJOz48zAKV2WG3iZOqVhPet/9geefm/Px5uo1fzlHu+DOjT+m0Mmiz3jkQzVHe6wxAWg==", - "requires": { - "alphanum-sort": "^1.0.0", - "browserslist": "^4.0.0", - "cssnano-util-get-arguments": "^4.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0", - "uniqs": "^2.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-minify-selectors": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-minify-selectors/-/postcss-minify-selectors-4.0.2.tgz", - "integrity": "sha512-D5S1iViljXBj9kflQo4YutWnJmwm8VvIsU1GeXJGiG9j8CIg9zs4voPMdQDUmIxetUOh60VilsNzCiAFTOqu3g==", - "requires": { - "alphanum-sort": "^1.0.0", - "has": "^1.0.0", - "postcss": "^7.0.0", - "postcss-selector-parser": "^3.0.0" - }, - "dependencies": { - "postcss-selector-parser": { - "version": "3.1.2", - "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-3.1.2.tgz", - "integrity": "sha512-h7fJ/5uWuRVyOtkO45pnt1Ih40CEleeyCHzipqAZO2e5H20g25Y48uYnFUiShvY4rZWNJ/Bib/KVPmanaCtOhA==", - "requires": { - "dot-prop": "^5.2.0", - "indexes-of": "^1.0.1", - "uniq": "^1.0.1" - } - } - } - }, - "postcss-modules-extract-imports": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/postcss-modules-extract-imports/-/postcss-modules-extract-imports-2.0.0.tgz", - "integrity": "sha512-LaYLDNS4SG8Q5WAWqIJgdHPJrDDr/Lv775rMBFUbgjTz6j34lUznACHcdRWroPvXANP2Vj7yNK57vp9eFqzLWQ==", - "requires": { - "postcss": "^7.0.5" - } - }, - "postcss-modules-local-by-default": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/postcss-modules-local-by-default/-/postcss-modules-local-by-default-2.0.6.tgz", - "integrity": "sha512-oLUV5YNkeIBa0yQl7EYnxMgy4N6noxmiwZStaEJUSe2xPMcdNc8WmBQuQCx18H5psYbVxz8zoHk0RAAYZXP9gA==", - "requires": { - "postcss": "^7.0.6", - "postcss-selector-parser": "^6.0.0", - "postcss-value-parser": "^3.3.1" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-modules-scope": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/postcss-modules-scope/-/postcss-modules-scope-2.2.0.tgz", - "integrity": "sha512-YyEgsTMRpNd+HmyC7H/mh3y+MeFWevy7V1evVhJWewmMbjDHIbZbOXICC2y+m1xI1UVfIT1HMW/O04Hxyu9oXQ==", - "requires": { - "postcss": "^7.0.6", - "postcss-selector-parser": "^6.0.0" - } - }, - "postcss-modules-values": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/postcss-modules-values/-/postcss-modules-values-2.0.0.tgz", - "integrity": "sha512-Ki7JZa7ff1N3EIMlPnGTZfUMe69FFwiQPnVSXC9mnn3jozCRBYIxiZd44yJOV2AmabOo4qFf8s0dC/+lweG7+w==", - "requires": { - "icss-replace-symbols": "^1.1.0", - "postcss": "^7.0.6" - } - }, - "postcss-normalize-charset": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-normalize-charset/-/postcss-normalize-charset-4.0.1.tgz", - "integrity": "sha512-gMXCrrlWh6G27U0hF3vNvR3w8I1s2wOBILvA87iNXaPvSNo5uZAMYsZG7XjCUf1eVxuPfyL4TJ7++SGZLc9A3g==", - "requires": { - "postcss": "^7.0.0" - } - }, - "postcss-normalize-display-values": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-normalize-display-values/-/postcss-normalize-display-values-4.0.2.tgz", - "integrity": "sha512-3F2jcsaMW7+VtRMAqf/3m4cPFhPD3EFRgNs18u+k3lTJJlVe7d0YPO+bnwqo2xg8YiRpDXJI2u8A0wqJxMsQuQ==", - "requires": { - "cssnano-util-get-match": "^4.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-positions": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-normalize-positions/-/postcss-normalize-positions-4.0.2.tgz", - "integrity": "sha512-Dlf3/9AxpxE+NF1fJxYDeggi5WwV35MXGFnnoccP/9qDtFrTArZ0D0R+iKcg5WsUd8nUYMIl8yXDCtcrT8JrdA==", - "requires": { - "cssnano-util-get-arguments": "^4.0.0", - "has": "^1.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-repeat-style": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-normalize-repeat-style/-/postcss-normalize-repeat-style-4.0.2.tgz", - "integrity": "sha512-qvigdYYMpSuoFs3Is/f5nHdRLJN/ITA7huIoCyqqENJe9PvPmLhNLMu7QTjPdtnVf6OcYYO5SHonx4+fbJE1+Q==", - "requires": { - "cssnano-util-get-arguments": "^4.0.0", - "cssnano-util-get-match": "^4.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-string": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-normalize-string/-/postcss-normalize-string-4.0.2.tgz", - "integrity": "sha512-RrERod97Dnwqq49WNz8qo66ps0swYZDSb6rM57kN2J+aoyEAJfZ6bMx0sx/F9TIEX0xthPGCmeyiam/jXif0eA==", - "requires": { - "has": "^1.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-timing-functions": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-normalize-timing-functions/-/postcss-normalize-timing-functions-4.0.2.tgz", - "integrity": "sha512-acwJY95edP762e++00Ehq9L4sZCEcOPyaHwoaFOhIwWCDfik6YvqsYNxckee65JHLKzuNSSmAdxwD2Cud1Z54A==", - "requires": { - "cssnano-util-get-match": "^4.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-unicode": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-normalize-unicode/-/postcss-normalize-unicode-4.0.1.tgz", - "integrity": "sha512-od18Uq2wCYn+vZ/qCOeutvHjB5jm57ToxRaMeNuf0nWVHaP9Hua56QyMF6fs/4FSUnVIw0CBPsU0K4LnBPwYwg==", - "requires": { - "browserslist": "^4.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-url": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-normalize-url/-/postcss-normalize-url-4.0.1.tgz", - "integrity": "sha512-p5oVaF4+IHwu7VpMan/SSpmpYxcJMtkGppYf0VbdH5B6hN8YNmVyJLuY9FmLQTzY3fag5ESUUHDqM+heid0UVA==", - "requires": { - "is-absolute-url": "^2.0.0", - "normalize-url": "^3.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "normalize-url": { - "version": "3.3.0", - "resolved": "https://registry.npmjs.org/normalize-url/-/normalize-url-3.3.0.tgz", - "integrity": "sha512-U+JJi7duF1o+u2pynbp2zXDW2/PADgC30f0GsHZtRh+HOcXHnw137TrNlyxxRvWW5fjKd3bcLHPxofWuCjaeZg==" - }, - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-normalize-whitespace": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-normalize-whitespace/-/postcss-normalize-whitespace-4.0.2.tgz", - "integrity": "sha512-tO8QIgrsI3p95r8fyqKV+ufKlSHh9hMJqACqbv2XknufqEDhDvbguXGBBqxw9nsQoXWf0qOqppziKJKHMD4GtA==", - "requires": { - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-ordered-values": { - "version": "4.1.2", - "resolved": "https://registry.npmjs.org/postcss-ordered-values/-/postcss-ordered-values-4.1.2.tgz", - "integrity": "sha512-2fCObh5UanxvSxeXrtLtlwVThBvHn6MQcu4ksNT2tsaV2Fg76R2CV98W7wNSlX+5/pFwEyaDwKLLoEV7uRybAw==", - "requires": { - "cssnano-util-get-arguments": "^4.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-reduce-initial": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/postcss-reduce-initial/-/postcss-reduce-initial-4.0.3.tgz", - "integrity": "sha512-gKWmR5aUulSjbzOfD9AlJiHCGH6AEVLaM0AV+aSioxUDd16qXP1PCh8d1/BGVvpdWn8k/HiK7n6TjeoXN1F7DA==", - "requires": { - "browserslist": "^4.0.0", - "caniuse-api": "^3.0.0", - "has": "^1.0.0", - "postcss": "^7.0.0" - } - }, - "postcss-reduce-transforms": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-reduce-transforms/-/postcss-reduce-transforms-4.0.2.tgz", - "integrity": "sha512-EEVig1Q2QJ4ELpJXMZR8Vt5DQx8/mo+dGWSR7vWXqcob2gQLyQGsionYcGKATXvQzMPn6DSN1vTN7yFximdIAg==", - "requires": { - "cssnano-util-get-match": "^4.0.0", - "has": "^1.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-safe-parser": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-safe-parser/-/postcss-safe-parser-4.0.2.tgz", - "integrity": "sha512-Uw6ekxSWNLCPesSv/cmqf2bY/77z11O7jZGPax3ycZMFU/oi2DMH9i89AdHc1tRwFg/arFoEwX0IS3LCUxJh1g==", - "requires": { - "postcss": "^7.0.26" - } - }, - "postcss-selector-parser": { - "version": "6.0.4", - "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-6.0.4.tgz", - "integrity": "sha512-gjMeXBempyInaBqpp8gODmwZ52WaYsVOsfr4L4lDQ7n3ncD6mEyySiDtgzCT+NYC0mmeOLvtsF8iaEf0YT6dBw==", - "requires": { - "cssesc": "^3.0.0", - "indexes-of": "^1.0.1", - "uniq": "^1.0.1", - "util-deprecate": "^1.0.2" - } - }, - "postcss-svgo": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/postcss-svgo/-/postcss-svgo-4.0.2.tgz", - "integrity": "sha512-C6wyjo3VwFm0QgBy+Fu7gCYOkCmgmClghO+pjcxvrcBKtiKt0uCF+hvbMO1fyv5BMImRK90SMb+dwUnfbGd+jw==", - "requires": { - "is-svg": "^3.0.0", - "postcss": "^7.0.0", - "postcss-value-parser": "^3.0.0", - "svgo": "^1.0.0" - }, - "dependencies": { - "postcss-value-parser": { - "version": "3.3.1", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.1.tgz", - "integrity": "sha512-pISE66AbVkp4fDQ7VHBwRNXzAAKJjw4Vw7nWI/+Q3vuly7SNfgYXvm6i5IgFylHGK5sP/xHAbB7N49OS4gWNyQ==" - } - } - }, - "postcss-unique-selectors": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/postcss-unique-selectors/-/postcss-unique-selectors-4.0.1.tgz", - "integrity": "sha512-+JanVaryLo9QwZjKrmJgkI4Fn8SBgRO6WXQBJi7KiAVPlmxikB5Jzc4EvXMT2H0/m0RjrVVm9rGNhZddm/8Spg==", - "requires": { - "alphanum-sort": "^1.0.0", - "postcss": "^7.0.0", - "uniqs": "^2.0.0" - } - }, - "postcss-value-parser": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.1.0.tgz", - "integrity": "sha512-97DXOFbQJhk71ne5/Mt6cOu6yxsSfM0QGQyl0L25Gca4yGWEGJaig7l7gbCX623VqTBNGLRLaVUCnNkcedlRSQ==" - }, - "prepend-http": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/prepend-http/-/prepend-http-2.0.0.tgz", - "integrity": "sha1-6SQ0v6XqjBn0HN/UAddBo8gZ2Jc=" - }, - "prettier": { - "version": "1.19.1", - "resolved": "https://registry.npmjs.org/prettier/-/prettier-1.19.1.tgz", - "integrity": "sha512-s7PoyDv/II1ObgQunCbB9PdLmUcBZcnWOcxDh7O0N/UwDEsHyqkW+Qh28jW+mVuCdx7gLB0BotYI1Y6uI9iyew==", - "optional": true - }, - "pretty-error": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/pretty-error/-/pretty-error-2.1.2.tgz", - "integrity": "sha512-EY5oDzmsX5wvuynAByrmY0P0hcp+QpnAKbJng2A2MPjVKXCxrDSUkzghVJ4ZGPIv+JC4gX8fPUWscC0RtjsWGw==", - "requires": { - "lodash": "^4.17.20", - "renderkid": "^2.0.4" - } - }, - "pretty-time": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/pretty-time/-/pretty-time-1.1.0.tgz", - "integrity": "sha512-28iF6xPQrP8Oa6uxE6a1biz+lWeTOAPKggvjB8HAs6nVMKZwf5bG++632Dx614hIWgUPkgivRfG+a8uAXGTIbA==" - }, - "prismjs": { - "version": "1.23.0", - "resolved": "https://registry.npmjs.org/prismjs/-/prismjs-1.23.0.tgz", - "integrity": "sha512-c29LVsqOaLbBHuIbsTxaKENh1N2EQBOHaWv7gkHN4dgRbxSREqDnDbtFJYdpPauS4YCplMSNCABQ6Eeor69bAA==", - "requires": { - "clipboard": "^2.0.0" - } - }, - "process": { - "version": "0.11.10", - "resolved": "https://registry.npmjs.org/process/-/process-0.11.10.tgz", - "integrity": "sha1-czIwDoQBYb2j5podHZGn1LwW8YI=" - }, - "process-nextick-args": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/process-nextick-args/-/process-nextick-args-2.0.1.tgz", - "integrity": "sha512-3ouUOpQhtgrbOa17J7+uxOTpITYWaGP7/AhoR3+A+/1e9skrzelGi/dXzEYyvbxubEF6Wn2ypscTKiKJFFn1ag==" - }, - "promise": { - "version": "7.3.1", - "resolved": "https://registry.npmjs.org/promise/-/promise-7.3.1.tgz", - "integrity": "sha512-nolQXZ/4L+bP/UGlkfaIujX9BKxGwmQ9OT4mOt5yvy8iK1h3wqTEJCijzGANTCCl9nWjY41juyAn2K3Q1hLLTg==", - "requires": { - "asap": "~2.0.3" - } - }, - "promise-inflight": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/promise-inflight/-/promise-inflight-1.0.1.tgz", - "integrity": "sha1-mEcocL8igTL8vdhoEputEsPAKeM=" - }, - "proxy-addr": { - "version": "2.0.6", - "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.6.tgz", - "integrity": "sha512-dh/frvCBVmSsDYzw6n926jv974gddhkFPfiN8hPOi30Wax25QZyZEGveluCgliBnqmuM+UJmBErbAUFIoDbjOw==", - "requires": { - "forwarded": "~0.1.2", - "ipaddr.js": "1.9.1" - } - }, - "prr": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/prr/-/prr-1.0.1.tgz", - "integrity": "sha1-0/wRS6BplaRexok/SEzrHXj19HY=" - }, - "pseudomap": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/pseudomap/-/pseudomap-1.0.2.tgz", - "integrity": "sha1-8FKijacOYYkX7wqKw0wa5aaChrM=" - }, - "psl": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/psl/-/psl-1.8.0.tgz", - "integrity": "sha512-RIdOzyoavK+hA18OGGWDqUTsCLhtA7IcZ/6NCs4fFJaHBDab+pDDmDIByWFRQJq2Cd7r1OoQxBGKOaztq+hjIQ==" - }, - "public-encrypt": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/public-encrypt/-/public-encrypt-4.0.3.tgz", - "integrity": "sha512-zVpa8oKZSz5bTMTFClc1fQOnyyEzpl5ozpi1B5YcvBrdohMjH2rfsBtyXcuNuwjsDIXmBYlF2N5FlJYhR29t8Q==", - "requires": { - "bn.js": "^4.1.0", - "browserify-rsa": "^4.0.0", - "create-hash": "^1.1.0", - "parse-asn1": "^5.0.0", - "randombytes": "^2.0.1", - "safe-buffer": "^5.1.2" - }, - "dependencies": { - "bn.js": { - "version": "4.11.9", - "resolved": "https://registry.npmjs.org/bn.js/-/bn.js-4.11.9.tgz", - "integrity": "sha512-E6QoYqCKZfgatHTdHzs1RRKP7ip4vvm+EyRUeE2RF0NblwVvb0p6jSVeNTOFxPn26QXN2o6SMfNxKp6kU8zQaw==" - } - } - }, - "pug": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/pug/-/pug-2.0.4.tgz", - "integrity": "sha512-XhoaDlvi6NIzL49nu094R2NA6P37ijtgMDuWE+ofekDChvfKnzFal60bhSdiy8y2PBO6fmz3oMEIcfpBVRUdvw==", - "requires": { - "pug-code-gen": "^2.0.2", - "pug-filters": "^3.1.1", - "pug-lexer": "^4.1.0", - "pug-linker": "^3.0.6", - "pug-load": "^2.0.12", - "pug-parser": "^5.0.1", - "pug-runtime": "^2.0.5", - "pug-strip-comments": "^1.0.4" - } - }, - "pug-attrs": { - "version": "2.0.4", - "resolved": "https://registry.npmjs.org/pug-attrs/-/pug-attrs-2.0.4.tgz", - "integrity": "sha512-TaZ4Z2TWUPDJcV3wjU3RtUXMrd3kM4Wzjbe3EWnSsZPsJ3LDI0F3yCnf2/W7PPFF+edUFQ0HgDL1IoxSz5K8EQ==", - "requires": { - "constantinople": "^3.0.1", - "js-stringify": "^1.0.1", - "pug-runtime": "^2.0.5" - } - }, - "pug-code-gen": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/pug-code-gen/-/pug-code-gen-2.0.2.tgz", - "integrity": "sha512-kROFWv/AHx/9CRgoGJeRSm+4mLWchbgpRzTEn8XCiwwOy6Vh0gAClS8Vh5TEJ9DBjaP8wCjS3J6HKsEsYdvaCw==", - "requires": { - "constantinople": "^3.1.2", - "doctypes": "^1.1.0", - "js-stringify": "^1.0.1", - "pug-attrs": "^2.0.4", - "pug-error": "^1.3.3", - "pug-runtime": "^2.0.5", - "void-elements": "^2.0.1", - "with": "^5.0.0" - } - }, - "pug-error": { - "version": "1.3.3", - "resolved": "https://registry.npmjs.org/pug-error/-/pug-error-1.3.3.tgz", - "integrity": "sha512-qE3YhESP2mRAWMFJgKdtT5D7ckThRScXRwkfo+Erqga7dyJdY3ZquspprMCj/9sJ2ijm5hXFWQE/A3l4poMWiQ==" - }, - "pug-filters": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/pug-filters/-/pug-filters-3.1.1.tgz", - "integrity": "sha512-lFfjNyGEyVWC4BwX0WyvkoWLapI5xHSM3xZJFUhx4JM4XyyRdO8Aucc6pCygnqV2uSgJFaJWW3Ft1wCWSoQkQg==", - "requires": { - "clean-css": "^4.1.11", - "constantinople": "^3.0.1", - "jstransformer": "1.0.0", - "pug-error": "^1.3.3", - "pug-walk": "^1.1.8", - "resolve": "^1.1.6", - "uglify-js": "^2.6.1" - } - }, - "pug-lexer": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/pug-lexer/-/pug-lexer-4.1.0.tgz", - "integrity": "sha512-i55yzEBtjm0mlplW4LoANq7k3S8gDdfC6+LThGEvsK4FuobcKfDAwt6V4jKPH9RtiE3a2Akfg5UpafZ1OksaPA==", - "requires": { - "character-parser": "^2.1.1", - "is-expression": "^3.0.0", - "pug-error": "^1.3.3" - } - }, - "pug-linker": { - "version": "3.0.6", - "resolved": "https://registry.npmjs.org/pug-linker/-/pug-linker-3.0.6.tgz", - "integrity": "sha512-bagfuHttfQOpANGy1Y6NJ+0mNb7dD2MswFG2ZKj22s8g0wVsojpRlqveEQHmgXXcfROB2RT6oqbPYr9EN2ZWzg==", - "requires": { - "pug-error": "^1.3.3", - "pug-walk": "^1.1.8" - } - }, - "pug-load": { - "version": "2.0.12", - "resolved": "https://registry.npmjs.org/pug-load/-/pug-load-2.0.12.tgz", - "integrity": "sha512-UqpgGpyyXRYgJs/X60sE6SIf8UBsmcHYKNaOccyVLEuT6OPBIMo6xMPhoJnqtB3Q3BbO4Z3Bjz5qDsUWh4rXsg==", - "requires": { - "object-assign": "^4.1.0", - "pug-walk": "^1.1.8" - } - }, - "pug-parser": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/pug-parser/-/pug-parser-5.0.1.tgz", - "integrity": "sha512-nGHqK+w07p5/PsPIyzkTQfzlYfuqoiGjaoqHv1LjOv2ZLXmGX1O+4Vcvps+P4LhxZ3drYSljjq4b+Naid126wA==", - "requires": { - "pug-error": "^1.3.3", - "token-stream": "0.0.1" - } - }, - "pug-plain-loader": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/pug-plain-loader/-/pug-plain-loader-1.1.0.tgz", - "integrity": "sha512-1nYgIJLaahRuHJHhzSPODV44aZfb00bO7kiJiMkke6Hj4SVZftuvx6shZ4BOokk50dJc2RSFqNUBOlus0dniFQ==", - "requires": { - "loader-utils": "^1.1.0" - } - }, - "pug-runtime": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/pug-runtime/-/pug-runtime-2.0.5.tgz", - "integrity": "sha512-P+rXKn9un4fQY77wtpcuFyvFaBww7/91f3jHa154qU26qFAnOe6SW1CbIDcxiG5lLK9HazYrMCCuDvNgDQNptw==" - }, - "pug-strip-comments": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/pug-strip-comments/-/pug-strip-comments-1.0.4.tgz", - "integrity": "sha512-i5j/9CS4yFhSxHp5iKPHwigaig/VV9g+FgReLJWWHEHbvKsbqL0oP/K5ubuLco6Wu3Kan5p7u7qk8A4oLLh6vw==", - "requires": { - "pug-error": "^1.3.3" - } - }, - "pug-walk": { - "version": "1.1.8", - "resolved": "https://registry.npmjs.org/pug-walk/-/pug-walk-1.1.8.tgz", - "integrity": "sha512-GMu3M5nUL3fju4/egXwZO0XLi6fW/K3T3VTgFQ14GxNi8btlxgT5qZL//JwZFm/2Fa64J/PNS8AZeys3wiMkVA==" - }, - "pump": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pump/-/pump-3.0.0.tgz", - "integrity": "sha512-LwZy+p3SFs1Pytd/jYct4wpv49HiYCqd9Rlc5ZVdk0V+8Yzv6jR5Blk3TRmPL1ft69TxP0IMZGJ+WPFU2BFhww==", - "requires": { - "end-of-stream": "^1.1.0", - "once": "^1.3.1" - } - }, - "pumpify": { - "version": "1.5.1", - "resolved": "https://registry.npmjs.org/pumpify/-/pumpify-1.5.1.tgz", - "integrity": "sha512-oClZI37HvuUJJxSKKrC17bZ9Cu0ZYhEAGPsPUy9KlMUmv9dKX2o77RUmq7f3XjIxbwyGwYzbzQ1L2Ks8sIradQ==", - "requires": { - "duplexify": "^3.6.0", - "inherits": "^2.0.3", - "pump": "^2.0.0" - }, - "dependencies": { - "pump": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/pump/-/pump-2.0.1.tgz", - "integrity": "sha512-ruPMNRkN3MHP1cWJc9OWr+T/xDP0jhXYCLfJcBuX54hhfIBnaQmAUMfDcG4DM5UMWByBbJY69QSphm3jtDKIkA==", - "requires": { - "end-of-stream": "^1.1.0", - "once": "^1.3.1" - } - } - } - }, - "punycode": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/punycode/-/punycode-2.1.1.tgz", - "integrity": "sha512-XRsRjdf+j5ml+y/6GKHPZbrF/8p2Yga0JPtdqTIY2Xe5ohJPD9saDJJLPvp9+NSBprVvevdXZybnj2cv8OEd0A==" - }, - "pupa": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/pupa/-/pupa-2.1.1.tgz", - "integrity": "sha512-l1jNAspIBSFqbT+y+5FosojNpVpF94nlI+wDUpqP9enwOTfHx9f0gh5nB96vl+6yTpsJsypeNrwfzPrKuHB41A==", - "requires": { - "escape-goat": "^2.0.0" - } - }, - "q": { - "version": "1.5.1", - "resolved": "https://registry.npmjs.org/q/-/q-1.5.1.tgz", - "integrity": "sha1-fjL3W0E4EpHQRhHxvxQQmsAGUdc=" - }, - "qs": { - "version": "6.7.0", - "resolved": "https://registry.npmjs.org/qs/-/qs-6.7.0.tgz", - "integrity": "sha512-VCdBRNFTX1fyE7Nb6FYoURo/SPe62QCaAyzJvUjwRaIsc+NePBEniHlvxFmmX56+HZphIGtV0XeCirBtpDrTyQ==" - }, - "query-string": { - "version": "5.1.1", - "resolved": "https://registry.npmjs.org/query-string/-/query-string-5.1.1.tgz", - "integrity": "sha512-gjWOsm2SoGlgLEdAGt7a6slVOk9mGiXmPFMqrEhLQ68rhQuBnpfs3+EmlvqKyxnCo9/PPlF+9MtY02S1aFg+Jw==", - "requires": { - "decode-uri-component": "^0.2.0", - "object-assign": "^4.1.0", - "strict-uri-encode": "^1.0.0" - } - }, - "querystring": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/querystring/-/querystring-0.2.0.tgz", - "integrity": "sha1-sgmEkgO7Jd+CDadW50cAWHhSFiA=" - }, - "querystring-es3": { - "version": "0.2.1", - "resolved": "https://registry.npmjs.org/querystring-es3/-/querystring-es3-0.2.1.tgz", - "integrity": "sha1-nsYfeQSYdXB9aUFFlv2Qek1xHnM=" - }, - "querystringify": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/querystringify/-/querystringify-2.2.0.tgz", - "integrity": "sha512-FIqgj2EUvTa7R50u0rGsyTftzjYmv/a3hO345bZNrqabNqjtgiDMgmo4mkUjd+nzU5oF3dClKqFIPUKybUyqoQ==" - }, - "randombytes": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/randombytes/-/randombytes-2.1.0.tgz", - "integrity": "sha512-vYl3iOX+4CKUWuxGi9Ukhie6fsqXqS9FE2Zaic4tNFD2N2QQaXOMFbuKK4QmDHC0JO6B1Zp41J0LpT0oR68amQ==", - "requires": { - "safe-buffer": "^5.1.0" - } - }, - "randomfill": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/randomfill/-/randomfill-1.0.4.tgz", - "integrity": "sha512-87lcbR8+MhcWcUiQ+9e+Rwx8MyR2P7qnt15ynUlbm3TU/fjbgz4GsvfSUDTemtCCtVCqb4ZcEFlyPNTh9bBTLw==", - "requires": { - "randombytes": "^2.0.5", - "safe-buffer": "^5.1.0" - } - }, - "range-parser": { - "version": "1.2.1", - "resolved": "https://registry.npmjs.org/range-parser/-/range-parser-1.2.1.tgz", - "integrity": "sha512-Hrgsx+orqoygnmhFbKaHE6c296J+HTAQXoxEF6gNupROmmGJRoyzfG3ccAveqCBrwr/2yxQ5BVd/GTl5agOwSg==" - }, - "raw-body": { - "version": "2.4.0", - "resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.4.0.tgz", - "integrity": "sha512-4Oz8DUIwdvoa5qMJelxipzi/iJIi40O5cGV1wNYp5hvZP8ZN0T+jiNkL0QepXs+EsQ9XJ8ipEDoiH70ySUJP3Q==", - "requires": { - "bytes": "3.1.0", - "http-errors": "1.7.2", - "iconv-lite": "0.4.24", - "unpipe": "1.0.0" - }, - "dependencies": { - "bytes": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/bytes/-/bytes-3.1.0.tgz", - "integrity": "sha512-zauLjrfCG+xvoyaqLoV8bLVXXNGC4JqlxFCutSDWA6fJrTo2ZuvLYTqZ7aHBLZSMOopbzwv8f+wZcVzfVTI2Dg==" - } - } - }, - "rc": { - "version": "1.2.8", - "resolved": "https://registry.npmjs.org/rc/-/rc-1.2.8.tgz", - "integrity": "sha512-y3bGgqKj3QBdxLbLkomlohkvsA8gdAiUQlSBJnBhfn+BPxg4bc62d8TcBW15wavDfgexCgccckhcZvywyQYPOw==", - "requires": { - "deep-extend": "^0.6.0", - "ini": "~1.3.0", - "minimist": "^1.2.0", - "strip-json-comments": "~2.0.1" - } - }, - "readable-stream": { - "version": "2.3.7", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.7.tgz", - "integrity": "sha512-Ebho8K4jIbHAxnuxi7o42OrZgF/ZTNcsZj6nRKyUmkhLFq8CHItp/fy6hQZuZmP/n3yZ9VBUbp4zz/mX8hmYPw==", - "requires": { - "core-util-is": "~1.0.0", - "inherits": "~2.0.3", - "isarray": "~1.0.0", - "process-nextick-args": "~2.0.0", - "safe-buffer": "~5.1.1", - "string_decoder": "~1.1.1", - "util-deprecate": "~1.0.1" - } - }, - "readdirp": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-2.2.1.tgz", - "integrity": "sha512-1JU/8q+VgFZyxwrJ+SVIOsh+KywWGpds3NTqikiKpDMZWScmAYyKIgqkO+ARvNWJfXeXR1zxz7aHF4u4CyH6vQ==", - "requires": { - "graceful-fs": "^4.1.11", - "micromatch": "^3.1.10", - "readable-stream": "^2.0.2" - } - }, - "reduce": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/reduce/-/reduce-1.0.2.tgz", - "integrity": "sha512-xX7Fxke/oHO5IfZSk77lvPa/7bjMh9BuCk4OOoX5XTXrM7s0Z+MkPfSDfz0q7r91BhhGSs8gii/VEN/7zhCPpQ==", - "requires": { - "object-keys": "^1.1.0" - } - }, - "regenerate": { - "version": "1.4.2", - "resolved": "https://registry.npmjs.org/regenerate/-/regenerate-1.4.2.tgz", - "integrity": "sha512-zrceR/XhGYU/d/opr2EKO7aRHUeiBI8qjtfHqADTwZd6Szfy16la6kqD0MIUs5z5hx6AaKa+PixpPrR289+I0A==" - }, - "regenerate-unicode-properties": { - "version": "8.2.0", - "resolved": "https://registry.npmjs.org/regenerate-unicode-properties/-/regenerate-unicode-properties-8.2.0.tgz", - "integrity": "sha512-F9DjY1vKLo/tPePDycuH3dn9H1OTPIkVD9Kz4LODu+F2C75mgjAJ7x/gwy6ZcSNRAAkhNlJSOHRe8k3p+K9WhA==", - "requires": { - "regenerate": "^1.4.0" - } - }, - "regenerator-runtime": { - "version": "0.11.1", - "resolved": "https://registry.npmjs.org/regenerator-runtime/-/regenerator-runtime-0.11.1.tgz", - "integrity": "sha512-MguG95oij0fC3QV3URf4V2SDYGJhJnJGqvIIgdECeODCT98wSWDAJ94SSuVpYQUoTcGUIL6L4yNB7j1DFFHSBg==" - }, - "regenerator-transform": { - "version": "0.14.5", - "resolved": "https://registry.npmjs.org/regenerator-transform/-/regenerator-transform-0.14.5.tgz", - "integrity": "sha512-eOf6vka5IO151Jfsw2NO9WpGX58W6wWmefK3I1zEGr0lOD0u8rwPaNqQL1aRxUaxLeKO3ArNh3VYg1KbaD+FFw==", - "requires": { - "@babel/runtime": "^7.8.4" - } - }, - "regex-not": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/regex-not/-/regex-not-1.0.2.tgz", - "integrity": "sha512-J6SDjUgDxQj5NusnOtdFxDwN/+HWykR8GELwctJ7mdqhcyy1xEc4SRFHUXvxTp661YaVKAjfRLZ9cCqS6tn32A==", - "requires": { - "extend-shallow": "^3.0.2", - "safe-regex": "^1.1.0" - }, - "dependencies": { - "extend-shallow": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-3.0.2.tgz", - "integrity": "sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=", - "requires": { - "assign-symbols": "^1.0.0", - "is-extendable": "^1.0.1" - } - }, - "is-extendable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz", - "integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==", - "requires": { - "is-plain-object": "^2.0.4" - } - } - } - }, - "regexp.prototype.flags": { - "version": "1.3.1", - "resolved": "https://registry.npmjs.org/regexp.prototype.flags/-/regexp.prototype.flags-1.3.1.tgz", - "integrity": "sha512-JiBdRBq91WlY7uRJ0ds7R+dU02i6LKi8r3BuQhNXn+kmeLN+EfHhfjqMRis1zJxnlu88hq/4dx0P2OP3APRTOA==", - "requires": { - "call-bind": "^1.0.2", - "define-properties": "^1.1.3" - } - }, - "regexpu-core": { - "version": "4.7.1", - "resolved": "https://registry.npmjs.org/regexpu-core/-/regexpu-core-4.7.1.tgz", - "integrity": "sha512-ywH2VUraA44DZQuRKzARmw6S66mr48pQVva4LBeRhcOltJ6hExvWly5ZjFLYo67xbIxb6W1q4bAGtgfEl20zfQ==", - "requires": { - "regenerate": "^1.4.0", - "regenerate-unicode-properties": "^8.2.0", - "regjsgen": "^0.5.1", - "regjsparser": "^0.6.4", - "unicode-match-property-ecmascript": "^1.0.4", - "unicode-match-property-value-ecmascript": "^1.2.0" - } - }, - "registry-auth-token": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/registry-auth-token/-/registry-auth-token-4.2.1.tgz", - "integrity": "sha512-6gkSb4U6aWJB4SF2ZvLb76yCBjcvufXBqvvEx1HbmKPkutswjW1xNVRY0+daljIYRbogN7O0etYSlbiaEQyMyw==", - "requires": { - "rc": "^1.2.8" - } - }, - "registry-url": { - "version": "5.1.0", - "resolved": "https://registry.npmjs.org/registry-url/-/registry-url-5.1.0.tgz", - "integrity": "sha512-8acYXXTI0AkQv6RAOjE3vOaIXZkT9wo4LOFbBKYQEEnnMNBpKqdUrI6S4NT0KPIo/WVvJ5tE/X5LF/TQUf0ekw==", - "requires": { - "rc": "^1.2.8" - } - }, - "regjsgen": { - "version": "0.5.2", - "resolved": "https://registry.npmjs.org/regjsgen/-/regjsgen-0.5.2.tgz", - "integrity": "sha512-OFFT3MfrH90xIW8OOSyUrk6QHD5E9JOTeGodiJeBS3J6IwlgzJMNE/1bZklWz5oTg+9dCMyEetclvCVXOPoN3A==" - }, - "regjsparser": { - "version": "0.6.6", - "resolved": "https://registry.npmjs.org/regjsparser/-/regjsparser-0.6.6.tgz", - "integrity": "sha512-jjyuCp+IEMIm3N1H1LLTJW1EISEJV9+5oHdEyrt43Pg9cDSb6rrLZei2cVWpl0xTjmmlpec/lEQGYgM7xfpGCQ==", - "requires": { - "jsesc": "~0.5.0" - }, - "dependencies": { - "jsesc": { - "version": "0.5.0", - "resolved": "https://registry.npmjs.org/jsesc/-/jsesc-0.5.0.tgz", - "integrity": "sha1-597mbjXW/Bb3EP6R1c9p9w8IkR0=" - } - } - }, - "relateurl": { - "version": "0.2.7", - "resolved": "https://registry.npmjs.org/relateurl/-/relateurl-0.2.7.tgz", - "integrity": "sha1-VNvzd+UUQKypCkzSdGANP/LYiKk=" - }, - "remove-trailing-separator": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/remove-trailing-separator/-/remove-trailing-separator-1.1.0.tgz", - "integrity": "sha1-wkvOKig62tW8P1jg1IJJuSN52O8=" - }, - "renderkid": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/renderkid/-/renderkid-2.0.5.tgz", - "integrity": "sha512-ccqoLg+HLOHq1vdfYNm4TBeaCDIi1FLt3wGojTDSvdewUv65oTmI3cnT2E4hRjl1gzKZIPK+KZrXzlUYKnR+vQ==", - "requires": { - "css-select": "^2.0.2", - "dom-converter": "^0.2", - "htmlparser2": "^3.10.1", - "lodash": "^4.17.20", - "strip-ansi": "^3.0.0" - }, - "dependencies": { - "css-select": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/css-select/-/css-select-2.1.0.tgz", - "integrity": "sha512-Dqk7LQKpwLoH3VovzZnkzegqNSuAziQyNZUcrdDM401iY+R5NkGBXGmtO05/yaXQziALuPogeG0b7UAgjnTJTQ==", - "requires": { - "boolbase": "^1.0.0", - "css-what": "^3.2.1", - "domutils": "^1.7.0", - "nth-check": "^1.0.2" - } - }, - "css-what": { - "version": "3.4.2", - "resolved": "https://registry.npmjs.org/css-what/-/css-what-3.4.2.tgz", - "integrity": "sha512-ACUm3L0/jiZTqfzRM3Hi9Q8eZqd6IK37mMWPLz9PJxkLWllYeRf+EHUSHYEtFop2Eqytaq1FizFVh7XfBnXCDQ==" - }, - "dom-serializer": { - "version": "0.2.2", - "resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-0.2.2.tgz", - "integrity": "sha512-2/xPb3ORsQ42nHYiSunXkDjPLBaEj/xTwUO4B7XCZQTRk7EBtTOPaygh10YAAh2OI1Qrp6NWfpAhzswj0ydt9g==", - "requires": { - "domelementtype": "^2.0.1", - "entities": "^2.0.0" - }, - "dependencies": { - "domelementtype": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.1.0.tgz", - "integrity": "sha512-LsTgx/L5VpD+Q8lmsXSHW2WpA+eBlZ9HPf3erD1IoPF00/3JKHZ3BknUVA2QGDNu69ZNmyFmCWBSO45XjYKC5w==" - } - } - }, - "domelementtype": { - "version": "1.3.1", - "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-1.3.1.tgz", - "integrity": "sha512-BSKB+TSpMpFI/HOxCNr1O8aMOTZ8hT3pM3GQ0w/mWRmkhEDSFJkkyzz4XQsBV44BChwGkrDfMyjVD0eA2aFV3w==" - }, - "domhandler": { - "version": "2.4.2", - "resolved": "https://registry.npmjs.org/domhandler/-/domhandler-2.4.2.tgz", - "integrity": "sha512-JiK04h0Ht5u/80fdLMCEmV4zkNh2BcoMFBmZ/91WtYZ8qVXSKjiw7fXMgFPnHcSZgOo3XdinHvmnDUeMf5R4wA==", - "requires": { - "domelementtype": "1" - } - }, - "domutils": { - "version": "1.7.0", - "resolved": "https://registry.npmjs.org/domutils/-/domutils-1.7.0.tgz", - "integrity": "sha512-Lgd2XcJ/NjEw+7tFvfKxOzCYKZsdct5lczQ2ZaQY8Djz7pfAD3Gbp8ySJWtreII/vDlMVmxwa6pHmdxIYgttDg==", - "requires": { - "dom-serializer": "0", - "domelementtype": "1" - } - }, - "htmlparser2": { - "version": "3.10.1", - "resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-3.10.1.tgz", - "integrity": "sha512-IgieNijUMbkDovyoKObU1DUhm1iwNYE/fuifEoEHfd1oZKZDaONBSkal7Y01shxsM49R4XaMdGez3WnF9UfiCQ==", - "requires": { - "domelementtype": "^1.3.1", - "domhandler": "^2.3.0", - "domutils": "^1.5.1", - "entities": "^1.1.1", - "inherits": "^2.0.1", - "readable-stream": "^3.1.1" - }, - "dependencies": { - "entities": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/entities/-/entities-1.1.2.tgz", - "integrity": "sha512-f2LZMYl1Fzu7YSBKg+RoROelpOaNrcGmE9AZubeDfrCEia483oW4MI4VyFd5VNHIgQ/7qm1I0wUHK1eJnn2y2w==" - } - } - }, - "nth-check": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/nth-check/-/nth-check-1.0.2.tgz", - "integrity": "sha512-WeBOdju8SnzPN5vTUJYxYUxLeXpCaVP5i5e0LF8fg7WORF2Wd7wFX/pk0tYZk7s8T+J7VLy0Da6J1+wCT0AtHg==", - "requires": { - "boolbase": "~1.0.0" - } - }, - "readable-stream": { - "version": "3.6.0", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.0.tgz", - "integrity": "sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==", - "requires": { - "inherits": "^2.0.3", - "string_decoder": "^1.1.1", - "util-deprecate": "^1.0.1" - } - } - } - }, - "repeat-element": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/repeat-element/-/repeat-element-1.1.3.tgz", - "integrity": "sha512-ahGq0ZnV5m5XtZLMb+vP76kcAM5nkLqk0lpqAuojSKGgQtn4eRi4ZZGm2olo2zKFH+sMsWaqOCW1dqAnOru72g==" - }, - "repeat-string": { - "version": "1.6.1", - "resolved": "https://registry.npmjs.org/repeat-string/-/repeat-string-1.6.1.tgz", - "integrity": "sha1-jcrkcOHIirwtYA//Sndihtp15jc=" - }, - "request": { - "version": "2.88.2", - "resolved": "https://registry.npmjs.org/request/-/request-2.88.2.tgz", - "integrity": "sha512-MsvtOrfG9ZcrOwAW+Qi+F6HbD0CWXEh9ou77uOb7FM2WPhwT7smM833PzanhJLsgXjN89Ir6V2PczXNnMpwKhw==", - "requires": { - "aws-sign2": "~0.7.0", - "aws4": "^1.8.0", - "caseless": "~0.12.0", - "combined-stream": "~1.0.6", - "extend": "~3.0.2", - "forever-agent": "~0.6.1", - "form-data": "~2.3.2", - "har-validator": "~5.1.3", - "http-signature": "~1.2.0", - "is-typedarray": "~1.0.0", - "isstream": "~0.1.2", - "json-stringify-safe": "~5.0.1", - "mime-types": "~2.1.19", - "oauth-sign": "~0.9.0", - "performance-now": "^2.1.0", - "qs": "~6.5.2", - "safe-buffer": "^5.1.2", - "tough-cookie": "~2.5.0", - "tunnel-agent": "^0.6.0", - "uuid": "^3.3.2" - }, - "dependencies": { - "qs": { - "version": "6.5.2", - "resolved": "https://registry.npmjs.org/qs/-/qs-6.5.2.tgz", - "integrity": "sha512-N5ZAX4/LxJmF+7wN74pUD6qAh9/wnvdQcjq9TZjevvXzSUo7bfmw91saqMjzGS2xq91/odN2dW/WOl7qQHNDGA==" - } - } - }, - "require-directory": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz", - "integrity": "sha1-jGStX9MNqxyXbiNE/+f3kqam30I=" - }, - "require-main-filename": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/require-main-filename/-/require-main-filename-2.0.0.tgz", - "integrity": "sha512-NKN5kMDylKuldxYLSUfrbo5Tuzh4hd+2E8NPPX02mZtn1VuREQToYe/ZdlJy+J3uCpfaiGF05e7B8W0iXbQHmg==" - }, - "requires-port": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/requires-port/-/requires-port-1.0.0.tgz", - "integrity": "sha1-kl0mAdOaxIXgkc8NpcbmlNw9yv8=" - }, - "resolve": { - "version": "1.19.0", - "resolved": "https://registry.npmjs.org/resolve/-/resolve-1.19.0.tgz", - "integrity": "sha512-rArEXAgsBG4UgRGcynxWIWKFvh/XZCcS8UJdHhwy91zwAvCZIbcs+vAbflgBnNjYMs/i/i+/Ux6IZhML1yPvxg==", - "requires": { - "is-core-module": "^2.1.0", - "path-parse": "^1.0.6" - } - }, - "resolve-cwd": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/resolve-cwd/-/resolve-cwd-2.0.0.tgz", - "integrity": "sha1-AKn3OHVW4nA46uIyyqNypqWbZlo=", - "requires": { - "resolve-from": "^3.0.0" - } - }, - "resolve-from": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-3.0.0.tgz", - "integrity": "sha1-six699nWiBvItuZTM17rywoYh0g=" - }, - "resolve-url": { - "version": "0.2.1", - "resolved": "https://registry.npmjs.org/resolve-url/-/resolve-url-0.2.1.tgz", - "integrity": "sha1-LGN/53yJOv0qZj/iGqkIAGjiBSo=" - }, - "responselike": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/responselike/-/responselike-1.0.2.tgz", - "integrity": "sha1-kYcg7ztjHFZCvgaPFa3lpG9Loec=", - "requires": { - "lowercase-keys": "^1.0.0" - } - }, - "ret": { - "version": "0.1.15", - "resolved": "https://registry.npmjs.org/ret/-/ret-0.1.15.tgz", - "integrity": "sha512-TTlYpa+OL+vMMNG24xSlQGEJ3B/RzEfUlLct7b5G/ytav+wPrplCpVMFuwzXbkecJrb6IYo1iFb0S9v37754mg==" - }, - "retry": { - "version": "0.12.0", - "resolved": "https://registry.npmjs.org/retry/-/retry-0.12.0.tgz", - "integrity": "sha1-G0KmJmoh8HQh0bC1S33BZ7AcATs=" - }, - "rgb-regex": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/rgb-regex/-/rgb-regex-1.0.1.tgz", - "integrity": "sha1-wODWiC3w4jviVKR16O3UGRX+rrE=" - }, - "rgba-regex": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/rgba-regex/-/rgba-regex-1.0.0.tgz", - "integrity": "sha1-QzdOLiyglosO8VI0YLfXMP8i7rM=" - }, - "right-align": { - "version": "0.1.3", - "resolved": "https://registry.npmjs.org/right-align/-/right-align-0.1.3.tgz", - "integrity": "sha1-YTObci/mo1FWiSENJOFMlhSGE+8=", - "requires": { - "align-text": "^0.1.1" - } - }, - "rimraf": { - "version": "2.7.1", - "resolved": "https://registry.npmjs.org/rimraf/-/rimraf-2.7.1.tgz", - "integrity": "sha512-uWjbaKIK3T1OSVptzX7Nl6PvQ3qAGtKEtVRjRuazjfL3Bx5eI409VZSqgND+4UNnmzLVdPj9FqFJNPqBZFve4w==", - "requires": { - "glob": "^7.1.3" - } - }, - "ripemd160": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/ripemd160/-/ripemd160-2.0.2.tgz", - "integrity": "sha512-ii4iagi25WusVoiC4B4lq7pbXfAp3D9v5CwfkY33vffw2+pkDjY1D8GaN7spsxvCSx8dkPqOZCEZyfxcmJG2IA==", - "requires": { - "hash-base": "^3.0.0", - "inherits": "^2.0.1" - } - }, - "run-queue": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/run-queue/-/run-queue-1.0.3.tgz", - "integrity": "sha1-6Eg5bwV9Ij8kOGkkYY4laUFh7Ec=", - "requires": { - "aproba": "^1.1.1" - } - }, - "safe-buffer": { - "version": "5.1.2", - "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.1.2.tgz", - "integrity": "sha512-Gd2UZBJDkXlY7GbJxfsE8/nvKkUEU1G38c1siN6QP6a9PT9MmHB8GnpscSmMJSoF8LOIrt8ud/wPtojys4G6+g==" - }, - "safe-regex": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/safe-regex/-/safe-regex-1.1.0.tgz", - "integrity": "sha1-QKNmnzsHfR6UPURinhV91IAjvy4=", - "requires": { - "ret": "~0.1.10" - } - }, - "safer-buffer": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz", - "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==" - }, - "sax": { - "version": "1.2.4", - "resolved": "https://registry.npmjs.org/sax/-/sax-1.2.4.tgz", - "integrity": "sha512-NqVDv9TpANUjFm0N8uM5GxL36UgKi9/atZw+x7YFnQ8ckwFGKrl4xX4yWtrey3UJm5nP1kUbnYgLopqWNSRhWw==" - }, - "schema-utils": { - "version": "2.7.1", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-2.7.1.tgz", - "integrity": "sha512-SHiNtMOUGWBQJwzISiVYKu82GiV4QYGePp3odlY1tuKO7gPtphAT5R/py0fA6xtbgLL/RvtJZnU9b8s0F1q0Xg==", - "requires": { - "@types/json-schema": "^7.0.5", - "ajv": "^6.12.4", - "ajv-keywords": "^3.5.2" - } - }, - "section-matter": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/section-matter/-/section-matter-1.0.0.tgz", - "integrity": "sha512-vfD3pmTzGpufjScBh50YHKzEu2lxBWhVEHsNGoEXmCmn2hKGfeNLYMzCJpe8cD7gqX7TJluOVpBkAequ6dgMmA==", - "requires": { - "extend-shallow": "^2.0.1", - "kind-of": "^6.0.0" - } - }, - "select": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/select/-/select-1.1.2.tgz", - "integrity": "sha1-DnNQrN7ICxEIUoeG7B1EGNEbOW0=", - "optional": true - }, - "select-hose": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/select-hose/-/select-hose-2.0.0.tgz", - "integrity": "sha1-Yl2GWPhlr0Psliv8N2o3NZpJlMo=" - }, - "selfsigned": { - "version": "1.10.8", - "resolved": "https://registry.npmjs.org/selfsigned/-/selfsigned-1.10.8.tgz", - "integrity": "sha512-2P4PtieJeEwVgTU9QEcwIRDQ/mXJLX8/+I3ur+Pg16nS8oNbrGxEso9NyYWy8NAmXiNl4dlAp5MwoNeCWzON4w==", - "requires": { - "node-forge": "^0.10.0" - } - }, - "semver": { - "version": "6.3.0", - "resolved": "https://registry.npmjs.org/semver/-/semver-6.3.0.tgz", - "integrity": "sha512-b39TBaTSfV6yBrapU89p5fKekE2m/NwnDocOVruQFS1/veMgdzuPcnOM34M6CwxW8jH/lxEa5rBoDeUwu5HHTw==" - }, - "semver-diff": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/semver-diff/-/semver-diff-3.1.1.tgz", - "integrity": "sha512-GX0Ix/CJcHyB8c4ykpHGIAvLyOwOobtM/8d+TQkAd81/bEjgPHrfba41Vpesr7jX/t8Uh+R3EX9eAS5be+jQYg==", - "requires": { - "semver": "^6.3.0" - } - }, - "send": { - "version": "0.17.1", - "resolved": "https://registry.npmjs.org/send/-/send-0.17.1.tgz", - "integrity": "sha512-BsVKsiGcQMFwT8UxypobUKyv7irCNRHk1T0G680vk88yf6LBByGcZJOTJCrTP2xVN6yI+XjPJcNuE3V4fT9sAg==", - "requires": { - "debug": "2.6.9", - "depd": "~1.1.2", - "destroy": "~1.0.4", - "encodeurl": "~1.0.2", - "escape-html": "~1.0.3", - "etag": "~1.8.1", - "fresh": "0.5.2", - "http-errors": "~1.7.2", - "mime": "1.6.0", - "ms": "2.1.1", - "on-finished": "~2.3.0", - "range-parser": "~1.2.1", - "statuses": "~1.5.0" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - }, - "dependencies": { - "ms": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz", - "integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=" - } - } - }, - "mime": { - "version": "1.6.0", - "resolved": "https://registry.npmjs.org/mime/-/mime-1.6.0.tgz", - "integrity": "sha512-x0Vn8spI+wuJ1O6S7gnbaQg8Pxh4NNHb7KSINmEWKiPE4RKOplvijn+NkmYmmRgP68mc70j2EbeTFRsrswaQeg==" - }, - "ms": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.1.tgz", - "integrity": "sha512-tgp+dl5cGk28utYktBsrFqA7HKgrhgPsg6Z/EfhWI4gl1Hwq8B/GmY/0oXZ6nF8hDVesS/FpnYaD/kOWhYQvyg==" - } - } - }, - "serialize-javascript": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/serialize-javascript/-/serialize-javascript-4.0.0.tgz", - "integrity": "sha512-GaNA54380uFefWghODBWEGisLZFj00nS5ACs6yHa9nLqlLpVLO8ChDGeKRjZnV4Nh4n0Qi7nhYZD/9fCPzEqkw==", - "requires": { - "randombytes": "^2.1.0" - } - }, - "serve-index": { - "version": "1.9.1", - "resolved": "https://registry.npmjs.org/serve-index/-/serve-index-1.9.1.tgz", - "integrity": "sha1-03aNabHn2C5c4FD/9bRTvqEqkjk=", - "requires": { - "accepts": "~1.3.4", - "batch": "0.6.1", - "debug": "2.6.9", - "escape-html": "~1.0.3", - "http-errors": "~1.6.2", - "mime-types": "~2.1.17", - "parseurl": "~1.3.2" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - }, - "http-errors": { - "version": "1.6.3", - "resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.6.3.tgz", - "integrity": "sha1-i1VoC7S+KDoLW/TqLjhYC+HZMg0=", - "requires": { - "depd": "~1.1.2", - "inherits": "2.0.3", - "setprototypeof": "1.1.0", - "statuses": ">= 1.4.0 < 2" - } - }, - "inherits": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz", - "integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=" - }, - "setprototypeof": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.1.0.tgz", - "integrity": "sha512-BvE/TwpZX4FXExxOxZyRGQQv651MSwmWKZGqvmPcRIjDqWub67kTKuIMx43cZZrS/cBBzwBcNDWoFxt2XEFIpQ==" - } - } - }, - "serve-static": { - "version": "1.14.1", - "resolved": "https://registry.npmjs.org/serve-static/-/serve-static-1.14.1.tgz", - "integrity": "sha512-JMrvUwE54emCYWlTI+hGrGv5I8dEwmco/00EvkzIIsR7MqrHonbD9pO2MOfFnpFntl7ecpZs+3mW+XbQZu9QCg==", - "requires": { - "encodeurl": "~1.0.2", - "escape-html": "~1.0.3", - "parseurl": "~1.3.3", - "send": "0.17.1" - } - }, - "set-blocking": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/set-blocking/-/set-blocking-2.0.0.tgz", - "integrity": "sha1-BF+XgtARrppoA93TgrJDkrPYkPc=" - }, - "set-value": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/set-value/-/set-value-2.0.1.tgz", - "integrity": "sha512-JxHc1weCN68wRY0fhCoXpyK55m/XPHafOmK4UWD7m2CI14GMcFypt4w/0+NV5f/ZMby2F6S2wwA7fgynh9gWSw==", - "requires": { - "extend-shallow": "^2.0.1", - "is-extendable": "^0.1.1", - "is-plain-object": "^2.0.3", - "split-string": "^3.0.1" - } - }, - "setimmediate": { - "version": "1.0.5", - "resolved": "https://registry.npmjs.org/setimmediate/-/setimmediate-1.0.5.tgz", - "integrity": "sha1-KQy7Iy4waULX1+qbg3Mqt4VvgoU=" - }, - "setprototypeof": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/setprototypeof/-/setprototypeof-1.1.1.tgz", - "integrity": "sha512-JvdAWfbXeIGaZ9cILp38HntZSFSo3mWg6xGcJJsd+d4aRMOqauag1C63dJfDw7OaMYwEbHMOxEZ1lqVRYP2OAw==" - }, - "sha.js": { - "version": "2.4.11", - "resolved": "https://registry.npmjs.org/sha.js/-/sha.js-2.4.11.tgz", - "integrity": "sha512-QMEp5B7cftE7APOjk5Y6xgrbWu+WkLVQwk8JNjZ8nKRciZaByEW6MubieAiToS7+dwvrjGhH8jRXz3MVd0AYqQ==", - "requires": { - "inherits": "^2.0.1", - "safe-buffer": "^5.0.1" - } - }, - "shebang-command": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/shebang-command/-/shebang-command-1.2.0.tgz", - "integrity": "sha1-RKrGW2lbAzmJaMOfNj/uXer98eo=", - "requires": { - "shebang-regex": "^1.0.0" - } - }, - "shebang-regex": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/shebang-regex/-/shebang-regex-1.0.0.tgz", - "integrity": "sha1-2kL0l0DAtC2yypcoVxyxkMmO/qM=" - }, - "signal-exit": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.3.tgz", - "integrity": "sha512-VUJ49FC8U1OxwZLxIbTTrDvLnf/6TDgxZcK8wxR8zs13xpx7xbG60ndBlhNrFi2EMuFRoeDoJO7wthSLq42EjA==" - }, - "simple-swizzle": { - "version": "0.2.2", - "resolved": "https://registry.npmjs.org/simple-swizzle/-/simple-swizzle-0.2.2.tgz", - "integrity": "sha1-pNprY1/8zMoz9w0Xy5JZLeleVXo=", - "requires": { - "is-arrayish": "^0.3.1" - }, - "dependencies": { - "is-arrayish": { - "version": "0.3.2", - "resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.3.2.tgz", - "integrity": "sha512-eVRqCvVlZbuw3GrM63ovNSNAeA1K16kaR/LRY/92w0zxQ5/1YzwblUX652i4Xs9RwAGjW9d9y6X88t8OaAJfWQ==" - } - } - }, - "sitemap": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/sitemap/-/sitemap-3.2.2.tgz", - "integrity": "sha512-TModL/WU4m2q/mQcrDgNANn0P4LwprM9MMvG4hu5zP4c6IIKs2YLTu6nXXnNr8ODW/WFtxKggiJ1EGn2W0GNmg==", - "requires": { - "lodash.chunk": "^4.2.0", - "lodash.padstart": "^4.6.1", - "whatwg-url": "^7.0.0", - "xmlbuilder": "^13.0.0" - } - }, - "slash": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/slash/-/slash-2.0.0.tgz", - "integrity": "sha512-ZYKh3Wh2z1PpEXWr0MpSBZ0V6mZHAQfYevttO11c51CaWjGTaadiKZ+wVt1PbMlDV5qhMFslpZCemhwOK7C89A==" - }, - "smoothscroll-polyfill": { - "version": "0.4.4", - "resolved": "https://registry.npmjs.org/smoothscroll-polyfill/-/smoothscroll-polyfill-0.4.4.tgz", - "integrity": "sha512-TK5ZA9U5RqCwMpfoMq/l1mrH0JAR7y7KRvOBx0n2869aLxch+gT9GhN3yUfjiw+d/DiF1mKo14+hd62JyMmoBg==" - }, - "snapdragon": { - "version": "0.8.2", - "resolved": "https://registry.npmjs.org/snapdragon/-/snapdragon-0.8.2.tgz", - "integrity": "sha512-FtyOnWN/wCHTVXOMwvSv26d+ko5vWlIDD6zoUJ7LW8vh+ZBC8QdljveRP+crNrtBwioEUWy/4dMtbBjA4ioNlg==", - "requires": { - "base": "^0.11.1", - "debug": "^2.2.0", - "define-property": "^0.2.5", - "extend-shallow": "^2.0.1", - "map-cache": "^0.2.2", - "source-map": "^0.5.6", - "source-map-resolve": "^0.5.0", - "use": "^3.1.0" - }, - "dependencies": { - "debug": { - "version": "2.6.9", - "resolved": "https://registry.npmjs.org/debug/-/debug-2.6.9.tgz", - "integrity": "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==", - "requires": { - "ms": "2.0.0" - } - }, - "define-property": { - "version": "0.2.5", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-0.2.5.tgz", - "integrity": "sha1-w1se+RjsPJkPmlvFe+BKrOxcgRY=", - "requires": { - "is-descriptor": "^0.1.0" - } - }, - "source-map": { - "version": "0.5.7", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz", - "integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=" - } - } - }, - "snapdragon-node": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/snapdragon-node/-/snapdragon-node-2.1.1.tgz", - "integrity": "sha512-O27l4xaMYt/RSQ5TR3vpWCAB5Kb/czIcqUFOM/C4fYcLnbZUc1PkjTAMjof2pBWaSTwOUd6qUHcFGVGj7aIwnw==", - "requires": { - "define-property": "^1.0.0", - "isobject": "^3.0.0", - "snapdragon-util": "^3.0.1" - }, - "dependencies": { - "define-property": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-1.0.0.tgz", - "integrity": "sha1-dp66rz9KY6rTr56NMEybvnm/sOY=", - "requires": { - "is-descriptor": "^1.0.0" - } - }, - "is-accessor-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-accessor-descriptor/-/is-accessor-descriptor-1.0.0.tgz", - "integrity": "sha512-m5hnHTkcVsPfqx3AKlyttIPb7J+XykHvJP2B9bZDjlhLIoEq4XoK64Vg7boZlVWYK6LUY94dYPEE7Lh0ZkZKcQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-data-descriptor": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/is-data-descriptor/-/is-data-descriptor-1.0.0.tgz", - "integrity": "sha512-jbRXy1FmtAoCjQkVmIVYwuuqDFUbaOeDjmed1tOGPrsMhtJA4rD9tkgA0F1qJ3gRFRXcHYVkdeaP50Q5rE/jLQ==", - "requires": { - "kind-of": "^6.0.0" - } - }, - "is-descriptor": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/is-descriptor/-/is-descriptor-1.0.2.tgz", - "integrity": "sha512-2eis5WqQGV7peooDyLmNEPUrps9+SXX5c9pL3xEB+4e9HnGuDa7mB7kHxHw4CbqS9k1T2hOH3miL8n8WtiYVtg==", - "requires": { - "is-accessor-descriptor": "^1.0.0", - "is-data-descriptor": "^1.0.0", - "kind-of": "^6.0.2" - } - } - } - }, - "snapdragon-util": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/snapdragon-util/-/snapdragon-util-3.0.1.tgz", - "integrity": "sha512-mbKkMdQKsjX4BAL4bRYTj21edOf8cN7XHdYUJEe+Zn99hVEYcMvKPct1IqNe7+AZPirn8BCDOQBHQZknqmKlZQ==", - "requires": { - "kind-of": "^3.2.0" - }, - "dependencies": { - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "sockjs": { - "version": "0.3.21", - "resolved": "https://registry.npmjs.org/sockjs/-/sockjs-0.3.21.tgz", - "integrity": "sha512-DhbPFGpxjc6Z3I+uX07Id5ZO2XwYsWOrYjaSeieES78cq+JaJvVe5q/m1uvjIQhXinhIeCFRH6JgXe+mvVMyXw==", - "requires": { - "faye-websocket": "^0.11.3", - "uuid": "^3.4.0", - "websocket-driver": "^0.7.4" - } - }, - "sockjs-client": { - "version": "1.5.0", - "resolved": "https://registry.npmjs.org/sockjs-client/-/sockjs-client-1.5.0.tgz", - "integrity": "sha512-8Dt3BDi4FYNrCFGTL/HtwVzkARrENdwOUf1ZoW/9p3M8lZdFT35jVdrHza+qgxuG9H3/shR4cuX/X9umUrjP8Q==", - "requires": { - "debug": "^3.2.6", - "eventsource": "^1.0.7", - "faye-websocket": "^0.11.3", - "inherits": "^2.0.4", - "json3": "^3.3.3", - "url-parse": "^1.4.7" - }, - "dependencies": { - "debug": { - "version": "3.2.7", - "resolved": "https://registry.npmjs.org/debug/-/debug-3.2.7.tgz", - "integrity": "sha512-CFjzYYAi4ThfiQvizrFQevTTXHtnCqWfe7x1AhgEscTz6ZbLbfoLRLPugTQyBth6f8ZERVUSyWHFD/7Wu4t1XQ==", - "requires": { - "ms": "^2.1.1" - } - }, - "ms": { - "version": "2.1.3", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.3.tgz", - "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==" - } - } - }, - "sort-keys": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/sort-keys/-/sort-keys-2.0.0.tgz", - "integrity": "sha1-ZYU1WEhh7JfXMNbPQYIuH1ZoQSg=", - "requires": { - "is-plain-obj": "^1.0.0" - } - }, - "source-list-map": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/source-list-map/-/source-list-map-2.0.1.tgz", - "integrity": "sha512-qnQ7gVMxGNxsiL4lEuJwe/To8UnK7fAnmbGEEH8RpLouuKbeEm0lhbQVFIrNSuB+G7tVrAlVsZgETT5nljf+Iw==" - }, - "source-map": { - "version": "0.6.1", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.6.1.tgz", - "integrity": "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==" - }, - "source-map-resolve": { - "version": "0.5.3", - "resolved": "https://registry.npmjs.org/source-map-resolve/-/source-map-resolve-0.5.3.tgz", - "integrity": "sha512-Htz+RnsXWk5+P2slx5Jh3Q66vhQj1Cllm0zvnaY98+NFx+Dv2CF/f5O/t8x+KaNdrdIAsruNzoh/KpialbqAnw==", - "requires": { - "atob": "^2.1.2", - "decode-uri-component": "^0.2.0", - "resolve-url": "^0.2.1", - "source-map-url": "^0.4.0", - "urix": "^0.1.0" - } - }, - "source-map-support": { - "version": "0.5.19", - "resolved": "https://registry.npmjs.org/source-map-support/-/source-map-support-0.5.19.tgz", - "integrity": "sha512-Wonm7zOCIJzBGQdB+thsPar0kYuCIzYvxZwlBa87yi/Mdjv7Tip2cyVbLj5o0cFPN4EVkuTwb3GDDyUx2DGnGw==", - "requires": { - "buffer-from": "^1.0.0", - "source-map": "^0.6.0" - } - }, - "source-map-url": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/source-map-url/-/source-map-url-0.4.0.tgz", - "integrity": "sha1-PpNdfd1zYxuXZZlW1VEo6HtQhKM=" - }, - "spdy": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/spdy/-/spdy-4.0.2.tgz", - "integrity": "sha512-r46gZQZQV+Kl9oItvl1JZZqJKGr+oEkB08A6BzkiR7593/7IbtuncXHd2YoYeTsG4157ZssMu9KYvUHLcjcDoA==", - "requires": { - "debug": "^4.1.0", - "handle-thing": "^2.0.0", - "http-deceiver": "^1.2.7", - "select-hose": "^2.0.0", - "spdy-transport": "^3.0.0" - }, - "dependencies": { - "debug": { - "version": "4.3.1", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz", - "integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==", - "requires": { - "ms": "2.1.2" - } - }, - "ms": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", - "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==" - } - } - }, - "spdy-transport": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/spdy-transport/-/spdy-transport-3.0.0.tgz", - "integrity": "sha512-hsLVFE5SjA6TCisWeJXFKniGGOpBgMLmerfO2aCyCU5s7nJ/rpAepqmFifv/GCbSbueEeAJJnmSQ2rKC/g8Fcw==", - "requires": { - "debug": "^4.1.0", - "detect-node": "^2.0.4", - "hpack.js": "^2.1.6", - "obuf": "^1.1.2", - "readable-stream": "^3.0.6", - "wbuf": "^1.7.3" - }, - "dependencies": { - "debug": { - "version": "4.3.1", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz", - "integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==", - "requires": { - "ms": "2.1.2" - } - }, - "ms": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", - "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==" - }, - "readable-stream": { - "version": "3.6.0", - "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-3.6.0.tgz", - "integrity": "sha512-BViHy7LKeTz4oNnkcLJ+lVSL6vpiFeX6/d3oSH8zCW7UxP2onchk+vTGB143xuFjHS3deTgkKoXXymXqymiIdA==", - "requires": { - "inherits": "^2.0.3", - "string_decoder": "^1.1.1", - "util-deprecate": "^1.0.1" - } - } - } - }, - "split-string": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/split-string/-/split-string-3.1.0.tgz", - "integrity": "sha512-NzNVhJDYpwceVVii8/Hu6DKfD2G+NrQHlS/V/qgv763EYudVwEcMQNxd2lh+0VrUByXN/oJkl5grOhYWvQUYiw==", - "requires": { - "extend-shallow": "^3.0.0" - }, - "dependencies": { - "extend-shallow": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-3.0.2.tgz", - "integrity": "sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=", - "requires": { - "assign-symbols": "^1.0.0", - "is-extendable": "^1.0.1" - } - }, - "is-extendable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz", - "integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==", - "requires": { - "is-plain-object": "^2.0.4" - } - } - } - }, - "sprintf-js": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz", - "integrity": "sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw=" - }, - "sshpk": { - "version": "1.16.1", - "resolved": "https://registry.npmjs.org/sshpk/-/sshpk-1.16.1.tgz", - "integrity": "sha512-HXXqVUq7+pcKeLqqZj6mHFUMvXtOJt1uoUx09pFW6011inTMxqI8BA8PM95myrIyyKwdnzjdFjLiE6KBPVtJIg==", - "requires": { - "asn1": "~0.2.3", - "assert-plus": "^1.0.0", - "bcrypt-pbkdf": "^1.0.0", - "dashdash": "^1.12.0", - "ecc-jsbn": "~0.1.1", - "getpass": "^0.1.1", - "jsbn": "~0.1.0", - "safer-buffer": "^2.0.2", - "tweetnacl": "~0.14.0" - } - }, - "ssri": { - "version": "6.0.1", - "resolved": "https://registry.npmjs.org/ssri/-/ssri-6.0.1.tgz", - "integrity": "sha512-3Wge10hNcT1Kur4PDFwEieXSCMCJs/7WvSACcrMYrNp+b8kDL1/0wJch5Ni2WrtwEa2IO8OsVfeKIciKCDx/QA==", - "requires": { - "figgy-pudding": "^3.5.1" - } - }, - "stable": { - "version": "0.1.8", - "resolved": "https://registry.npmjs.org/stable/-/stable-0.1.8.tgz", - "integrity": "sha512-ji9qxRnOVfcuLDySj9qzhGSEFVobyt1kIOSkj1qZzYLzq7Tos/oUUWvotUPQLlrsidqsK6tBH89Bc9kL5zHA6w==" - }, - "stack-utils": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/stack-utils/-/stack-utils-1.0.4.tgz", - "integrity": "sha512-IPDJfugEGbfizBwBZRZ3xpccMdRyP5lqsBWXGQWimVjua/ccLCeMOAVjlc1R7LxFjo5sEDhyNIXd8mo/AiDS9w==", - "requires": { - "escape-string-regexp": "^2.0.0" - }, - "dependencies": { - "escape-string-regexp": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-2.0.0.tgz", - "integrity": "sha512-UpzcLCXolUWcNu5HtVMHYdXJjArjsF9C0aNnquZYY4uW/Vu0miy5YoWvbV345HauVvcAUnpRuhMMcqTcGOY2+w==" - } - } - }, - "static-extend": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/static-extend/-/static-extend-0.1.2.tgz", - "integrity": "sha1-YICcOcv/VTNyJv1eC1IPNB8ftcY=", - "requires": { - "define-property": "^0.2.5", - "object-copy": "^0.1.0" - }, - "dependencies": { - "define-property": { - "version": "0.2.5", - "resolved": "https://registry.npmjs.org/define-property/-/define-property-0.2.5.tgz", - "integrity": "sha1-w1se+RjsPJkPmlvFe+BKrOxcgRY=", - "requires": { - "is-descriptor": "^0.1.0" - } - } - } - }, - "statuses": { - "version": "1.5.0", - "resolved": "https://registry.npmjs.org/statuses/-/statuses-1.5.0.tgz", - "integrity": "sha1-Fhx9rBd2Wf2YEfQ3cfqZOBR4Yow=" - }, - "std-env": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/std-env/-/std-env-2.2.1.tgz", - "integrity": "sha512-IjYQUinA3lg5re/YMlwlfhqNRTzMZMqE+pezevdcTaHceqx8ngEi1alX9nNCk9Sc81fy1fLDeQoaCzeiW1yBOQ==", - "requires": { - "ci-info": "^1.6.0" - } - }, - "stream-browserify": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/stream-browserify/-/stream-browserify-2.0.2.tgz", - "integrity": "sha512-nX6hmklHs/gr2FuxYDltq8fJA1GDlxKQCz8O/IM4atRqBH8OORmBNgfvW5gG10GT/qQ9u0CzIvr2X5Pkt6ntqg==", - "requires": { - "inherits": "~2.0.1", - "readable-stream": "^2.0.2" - } - }, - "stream-each": { - "version": "1.2.3", - "resolved": "https://registry.npmjs.org/stream-each/-/stream-each-1.2.3.tgz", - "integrity": "sha512-vlMC2f8I2u/bZGqkdfLQW/13Zihpej/7PmSiMQsbYddxuTsJp8vRe2x2FvVExZg7FaOds43ROAuFJwPR4MTZLw==", - "requires": { - "end-of-stream": "^1.1.0", - "stream-shift": "^1.0.0" - } - }, - "stream-http": { - "version": "2.8.3", - "resolved": "https://registry.npmjs.org/stream-http/-/stream-http-2.8.3.tgz", - "integrity": "sha512-+TSkfINHDo4J+ZobQLWiMouQYB+UVYFttRA94FpEzzJ7ZdqcL4uUUQ7WkdkI4DSozGmgBUE/a47L+38PenXhUw==", - "requires": { - "builtin-status-codes": "^3.0.0", - "inherits": "^2.0.1", - "readable-stream": "^2.3.6", - "to-arraybuffer": "^1.0.0", - "xtend": "^4.0.0" - } - }, - "stream-shift": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/stream-shift/-/stream-shift-1.0.1.tgz", - "integrity": "sha512-AiisoFqQ0vbGcZgQPY1cdP2I76glaVA/RauYR4G4thNFgkTqr90yXTo4LYX60Jl+sIlPNHHdGSwo01AvbKUSVQ==" - }, - "strict-uri-encode": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/strict-uri-encode/-/strict-uri-encode-1.1.0.tgz", - "integrity": "sha1-J5siXfHVgrH1TmWt3UNS4Y+qBxM=" - }, - "string-width": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/string-width/-/string-width-3.1.0.tgz", - "integrity": "sha512-vafcv6KjVZKSgz06oM/H6GDBrAtz8vdhQakGjFIvNrHA6y3HCF1CInLy+QLq8dTJPQ1b+KDUqDFctkdRW44e1w==", - "requires": { - "emoji-regex": "^7.0.1", - "is-fullwidth-code-point": "^2.0.0", - "strip-ansi": "^5.1.0" - }, - "dependencies": { - "ansi-regex": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-4.1.0.tgz", - "integrity": "sha512-1apePfXM1UOSqw0o9IiFAovVz9M5S1Dg+4TrDwfMewQ6p/rmMueb7tWZjQ1rx4Loy1ArBggoqGpfqqdI4rondg==" - }, - "strip-ansi": { - "version": "5.2.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-5.2.0.tgz", - "integrity": "sha512-DuRs1gKbBqsMKIZlrffwlug8MHkcnpjs5VPmL1PAh+mA30U0DTotfDZ0d2UUsXpPmPmMMJ6W773MaA3J+lbiWA==", - "requires": { - "ansi-regex": "^4.1.0" - } - } - } - }, - "string.prototype.trimend": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/string.prototype.trimend/-/string.prototype.trimend-1.0.3.tgz", - "integrity": "sha512-ayH0pB+uf0U28CtjlLvL7NaohvR1amUvVZk+y3DYb0Ey2PUV5zPkkKy9+U1ndVEIXO8hNg18eIv9Jntbii+dKw==", - "requires": { - "call-bind": "^1.0.0", - "define-properties": "^1.1.3" - } - }, - "string.prototype.trimstart": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/string.prototype.trimstart/-/string.prototype.trimstart-1.0.3.tgz", - "integrity": "sha512-oBIBUy5lea5tt0ovtOFiEQaBkoBBkyJhZXzJYrSmDo5IUUqbOPvVezuRs/agBIdZ2p2Eo1FD6bD9USyBLfl3xg==", - "requires": { - "call-bind": "^1.0.0", - "define-properties": "^1.1.3" - } - }, - "string_decoder": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.1.1.tgz", - "integrity": "sha512-n/ShnvDi6FHbbVfviro+WojiFzv+s8MPMHBczVePfUpDJLwoLT0ht1l4YwBCbi8pJAveEEdnkHyPyTP/mzRfwg==", - "requires": { - "safe-buffer": "~5.1.0" - } - }, - "strip-ansi": { - "version": "3.0.1", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-3.0.1.tgz", - "integrity": "sha1-ajhfuIU9lS1f8F0Oiq+UJ43GPc8=", - "requires": { - "ansi-regex": "^2.0.0" - } - }, - "strip-bom-string": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/strip-bom-string/-/strip-bom-string-1.0.0.tgz", - "integrity": "sha1-5SEekiQ2n7uB1jOi8ABE3IztrZI=" - }, - "strip-eof": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/strip-eof/-/strip-eof-1.0.0.tgz", - "integrity": "sha1-u0P/VZim6wXYm1n80SnJgzE2Br8=" - }, - "strip-json-comments": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-2.0.1.tgz", - "integrity": "sha1-PFMZQukIwml8DsNEhYwobHygpgo=" - }, - "stylehacks": { - "version": "4.0.3", - "resolved": "https://registry.npmjs.org/stylehacks/-/stylehacks-4.0.3.tgz", - "integrity": "sha512-7GlLk9JwlElY4Y6a/rmbH2MhVlTyVmiJd1PfTCqFaIBEGMYNsrO/v3SeGTdhBThLg4Z+NbOk/qFMwCa+J+3p/g==", - "requires": { - "browserslist": "^4.0.0", - "postcss": "^7.0.0", - "postcss-selector-parser": "^3.0.0" - }, - "dependencies": { - "postcss-selector-parser": { - "version": "3.1.2", - "resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-3.1.2.tgz", - "integrity": "sha512-h7fJ/5uWuRVyOtkO45pnt1Ih40CEleeyCHzipqAZO2e5H20g25Y48uYnFUiShvY4rZWNJ/Bib/KVPmanaCtOhA==", - "requires": { - "dot-prop": "^5.2.0", - "indexes-of": "^1.0.1", - "uniq": "^1.0.1" - } - } - } - }, - "stylus": { - "version": "0.54.8", - "resolved": "https://registry.npmjs.org/stylus/-/stylus-0.54.8.tgz", - "integrity": "sha512-vr54Or4BZ7pJafo2mpf0ZcwA74rpuYCZbxrHBsH8kbcXOwSfvBFwsRfpGO5OD5fhG5HDCFW737PKaawI7OqEAg==", - "requires": { - "css-parse": "~2.0.0", - "debug": "~3.1.0", - "glob": "^7.1.6", - "mkdirp": "~1.0.4", - "safer-buffer": "^2.1.2", - "sax": "~1.2.4", - "semver": "^6.3.0", - "source-map": "^0.7.3" - }, - "dependencies": { - "source-map": { - "version": "0.7.3", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.7.3.tgz", - "integrity": "sha512-CkCj6giN3S+n9qrYiBTX5gystlENnRW5jZeNLHpe6aue+SrHcG5VYwujhW9s4dY31mEGsxBDrHR6oI69fTXsaQ==" - } - } - }, - "stylus-loader": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/stylus-loader/-/stylus-loader-3.0.2.tgz", - "integrity": "sha512-+VomPdZ6a0razP+zinir61yZgpw2NfljeSsdUF5kJuEzlo3khXhY19Fn6l8QQz1GRJGtMCo8nG5C04ePyV7SUA==", - "requires": { - "loader-utils": "^1.0.2", - "lodash.clonedeep": "^4.5.0", - "when": "~3.6.x" - } - }, - "supports-color": { - "version": "5.5.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-5.5.0.tgz", - "integrity": "sha512-QjVjwdXIt408MIiAqCX4oUKsgU2EqAGzs2Ppkm4aQYbjm+ZEWEcW4SfFNTr4uMNZma0ey4f5lgLrkB0aX0QMow==", - "requires": { - "has-flag": "^3.0.0" - } - }, - "svg-tags": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/svg-tags/-/svg-tags-1.0.0.tgz", - "integrity": "sha1-WPcc7jvVGbWdSyqEO2x95krAR2Q=" - }, - "svgo": { - "version": "1.3.2", - "resolved": "https://registry.npmjs.org/svgo/-/svgo-1.3.2.tgz", - "integrity": "sha512-yhy/sQYxR5BkC98CY7o31VGsg014AKLEPxdfhora76l36hD9Rdy5NZA/Ocn6yayNPgSamYdtX2rFJdcv07AYVw==", - "requires": { - "chalk": "^2.4.1", - "coa": "^2.0.2", - "css-select": "^2.0.0", - "css-select-base-adapter": "^0.1.1", - "css-tree": "1.0.0-alpha.37", - "csso": "^4.0.2", - "js-yaml": "^3.13.1", - "mkdirp": "~0.5.1", - "object.values": "^1.1.0", - "sax": "~1.2.4", - "stable": "^0.1.8", - "unquote": "~1.1.1", - "util.promisify": "~1.0.0" - }, - "dependencies": { - "css-select": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/css-select/-/css-select-2.1.0.tgz", - "integrity": "sha512-Dqk7LQKpwLoH3VovzZnkzegqNSuAziQyNZUcrdDM401iY+R5NkGBXGmtO05/yaXQziALuPogeG0b7UAgjnTJTQ==", - "requires": { - "boolbase": "^1.0.0", - "css-what": "^3.2.1", - "domutils": "^1.7.0", - "nth-check": "^1.0.2" - } - }, - "css-what": { - "version": "3.4.2", - "resolved": "https://registry.npmjs.org/css-what/-/css-what-3.4.2.tgz", - "integrity": "sha512-ACUm3L0/jiZTqfzRM3Hi9Q8eZqd6IK37mMWPLz9PJxkLWllYeRf+EHUSHYEtFop2Eqytaq1FizFVh7XfBnXCDQ==" - }, - "dom-serializer": { - "version": "0.2.2", - "resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-0.2.2.tgz", - "integrity": "sha512-2/xPb3ORsQ42nHYiSunXkDjPLBaEj/xTwUO4B7XCZQTRk7EBtTOPaygh10YAAh2OI1Qrp6NWfpAhzswj0ydt9g==", - "requires": { - "domelementtype": "^2.0.1", - "entities": "^2.0.0" - }, - "dependencies": { - "domelementtype": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-2.1.0.tgz", - "integrity": "sha512-LsTgx/L5VpD+Q8lmsXSHW2WpA+eBlZ9HPf3erD1IoPF00/3JKHZ3BknUVA2QGDNu69ZNmyFmCWBSO45XjYKC5w==" - } - } - }, - "domelementtype": { - "version": "1.3.1", - "resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-1.3.1.tgz", - "integrity": "sha512-BSKB+TSpMpFI/HOxCNr1O8aMOTZ8hT3pM3GQ0w/mWRmkhEDSFJkkyzz4XQsBV44BChwGkrDfMyjVD0eA2aFV3w==" - }, - "domutils": { - "version": "1.7.0", - "resolved": "https://registry.npmjs.org/domutils/-/domutils-1.7.0.tgz", - "integrity": "sha512-Lgd2XcJ/NjEw+7tFvfKxOzCYKZsdct5lczQ2ZaQY8Djz7pfAD3Gbp8ySJWtreII/vDlMVmxwa6pHmdxIYgttDg==", - "requires": { - "dom-serializer": "0", - "domelementtype": "1" - } - }, - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - }, - "nth-check": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/nth-check/-/nth-check-1.0.2.tgz", - "integrity": "sha512-WeBOdju8SnzPN5vTUJYxYUxLeXpCaVP5i5e0LF8fg7WORF2Wd7wFX/pk0tYZk7s8T+J7VLy0Da6J1+wCT0AtHg==", - "requires": { - "boolbase": "~1.0.0" - } - } - } - }, - "tapable": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/tapable/-/tapable-1.1.3.tgz", - "integrity": "sha512-4WK/bYZmj8xLr+HUCODHGF1ZFzsYffasLUgEiMBY4fgtltdO6B4WJtlSbPaDTLpYTcGVwM2qLnFTICEcNxs3kA==" - }, - "term-size": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/term-size/-/term-size-2.2.1.tgz", - "integrity": "sha512-wK0Ri4fOGjv/XPy8SBHZChl8CM7uMc5VML7SqiQ0zG7+J5Vr+RMQDoHa2CNT6KHUnTGIXH34UDMkPzAUyapBZg==" - }, - "terser": { - "version": "4.8.0", - "resolved": "https://registry.npmjs.org/terser/-/terser-4.8.0.tgz", - "integrity": "sha512-EAPipTNeWsb/3wLPeup1tVPaXfIaU68xMnVdPafIL1TV05OhASArYyIfFvnvJCNrR2NIOvDVNNTFRa+Re2MWyw==", - "requires": { - "commander": "^2.20.0", - "source-map": "~0.6.1", - "source-map-support": "~0.5.12" - }, - "dependencies": { - "commander": { - "version": "2.20.3", - "resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz", - "integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==" - } - } - }, - "terser-webpack-plugin": { - "version": "1.4.5", - "resolved": "https://registry.npmjs.org/terser-webpack-plugin/-/terser-webpack-plugin-1.4.5.tgz", - "integrity": "sha512-04Rfe496lN8EYruwi6oPQkG0vo8C+HT49X687FZnpPF0qMAIHONI6HEXYPKDOE8e5HjXTyKfqRd/agHtH0kOtw==", - "requires": { - "cacache": "^12.0.2", - "find-cache-dir": "^2.1.0", - "is-wsl": "^1.1.0", - "schema-utils": "^1.0.0", - "serialize-javascript": "^4.0.0", - "source-map": "^0.6.1", - "terser": "^4.1.2", - "webpack-sources": "^1.4.0", - "worker-farm": "^1.7.0" - }, - "dependencies": { - "find-cache-dir": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/find-cache-dir/-/find-cache-dir-2.1.0.tgz", - "integrity": "sha512-Tq6PixE0w/VMFfCgbONnkiQIVol/JJL7nRMi20fqzA4NRs9AfeqMGeRdPi3wIhYkxjeBaWh2rxwapn5Tu3IqOQ==", - "requires": { - "commondir": "^1.0.1", - "make-dir": "^2.0.0", - "pkg-dir": "^3.0.0" - } - }, - "find-up": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/find-up/-/find-up-3.0.0.tgz", - "integrity": "sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==", - "requires": { - "locate-path": "^3.0.0" - } - }, - "locate-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-3.0.0.tgz", - "integrity": "sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==", - "requires": { - "p-locate": "^3.0.0", - "path-exists": "^3.0.0" - } - }, - "make-dir": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/make-dir/-/make-dir-2.1.0.tgz", - "integrity": "sha512-LS9X+dc8KLxXCb8dni79fLIIUA5VyZoyjSMCwTluaXA0o27cCK0bhXkpgw+sTXVpPy/lSO57ilRixqk0vDmtRA==", - "requires": { - "pify": "^4.0.1", - "semver": "^5.6.0" - } - }, - "p-locate": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-3.0.0.tgz", - "integrity": "sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==", - "requires": { - "p-limit": "^2.0.0" - } - }, - "path-exists": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-3.0.0.tgz", - "integrity": "sha1-zg6+ql94yxiSXqfYENe1mwEP1RU=" - }, - "pkg-dir": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/pkg-dir/-/pkg-dir-3.0.0.tgz", - "integrity": "sha512-/E57AYkoeQ25qkxMj5PBOVgF8Kiu/h7cYS30Z5+R7WaiCCBfLq58ZI/dSeaEKb9WVJV5n/03QwrN3IeWIFllvw==", - "requires": { - "find-up": "^3.0.0" - } - }, - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - }, - "semver": { - "version": "5.7.1", - "resolved": "https://registry.npmjs.org/semver/-/semver-5.7.1.tgz", - "integrity": "sha512-sauaDf/PZdVgrLTNYHRtpXa1iRiKcaebiKQ1BJdpQlWH2lCvexQdX55snPFyK7QzpudqbCI0qXFfOasHdyNDGQ==" - } - } - }, - "text-table": { - "version": "0.2.0", - "resolved": "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz", - "integrity": "sha1-f17oI66AUgfACvLfSoTsP8+lcLQ=" - }, - "through": { - "version": "2.3.8", - "resolved": "https://registry.npmjs.org/through/-/through-2.3.8.tgz", - "integrity": "sha1-DdTJ/6q8NXlgsbckEV1+Doai4fU=" - }, - "through2": { - "version": "2.0.5", - "resolved": "https://registry.npmjs.org/through2/-/through2-2.0.5.tgz", - "integrity": "sha512-/mrRod8xqpA+IHSLyGCQ2s8SPHiCDEeQJSep1jqLYeEUClOFG2Qsh+4FU6G9VeqpZnGW/Su8LQGc4YKni5rYSQ==", - "requires": { - "readable-stream": "~2.3.6", - "xtend": "~4.0.1" - } - }, - "thunky": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/thunky/-/thunky-1.1.0.tgz", - "integrity": "sha512-eHY7nBftgThBqOyHGVN+l8gF0BucP09fMo0oO/Lb0w1OF80dJv+lDVpXG60WMQvkcxAkNybKsrEIE3ZtKGmPrA==" - }, - "timers-browserify": { - "version": "2.0.12", - "resolved": "https://registry.npmjs.org/timers-browserify/-/timers-browserify-2.0.12.tgz", - "integrity": "sha512-9phl76Cqm6FhSX9Xe1ZUAMLtm1BLkKj2Qd5ApyWkXzsMRaA7dgr81kf4wJmQf/hAvg8EEyJxDo3du/0KlhPiKQ==", - "requires": { - "setimmediate": "^1.0.4" - } - }, - "timsort": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/timsort/-/timsort-0.3.0.tgz", - "integrity": "sha1-QFQRqOfmM5/mTbmiNN4R3DHgK9Q=" - }, - "tiny-cookie": { - "version": "2.3.2", - "resolved": "https://registry.npmjs.org/tiny-cookie/-/tiny-cookie-2.3.2.tgz", - "integrity": "sha512-qbymkVh+6+Gc/c9sqnvbG+dOHH6bschjphK3SHgIfT6h/t+63GBL37JXNoXEc6u/+BcwU6XmaWUuf19ouLVtPg==" - }, - "tiny-emitter": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/tiny-emitter/-/tiny-emitter-2.1.0.tgz", - "integrity": "sha512-NB6Dk1A9xgQPMoGqC5CVXn123gWyte215ONT5Pp5a0yt4nlEoO1ZWeCwpncaekPHXO60i47ihFnZPiRPjRMq4Q==", - "optional": true - }, - "to-arraybuffer": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/to-arraybuffer/-/to-arraybuffer-1.0.1.tgz", - "integrity": "sha1-fSKbH8xjfkZsoIEYCDanqr/4P0M=" - }, - "to-factory": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/to-factory/-/to-factory-1.0.0.tgz", - "integrity": "sha1-hzivi9lxIK0dQEeXKtpVY7+UebE=" - }, - "to-fast-properties": { - "version": "1.0.3", - "resolved": "https://registry.npmjs.org/to-fast-properties/-/to-fast-properties-1.0.3.tgz", - "integrity": "sha1-uDVx+k2MJbguIxsG46MFXeTKGkc=" - }, - "to-object-path": { - "version": "0.3.0", - "resolved": "https://registry.npmjs.org/to-object-path/-/to-object-path-0.3.0.tgz", - "integrity": "sha1-KXWIt7Dn4KwI4E5nL4XB9JmeF68=", - "requires": { - "kind-of": "^3.0.2" - }, - "dependencies": { - "kind-of": { - "version": "3.2.2", - "resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz", - "integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=", - "requires": { - "is-buffer": "^1.1.5" - } - } - } - }, - "to-readable-stream": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/to-readable-stream/-/to-readable-stream-1.0.0.tgz", - "integrity": "sha512-Iq25XBt6zD5npPhlLVXGFN3/gyR2/qODcKNNyTMd4vbm39HUaOiAM4PMq0eMVC/Tkxz+Zjdsc55g9yyz+Yq00Q==" - }, - "to-regex": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/to-regex/-/to-regex-3.0.2.tgz", - "integrity": "sha512-FWtleNAtZ/Ki2qtqej2CXTOayOH9bHDQF+Q48VpWyDXjbYxA4Yz8iDB31zXOBUlOHHKidDbqGVrTUvQMPmBGBw==", - "requires": { - "define-property": "^2.0.2", - "extend-shallow": "^3.0.2", - "regex-not": "^1.0.2", - "safe-regex": "^1.1.0" - }, - "dependencies": { - "extend-shallow": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/extend-shallow/-/extend-shallow-3.0.2.tgz", - "integrity": "sha1-Jqcarwc7OfshJxcnRhMcJwQCjbg=", - "requires": { - "assign-symbols": "^1.0.0", - "is-extendable": "^1.0.1" - } - }, - "is-extendable": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/is-extendable/-/is-extendable-1.0.1.tgz", - "integrity": "sha512-arnXMxT1hhoKo9k1LZdmlNyJdDDfy2v0fXjFlmok4+i8ul/6WlbVge9bhM74OpNPQPMGUToDtz+KXa1PneJxOA==", - "requires": { - "is-plain-object": "^2.0.4" - } - } - } - }, - "to-regex-range": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-2.1.1.tgz", - "integrity": "sha1-fIDBe53+vlmeJzZ+DU3VWQFB2zg=", - "requires": { - "is-number": "^3.0.0", - "repeat-string": "^1.6.1" - } - }, - "toidentifier": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/toidentifier/-/toidentifier-1.0.0.tgz", - "integrity": "sha512-yaOH/Pk/VEhBWWTlhI+qXxDFXlejDGcQipMlyxda9nthulaxLZUNcUqFxokp0vcYnvteJln5FNQDRrxj3YcbVw==" - }, - "token-stream": { - "version": "0.0.1", - "resolved": "https://registry.npmjs.org/token-stream/-/token-stream-0.0.1.tgz", - "integrity": "sha1-zu78cXp2xDFvEm0LnbqlXX598Bo=" - }, - "toml": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/toml/-/toml-3.0.0.tgz", - "integrity": "sha512-y/mWCZinnvxjTKYhJ+pYxwD0mRLVvOtdS2Awbgxln6iEnt4rk0yBxeSBHkGJcPucRiG0e55mwWp+g/05rsrd6w==" - }, - "toposort": { - "version": "1.0.7", - "resolved": "https://registry.npmjs.org/toposort/-/toposort-1.0.7.tgz", - "integrity": "sha1-LmhELZ9k7HILjMieZEOsbKqVACk=" - }, - "tough-cookie": { - "version": "2.5.0", - "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-2.5.0.tgz", - "integrity": "sha512-nlLsUzgm1kfLXSXfRZMc1KLAugd4hqJHDTvc2hDIwS3mZAfMEuMbc03SujMF+GEcpaX/qboeycw6iO8JwVv2+g==", - "requires": { - "psl": "^1.1.28", - "punycode": "^2.1.1" - } - }, - "tr46": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/tr46/-/tr46-1.0.1.tgz", - "integrity": "sha1-qLE/1r/SSJUZZ0zN5VujaTtwbQk=", - "requires": { - "punycode": "^2.1.0" - } - }, - "tslib": { - "version": "1.14.1", - "resolved": "https://registry.npmjs.org/tslib/-/tslib-1.14.1.tgz", - "integrity": "sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg==" - }, - "tty-browserify": { - "version": "0.0.0", - "resolved": "https://registry.npmjs.org/tty-browserify/-/tty-browserify-0.0.0.tgz", - "integrity": "sha1-oVe6QC2iTpv5V/mqadUk7tQpAaY=" - }, - "tunnel-agent": { - "version": "0.6.0", - "resolved": "https://registry.npmjs.org/tunnel-agent/-/tunnel-agent-0.6.0.tgz", - "integrity": "sha1-J6XeoGs2sEoKmWZ3SykIaPD8QP0=", - "requires": { - "safe-buffer": "^5.0.1" - } - }, - "tweetnacl": { - "version": "0.14.5", - "resolved": "https://registry.npmjs.org/tweetnacl/-/tweetnacl-0.14.5.tgz", - "integrity": "sha1-WuaBd/GS1EViadEIr6k/+HQ/T2Q=" - }, - "type-fest": { - "version": "0.11.0", - "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.11.0.tgz", - "integrity": "sha512-OdjXJxnCN1AvyLSzeKIgXTXxV+99ZuXl3Hpo9XpJAv9MBcHrrJOQ5kV7ypXOuQie+AmWG25hLbiKdwYTifzcfQ==" - }, - "type-is": { - "version": "1.6.18", - "resolved": "https://registry.npmjs.org/type-is/-/type-is-1.6.18.tgz", - "integrity": "sha512-TkRKr9sUTxEH8MdfuCSP7VizJyzRNMjj2J2do2Jr3Kym598JVdEksuzPQCnlFPW4ky9Q+iA+ma9BGm06XQBy8g==", - "requires": { - "media-typer": "0.3.0", - "mime-types": "~2.1.24" - } - }, - "typedarray": { - "version": "0.0.6", - "resolved": "https://registry.npmjs.org/typedarray/-/typedarray-0.0.6.tgz", - "integrity": "sha1-hnrHTjhkGHsdPUfZlqeOxciDB3c=" - }, - "typedarray-to-buffer": { - "version": "3.1.5", - "resolved": "https://registry.npmjs.org/typedarray-to-buffer/-/typedarray-to-buffer-3.1.5.tgz", - "integrity": "sha512-zdu8XMNEDepKKR+XYOXAVPtWui0ly0NtohUscw+UmaHiAWT8hrV1rr//H6V+0DvJ3OQ19S979M0laLfX8rm82Q==", - "requires": { - "is-typedarray": "^1.0.0" - } - }, - "uc.micro": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-1.0.6.tgz", - "integrity": "sha512-8Y75pvTYkLJW2hWQHXxoqRgV7qb9B+9vFEtidML+7koHUFapnVJAZ6cKs+Qjz5Aw3aZWHMC6u0wJE3At+nSGwA==" - }, - "uglify-js": { - "version": "2.8.29", - "resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-2.8.29.tgz", - "integrity": "sha1-KcVzMUgFe7Th913zW3qcty5qWd0=", - "requires": { - "source-map": "~0.5.1", - "uglify-to-browserify": "~1.0.0", - "yargs": "~3.10.0" - }, - "dependencies": { - "source-map": { - "version": "0.5.7", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.7.tgz", - "integrity": "sha1-igOdLRAh0i0eoUyA2OpGi6LvP8w=" - } - } - }, - "uglify-to-browserify": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/uglify-to-browserify/-/uglify-to-browserify-1.0.2.tgz", - "integrity": "sha1-bgkk1r2mta/jSeOabWMoUKD4grc=", - "optional": true - }, - "unicode-canonical-property-names-ecmascript": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/unicode-canonical-property-names-ecmascript/-/unicode-canonical-property-names-ecmascript-1.0.4.tgz", - "integrity": "sha512-jDrNnXWHd4oHiTZnx/ZG7gtUTVp+gCcTTKr8L0HjlwphROEW3+Him+IpvC+xcJEFegapiMZyZe02CyuOnRmbnQ==" - }, - "unicode-match-property-ecmascript": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/unicode-match-property-ecmascript/-/unicode-match-property-ecmascript-1.0.4.tgz", - "integrity": "sha512-L4Qoh15vTfntsn4P1zqnHulG0LdXgjSO035fEpdtp6YxXhMT51Q6vgM5lYdG/5X3MjS+k/Y9Xw4SFCY9IkR0rg==", - "requires": { - "unicode-canonical-property-names-ecmascript": "^1.0.4", - "unicode-property-aliases-ecmascript": "^1.0.4" - } - }, - "unicode-match-property-value-ecmascript": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/unicode-match-property-value-ecmascript/-/unicode-match-property-value-ecmascript-1.2.0.tgz", - "integrity": "sha512-wjuQHGQVofmSJv1uVISKLE5zO2rNGzM/KCYZch/QQvez7C1hUhBIuZ701fYXExuufJFMPhv2SyL8CyoIfMLbIQ==" - }, - "unicode-property-aliases-ecmascript": { - "version": "1.1.0", - "resolved": "https://registry.npmjs.org/unicode-property-aliases-ecmascript/-/unicode-property-aliases-ecmascript-1.1.0.tgz", - "integrity": "sha512-PqSoPh/pWetQ2phoj5RLiaqIk4kCNwoV3CI+LfGmWLKI3rE3kl1h59XpX2BjgDrmbxD9ARtQobPGU1SguCYuQg==" - }, - "union-value": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/union-value/-/union-value-1.0.1.tgz", - "integrity": "sha512-tJfXmxMeWYnczCVs7XAEvIV7ieppALdyepWMkHkwciRpZraG/xwT+s2JN8+pr1+8jCRf80FFzvr+MpQeeoF4Xg==", - "requires": { - "arr-union": "^3.1.0", - "get-value": "^2.0.6", - "is-extendable": "^0.1.1", - "set-value": "^2.0.1" - } - }, - "uniq": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/uniq/-/uniq-1.0.1.tgz", - "integrity": "sha1-sxxa6CVIRKOoKBVBzisEuGWnNP8=" - }, - "uniqs": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/uniqs/-/uniqs-2.0.0.tgz", - "integrity": "sha1-/+3ks2slKQaW5uFl1KWe25mOawI=" - }, - "unique-filename": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/unique-filename/-/unique-filename-1.1.1.tgz", - "integrity": "sha512-Vmp0jIp2ln35UTXuryvjzkjGdRyf9b2lTXuSYUiPmzRcl3FDtYqAwOnTJkAngD9SWhnoJzDbTKwaOrZ+STtxNQ==", - "requires": { - "unique-slug": "^2.0.0" - } - }, - "unique-slug": { - "version": "2.0.2", - "resolved": "https://registry.npmjs.org/unique-slug/-/unique-slug-2.0.2.tgz", - "integrity": "sha512-zoWr9ObaxALD3DOPfjPSqxt4fnZiWblxHIgeWqW8x7UqDzEtHEQLzji2cuJYQFCU6KmoJikOYAZlrTHHebjx2w==", - "requires": { - "imurmurhash": "^0.1.4" - } - }, - "unique-string": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/unique-string/-/unique-string-2.0.0.tgz", - "integrity": "sha512-uNaeirEPvpZWSgzwsPGtU2zVSTrn/8L5q/IexZmH0eH6SA73CmAA5U4GwORTxQAZs95TAXLNqeLoPPNO5gZfWg==", - "requires": { - "crypto-random-string": "^2.0.0" - } - }, - "universalify": { - "version": "0.1.2", - "resolved": "https://registry.npmjs.org/universalify/-/universalify-0.1.2.tgz", - "integrity": "sha512-rBJeI5CXAlmy1pV+617WB9J63U6XcazHHF2f2dbJix4XzpUF0RS3Zbj0FGIOCAva5P/d/GBOYaACQ1w+0azUkg==" - }, - "unpipe": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/unpipe/-/unpipe-1.0.0.tgz", - "integrity": "sha1-sr9O6FFKrmFltIF4KdIbLvSZBOw=" - }, - "unquote": { - "version": "1.1.1", - "resolved": "https://registry.npmjs.org/unquote/-/unquote-1.1.1.tgz", - "integrity": "sha1-j97XMk7G6IoP+LkF58CYzcCG1UQ=" - }, - "unset-value": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/unset-value/-/unset-value-1.0.0.tgz", - "integrity": "sha1-g3aHP30jNRef+x5vw6jtDfyKtVk=", - "requires": { - "has-value": "^0.3.1", - "isobject": "^3.0.0" - }, - "dependencies": { - "has-value": { - "version": "0.3.1", - "resolved": "https://registry.npmjs.org/has-value/-/has-value-0.3.1.tgz", - "integrity": "sha1-ex9YutpiyoJ+wKIHgCVlSEWZXh8=", - "requires": { - "get-value": "^2.0.3", - "has-values": "^0.1.4", - "isobject": "^2.0.0" - }, - "dependencies": { - "isobject": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/isobject/-/isobject-2.1.0.tgz", - "integrity": "sha1-8GVWEJaj8dou9GJy+BXIQNh+DIk=", - "requires": { - "isarray": "1.0.0" - } - } - } - }, - "has-values": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/has-values/-/has-values-0.1.4.tgz", - "integrity": "sha1-bWHeldkd/Km5oCCJrThL/49it3E=" - } - } - }, - "upath": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/upath/-/upath-1.2.0.tgz", - "integrity": "sha512-aZwGpamFO61g3OlfT7OQCHqhGnW43ieH9WZeP7QxN/G/jS4jfqUkZxoryvJgVPEcrl5NL/ggHsSmLMHuH64Lhg==" - }, - "update-notifier": { - "version": "4.1.3", - "resolved": "https://registry.npmjs.org/update-notifier/-/update-notifier-4.1.3.tgz", - "integrity": "sha512-Yld6Z0RyCYGB6ckIjffGOSOmHXj1gMeE7aROz4MG+XMkmixBX4jUngrGXNYz7wPKBmtoD4MnBa2Anu7RSKht/A==", - "requires": { - "boxen": "^4.2.0", - "chalk": "^3.0.0", - "configstore": "^5.0.1", - "has-yarn": "^2.1.0", - "import-lazy": "^2.1.0", - "is-ci": "^2.0.0", - "is-installed-globally": "^0.3.1", - "is-npm": "^4.0.0", - "is-yarn-global": "^0.3.0", - "latest-version": "^5.0.0", - "pupa": "^2.0.1", - "semver-diff": "^3.1.1", - "xdg-basedir": "^4.0.0" - }, - "dependencies": { - "ansi-styles": { - "version": "4.3.0", - "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz", - "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==", - "requires": { - "color-convert": "^2.0.1" - } - }, - "chalk": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/chalk/-/chalk-3.0.0.tgz", - "integrity": "sha512-4D3B6Wf41KOYRFdszmDqMCGq5VV/uMAB273JILmO+3jAlh8X4qDtdtgCR3fxtbLEMzSx22QdhnDcJvu2u1fVwg==", - "requires": { - "ansi-styles": "^4.1.0", - "supports-color": "^7.1.0" - } - }, - "color-convert": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz", - "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==", - "requires": { - "color-name": "~1.1.4" - } - }, - "color-name": { - "version": "1.1.4", - "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz", - "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==" - }, - "has-flag": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz", - "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==" - }, - "supports-color": { - "version": "7.2.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz", - "integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==", - "requires": { - "has-flag": "^4.0.0" - } - } - } - }, - "upper-case": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/upper-case/-/upper-case-1.1.3.tgz", - "integrity": "sha1-9rRQHC7EzdJrp4vnIilh3ndiFZg=" - }, - "uri-js": { - "version": "4.4.1", - "resolved": "https://registry.npmjs.org/uri-js/-/uri-js-4.4.1.tgz", - "integrity": "sha512-7rKUyy33Q1yc98pQ1DAmLtwX109F7TIfWlW1Ydo8Wl1ii1SeHieeh0HHfPeL2fMXK6z0s8ecKs9frCuLJvndBg==", - "requires": { - "punycode": "^2.1.0" - } - }, - "urix": { - "version": "0.1.0", - "resolved": "https://registry.npmjs.org/urix/-/urix-0.1.0.tgz", - "integrity": "sha1-2pN/emLiH+wf0Y1Js1wpNQZ6bHI=" - }, - "url": { - "version": "0.11.0", - "resolved": "https://registry.npmjs.org/url/-/url-0.11.0.tgz", - "integrity": "sha1-ODjpfPxgUh63PFJajlW/3Z4uKPE=", - "requires": { - "punycode": "1.3.2", - "querystring": "0.2.0" - }, - "dependencies": { - "punycode": { - "version": "1.3.2", - "resolved": "https://registry.npmjs.org/punycode/-/punycode-1.3.2.tgz", - "integrity": "sha1-llOgNvt8HuQjQvIyXM7v6jkmxI0=" - } - } - }, - "url-loader": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/url-loader/-/url-loader-1.1.2.tgz", - "integrity": "sha512-dXHkKmw8FhPqu8asTc1puBfe3TehOCo2+RmOOev5suNCIYBcT626kxiWg1NBVkwc4rO8BGa7gP70W7VXuqHrjg==", - "requires": { - "loader-utils": "^1.1.0", - "mime": "^2.0.3", - "schema-utils": "^1.0.0" - }, - "dependencies": { - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - } - } - }, - "url-parse": { - "version": "1.4.7", - "resolved": "https://registry.npmjs.org/url-parse/-/url-parse-1.4.7.tgz", - "integrity": "sha512-d3uaVyzDB9tQoSXFvuSUNFibTd9zxd2bkVrDRvF5TmvWWQwqE4lgYJ5m+x1DbecWkw+LK4RNl2CU1hHuOKPVlg==", - "requires": { - "querystringify": "^2.1.1", - "requires-port": "^1.0.0" - } - }, - "url-parse-lax": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/url-parse-lax/-/url-parse-lax-3.0.0.tgz", - "integrity": "sha1-FrXK/Afb42dsGxmZF3gj1lA6yww=", - "requires": { - "prepend-http": "^2.0.0" - } - }, - "use": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/use/-/use-3.1.1.tgz", - "integrity": "sha512-cwESVXlO3url9YWlFW/TA9cshCEhtu7IKJ/p5soJ/gGpj7vbvFrAY/eIioQ6Dw23KjZhYgiIo8HOs1nQ2vr/oQ==" - }, - "util": { - "version": "0.11.1", - "resolved": "https://registry.npmjs.org/util/-/util-0.11.1.tgz", - "integrity": "sha512-HShAsny+zS2TZfaXxD9tYj4HQGlBezXZMZuM/S5PKLLoZkShZiGk9o5CzukI1LVHZvjdvZ2Sj1aW/Ndn2NB/HQ==", - "requires": { - "inherits": "2.0.3" - }, - "dependencies": { - "inherits": { - "version": "2.0.3", - "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz", - "integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=" - } - } - }, - "util-deprecate": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz", - "integrity": "sha1-RQ1Nyfpw3nMnYvvS1KKJgUGaDM8=" - }, - "util.promisify": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/util.promisify/-/util.promisify-1.0.1.tgz", - "integrity": "sha512-g9JpC/3He3bm38zsLupWryXHoEcS22YHthuPQSJdMy6KNrzIRzWqcsHzD/WUnqe45whVou4VIsPew37DoXWNrA==", - "requires": { - "define-properties": "^1.1.3", - "es-abstract": "^1.17.2", - "has-symbols": "^1.0.1", - "object.getownpropertydescriptors": "^2.1.0" - }, - "dependencies": { - "es-abstract": { - "version": "1.17.7", - "resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.17.7.tgz", - "integrity": "sha512-VBl/gnfcJ7OercKA9MVaegWsBHFjV492syMudcnQZvt/Dw8ezpcOHYZXa/J96O8vx+g4x65YKhxOwDUh63aS5g==", - "requires": { - "es-to-primitive": "^1.2.1", - "function-bind": "^1.1.1", - "has": "^1.0.3", - "has-symbols": "^1.0.1", - "is-callable": "^1.2.2", - "is-regex": "^1.1.1", - "object-inspect": "^1.8.0", - "object-keys": "^1.1.1", - "object.assign": "^4.1.1", - "string.prototype.trimend": "^1.0.1", - "string.prototype.trimstart": "^1.0.1" - } - } - } - }, - "utila": { - "version": "0.4.0", - "resolved": "https://registry.npmjs.org/utila/-/utila-0.4.0.tgz", - "integrity": "sha1-ihagXURWV6Oupe7MWxKk+lN5dyw=" - }, - "utils-merge": { - "version": "1.0.1", - "resolved": "https://registry.npmjs.org/utils-merge/-/utils-merge-1.0.1.tgz", - "integrity": "sha1-n5VxD1CiZ5R7LMwSR0HBAoQn5xM=" - }, - "uuid": { - "version": "3.4.0", - "resolved": "https://registry.npmjs.org/uuid/-/uuid-3.4.0.tgz", - "integrity": "sha512-HjSDRw6gZE5JMggctHBcjVak08+KEVhSIiDzFnT9S9aegmp85S/bReBVTb4QTFaRNptJ9kuYaNhnbNEOkbKb/A==" - }, - "v-runtime-template": { - "version": "1.10.0", - "resolved": "https://registry.npmjs.org/v-runtime-template/-/v-runtime-template-1.10.0.tgz", - "integrity": "sha512-WLlq9jUepSfUrMEenw3mn7FDXX6hhbl11JjC1OKhwLzifHzVrY5a696TUHDPyj9jke3GGnR7b+2T3od/RL5cww==" - }, - "vary": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/vary/-/vary-1.1.2.tgz", - "integrity": "sha1-IpnwLG3tMNSllhsLn3RSShj2NPw=" - }, - "vendors": { - "version": "1.0.4", - "resolved": "https://registry.npmjs.org/vendors/-/vendors-1.0.4.tgz", - "integrity": "sha512-/juG65kTL4Cy2su4P8HjtkTxk6VmJDiOPBufWniqQ6wknac6jNiXS9vU+hO3wgusiyqWlzTbVHi0dyJqRONg3w==" - }, - "verror": { - "version": "1.10.0", - "resolved": "https://registry.npmjs.org/verror/-/verror-1.10.0.tgz", - "integrity": "sha1-OhBcoXBTr1XW4nDB+CiGguGNpAA=", - "requires": { - "assert-plus": "^1.0.0", - "core-util-is": "1.0.2", - "extsprintf": "^1.2.0" - } - }, - "vm-browserify": { - "version": "1.1.2", - "resolved": "https://registry.npmjs.org/vm-browserify/-/vm-browserify-1.1.2.tgz", - "integrity": "sha512-2ham8XPWTONajOR0ohOKOHXkm3+gaBmGut3SRuu75xLd/RRaY6vqgh8NBYYk7+RW3u5AtzPQZG8F10LHkl0lAQ==" - }, - "void-elements": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/void-elements/-/void-elements-2.0.1.tgz", - "integrity": "sha1-wGavtYK7HLQSjWDqkjkulNXp2+w=" - }, - "vue": { - "version": "2.6.12", - "resolved": "https://registry.npmjs.org/vue/-/vue-2.6.12.tgz", - "integrity": "sha512-uhmLFETqPPNyuLLbsKz6ioJ4q7AZHzD8ZVFNATNyICSZouqP2Sz0rotWQC8UNBF6VGSCs5abnKJoStA6JbCbfg==" - }, - "vue-hot-reload-api": { - "version": "2.3.4", - "resolved": "https://registry.npmjs.org/vue-hot-reload-api/-/vue-hot-reload-api-2.3.4.tgz", - "integrity": "sha512-BXq3jwIagosjgNVae6tkHzzIk6a8MHFtzAdwhnV5VlvPTFxDCvIttgSiHWjdGoTJvXtmRu5HacExfdarRcFhog==" - }, - "vue-loader": { - "version": "15.9.6", - "resolved": "https://registry.npmjs.org/vue-loader/-/vue-loader-15.9.6.tgz", - "integrity": "sha512-j0cqiLzwbeImIC6nVIby2o/ABAWhlppyL/m5oJ67R5MloP0hj/DtFgb0Zmq3J9CG7AJ+AXIvHVnJAPBvrLyuDg==", - "requires": { - "@vue/component-compiler-utils": "^3.1.0", - "hash-sum": "^1.0.2", - "loader-utils": "^1.1.0", - "vue-hot-reload-api": "^2.3.0", - "vue-style-loader": "^4.1.0" - } - }, - "vue-router": { - "version": "3.4.9", - "resolved": "https://registry.npmjs.org/vue-router/-/vue-router-3.4.9.tgz", - "integrity": "sha512-CGAKWN44RqXW06oC+u4mPgHLQQi2t6vLD/JbGRDAXm0YpMv0bgpKuU5bBd7AvMgfTz9kXVRIWKHqRwGEb8xFkA==" - }, - "vue-server-renderer": { - "version": "2.6.12", - "resolved": "https://registry.npmjs.org/vue-server-renderer/-/vue-server-renderer-2.6.12.tgz", - "integrity": "sha512-3LODaOsnQx7iMFTBLjki8xSyOxhCtbZ+nQie0wWY4iOVeEtTg1a3YQAjd82WvKxrWHHTshjvLb7OXMc2/dYuxw==", - "requires": { - "chalk": "^1.1.3", - "hash-sum": "^1.0.2", - "he": "^1.1.0", - "lodash.template": "^4.5.0", - "lodash.uniq": "^4.5.0", - "resolve": "^1.2.0", - "serialize-javascript": "^3.1.0", - "source-map": "0.5.6" - }, - "dependencies": { - "ansi-styles": { - "version": "2.2.1", - "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-2.2.1.tgz", - "integrity": "sha1-tDLdM1i2NM914eRmQ2gkBTPB3b4=" - }, - "chalk": { - "version": "1.1.3", - "resolved": "https://registry.npmjs.org/chalk/-/chalk-1.1.3.tgz", - "integrity": "sha1-qBFcVeSnAv5NFQq9OHKCKn4J/Jg=", - "requires": { - "ansi-styles": "^2.2.1", - "escape-string-regexp": "^1.0.2", - "has-ansi": "^2.0.0", - "strip-ansi": "^3.0.0", - "supports-color": "^2.0.0" - } - }, - "serialize-javascript": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/serialize-javascript/-/serialize-javascript-3.1.0.tgz", - "integrity": "sha512-JIJT1DGiWmIKhzRsG91aS6Ze4sFUrYbltlkg2onR5OrnNM02Kl/hnY/T4FN2omvyeBbQmMJv+K4cPOpGzOTFBg==", - "requires": { - "randombytes": "^2.1.0" - } - }, - "source-map": { - "version": "0.5.6", - "resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.6.tgz", - "integrity": "sha1-dc449SvwczxafwwRjYEzSiu19BI=" - }, - "supports-color": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-2.0.0.tgz", - "integrity": "sha1-U10EXOa2Nj+kARcIRimZXp3zJMc=" - } - } - }, - "vue-style-loader": { - "version": "4.1.2", - "resolved": "https://registry.npmjs.org/vue-style-loader/-/vue-style-loader-4.1.2.tgz", - "integrity": "sha512-0ip8ge6Gzz/Bk0iHovU9XAUQaFt/G2B61bnWa2tCcqqdgfHs1lF9xXorFbE55Gmy92okFT+8bfmySuUOu13vxQ==", - "requires": { - "hash-sum": "^1.0.2", - "loader-utils": "^1.0.2" - } - }, - "vue-template-compiler": { - "version": "2.6.12", - "resolved": "https://registry.npmjs.org/vue-template-compiler/-/vue-template-compiler-2.6.12.tgz", - "integrity": "sha512-OzzZ52zS41YUbkCBfdXShQTe69j1gQDZ9HIX8miuC9C3rBCk9wIRjLiZZLrmX9V+Ftq/YEyv1JaVr5Y/hNtByg==", - "requires": { - "de-indent": "^1.0.2", - "he": "^1.1.0" - } - }, - "vue-template-es2015-compiler": { - "version": "1.9.1", - "resolved": "https://registry.npmjs.org/vue-template-es2015-compiler/-/vue-template-es2015-compiler-1.9.1.tgz", - "integrity": "sha512-4gDntzrifFnCEvyoO8PqyJDmguXgVPxKiIxrBKjIowvL9l+N66196+72XVYR8BBf1Uv1Fgt3bGevJ+sEmxfZzw==" - }, - "vuepress": { - "version": "1.8.0", - "resolved": "https://registry.npmjs.org/vuepress/-/vuepress-1.8.0.tgz", - "integrity": "sha512-YvNitvoEc+JSJRv1W+IoRnvOTFyTWyUMuGuF2kTIbiSwIHb1hNinc3lqNSeBQJy7IBqyEzK5fnTq1mlynh4gwA==", - "requires": { - "@vuepress/core": "1.8.0", - "@vuepress/theme-default": "1.8.0", - "cac": "^6.5.6", - "envinfo": "^7.2.0", - "opencollective-postinstall": "^2.0.2", - "update-notifier": "^4.0.0" - } - }, - "vuepress-html-webpack-plugin": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/vuepress-html-webpack-plugin/-/vuepress-html-webpack-plugin-3.2.0.tgz", - "integrity": "sha512-BebAEl1BmWlro3+VyDhIOCY6Gef2MCBllEVAP3NUAtMguiyOwo/dClbwJ167WYmcxHJKLl7b0Chr9H7fpn1d0A==", - "requires": { - "html-minifier": "^3.2.3", - "loader-utils": "^0.2.16", - "lodash": "^4.17.3", - "pretty-error": "^2.0.2", - "tapable": "^1.0.0", - "toposort": "^1.0.0", - "util.promisify": "1.0.0" - }, - "dependencies": { - "big.js": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/big.js/-/big.js-3.2.0.tgz", - "integrity": "sha512-+hN/Zh2D08Mx65pZ/4g5bsmNiZUuChDiQfTUQ7qJr4/kuopCr88xZsAXv6mBoZEsUI4OuGHlX59qE94K2mMW8Q==" - }, - "emojis-list": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/emojis-list/-/emojis-list-2.1.0.tgz", - "integrity": "sha1-TapNnbAPmBmIDHn6RXrlsJof04k=" - }, - "json5": { - "version": "0.5.1", - "resolved": "https://registry.npmjs.org/json5/-/json5-0.5.1.tgz", - "integrity": "sha1-Hq3nrMASA0rYTiOWdn6tn6VJWCE=" - }, - "loader-utils": { - "version": "0.2.17", - "resolved": "https://registry.npmjs.org/loader-utils/-/loader-utils-0.2.17.tgz", - "integrity": "sha1-+G5jdNQyBabmxg6RlvF8Apm/s0g=", - "requires": { - "big.js": "^3.1.3", - "emojis-list": "^2.0.0", - "json5": "^0.5.0", - "object-assign": "^4.0.1" - } - }, - "util.promisify": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/util.promisify/-/util.promisify-1.0.0.tgz", - "integrity": "sha512-i+6qA2MPhvoKLuxnJNpXAGhg7HphQOSUq2LKMZD0m15EiskXUkMvKdF4Uui0WYeCUGea+o2cw/ZuwehtfsrNkA==", - "requires": { - "define-properties": "^1.1.2", - "object.getownpropertydescriptors": "^2.0.3" - } - } - } - }, - "vuepress-plugin-container": { - "version": "2.1.5", - "resolved": "https://registry.npmjs.org/vuepress-plugin-container/-/vuepress-plugin-container-2.1.5.tgz", - "integrity": "sha512-TQrDX/v+WHOihj3jpilVnjXu9RcTm6m8tzljNJwYhxnJUW0WWQ0hFLcDTqTBwgKIFdEiSxVOmYE+bJX/sq46MA==", - "requires": { - "@vuepress/shared-utils": "^1.2.0", - "markdown-it-container": "^2.0.0" - } - }, - "vuepress-plugin-google-tag-manager": { - "version": "0.0.5", - "resolved": "https://registry.npmjs.org/vuepress-plugin-google-tag-manager/-/vuepress-plugin-google-tag-manager-0.0.5.tgz", - "integrity": "sha512-Hm1GNDdNmc4Vs9c3OMfTtHicB/oZWNCmzMFPdlOObVN1OjizIjImdm+LZIwiVKVndT2TQ4BPhMx7HQkovmD2Lg==" - }, - "vuepress-plugin-sitemap": { - "version": "2.3.1", - "resolved": "https://registry.npmjs.org/vuepress-plugin-sitemap/-/vuepress-plugin-sitemap-2.3.1.tgz", - "integrity": "sha512-n+8lbukhrKrsI9H/EX0EBgkE1pn85LAQFvQ5dIvrZP4Kz6JxPOPPNTQmZMhahQV1tXbLZQCEN7A1WZH4x+arJQ==", - "requires": { - "sitemap": "^3.0.0" - } - }, - "vuepress-plugin-smooth-scroll": { - "version": "0.0.3", - "resolved": "https://registry.npmjs.org/vuepress-plugin-smooth-scroll/-/vuepress-plugin-smooth-scroll-0.0.3.tgz", - "integrity": "sha512-qsQkDftLVFLe8BiviIHaLV0Ea38YLZKKonDGsNQy1IE0wllFpFIEldWD8frWZtDFdx6b/O3KDMgVQ0qp5NjJCg==", - "requires": { - "smoothscroll-polyfill": "^0.4.3" - } - }, - "vuepress-theme-cosmos": { - "version": "1.0.180", - "resolved": "https://registry.npmjs.org/vuepress-theme-cosmos/-/vuepress-theme-cosmos-1.0.180.tgz", - "integrity": "sha512-NooA8qCNq/e4fjchOkKtLTaBkPHX1PAfMezP+1ttwezjnHeA1TIccjlqDbq8U7Ath4BXzmcDL5KMX3RtuDARDg==", - "requires": { - "@cosmos-ui/vue": "^0.35.0", - "@vuepress/plugin-google-analytics": "1.7.1", - "algoliasearch": "^4.2.0", - "axios": "^0.21.0", - "cheerio": "^1.0.0-rc.3", - "clipboard-copy": "^3.1.0", - "entities": "2.1.0", - "esm": "^3.2.25", - "gray-matter": "^4.0.2", - "hotkeys-js": "3.8.1", - "jsonp": "^0.2.1", - "markdown-it": "^12.0.0", - "markdown-it-attrs": "^3.0.3", - "prismjs": "^1.22.0", - "pug": "^2.0.4", - "pug-plain-loader": "^1.0.0", - "stylus": "^0.54.8", - "stylus-loader": "^3.0.2", - "tiny-cookie": "^2.3.2", - "v-runtime-template": "^1.10.0", - "vuepress": "^1.5.4", - "vuepress-plugin-google-tag-manager": "0.0.5", - "vuepress-plugin-sitemap": "^2.3.1" - } - }, - "watchpack": { - "version": "1.7.5", - "resolved": "https://registry.npmjs.org/watchpack/-/watchpack-1.7.5.tgz", - "integrity": "sha512-9P3MWk6SrKjHsGkLT2KHXdQ/9SNkyoJbabxnKOoJepsvJjJG8uYTR3yTPxPQvNDI3w4Nz1xnE0TLHK4RIVe/MQ==", - "requires": { - "chokidar": "^3.4.1", - "graceful-fs": "^4.1.2", - "neo-async": "^2.5.0", - "watchpack-chokidar2": "^2.0.1" - }, - "dependencies": { - "anymatch": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.1.tgz", - "integrity": "sha512-mM8522psRCqzV+6LhomX5wgp25YVibjh8Wj23I5RPkPppSVSjyKD2A2mBJmWGa+KN7f2D6LNh9jkBCeyLktzjg==", - "optional": true, - "requires": { - "normalize-path": "^3.0.0", - "picomatch": "^2.0.4" - } - }, - "binary-extensions": { - "version": "2.2.0", - "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.2.0.tgz", - "integrity": "sha512-jDctJ/IVQbZoJykoeHbhXpOlNBqGNcwXJKJog42E5HDPUwQTSdjCHdihjj0DlnheQ7blbT6dHOafNAiS8ooQKA==", - "optional": true - }, - "braces": { - "version": "3.0.2", - "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz", - "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==", - "optional": true, - "requires": { - "fill-range": "^7.0.1" - } - }, - "chokidar": { - "version": "3.5.1", - "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.5.1.tgz", - "integrity": "sha512-9+s+Od+W0VJJzawDma/gvBNQqkTiqYTWLuZoyAsivsI4AaWTCzHG06/TMjsf1cYe9Cb97UCEhjz7HvnPk2p/tw==", - "optional": true, - "requires": { - "anymatch": "~3.1.1", - "braces": "~3.0.2", - "fsevents": "~2.3.1", - "glob-parent": "~5.1.0", - "is-binary-path": "~2.1.0", - "is-glob": "~4.0.1", - "normalize-path": "~3.0.0", - "readdirp": "~3.5.0" - } - }, - "fill-range": { - "version": "7.0.1", - "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz", - "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==", - "optional": true, - "requires": { - "to-regex-range": "^5.0.1" - } - }, - "fsevents": { - "version": "2.3.1", - "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.1.tgz", - "integrity": "sha512-YR47Eg4hChJGAB1O3yEAOkGO+rlzutoICGqGo9EZ4lKWokzZRSyIW1QmTzqjtw8MJdj9srP869CuWw/hyzSiBw==", - "optional": true - }, - "glob-parent": { - "version": "5.1.1", - "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.1.tgz", - "integrity": "sha512-FnI+VGOpnlGHWZxthPGR+QhR78fuiK0sNLkHQv+bL9fQi57lNNdquIbna/WrfROrolq8GK5Ek6BiMwqL/voRYQ==", - "optional": true, - "requires": { - "is-glob": "^4.0.1" - } - }, - "is-binary-path": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz", - "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==", - "optional": true, - "requires": { - "binary-extensions": "^2.0.0" - } - }, - "is-number": { - "version": "7.0.0", - "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz", - "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==", - "optional": true - }, - "readdirp": { - "version": "3.5.0", - "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.5.0.tgz", - "integrity": "sha512-cMhu7c/8rdhkHXWsY+osBhfSy0JikwpHK/5+imo+LpeasTF8ouErHrlYkwT0++njiyuDvc7OFY5T3ukvZ8qmFQ==", - "optional": true, - "requires": { - "picomatch": "^2.2.1" - } - }, - "to-regex-range": { - "version": "5.0.1", - "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz", - "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==", - "optional": true, - "requires": { - "is-number": "^7.0.0" - } - } - } - }, - "watchpack-chokidar2": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/watchpack-chokidar2/-/watchpack-chokidar2-2.0.1.tgz", - "integrity": "sha512-nCFfBIPKr5Sh61s4LPpy1Wtfi0HE8isJ3d2Yb5/Ppw2P2B/3eVSEBjKfN0fmHJSK14+31KwMKmcrzs2GM4P0Ww==", - "optional": true, - "requires": { - "chokidar": "^2.1.8" - } - }, - "wbuf": { - "version": "1.7.3", - "resolved": "https://registry.npmjs.org/wbuf/-/wbuf-1.7.3.tgz", - "integrity": "sha512-O84QOnr0icsbFGLS0O3bI5FswxzRr8/gHwWkDlQFskhSPryQXvrTMxjxGP4+iWYoauLoBvfDpkrOauZ+0iZpDA==", - "requires": { - "minimalistic-assert": "^1.0.0" - } - }, - "webidl-conversions": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-4.0.2.tgz", - "integrity": "sha512-YQ+BmxuTgd6UXZW3+ICGfyqRyHXVlD5GtQr5+qjiNW7bF0cqrzX500HVXPBOvgXb5YnzDd+h0zqyv61KUD7+Sg==" - }, - "webpack": { - "version": "4.46.0", - "resolved": "https://registry.npmjs.org/webpack/-/webpack-4.46.0.tgz", - "integrity": "sha512-6jJuJjg8znb/xRItk7bkT0+Q7AHCYjjFnvKIWQPkNIOyRqoCGvkOs0ipeQzrqz4l5FtN5ZI/ukEHroeX/o1/5Q==", - "requires": { - "@webassemblyjs/ast": "1.9.0", - "@webassemblyjs/helper-module-context": "1.9.0", - "@webassemblyjs/wasm-edit": "1.9.0", - "@webassemblyjs/wasm-parser": "1.9.0", - "acorn": "^6.4.1", - "ajv": "^6.10.2", - "ajv-keywords": "^3.4.1", - "chrome-trace-event": "^1.0.2", - "enhanced-resolve": "^4.5.0", - "eslint-scope": "^4.0.3", - "json-parse-better-errors": "^1.0.2", - "loader-runner": "^2.4.0", - "loader-utils": "^1.2.3", - "memory-fs": "^0.4.1", - "micromatch": "^3.1.10", - "mkdirp": "^0.5.3", - "neo-async": "^2.6.1", - "node-libs-browser": "^2.2.1", - "schema-utils": "^1.0.0", - "tapable": "^1.1.3", - "terser-webpack-plugin": "^1.4.3", - "watchpack": "^1.7.4", - "webpack-sources": "^1.4.1" - }, - "dependencies": { - "acorn": { - "version": "6.4.2", - "resolved": "https://registry.npmjs.org/acorn/-/acorn-6.4.2.tgz", - "integrity": "sha512-XtGIhXwF8YM8bJhGxG5kXgjkEuNGLTkoYqVE+KMR+aspr4KGYmKYg7yUe3KghyQ9yheNwLnjmzh/7+gfDBmHCQ==" - }, - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - }, - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - } - } - }, - "webpack-chain": { - "version": "6.5.1", - "resolved": "https://registry.npmjs.org/webpack-chain/-/webpack-chain-6.5.1.tgz", - "integrity": "sha512-7doO/SRtLu8q5WM0s7vPKPWX580qhi0/yBHkOxNkv50f6qB76Zy9o2wRTrrPULqYTvQlVHuvbA8v+G5ayuUDsA==", - "requires": { - "deepmerge": "^1.5.2", - "javascript-stringify": "^2.0.1" - }, - "dependencies": { - "javascript-stringify": { - "version": "2.0.1", - "resolved": "https://registry.npmjs.org/javascript-stringify/-/javascript-stringify-2.0.1.tgz", - "integrity": "sha512-yV+gqbd5vaOYjqlbk16EG89xB5udgjqQF3C5FAORDg4f/IS1Yc5ERCv5e/57yBcfJYw05V5JyIXabhwb75Xxow==" - } - } - }, - "webpack-dev-middleware": { - "version": "3.7.3", - "resolved": "https://registry.npmjs.org/webpack-dev-middleware/-/webpack-dev-middleware-3.7.3.tgz", - "integrity": "sha512-djelc/zGiz9nZj/U7PTBi2ViorGJXEWo/3ltkPbDyxCXhhEXkW0ce99falaok4TPj+AsxLiXJR0EBOb0zh9fKQ==", - "requires": { - "memory-fs": "^0.4.1", - "mime": "^2.4.4", - "mkdirp": "^0.5.1", - "range-parser": "^1.2.1", - "webpack-log": "^2.0.0" - }, - "dependencies": { - "mkdirp": { - "version": "0.5.5", - "resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.5.tgz", - "integrity": "sha512-NKmAlESf6jMGym1++R0Ra7wvhV+wFW63FaSOFPwRahvea0gMUcGUhVeAg/0BC0wiv9ih5NYPB1Wn1UEI1/L+xQ==", - "requires": { - "minimist": "^1.2.5" - } - } - } - }, - "webpack-dev-server": { - "version": "3.11.2", - "resolved": "https://registry.npmjs.org/webpack-dev-server/-/webpack-dev-server-3.11.2.tgz", - "integrity": "sha512-A80BkuHRQfCiNtGBS1EMf2ChTUs0x+B3wGDFmOeT4rmJOHhHTCH2naNxIHhmkr0/UillP4U3yeIyv1pNp+QDLQ==", - "requires": { - "ansi-html": "0.0.7", - "bonjour": "^3.5.0", - "chokidar": "^2.1.8", - "compression": "^1.7.4", - "connect-history-api-fallback": "^1.6.0", - "debug": "^4.1.1", - "del": "^4.1.1", - "express": "^4.17.1", - "html-entities": "^1.3.1", - "http-proxy-middleware": "0.19.1", - "import-local": "^2.0.0", - "internal-ip": "^4.3.0", - "ip": "^1.1.5", - "is-absolute-url": "^3.0.3", - "killable": "^1.0.1", - "loglevel": "^1.6.8", - "opn": "^5.5.0", - "p-retry": "^3.0.1", - "portfinder": "^1.0.26", - "schema-utils": "^1.0.0", - "selfsigned": "^1.10.8", - "semver": "^6.3.0", - "serve-index": "^1.9.1", - "sockjs": "^0.3.21", - "sockjs-client": "^1.5.0", - "spdy": "^4.0.2", - "strip-ansi": "^3.0.1", - "supports-color": "^6.1.0", - "url": "^0.11.0", - "webpack-dev-middleware": "^3.7.2", - "webpack-log": "^2.0.0", - "ws": "^6.2.1", - "yargs": "^13.3.2" - }, - "dependencies": { - "ansi-regex": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-4.1.0.tgz", - "integrity": "sha512-1apePfXM1UOSqw0o9IiFAovVz9M5S1Dg+4TrDwfMewQ6p/rmMueb7tWZjQ1rx4Loy1ArBggoqGpfqqdI4rondg==" - }, - "cliui": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/cliui/-/cliui-5.0.0.tgz", - "integrity": "sha512-PYeGSEmmHM6zvoef2w8TPzlrnNpXIjTipYK780YswmIP9vjxmd6Y2a3CB2Ks6/AU8NHjZugXvo8w3oWM2qnwXA==", - "requires": { - "string-width": "^3.1.0", - "strip-ansi": "^5.2.0", - "wrap-ansi": "^5.1.0" - }, - "dependencies": { - "strip-ansi": { - "version": "5.2.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-5.2.0.tgz", - "integrity": "sha512-DuRs1gKbBqsMKIZlrffwlug8MHkcnpjs5VPmL1PAh+mA30U0DTotfDZ0d2UUsXpPmPmMMJ6W773MaA3J+lbiWA==", - "requires": { - "ansi-regex": "^4.1.0" - } - } - } - }, - "debug": { - "version": "4.3.1", - "resolved": "https://registry.npmjs.org/debug/-/debug-4.3.1.tgz", - "integrity": "sha512-doEwdvm4PCeK4K3RQN2ZC2BYUBaxwLARCqZmMjtF8a51J2Rb0xpVloFRnCODwqjpwnAoao4pelN8l3RJdv3gRQ==", - "requires": { - "ms": "2.1.2" - } - }, - "find-up": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/find-up/-/find-up-3.0.0.tgz", - "integrity": "sha512-1yD6RmLI1XBfxugvORwlck6f75tYL+iR0jqwsOrOxMZyGYqUuDhJ0l4AXdO1iX/FTs9cBAMEk1gWSEx1kSbylg==", - "requires": { - "locate-path": "^3.0.0" - } - }, - "is-absolute-url": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/is-absolute-url/-/is-absolute-url-3.0.3.tgz", - "integrity": "sha512-opmNIX7uFnS96NtPmhWQgQx6/NYFgsUXYMllcfzwWKUMwfo8kku1TvE6hkNcH+Q1ts5cMVrsY7j0bxXQDciu9Q==" - }, - "locate-path": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/locate-path/-/locate-path-3.0.0.tgz", - "integrity": "sha512-7AO748wWnIhNqAuaty2ZWHkQHRSNfPVIsPIfwEOWO22AmaoVrWavlOcMR5nzTLNYvp36X220/maaRsrec1G65A==", - "requires": { - "p-locate": "^3.0.0", - "path-exists": "^3.0.0" - } - }, - "ms": { - "version": "2.1.2", - "resolved": "https://registry.npmjs.org/ms/-/ms-2.1.2.tgz", - "integrity": "sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==" - }, - "p-locate": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/p-locate/-/p-locate-3.0.0.tgz", - "integrity": "sha512-x+12w/To+4GFfgJhBEpiDcLozRJGegY+Ei7/z0tSLkMmxGZNybVMSfWj9aJn8Z5Fc7dBUNJOOVgPv2H7IwulSQ==", - "requires": { - "p-limit": "^2.0.0" - } - }, - "path-exists": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/path-exists/-/path-exists-3.0.0.tgz", - "integrity": "sha1-zg6+ql94yxiSXqfYENe1mwEP1RU=" - }, - "schema-utils": { - "version": "1.0.0", - "resolved": "https://registry.npmjs.org/schema-utils/-/schema-utils-1.0.0.tgz", - "integrity": "sha512-i27Mic4KovM/lnGsy8whRCHhc7VicJajAjTrYg11K9zfZXnYIt4k5F+kZkwjnrhKzLic/HLU4j11mjsz2G/75g==", - "requires": { - "ajv": "^6.1.0", - "ajv-errors": "^1.0.0", - "ajv-keywords": "^3.1.0" - } - }, - "supports-color": { - "version": "6.1.0", - "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-6.1.0.tgz", - "integrity": "sha512-qe1jfm1Mg7Nq/NSh6XE24gPXROEVsWHxC1LIx//XNlD9iw7YZQGjZNjYN7xGaEG6iKdA8EtNFW6R0gjnVXp+wQ==", - "requires": { - "has-flag": "^3.0.0" - } - }, - "yargs": { - "version": "13.3.2", - "resolved": "https://registry.npmjs.org/yargs/-/yargs-13.3.2.tgz", - "integrity": "sha512-AX3Zw5iPruN5ie6xGRIDgqkT+ZhnRlZMLMHAs8tg7nRruy2Nb+i5o9bwghAogtM08q1dpr2LVoS8KSTMYpWXUw==", - "requires": { - "cliui": "^5.0.0", - "find-up": "^3.0.0", - "get-caller-file": "^2.0.1", - "require-directory": "^2.1.1", - "require-main-filename": "^2.0.0", - "set-blocking": "^2.0.0", - "string-width": "^3.0.0", - "which-module": "^2.0.0", - "y18n": "^4.0.0", - "yargs-parser": "^13.1.2" - } - } - } - }, - "webpack-log": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/webpack-log/-/webpack-log-2.0.0.tgz", - "integrity": "sha512-cX8G2vR/85UYG59FgkoMamwHUIkSSlV3bBMRsbxVXVUk2j6NleCKjQ/WE9eYg9WY4w25O9w8wKP4rzNZFmUcUg==", - "requires": { - "ansi-colors": "^3.0.0", - "uuid": "^3.3.2" - } - }, - "webpack-merge": { - "version": "4.2.2", - "resolved": "https://registry.npmjs.org/webpack-merge/-/webpack-merge-4.2.2.tgz", - "integrity": "sha512-TUE1UGoTX2Cd42j3krGYqObZbOD+xF7u28WB7tfUordytSjbWTIjK/8V0amkBfTYN4/pB/GIDlJZZ657BGG19g==", - "requires": { - "lodash": "^4.17.15" - } - }, - "webpack-sources": { - "version": "1.4.3", - "resolved": "https://registry.npmjs.org/webpack-sources/-/webpack-sources-1.4.3.tgz", - "integrity": "sha512-lgTS3Xhv1lCOKo7SA5TjKXMjpSM4sBjNV5+q2bqesbSPs5FjGmU6jjtBSkX9b4qW87vDIsCIlUPOEhbZrMdjeQ==", - "requires": { - "source-list-map": "^2.0.0", - "source-map": "~0.6.1" - } - }, - "webpackbar": { - "version": "3.2.0", - "resolved": "https://registry.npmjs.org/webpackbar/-/webpackbar-3.2.0.tgz", - "integrity": "sha512-PC4o+1c8gWWileUfwabe0gqptlXUDJd5E0zbpr2xHP1VSOVlZVPBZ8j6NCR8zM5zbKdxPhctHXahgpNK1qFDPw==", - "requires": { - "ansi-escapes": "^4.1.0", - "chalk": "^2.4.1", - "consola": "^2.6.0", - "figures": "^3.0.0", - "pretty-time": "^1.1.0", - "std-env": "^2.2.1", - "text-table": "^0.2.0", - "wrap-ansi": "^5.1.0" - } - }, - "websocket-driver": { - "version": "0.7.4", - "resolved": "https://registry.npmjs.org/websocket-driver/-/websocket-driver-0.7.4.tgz", - "integrity": "sha512-b17KeDIQVjvb0ssuSDF2cYXSg2iztliJ4B9WdsuB6J952qCPKmnVq4DyW5motImXHDC1cBT/1UezrJVsKw5zjg==", - "requires": { - "http-parser-js": ">=0.5.1", - "safe-buffer": ">=5.1.0", - "websocket-extensions": ">=0.1.1" - } - }, - "websocket-extensions": { - "version": "0.1.4", - "resolved": "https://registry.npmjs.org/websocket-extensions/-/websocket-extensions-0.1.4.tgz", - "integrity": "sha512-OqedPIGOfsDlo31UNwYbCFMSaO9m9G/0faIHj5/dZFDMFqPTcx6UwqyOy3COEaEOg/9VsGIpdqn62W5KhoKSpg==" - }, - "whatwg-url": { - "version": "7.1.0", - "resolved": "https://registry.npmjs.org/whatwg-url/-/whatwg-url-7.1.0.tgz", - "integrity": "sha512-WUu7Rg1DroM7oQvGWfOiAK21n74Gg+T4elXEQYkOhtyLeWiJFoOGLXPKI/9gzIie9CtwVLm8wtw6YJdKyxSjeg==", - "requires": { - "lodash.sortby": "^4.7.0", - "tr46": "^1.0.1", - "webidl-conversions": "^4.0.2" - } - }, - "when": { - "version": "3.6.4", - "resolved": "https://registry.npmjs.org/when/-/when-3.6.4.tgz", - "integrity": "sha1-RztRfsFZ4rhQBUl6E5g/CVQS404=" - }, - "which": { - "version": "1.3.1", - "resolved": "https://registry.npmjs.org/which/-/which-1.3.1.tgz", - "integrity": "sha512-HxJdYWq1MTIQbJ3nw0cqssHoTNU267KlrDuGZ1WYlxDStUtKUhOaJmh112/TZmHxxUfuJqPXSOm7tDyas0OSIQ==", - "requires": { - "isexe": "^2.0.0" - } - }, - "which-module": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/which-module/-/which-module-2.0.0.tgz", - "integrity": "sha1-2e8H3Od7mQK4o6j6SzHD4/fm6Ho=" - }, - "widest-line": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/widest-line/-/widest-line-3.1.0.tgz", - "integrity": "sha512-NsmoXalsWVDMGupxZ5R08ka9flZjjiLvHVAWYOKtiKM8ujtZWr9cRffak+uSE48+Ob8ObalXpwyeUiyDD6QFgg==", - "requires": { - "string-width": "^4.0.0" - }, - "dependencies": { - "ansi-regex": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.0.tgz", - "integrity": "sha512-bY6fj56OUQ0hU1KjFNDQuJFezqKdrAyFdIevADiqrWHwSlbmBNMHp5ak2f40Pm8JTFyM2mqxkG6ngkHO11f/lg==" - }, - "emoji-regex": { - "version": "8.0.0", - "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz", - "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==" - }, - "is-fullwidth-code-point": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz", - "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==" - }, - "string-width": { - "version": "4.2.0", - "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.0.tgz", - "integrity": "sha512-zUz5JD+tgqtuDjMhwIg5uFVV3dtqZ9yQJlZVfq4I01/K5Paj5UHj7VyrQOJvzawSVlKpObApbfD0Ed6yJc+1eg==", - "requires": { - "emoji-regex": "^8.0.0", - "is-fullwidth-code-point": "^3.0.0", - "strip-ansi": "^6.0.0" - } - }, - "strip-ansi": { - "version": "6.0.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.0.tgz", - "integrity": "sha512-AuvKTrTfQNYNIctbR1K/YGTR1756GycPsg7b9bdV9Duqur4gv6aKqHXah67Z8ImS7WEz5QVcOtlfW2rZEugt6w==", - "requires": { - "ansi-regex": "^5.0.0" - } - } - } - }, - "window-size": { - "version": "0.1.0", - "resolved": "https://registry.npmjs.org/window-size/-/window-size-0.1.0.tgz", - "integrity": "sha1-VDjNLqk7IC76Ohn+iIeu58lPnJ0=" - }, - "with": { - "version": "5.1.1", - "resolved": "https://registry.npmjs.org/with/-/with-5.1.1.tgz", - "integrity": "sha1-+k2qktrzLE6pTtRTyB8EaGtXXf4=", - "requires": { - "acorn": "^3.1.0", - "acorn-globals": "^3.0.0" - } - }, - "wordwrap": { - "version": "0.0.2", - "resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.2.tgz", - "integrity": "sha1-t5Zpu0LstAn4PVg8rVLKF+qhZD8=" - }, - "worker-farm": { - "version": "1.7.0", - "resolved": "https://registry.npmjs.org/worker-farm/-/worker-farm-1.7.0.tgz", - "integrity": "sha512-rvw3QTZc8lAxyVrqcSGVm5yP/IJ2UcB3U0graE3LCFoZ0Yn2x4EoVSqJKdB/T5M+FLcRPjz4TDacRf3OCfNUzw==", - "requires": { - "errno": "~0.1.7" - } - }, - "wrap-ansi": { - "version": "5.1.0", - "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-5.1.0.tgz", - "integrity": "sha512-QC1/iN/2/RPVJ5jYK8BGttj5z83LmSKmvbvrXPNCLZSEb32KKVDJDl/MOt2N01qU2H/FkzEa9PKto1BqDjtd7Q==", - "requires": { - "ansi-styles": "^3.2.0", - "string-width": "^3.0.0", - "strip-ansi": "^5.0.0" - }, - "dependencies": { - "ansi-regex": { - "version": "4.1.0", - "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-4.1.0.tgz", - "integrity": "sha512-1apePfXM1UOSqw0o9IiFAovVz9M5S1Dg+4TrDwfMewQ6p/rmMueb7tWZjQ1rx4Loy1ArBggoqGpfqqdI4rondg==" - }, - "strip-ansi": { - "version": "5.2.0", - "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-5.2.0.tgz", - "integrity": "sha512-DuRs1gKbBqsMKIZlrffwlug8MHkcnpjs5VPmL1PAh+mA30U0DTotfDZ0d2UUsXpPmPmMMJ6W773MaA3J+lbiWA==", - "requires": { - "ansi-regex": "^4.1.0" - } - } - } - }, - "wrappy": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz", - "integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=" - }, - "write-file-atomic": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/write-file-atomic/-/write-file-atomic-3.0.3.tgz", - "integrity": "sha512-AvHcyZ5JnSfq3ioSyjrBkH9yW4m7Ayk8/9My/DD9onKeu/94fwrMocemO2QAJFAlnnDN+ZDS+ZjAR5ua1/PV/Q==", - "requires": { - "imurmurhash": "^0.1.4", - "is-typedarray": "^1.0.0", - "signal-exit": "^3.0.2", - "typedarray-to-buffer": "^3.1.5" - } - }, - "ws": { - "version": "6.2.1", - "resolved": "https://registry.npmjs.org/ws/-/ws-6.2.1.tgz", - "integrity": "sha512-GIyAXC2cB7LjvpgMt9EKS2ldqr0MTrORaleiOno6TweZ6r3TKtoFQWay/2PceJ3RuBasOHzXNn5Lrw1X0bEjqA==", - "requires": { - "async-limiter": "~1.0.0" - } - }, - "xdg-basedir": { - "version": "4.0.0", - "resolved": "https://registry.npmjs.org/xdg-basedir/-/xdg-basedir-4.0.0.tgz", - "integrity": "sha512-PSNhEJDejZYV7h50BohL09Er9VaIefr2LMAf3OEmpCkjOi34eYyQYAXUTjEQtZJTKcF0E2UKTh+osDLsgNim9Q==" - }, - "xmlbuilder": { - "version": "13.0.2", - "resolved": "https://registry.npmjs.org/xmlbuilder/-/xmlbuilder-13.0.2.tgz", - "integrity": "sha512-Eux0i2QdDYKbdbA6AM6xE4m6ZTZr4G4xF9kahI2ukSEMCzwce2eX9WlTI5J3s+NU7hpasFsr8hWIONae7LluAQ==" - }, - "xtend": { - "version": "4.0.2", - "resolved": "https://registry.npmjs.org/xtend/-/xtend-4.0.2.tgz", - "integrity": "sha512-LKYU1iAXJXUgAXn9URjiu+MWhyUXHsvfp7mcuYm9dSUKK0/CjtrUwFAxD82/mCWbtLsGjFIad0wIsod4zrTAEQ==" - }, - "y18n": { - "version": "4.0.1", - "resolved": "https://registry.npmjs.org/y18n/-/y18n-4.0.1.tgz", - "integrity": "sha512-wNcy4NvjMYL8gogWWYAO7ZFWFfHcbdbE57tZO8e4cbpj8tfUcwrwqSl3ad8HxpYWCdXcJUCeKKZS62Av1affwQ==" - }, - "yallist": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/yallist/-/yallist-3.1.1.tgz", - "integrity": "sha512-a4UGQaWPH59mOXUYnAG2ewncQS4i4F43Tv3JoAM+s2VDAmS9NsK8GpDMLrCHPksFT7h3K6TOoUNn2pb7RoXx4g==" - }, - "yargs": { - "version": "3.10.0", - "resolved": "https://registry.npmjs.org/yargs/-/yargs-3.10.0.tgz", - "integrity": "sha1-9+572FfdfB0tOMDnTvvWgdFDH9E=", - "requires": { - "camelcase": "^1.0.2", - "cliui": "^2.1.0", - "decamelize": "^1.0.0", - "window-size": "0.1.0" - } - }, - "yargs-parser": { - "version": "13.1.2", - "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-13.1.2.tgz", - "integrity": "sha512-3lbsNRf/j+A4QuSZfDRA7HRSfWrzO0YjqTJd5kjAq37Zep1CEgaYmrH9Q3GwPiB9cHyd1Y1UwggGhJGoxipbzg==", - "requires": { - "camelcase": "^5.0.0", - "decamelize": "^1.2.0" - }, - "dependencies": { - "camelcase": { - "version": "5.3.1", - "resolved": "https://registry.npmjs.org/camelcase/-/camelcase-5.3.1.tgz", - "integrity": "sha512-L28STB170nwWS63UjtlEOE3dldQApaJXZkOI1uMFfzf3rRuPegHaHesyee+YxQ+W6SvRDQV6UrdOdRiR153wJg==" - } - } - }, - "zepto": { - "version": "1.2.0", - "resolved": "https://registry.npmjs.org/zepto/-/zepto-1.2.0.tgz", - "integrity": "sha1-4Se9nmb9hGvl6rSME5SIL3wOT5g=" - } - } -} diff --git a/docs/package.json b/docs/package.json deleted file mode 100644 index e4427e8da2..0000000000 --- a/docs/package.json +++ /dev/null @@ -1,19 +0,0 @@ -{ - "name": "docs", - "version": "1.0.0", - "description": "Cosmos SDK Documentation", - "main": "index.js", - "scripts": { - "preserve": "./pre.sh", - "serve": "trap 'exit 0' SIGINT; vuepress dev --no-cache", - "postserve": "./post.sh", - "prebuild": "./pre.sh", - "build": "trap 'exit 0' SIGINT; vuepress build --no-cache", - "postbuild": "./post.sh" - }, - "author": "", - "license": "ISC", - "dependencies": { - "vuepress-theme-cosmos": "^1.0.179" - } -} diff --git a/docs/post.sh b/docs/post.sh deleted file mode 100755 index 2662dd1a31..0000000000 --- a/docs/post.sh +++ /dev/null @@ -1,3 +0,0 @@ -#!/usr/bin/env bash - -rm -rf modules diff --git a/docs/pre.sh b/docs/pre.sh deleted file mode 100755 index 47e4329fbf..0000000000 --- a/docs/pre.sh +++ /dev/null @@ -1,12 +0,0 @@ -#!/usr/bin/env bash - -mkdir -p modules - -for D in ../x/*; do - if [ -d "${D}" ]; then - rm -rf "modules/$(echo $D | awk -F/ '{print $NF}')" - mkdir -p "modules/$(echo $D | awk -F/ '{print $NF}')" && cp -r $D/spec/* "$_" - fi -done - -cat ../x/README.md | sed 's/\.\/x/\/modules/g' | sed 's/spec\/README.md//g' | sed 's/\.\.\/docs\/building-modules\/README\.md/\/building-modules\/intro\.html/g' > ./modules/README.md \ No newline at end of file diff --git a/docs/protodoc-markdown.tmpl b/docs/protodoc-markdown.tmpl deleted file mode 100644 index 28201837e5..0000000000 --- a/docs/protodoc-markdown.tmpl +++ /dev/null @@ -1,105 +0,0 @@ - -# Protobuf Documentation - - -## Table of Contents -{{range .Files}} -{{$file_name := .Name}}- [{{.Name}}](#{{.Name}}) - {{- if .Messages }} - {{range .Messages}} - [{{.LongName}}](#{{.FullName}}) - {{end}} - {{- end -}} - {{- if .Enums }} - {{range .Enums}} - [{{.LongName}}](#{{.FullName}}) - {{end}} - {{- end -}} - {{- if .Extensions }} - {{range .Extensions}} - [File-level Extensions](#{{$file_name}}-extensions) - {{end}} - {{- end -}} - {{- if .Services }} - {{range .Services}} - [{{.Name}}](#{{.FullName}}) - {{end}} - {{- end -}} -{{end}} -- [Scalar Value Types](#scalar-value-types) - -{{range .Files}} -{{$file_name := .Name}} - -

Top

- -## {{.Name}} -{{.Description}} - -{{range .Messages}} - - -### {{.LongName}} -{{.Description}} - -{{if .HasFields}} -| Field | Type | Label | Description | -| ----- | ---- | ----- | ----------- | -{{range .Fields -}} - | `{{.Name}}` | [{{.LongType}}](#{{.FullType}}) | {{.Label}} | {{if (index .Options "deprecated"|default false)}}**Deprecated.** {{end}}{{nobr .Description}}{{if .DefaultValue}} Default: {{.DefaultValue}}{{end}} | -{{end}} -{{end}} - -{{if .HasExtensions}} -| Extension | Type | Base | Number | Description | -| --------- | ---- | ---- | ------ | ----------- | -{{range .Extensions -}} - | `{{.Name}}` | {{.LongType}} | {{.ContainingLongType}} | {{.Number}} | {{nobr .Description}}{{if .DefaultValue}} Default: {{.DefaultValue}}{{end}} | -{{end}} -{{end}} - -{{end}} - -{{range .Enums}} - - -### {{.LongName}} -{{.Description}} - -| Name | Number | Description | -| ---- | ------ | ----------- | -{{range .Values -}} - | {{.Name}} | {{.Number}} | {{nobr .Description}} | -{{end}} - -{{end}} - -{{if .HasExtensions}} - - -### File-level Extensions -| Extension | Type | Base | Number | Description | -| --------- | ---- | ---- | ------ | ----------- | -{{range .Extensions -}} - | `{{.Name}}` | {{.LongType}} | {{.ContainingLongType}} | {{.Number}} | {{nobr .Description}}{{if .DefaultValue}} Default: `{{.DefaultValue}}`{{end}} | -{{end}} -{{end}} - -{{range .Services}} - - -### {{.Name}} -{{.Description}} - -| Method Name | Request Type | Response Type | Description | HTTP Verb | Endpoint | -| ----------- | ------------ | ------------- | ------------| ------- | -------- | -{{range .Methods -}} - | `{{.Name}}` | [{{.RequestLongType}}](#{{.RequestFullType}}){{if .RequestStreaming}} stream{{end}} | [{{.ResponseLongType}}](#{{.ResponseFullType}}){{if .ResponseStreaming}} stream{{end}} | {{nobr .Description}} | {{with (index .Options "google.api.http")}}{{range .Rules}}{{.Method}}|{{.Pattern}}{{end}}{{end}}| -{{end}} -{{end}} - -{{end}} - -## Scalar Value Types - -| .proto Type | Notes | C++ | Java | Python | Go | C# | PHP | Ruby | -| ----------- | ----- | --- | ---- | ------ | -- | -- | --- | ---- | -{{range .Scalars -}} - | {{.ProtoType}} | {{.Notes}} | {{.CppType}} | {{.JavaType}} | {{.PythonType}} | {{.GoType}} | {{.CSharp}} | {{.PhpType}} | {{.RubyType}} | -{{end}} diff --git a/docs/ru/intro/intro.md b/docs/ru/intro/intro.md deleted file mode 100644 index 9f08926330..0000000000 --- a/docs/ru/intro/intro.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -order: 1 ---- - -# Введение в Cosmos SDK - -## Что такое Cosmos SDK? - -[Cosmos SDK](https://github.com/cosmos/cosmos-sdk) — это фреймворк для создания публичных Proof-of-Stake (PoS) и закрытых Proof-Of-Authority (PoA) multi-asset блокчейнов. Блокчейны, разработанные с помощью Cosmos SDK, называют application-specific, то есть созданные для конкретного приложения. Исходный код Cosmos SDK находится в свободном доступе и распространяется под лицензией Apache License 2.0. - -Цель Cosmos SDK: дать разработчикам инструменты для создания с нуля собственных блокчейнов, которые смогут нативно взаимодействовать с другими блокчейнами. Мы видим SDK как напоминающий NPM фреймворк для разработки безопасных блокчейн-приложений поверх [Tendermint](https://github.com/tendermint/tendermint). Построенные с помощью SDK блокчейны состоят из совместимых друг с другом модулей, и большинство из них находятся в свободном доступе. Создать модуль для Cosmos SDK может любой разработчик, а для интеграции уже существующих модулей достаточно импортировать их в свое приложение. Cosmos SDK построен на системе «разрешений», которая позволяет разработчикам лучше контролировать взаимодействие между модулями. В общем, смарт-контракты ограничивают в отношении гибкости, суверенитета и производительности. - -## Почему блокчейн для конкретного приложения? - -Общепринятая парадигма в мире блокчейна предполагает существование виртуальной машины блокчейна, например Ethereum, и разработки децентрализованных приложений как набора смарт-контрактов поверх существующего блокчейна. Смарт-контракты могут быть удобны для создания «одноразовых» приложений, например для ICO, но плохо подходят для разработки сложных децентрализованных платформ. - -[Блокчейны для конкретных приложений](./why-app-specific.md) работают в совершенно отличной от виртуальных машин парадигме. Такие блокчейны создаются под потребности конкретного приложения и разработчики имеют полную свободу в принятии технических решений для создания блокчейна, который позволит их приложению работать оптимально. Это позволяет избежать ограничений смарт-контрактов. - -## Почему именно Cosmos SDK? - -Cosmos SDK является наиболее полным фреймворком для создания блокчейнов для приложений. Есть ряд причин, которые помогут сделать выбор в пользу Cosmos SDK: - -- В качестве движка консенсуса SDK по умолчанию использует [Tendermint Core](https://github.com/tendermint/tendermint) — проработанный BFT-движок, который пользуется широкой популярностью и фактически является «золотым стандартом» при построении Proof-of-Stake систем - -- Исходный код SDK находится в свободном доступе, а модульная система позволяет разрабатывать блокчейн в виде отдельных совместимых друг с другом модулей. По мере роста экосистемы модулей, находящихся в свободном доступе, разработка сложных децентрализованных приложений будет становится еще проще. - -- SDK построен на системе «разрешений» и большом опыте работы с вируальными машинами блокчейнов. Это делает Cosmos SDK очень безопасным фреймворком для создания блокчейнов. - -- Самое важное: Cosmos SDK уже используется для создания работающих в продакшене блокчейнов. В качестве примеров можно привести [Cosmos Hub](https://hub.cosmos.network), [IRIS Hub](https://irisnet.org), [Binance Chain](https://docs.binance.org/), [Terra](https://terra.money/), [Lino](https://lino.network/) и многие другие проекты, которые находятся в стадии разработки, используют Cosmos SDK. Примеры использования можно посмотреть на [странице экосистемы](https://cosmos.network/ecosystem). - -## Начало работы с Cosmos SDK - -- Прочитайте об [архитектуре приложения](./sdk-app-architecture.md), разрабатываемого с помощью SDK. - -- Узнайте, как с нуля создать блокчейн для вашего приложения в [пошаговом примере](https://cosmos.network/docs/tutorial). diff --git a/docs/ru/intro/sdk-app-architecture.md b/docs/ru/intro/sdk-app-architecture.md deleted file mode 100644 index b6a3b7f3a9..0000000000 --- a/docs/ru/intro/sdk-app-architecture.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -order: 3 ---- - -# Архитектура SDK-приложения - -## Конечный автомат (state machine) - -В ядре блокчейна находится [реплицированный детерминированный конечный автомат](https://en.wikipedia.org/wiki/State_machine_replication). - -В информатике конечный автомат — это математическая абстракция, имеющая один вход, один выход и в каждый момент времени находящаяся в одном из множества состояний. **Состояние** описывает текущее состояние автомата, а **транзакции** описывают изменения текущего состояния. - -Принимая в качестве входа состояние `S` и транзакцию `T`, автомат вернет новое состояние `S'`. - -``` -+--------+ +--------+ -| | | | -| S +---------------->+ S' | -| | apply(T) | | -+--------+ +--------+ -``` - -На практике транзакции сгруппированы в блоки, что позволяет сделать процесс более эффективным. Принимая в качестве входа состояние `S` и блок транзакций `B`, автомат вернет новое состояние `S'`. -``` -+--------+ +--------+ -| | | | -| S +----------------------------> | S' | -| | For each T in B: apply(T) | | -+--------+ +--------+ -``` - -В контексте блокчейна, конечный автомат является детерминированным. Детерминированность означает, что применение к одному состоянию одной и той же последовательности транзакций всегда приводит к одному и тому же конечному состоянию. - -Cosmos SDK дает максимальную гибкость в определеини состояния разрабатываемого приложения, типов транзакций и функций изменения состояния. Процесс разработки конечного автомата с помощью SDK будет описан в следующих главах. В начале рассмотрим процесс репликации с использованием **Tendermint**. - -### Tendermint - -Единственное, что нужно сделать разработчику, это описать конечный автомат с помощью Cosmos SDK. Процесс репликации через сеть берет на себя [*Tendermint*](https://tendermint.com/docs/introduction/what-is-tendermint.html). - -``` - ^ +-------------------------------+ ^ - | | | | Built with Cosmos SDK - | | Конечный автомат = приложение | | - | | | v - | +-------------------------------+ - | | | ^ - Нода блокчейна | | Консенсус | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Сеть | | - | | | | - v +-------------------------------+ v -``` - -Tendermint — это независимая от разрабатываемого приложения программа, ответственная за **сетевое взаимодействие** и **консенсус**. На практике это означает, что Tendermint отвечает за передачу и упорядочивание байтов транзакций. [Tendermint Core](https://tendermint.com/docs/introduction/what-is-tendermint.html) основан на алгоритме Byzantine-Fault-Tolerant (BFT) для достижения консенсуса о порядке транзакций. - -Алгоритм консенсуса Tendermint работает на множестве специальных нод, называемых **валидаторами**. Валидаторы отвечают за добавление блоков транзакций в блокчейн. В момент работы с каждым блоком существует множество валидаторов `V`. Из этого множества алгоритмом выбирается валидатор, который будет предлагать следующий блок. Блок считается валидным, если более чем две трети валидаторов подписали *[prevote](https://tendermint.com/docs/spec/consensus/consensus.html#prevote-step-height-h-round-r)* и *[precommit](https://tendermint.com/docs/spec/consensus/consensus.html#precommit-step-height-h-round-r)*, и все транзакции в блоке валидны. Множество валидаторов может быть изменено в правилах, по которым работает конечный автомат. Узнать подробнее о работе алгоритма можно на [следующей странице](https://tendermint.com/docs/introduction/what-is-tendermint.html#consensus-overview). - -Основной частью приложения, написанного с помощью Cosmos SDK, является фоновая программа (daemon), которая запускается на каждой ноде. Если в множестве валидаторов злоумышленниками являются менее одной трети валидаторов, то при запросе каждая нода должна получить одно и то же состояние в данный момент времени. - -## ABCI - -Tendermint передает приложению транзакции по сети через интерфейс [ABCI](https://github.com/tendermint/tendermint/tree/master/abci), который приложение должно реализовать. - -``` -+---------------------+ -| | -| Приложение | -| | -+--------+---+--------+ - ^ | - | | ABCI - | v -+--------+---+--------+ -| | -| | -| Tendermint | -| | -| | -+---------------------+ -``` - -**Tendermint работает с байтами транзакций**, но не имеет информации о том, что эти байты означают. Все, что делает Tendermint, — это детерминировано упорядочивает эти байты. Tendermint передает байты приложению через ABCI и ожидает получить код возврата, который содержит сообщение о том, успешно ли были обработаны транзакции. - -Наиболее важные типы сообщений ABCI: - -- `CheckTx`: после принятия транзации Tendermint Core, транзакция передается приложению для проверки базовых требований. `CheckTx` используется для защиты мемпула (mempool) нод от спама. Предварительный обработчик (Ante Handler) используется для выполнения последовательности валидационных шагов, таких как проверка вознаграждений (fees) и подписей валидаторов. Если транзакция валидна, она добавляется в [mempool](https://tendermint.com/docs/spec/reactors/mempool/functionality.html#mempool-functionality) и транслируется другим нодам. Следует заметить, что `CheckTx` не обрабатывает транзакции, то есть изменения состояния не происходит, потому что транзакции на этом этапе еще не были включены в блок. - -- `DeliverTx`: когда Tendermint Core принимает [валидный блок](https://tendermint.com/docs/spec/blockchain/blockchain.html#validation), каждая транзакция в данном блоке передается приложению через `DeliverTx` для обработки. Именно на этом этапе происходит изменение состояния. Обработчик (Ante Handler) выполняется повторно вместе с остальными обработчиками для каждого сообщения в транзакции. - -- `BeginBlock` / `EndBlock`: эти сообщения выполняются в начале и конце блока, вне зависимости от того, содержит блок транзакции или нет. Это удобно, если необходимо автоматически выполнить код. Следует заметить, что процессы, требующие больших вычислительных ресурсов, могут замедлить работу блокчейна или вовсе привести к остановке в случае бесконечного цикла. - -Более подробный обзор методов и типов ABCI находится на [следующей странице](https://tendermint.com/docs/spec/abci/abci.html#overview). - -Построенное на Tendermint приложение должно реализовать интерфейс ABCI для взаимодействия с локально запущенной программой Tendermint. К счастью, реализовывать интерфейс самостоятельно не нужно, потому что в составе Cosmos SDK уже есть его реализация в виде [baseapp](./sdk-design.md#baseapp). \ No newline at end of file diff --git a/docs/ru/intro/sdk-design.md b/docs/ru/intro/sdk-design.md deleted file mode 100644 index 09f04a96b8..0000000000 --- a/docs/ru/intro/sdk-design.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -order: 4 ---- - -# Обзор дизайна Cosmos SDK - -Cosmos SDK - это фреймворк, который облегчает разработку безопасных конечных автоматов поверх движка консенсуса Tendermint. По своей сути, SDK представляет собой реализацию ABCI на языке программирования Go. Он поставляется с хранилищем данных `multistore` и маршрутизатором для обработки транзакций `router`. - -Далее представлен алгоритм обработки транзакций в приложении на Cosmos SDK при передаче транзакций из Tendermint через `DeliverTx`: - -1. Декодируйте `transactions`, полученные от механизма консенсуса Tendermint (помните, что Tendermint работает только с `[]bytes`). - -2. Извлеките `messages` из `transactions` и выполните базовые проверки. - -3. Направьте каждое сообщение в соответствующий модуль для его обработки. - -4. Сохраните изменения состояния. - -Приложение также позволяет генерировать транзакции, кодировать их и передавать их базовому движку Tendermint для их трансляции. - -## `baseapp` - -`baseApp` — это базовая реализация ABCI в Cosmos SDK. Она поставляется с модулем `router` для маршрутизации транзакций в соответствующий модуль. Файл `app.go` вашего приложения будет определять ваш тип ` app`, который будет встраивать `baseapp`. Таким образом, ваш пользовательский тип `app` будет автоматически наследовать все ABCI-методы `baseapp`. Пример этого в [туториале по созданию приложения с помощью SDK] (https://github.com/cosmos/sdk-application-tutorial/blob/master/app.go#L27). - -Цель `baseapp`: обеспечить безопасный интерфейс между хранилищем и расширяемым конечным автоматом, в то же время определяя как можно меньше о конечном компьютере (соответствуя ABCI). - -УЗнать больше о `baseapp` можно [здесь](../concepts/baseapp.md). - -## `multistore` - -В составе Cosmos SDK есть хранилище для сохранения состояния. Это хранилище позволяет разработчикам создавать любое количество [`KVStores`](https://github.com/blocklayerhq/chainkit). Эти `KVStores` принимают только `[] byte` в качестве значения, и поэтому любая пользовательская структура должна быть собрана с помощью [go-amin](https://github.com/tendermint/go-amino) перед сохранением. - -Абстракция в виде этого хранилища используется для разделения состояния на отдельные части, каждый из которых управляется своим собственным модулем. Получить больше информации о `multistore` можно [здесь](../concepts/store.md). - -## Модули - -Основное преимуществе Cosmos SDK заключается в его модульности. Приложения SDK создаются путем объединения набора совместимых модулей. Каждый модуль определяет подмножество состояния и содержит свой собственный обработчик сообщений/транзакций, в то время как SDK отвечает за маршрутизацию каждого сообщения в соответствующий модуль. - -Вот упрощенное представление о том, как транзакция обрабатывается приложением каждого полной ноды, когда она получена в валидном блоке: - - -``` - + - | - | Транзакция ретранслируется из движка Tendermint - | полной ноды в приложение ноды через DeliverTx - | - | - | - +---------------------v--------------------------+ - | Приложение | - | | - | Используя методы baseapp, декодируй Tx, | - | извлеки сообщение и маршрутизируй его | - | | - +---------------------+--------------------------+ - | - | - | - +---------------------------+ - | - | - | Сообщение отправлено - | в нужный модуль - | для обработки - | - | -+----------------+ +---------------+ +----------------+ +------v----------+ -| | | | | | | | -| AUTH MODULE | | BANK MODULE | | STAKING MODULE | | GOV MODULE | -| | | | | | | | -| | | | | | | Обработай сооб.,| -| | | | | | | обнови состояние| -| | | | | | | | -+----------------+ +---------------+ +----------------+ +------+----------+ - | - | - | - | - +--------------------------+ - | - | Верни результат в Tendermint - | (0=Ok, 1=Err) - v -``` - -Каждый модуль можно рассматривать как самостоятельный конечный автомат. Разработчикам необходимо определить подмножество состояния, обрабатываемого модулем, а также настраиваемые типы сообщений, которые изменяют состояние (следует отметить, что `messages` извлекаются из `transactions` с использованием `baseapp`). В общем, каждый модуль создает свой собственный `KVStore` в `multistore`, чтобы сохранить подмножество состояния, которое он определяет. Большинству разработчиков потребуется доступ к другим сторонним модулям при создании своих собственных модулей. Учитывая, что Cosmos-SDK является открытой платформой, некоторые модули могут быть вредоносными, что означает необходимость создания правил безопасности для определения межмодульных взаимодействий. Эти правила основаны на [object-capabilities](../core/ocap.md). На практике это означает, что вместо того, чтобы каждый модуль вел список контроля доступа для других модулей, каждый модуль реализует специальные объекты, называемые хранителями, которые могут быть переданы другим модулям для предоставления предварительно определенного набора возможностей. - -Модули SDK определены в директории `x/` SDK. Основные модули в составе Cosmos SDK: - -- `x/auth`: используется для управления учетными записями и подписями. - -- `x/bank`: используется для создания и передачи токенов. - -- `x/staking` и `x/slashing`: используется для создания блокчейнов Proof-of-Stake. - -В дополнение к уже существующим модулям в `x/`, которые каждый может использовать в своем приложении, SDK позволяет [создавать собственные модули](https://cosmos.network/docs/tutorial/keeper.html). - - -### Далее, узнайте больше о модели безопасности Cosmos SDK, [ocap](./ocap.md) \ No newline at end of file diff --git a/docs/ru/intro/why-app-specific.md b/docs/ru/intro/why-app-specific.md deleted file mode 100644 index 251c2486de..0000000000 --- a/docs/ru/intro/why-app-specific.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -order: 2 ---- - -# Блокчейн для конкретного приложения - -В этом разделе описаны особенности блокчейнов для конкретных приложений и почему разработчики могут сделать выбор в пользу них, а не смарт-контрактов. - -## Почему блокчейн для конкретного приложения - -Вместо создания децентрализованного приложения поверх существующего блокчейна, такого как Ethereum, разработчики могут написать собственный блокчейн с нуля, который настроен для работы с одним конкретным приложением. Это предполагает создание полного клиента, легкого клиента, необходимых интерфейсов (CLI, REST...) для взаимодействия с нодами. - -``` - ^ +-------------------------------+ ^ - | | | | Built with Cosmos SDK - | | Конечный автомат = приложение | | - | | | v - | +-------------------------------+ - | | | ^ - Нода блокчейна | | Консенсус | | - | | | | - | +-------------------------------+ | Tendermint Core - | | | | - | | Сеть | | - | | | | - v +-------------------------------+ v -``` - -## Какие недостатки есть у смарт-контрактов? - -Блокчейны, основанные на виртуальных машинах, такие как Ethereum реализовали потребность в большей программируемости блокчейнов еще в 2014 году. В то время варианты доступные для создания децентрализованных приложений были ограничены. Большинство разработчиков строили свои приложения, используя сложный и ограниченный в возможностях скриптовый язык Биткоина, или же работая над форком исходного кода Биткоина, модифицировать который под свои потребности было сложно. - -Блокчейны, основанные на виртуальных машинах, имели новое ценностное предложение. Их конечный автомат включает в себя виртуальную машину, способную интерпретировать Тьюринг-полные программы, называемые смарт-контрактами. Эти умные контракты хорошо подходили для «одноразовых» программ, таких как ICO, однако плохо для построения сложных децентрализованных платформ: - -- Смарт-контракты обычно разрабатываются с использованием языков программирования, которые интерпретирует виртуальная машина. Эти языки часто действуют в рамках ограничений виртуальной машины. К примеру, виртуальная машина Ethereum (EVM) не позволяет разработчикам реализовать автоматическое исполнение кода. Разработчики также ограничены системой счетов EVM, и ограниченным множеством функций, необходимых для криптографии. Это примеры думонстрируют ограниченную **гибкость** смарт-контрактов. - -- Все смарт-контракты выполняются на одной и той же виртуальной машине. Это означает, что они конкурируют за ресурсы, что существенного ограничивает производительность. Даже если конечный автомат будет разделен на несколько множеств (например, с помощью шардинга), смарт-контракты все равно выполняются на виртуальной машине. Это ведет к низкой производительности в сравнении с нативным приложением, написанным на уровне самого конечного автомата. Наши тесты показывают 10-и кратное увеличение производительности в ситуациях без виртуальной машины. - -- Другая проблема связана с тем, что все смарт-контракты выполняются в одном окружении, что приводит к ограниченному **суверенитету**. Децентрализованное приложение — это экосистема, в которой участвуют несколько игроков. Если приложение построено на виртуальной машины общего блокчейна, эти игроки имеют очень ограниченный суверенитет над ним. Если в приложении есть ошибка, с этим мало что можно сделать. - -Специфичные для приложения блокчейны призваны устранить эти недостатки. - -### Преимущества специфичных блокчейнов - -### Гибкость - -Специфичные блокчейны предоставляют максимальную гибкость для разработчиков. - -- В блокчейнах, построенных на Cosmos, конечный автомат типично соединен с лежащим в основе движком консенсуса через интерфейс ABCI. Этот интерфейс можно использовать из любого языка программирования, это означает, что разработчик может использовать предпочтительный язык для создания своего приложения. - -- ABCI позволяет сменить движок консенсуса для своего блокчейна. На сегодняшний день только Tendermint готов для использования, но в будущем появятся и другие. - -- Разработчики имеют полную свободу действий при выборе количества валидаторов, желаемой производительности, безопасности, DB или IAVL-деревьев для хранения, UTXO... - -- Разработчики могут реализовать автоматическое исполнение кода. В Cosmos SDK код может автоматически запускаться в начале и конце каждого блока. У разработчика также остается выбор криптографической библиотеки, используемой в приложении. - -### Производительность - -Производительность децентрализованных приложений, построенных на основе смарт-контрактов, всегда ограничена окружением, в котором они работают. Построение приложения на своем собственном блокчейне позволяет оптимизировать производительность благодаря следующим преимуществам: - -- Разработчики могут выбрать более современный движок консенсуса, например, Tendermint BFT. В сравнении с Proof-of-Work, используемым в большинстве виртуальных машин блокчейнов, Tendermint позволяет получить высокую пропускную способность. - -- Собственный блокчейн хранит данные одного конкретного приложения, поэтому этому приложению не приходится конкурировать за ресурсы с другими. Это не так на большинстве блокчейнов, в которых смарт-контракты конкурируют за вычислительную мощность и пространство для хранения данных. - -- Даже если виртуальная машина блокчейна дает возможность шардинга и имеет эффективный алгоритм консенсуса, производительность будет ограничена самой виртуальной машиной: необходимость интерпретации транзакций виртуальной машиной существенно увеличивает требуюмую вычислительную мощность для из обработки. - -### Безопасность - -Безопасность сложно охарактеризовать количественно, и степень безопасности системы различается в зависимости от платформы. Тем не менее блокчкейн для конкретного приложения имеет ряд преимуществ: - -- Разработчики могут выбрать надежный и современный язык программирования, такой как, например, Go, для создания блокчейна, а не язык смарт-контрактов. - -- Разработчики не ограничены набором криптографических функций, доступных виртуальной машине. Они могут использовать свои функции и необходимые им библиотеки, которые прошли аудит. - -- Разработчикам не приходится переживать о безопасности самой виртуальной машины, что упрощает работу с безопаностью приложения. - -### Независимость - -Одно из основных преимуществ собственных блокчейнов заключается в их независимости. Децентрализованное приложение — это экосистема, которая включает множество акторов: пользователей, разработчиков, сторонних сервисов и прочих. Когда разработчики опираются на блокчейн виртуальной машины, где сосуществуют многие децентрализованные приложения, сообщество приложений отличается от сообщества блокчейна. Если появляется ошибка или требуется новая функция, сообщество приложения не имеет достаточных прав, чтобы внести измененения в код блокчейна. Если сообщество блокчейна отказывается самостоятельно исправлять ошибки, ничего не может произойти. - -Основная проблема здесь заключается в том, что управление приложением и управление сетью не согласованы. Эта проблема решается с помощью блокчейнов для конкретных приложений. Поскольку специфичные для приложения блокчейны специализируются на работе с одним приложением, сообщество приложения имеет полный контроль над всей системой. Это гарантирует, что действия сообщества не будут заблокированы, если будет обнаружена ошибка, и что оно имеет полную свободу выбора в траектории своего развития. - -## Начните создавать свой блокчейн для конкретного приложения уже сегодня - -Очевидно, что собственные блокчейны имеют массу преимуществ. Cosmos SDK делает их разработку проще как никогда. Создайте свой блокчейн! - -- Узнайте больше об [архитектуре](./ sdk-app-Architecture) приложения, построенного с помощью SDK. - -- Узнайте, как создать блокчейн для конкретного приложения с нуля, с помощью [SDK tutorial](https://cosmos.network/docs/tutorial) \ No newline at end of file diff --git a/docs/ru/readme.md b/docs/ru/readme.md deleted file mode 100644 index c8872c30fa..0000000000 --- a/docs/ru/readme.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -parent: - order: false ---- - -# RU diff --git a/docs/run-node/README.md b/docs/run-node/README.md deleted file mode 100644 index 0a2f24b879..0000000000 --- a/docs/run-node/README.md +++ /dev/null @@ -1,15 +0,0 @@ - - -# Running a Node, API and CLI - -This folder contains documentation on how to run a node and interact with it. - -1. [Setting up the keyring](./keyring.md) -1. [Running a Node](./run-node.md) -1. [Interacting with a Node](./interact-node.md) -1. [Generating, Signing and Broadcasting Transactions](./txs.md) -1. [Cosmos Upgrade Manager](./cosmovisor.md) diff --git a/docs/run-node/cosmovisor.md b/docs/run-node/cosmovisor.md deleted file mode 100644 index 99cb81e0cc..0000000000 --- a/docs/run-node/cosmovisor.md +++ /dev/null @@ -1,170 +0,0 @@ -# Cosmosvisor Quick Start - -`cosmovisor` is a small process manager around Cosmos SDK binaries that monitors the governance module via stdout to see if there's a chain upgrade proposal coming in. If it see a proposal that gets approved it can be run manually or automatically to download the new code, stop the node, run the migration script, replace the node binary, and start with the new genesis file. - -## Installation - -Run: - -`go get github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor` - -## Command Line Arguments And Environment Variables - -All arguments passed to the `cosmovisor` program will be passed to the current daemon binary (as a subprocess). -It will return `/dev/stdout` and `/dev/stderr` of the subprocess as its own. Because of that, it cannot accept -any command line arguments, nor print anything to output (unless it terminates unexpectedly before executing a -binary). - -`cosmovisor` reads its configuration from environment variables: - -* `DAEMON_HOME` is the location where upgrade binaries should be kept (e.g. `$HOME/.gaiad` or `$HOME/.xrnd`). -* `DAEMON_NAME` is the name of the binary itself (eg. `xrnd`, `gaiad`, `simd`, etc). -* `DAEMON_ALLOW_DOWNLOAD_BINARIES` (*optional*) if set to `true` will enable auto-downloading of new binaries -(for security reasons, this is intended for full nodes rather than validators). -* `DAEMON_RESTART_AFTER_UPGRADE` (*optional*) if set to `true` it will restart the sub-process with the same -command line arguments and flags (but new binary) after a successful upgrade. By default, `cosmovisor` dies -afterwards and allows the supervisor to restart it if needed. Note that this will not auto-restart the child -if there was an error. - -## Data Folder Layout - -`$DAEMON_HOME/cosmovisor` is expected to belong completely to `cosmovisor` and -subprocesses that are controlled by it. The folder content is organised as follows: - -``` -. -├── current -> genesis or upgrades/ -├── genesis -│   └── bin -│   └── $DAEMON_NAME -└── upgrades - └── - └── bin - └── $DAEMON_NAME -``` - -Each version of the Cosmos SDK application is stored under either `genesis` or `upgrades/`, which holds `bin/$DAEMON_NAME` -along with any other needed files such as auxiliary client programs or libraries. `current` is a symbolic link to the currently -active folder (so `current/bin/$DAEMON_NAME` is the currently active binary). - -*Note: the `name` variable in `upgrades/` holds the URI-encoded name of the upgrade as specified in the upgrade module plan.* - -Please note that `$DAEMON_HOME/cosmovisor` just stores the *binaries* and associated *program code*. -The `cosmovisor` binary can be stored in any typical location (eg `/usr/local/bin`). The actual blockchain -program will store it's data under their default data directory (e.g. `$HOME/.gaiad`) which is independent of -the `$DAEMON_HOME`. You can choose to set `$DAEMON_HOME` to the actual binary's home directory and then end up -with a configuation like the following, but this is left as a choice to the system admininstrator for best -directory layout: - -``` -.gaiad -├── config -├── data -└── cosmovisor -``` - -## Usage - -The system administrator admin is responsible for: -* installing the `cosmovisor` binary and configure the host's init system (e.g. `systemd`, `launchd`, etc) along with the environmental variables appropriately; -* installing the `genesis` folder manually; -* installing the `upgrades/` folders manually. - -`cosmovisor` will set the `current` link to point to `genesis` at first start (when no `current` link exists) and handles -binaries switch overs at the correct points in time, so that the system administrator can prepare days in advance and relax at upgrade time. - -Note that blockchain applications that wish to support upgrades may package up a genesis `cosmovisor` tarball with this information, -just as they prepare the genesis binary tarball. In fact, they may offer a tarball will all upgrades up to current point for easy download -for those who wish to sync a fullnode from start. - -The `DAEMON` specific code and operations (e.g. tendermint config, the application db, syncing blocks, etc) are performed as normal. -Application binaries' directives such as command-line flags and environment variables work normally. - -## Example: simd - -The following instructions provide a demonstration of `cosmovisor`'s integration with the `simd` application -shipped along the Cosmos SDK's source code. - -First compile `simd`: - -``` -cd cosmos-sdk/ -make build -``` - -Create a new key and setup the `simd` node: - -``` -rm -rf $HOME/.simapp -./build/simd keys --keyring-backend=test add validator -./build/simd init testing --chain-id test -./build/simd add-genesis-account --keyring-backend=test $(./build/simd keys --keyring-backend=test show validator -a) 1000000000stake,1000000000validatortoken -./build/simd gentx --keyring-backend test --chain-id test validator 100000stake -./build/simd collect-gentxs -``` - -Set the required environment variables: - -``` -export DAEMON_NAME=simd # binary name -export DAEMON_HOME=$HOME/.simapp # daemon's home directory -``` - -Create the `cosmovisor`’s genesis folders and deploy the binary: - -``` -mkdir -p $DAEMON_HOME/cosmovisor/genesis/bin -cp ./build/simd $DAEMON_HOME/cosmovisor/genesis/bin -``` - -For the sake of this demonstration, we would amend `voting_params.voting_period` in `.simapp/config/genesis.json` to a reduced time ~5 minutes (300s) and eventually launch `cosmosvisor`: - -``` -cosmovisor start -``` - -Submit a software upgrade proposal: - -``` -./build/simd tx gov submit-proposal software-upgrade test1 --title "upgrade-demo" --description "upgrade" --from validator --upgrade-height 100 --deposit 10000000stake --chain-id test --keyring-backend test -y -``` - -Query the proposal to ensure it was correctly broadcast and added to a block: - -``` -./build/simd query gov proposal 1 -``` - -Submit a `Yes` vote for the upgrade proposal: - -``` -./build/simd tx gov vote 1 yes --from validator --keyring-backend test --chain-id test -y -``` - -For the sake of this demonstration, we will hardcode a modification in `simapp` to simulate a code change. -In `simapp/app.go`, find the line containing the upgrade Keeper initialisation, it should look like -`app.UpgradeKeeper = upgradekeeper.NewKeeper(skipUpgradeHeights, keys[upgradetypes.StoreKey], appCodec, homePath)`. -After that line, add the following snippet: - - ``` - app.UpgradeKeeper.SetUpgradeHandler("test1", func(ctx sdk.Context, plan upgradetypes.Plan) { - // Add some coins to a random account - addr, err := sdk.AccAddressFromBech32("cosmos18cgkqduwuh253twzmhedesw3l7v3fm37sppt58") - if err != nil { - panic(err) - } - err = app.BankKeeper.AddCoins(ctx, addr, sdk.Coins{sdk.Coin{Denom: "stake", Amount: sdk.NewInt(345600000)}}) - if err != nil { - panic(err) - } - }) -``` - -Now recompile a new binary and place it in `$DAEMON_HOME/cosmosvisor/upgrades/test1/bin`: - -``` -make build -cp ./build/simd $DAEMON_HOME/cosmovisor/upgrades/test1/bin -``` - -The upgrade will occur automatically at height 100. diff --git a/docs/run-node/interact-node.md b/docs/run-node/interact-node.md deleted file mode 100644 index 089bc89672..0000000000 --- a/docs/run-node/interact-node.md +++ /dev/null @@ -1,242 +0,0 @@ - - -# Interacting with the Node - -There are multiple ways to interact with a node: using the CLI, using gRPC or using the REST endpoints. {synopsis} - -## Pre-requisite Readings - -- [gRPC, REST and Tendermint Endpoints](../core/grpc_rest.md) {prereq} -- [Running a Node](./run-node.md) {prereq} - -## Using the CLI - -Now that your chain is running, it is time to try sending tokens from the first account you created to a second account. In a new terminal window, start by running the following query command: - -```bash -simd query bank balances $MY_VALIDATOR_ADDRESS --chain-id my-test-chain -``` - -You should see the current balance of the account you created, equal to the original balance of `stake` you granted it minus the amount you delegated via the `gentx`. Now, create a second account: - -```bash -simd keys add recipient --keyring-backend test - -# Put the generated address in a variable for later use. -RECIPIENT=$(simd keys show recipient -a --keyring-backend test) -``` - -The command above creates a local key-pair that is not yet registered on the chain. An account is created the first time it receives tokens from another account. Now, run the following command to send tokens to the `recipient` account: - -```bash -simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000000stake --chain-id my-test-chain --keyring-backend test - -# Check that the recipient account did receive the tokens. -simd query bank balances $RECIPIENT --chain-id my-test-chain -``` - -Finally, delegate some of the stake tokens sent to the `recipient` account to the validator: - -```bash -simd tx staking delegate $(simd keys show my_validator --bech val -a --keyring-backend test) 500stake --from recipient --chain-id my-test-chain --keyring-backend test - -# Query the total delegations to `validator`. -simd query staking delegations-to $(simd keys show my_validator --bech val -a --keyring-backend test) --chain-id my-test-chain -``` - -You should see two delegations, the first one made from the `gentx`, and the second one you just performed from the `recipient` account. - -## Using gRPC - -The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow to build clients easily. Often, the client connection (i.e. the transport) can be plugged and replaced very easily. Let's explore one of the most popular transport: [gRPC](../core/grpc_rest.md). - -Since the code generation library largely depends on your own tech stack, we will only present three alternatives: - -- `grpcurl` for generic debugging and testing, -- programmatically via Go, -- CosmJS for JavaScript/TypeScript developers. - -### grpcurl - -[grpcurl])https://github.com/fullstorydev/grpcurl is like `curl` but for gRPC. It is also available as a Go library, but we will use it only as a CLI command for debugging and testing purposes. Follow the instructions in the previous link to install it. - -Assuming you have a local node running (either a localnet, or connected a live network), you should be able to run the following command to list the Protobuf services available (you can replace `localhost:9000` by the gRPC server endpoint of another node, which is configured under the `grpc.address` field inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml)): - -```bash -grpcurl -plaintext localhost:9090 list -``` - -You should see a list of gRPC services, like `cosmos.bank.v1beta1.Query`. This is called reflection, which is a Protobuf endpoint returning a description of all available endpoints. Each of these represents a different Protobuf service, and each service exposes multiple RPC methods you can query against. - -In the Cosmos SDK, we use [gogoprotobuf](https://github.com/gogo/protobuf) for code generation, and [grpc-go](https://github.com/grpc/grpc-go) for creating the gRPC server. Unfortunately, these two don't play well together, and more in-depth reflection (such as using grpcurl's `describe`) is not possible. See [this issue](https://github.com/grpc/grpc-go/issues/1873) for more info. - -Instead, we need to manually pass the reference to relevant `.proto` files. For example: - -```bash -grpcurl \ - -import-path ./proto \ # Import these proto files too - -import-path ./third_party/proto \ # Import these proto files too - -proto ./proto/cosmos/bank/v1beta1/query.proto \ # That's the proto file with the description of your service - localhost:9090 \ - describe cosmos.bank.v1beta1.Query # Service we want to inspect -``` - -Once the Protobuf definitions are given, making a gRPC query is then straightforward, by calling the correct `Query` service RPC method, and by passing the request argument as data (`-d` flag): - -```bash -grpcurl \ - -plaintext - -import-path ./proto \ - -import-path ./third_party/proto \ - -proto ./proto/cosmos/bank/v1beta1/query.proto \ - -d '{"address":"$MY_VALIDATOR"}' \ - localhost:9090 \ - cosmos.bank.v1beta1.Query/AllBalances -``` - -The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). - -#### Query for historical state using grpcurl - -You may also query for historical data by passing some [gRPC metadata](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) to the query: the `x-cosmos-block-height` metadata should contain the block to query. Using grpcurl as above, the command looks like: - -```bash -grpcurl \ - -plaintext - -import-path ./proto \ - -import-path ./third_party/proto \ - -proto ./proto/cosmos/bank/v1beta1/query.proto \ - -H "x-cosmos-block-height: 279256" \ - -d '{"address":"$MY_VALIDATOR"}' \ - localhost:9090 \ - cosmos.bank.v1beta1.Query/AllBalances -``` - -Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. - -### Programmatically via Go - -The following snippet shows how to query the state using gRPC inside a Go program. The idea is to create a gRPC connection, and use the Protobuf-generated client code to query the gRPC server. - -```go -import ( - "context" - "fmt" - - "google.golang.org/grpc" - - sdk "github.com/line/lbm-sdk/v2/types" - "github.com/line/lbm-sdk/v2/types/tx" -) - -func queryState() error { - myAddress, err := sdk.AccAddressFromBech32("cosmos1...") - if err != nil { - return err - } - - // Create a connection to the gRPC server. - grpcConn := grpc.Dial( - "127.0.0.1:9090", // Or your gRPC server address. - grpc.WithInsecure(), // The SDK doesn't support any transport security mechanism. - ) - defer grpcConn.Close() - - // This creates a gRPC client to query the x/bank service. - bankClient := banktypes.NewQueryClient(grpcConn) - bankRes, err := bankClient.Balance( - context.Background(), - &banktypes.QueryBalanceRequest{Address: myAddress, Denom: "atom"}, - ) - if err != nil { - return err - } - - fmt.Println(bankRes.GetBalance()) // Prints the account balance - - return nil -} -``` - -You can replace the query client (here we are using `x/bank`'s) with one generated from any other Protobuf service. The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). - -#### Query for historical state using Go - -Querying for historical blocks is done by adding the block height metadata in the gRPC request. - -```go -import ( - "context" - "fmt" - - "google.golang.org/grpc" - "google.golang.org/grpc/metadata" - - grpctypes "github.com/line/lbm-sdk/v2/types/grpc" - "github.com/line/lbm-sdk/v2/types/tx" -) - -func queryState() error { - // --snip-- - - var header metadata.MD - bankRes, err = bankClient.Balance( - metadata.AppendToOutgoingContext(context.Background(), grpctypes.GRPCBlockHeightHeader, "12"), // Add metadata to request - &banktypes.QueryBalanceRequest{Address: myAddress, Denom: denom}, - grpc.Header(&header), // Retrieve header from response - ) - if err != nil { - return err - } - blockHeight = header.Get(grpctypes.GRPCBlockHeightHeader) - - fmt.Println(blockHeight) // Prints the block height (12) - - return nil -} -``` - -### CosmJS - -CosmJS documentation can be found at [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs). As of January 2021, CosmJS documentation is still work in progress. - -## Using the REST Endpoints - -As described in the [gRPC guide](../core/grpc_rest.md), all gRPC services on the Cosmos SDK are made available for more convenient REST-based queries through gRPC-gateway. The format of the URL path is based on the Protobuf service method's full-qualified name, but may contain small customizations so that final URLs look more idiomatic. For example, the REST endpoint for the `cosmos.bank.v1beta1.Query/AllBalances` method is `GET /cosmos/bank/v1beta1/balances/{address}`. Request arguments are passed as query parameters. - -As a concrete example, the `curl` command to make balances request is: - -```bash -curl \ - -X GET \ - -H "Content-Type: application/json" \ - http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR -``` - -Make sure to replace `localhost:1317` with the REST endpoint of your node, configured under the `api.address` field. - -The list of all available REST endpoints is available as a Swagger specification file, it can be viewed at `localhost:1317/swagger`. Make sure that the `api.swagger` field is set to true in your [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) file. - -### Query for historical state using REST - -Querying for historical state is done using the HTTP header `x-cosmos-block-height`. For example, a curl command would look like: - -```bash -curl \ - -X GET \ - -H "Content-Type: application/json" \ - -H "x-cosmos-block-height: 279256" - http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR -``` - -Assuming the state at that block has not yet been pruned by the node, this query should return a non-empty response. - -### Cross-Origin Resource Sharing (CORS) - -[CORS policies](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) are not enabled by default to help with security. If you would like to use the rest-server in a public environment we recommend you provide a reverse proxy, this can be done with [nginx](https://www.nginx.com/). For testing and development purposes there is an `enabled-unsafe-cors` field inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). - -## Next {hide} - -Sending transactions using gRPC and REST requires some additional steps: generating the transaction, signing it, and finally broadcasting it. Read about [generating and signing transactions](./txs.md). {hide} diff --git a/docs/run-node/keyring.md b/docs/run-node/keyring.md deleted file mode 100644 index 61636f27fd..0000000000 --- a/docs/run-node/keyring.md +++ /dev/null @@ -1,127 +0,0 @@ - - -# Setting up the keyring - -This document describes how to configure and use the keyring and its various backends for an [**application**](../basics/app-anatomy.md). {synopsis} - -The keyring holds the private/public keypairs used to interact with a node. For instance, a validator key needs to be set up before running the blockchain node, so that blocks can be correctly signed. The private key can be stored in different locations, called "backends", such as a file or the operating system's own key storage. - -## Available backends for the keyring - -Starting with the v0.38.0 release, Cosmos SDK comes with a new keyring implementation -that provides a set of commands to manage cryptographic keys in a secure fashion. The -new keyring supports multiple storage backends, some of which may not be available on -all operating systems. - -### The `os` backend - -The `os` backend relies on operating system-specific defaults to handle key storage -securely. Typically, an operating system's credential sub-system handles password prompts, -private keys storage, and user sessions according to the user's password policies. Here -is a list of the most popular operating systems and their respective passwords manager: - -- macOS (since Mac OS 8.6): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac) -- Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) -- GNU/Linux: - - [libsecret](https://gitlab.gnome.org/GNOME/libsecret) - - [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) - -GNU/Linux distributions that use GNOME as default desktop environment typically come with -[Seahorse](https://wiki.gnome.org/Apps/Seahorse). Users of KDE based distributions are -commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager). -Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet` -client. - -`os` is the default option since operating system's default credentials managers are -designed to meet users' most common needs and provide them with a comfortable -experience without compromising on security. - -### The `file` backend - -The `file` backend more closely resembles the keybase implementation used prior to -v0.38.1. It stores the keyring encrypted within the app's configuration directory. This -keyring will request a password each time it is accessed, which may occur multiple -times in a single command resulting in repeated password prompts. If using bash scripts -to execute commands using the `file` option you may want to utilize the following format -for multiple prompts: - -```sh -# assuming that KEYPASSWD is set in the environment -$ gaiacli config keyring-backend file # use file backend -$ (echo $KEYPASSWD; echo $KEYPASSWD) | gaiacli keys add me # multiple prompts -$ echo $KEYPASSWD | gaiacli keys show me # single prompt -``` - -::: tip -The first time you add a key to an empty keyring, you will be prompted to type the password twice. -::: - -### The `pass` backend - -The `pass` backend uses the [pass](https://www.passwordstore.org/) utility to manage on-disk -encryption of keys' sensitive data and metadata. Keys are stored inside `gpg` encrypted files -within app-specific directories. `pass` is available for the most popular UNIX -operating systems as well as GNU/Linux distributions. Please refer to its manual page for -information on how to download and install it. - -::: tip -**pass** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` -daemon upon execution, which handles the caching of GnuPG credentials. Please refer to `gpg-agent` -man page for more information on how to configure cache parameters such as credentials TTL and -passphrase expiration. -::: - -The password store must be set up prior to first use: - -```sh -$ pass init -``` - -Replace `` with your GPG key ID. You can use your personal GPG key or an alternative -one you may want to use specifically to encrypt the password store. - -### The `test` backend - -The `test` backend is a password-less variation of the `file` backend. Keys are stored -unencrypted on disk. This backend is meant for testing purposes only and **should never be used -in production environments**. - -### The `kwallet` backend - -The `kwallet` backend uses `KDE Wallet Manager`, which comes installed by default on the -GNU/Linux distributions that ships KDE as default desktop environment. Please refer to -[KWallet Handbook](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) for more -information. - -## Adding keys to the keyring - -::: warning -Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. -::: - -Applications developed using the Cosmos SDK come with the `keys` subcommand. For the purpose of this tutorial, we're running the `simd` CLI, which is an application built using the Cosmos SDK for testing and educational purposes. For more information, see [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp). - -You can use `simd keys` for help about the keys command and `simd keys [command] --help` for more information about a particular subcommand. - -::: tip -You can also enable auto-completion with the `simd completion` command. For example, at the start of a bash session, run `. <(simd completion)`, and all `simd` subcommands will be auto-completed. -::: - -To create a new key in the keyring, run the `add` subcommand with a `` argument. For the purpose of this tutorial, we will solely use the `test` backend, and call our new key `my_validator`. This key will be used in the next section. - -```bash -$ simd keys add my_validator --keyring-backend test - -# Put the generated address in a variable for later use. -MY_VALIDATOR_ADDRESS=$(simd keys show my_validator -a --keyring-backend test) -``` - -This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe! - -By default, the keyring generates a `secp256k1` keypair. The keyring also supports `ed25519` keys, which may be created by passing the `--algo ed25519` flag. A keyring can of course hold both types of keys simultaneously, and the Cosmos SDK's `x/auth` module (in particular its [AnteHandlers](../core/baseapp.md#antehandler)) supports natively these two public key algorithms. - -## Next {hide} - -Read about [running a node](./run-node.md) {hide} diff --git a/docs/run-node/run-node.md b/docs/run-node/run-node.md deleted file mode 100644 index d7aaf8f582..0000000000 --- a/docs/run-node/run-node.md +++ /dev/null @@ -1,96 +0,0 @@ - - -# Running a Node - -Now that the application is ready and the keyring populated, it's time to see how to run the blockchain node. In this section, the application we are running is called [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp), and its corresponding CLI binary `simd`. {synopsis} - -## Pre-requisite Readings - -- [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq} -- [Setting up the keyring](./keyring.md) {prereq} - -## Initialize the Chain - -::: warning -Make sure you can build your own binary, and replace `simd` with the name of your binary in the snippets. -::: - -Before actually running the node, we need to initialize the chain, and most importantly its genesis file. This is done with the `init` subcommand: - -```bash -# The argument is the custom username of your node, it should be human-readable. -simd init --chain-id my-test-chain -``` - -The command above creates all the configuration files needed for your node to run, as well as a default genesis file, which defines the initial state of the network. All these configuration files are in `~/.simapp` by default, but you can overwrite the location of this folder by passing the `--home` flag. - -The `~/.simapp` folder has the following structure: - -```bash -. # ~/.simapp - |- data # Contains the databases used by the node. - |- config/ - |- app.toml # Application-related configuration file. - |- config.toml # Tendermint-related configuration file. - |- genesis.json # The genesis file. - |- node_key.json # Private key to use for node authentication in the p2p protocol. - |- priv_validator_key.json # Private key to use as a validator in the consensus protocol. -``` - -Before starting the chain, you need to populate the state with at least one account. To do so, first [create a new account in the keyring](./keyring.md#adding-keys-to-the-keyring) named `my_validator` under the `test` keyring backend (feel free to choose another name and another backend). - -Now that you have created a local account, go ahead and grant it some `stake` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence: - -```bash -simd add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000stake -``` - -Recall that `$MY_VALIDATOR_ADDRESS` is a variable that holds the address of the `my_validator` key in the [keyring](./keyring.md#adding-keys-to-the-keyring). Also note that the tokens in the SDK have the `{amount}{denom}` format: `amount` is is a 18-digit-precision decimal number, and `denom` is the unique token identifier with its denomination key (e.g. `atom` or `uatom`). Here, we are granting `stake` tokens, as `stake` is the token identifier used for staking in [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp). For your own chain with its own staking denom, that token identifier should be used instead. - -Now that your account has some tokens, you need to add a validator to your chain. Validators are special full-nodes that participate in the consensus process (implemented in the [underlying consensus engine](../intro/sdk-app-architecture.md#tendermint)) in order to add new blocks to the chain. Any account can declare its intention to become a validator operator, but only those with sufficient delegation get to enter the active set (for example, only the top 125 validator candidates with the most delegation get to be validators in the Cosmos Hub). For this guide, you will add your local node (created via the `init` command above) as a validator of your chain. Validators can be declared before a chain is first started via a special transaction included in the genesis file called a `gentx`: - -```bash -# Create a gentx. -simd gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backend test - -# Add the gentx to the genesis file. -simd collect-gentxs -``` - -A `gentx` does three things: - -1. Registers the `validator` account you created as a validator operator account (i.e. the account that controls the validator). -2. Self-delegates the provided `amount` of staking tokens. -3. Link the operator account with a Tendermint node pubkey that will be used for signing blocks. If no `--pubkey` flag is provided, it defaults to the local node pubkey created via the `simd init` command above. - -For more information on `gentx`, use the following command: - -```bash -simd gentx --help -``` - -## Run a Localnet - -Now that everything is set up, you can finally start your node: - -```bash -simd start -``` - -You should see blocks come in. - -The previous command allow you to run a single node. This is enough for the next section on interacting with this node, but you may wish to run multiple nodes at the same time, and see how consensus happens between them. - -The naive way would be to run the same commands again in separate terminal windows. This is possible, however in the SDK, we leverage the power of [Docker Compose](https://docs.docker.com/compose/) to run a localnet. If you need inspiration on how to set up your own localnet with Docker Compose, you can have a look at the SDK's [`docker-compose.yml`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/docker-compose.yml). - -## Configuring the Node Using `app.toml` - -The Cosmos SDK automatically generates an `app.toml` file inside `~/.simapp/config`. This file is used to configure your app, such as state pruning strategies, telemetry, gRPC and REST servers configuration, state sync... The file itself is heavily commented, please refer to it directly to tweak your node. - -Make sure to restart your node after modifying `app.toml`. - -## Next {hide} - -Read about the [Interacting with your Node](./interact-node.md) {hide} diff --git a/docs/run-node/txs.md b/docs/run-node/txs.md deleted file mode 100644 index 0018126626..0000000000 --- a/docs/run-node/txs.md +++ /dev/null @@ -1,357 +0,0 @@ - - -# Generating, Signing and Broadcasting Transactions - -This document describes how to generate an (unsigned) transaction, signing it (with one or multiple keys), and broadcasting it to the network. {synopsis} - -## Using the CLI - -The easiest way to send transactions is using the CLI, as we have seen in the previous page when [interacting with a node](./interact-node.md#using-the-cli). For example, running the following command - -```bash -simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --keyring-backend test -``` - -will run the following steps: - -- generate a transaction with one `Msg` (`x/bank`'s `MsgSend`), and print the generated transaction to the console. -- ask the user for confirmation to send the transaction from the `$MY_VALIDATOR_ADDRESS` account. -- fetch `$MY_VALIDATOR_ADDRESS` in the keyring. This is possible because we have [set up the CLI's keyring](./keyring.md) in a previous step. -- sign the generated transaction with the keyring's account. -- broadcast the signed transaction to the network. This is possible because the CLI connects to the node's Tendermint RPC endpoint. - -The CLI bundles all the necessary steps into a simple-to-use user experience. However, it's possible to run all the steps individually too. - -### Generating a Transaction - -Generating a transaction can simply be done by appending the `--generate-only` flag on any `tx` command, e.g.: - -```bash -simd tx bank send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake --chain-id my-test-chain --generate-only -``` - -This will output the unsigned transaction as JSON in the console. We can also save the unsigned transaction to a file (to be passed around between signers more easily) by appending `> unsigned_tx.json` to the above command. - -### Signing a Transaction - -Signing a transaction using the CLI requires the unsigned transaction to be saved in a file. Let's assume the unsigned transaction is in a file called `unsigned_tx.json` in the current directory (see previous paragraph on how to do that). Then, simply run the following command: - -```bash -simd tx sign unsigned_tx.json --chain-id my-test-chain --keyring-backend test --from $MY_VALIDATOR_ADDRESS -``` - -This command will decode the unsigned transaction and sign it with `SIGN_MODE_DIRECT` with `$MY_VALIDATOR_ADDRESS`'s key, which we already set up in the keyring. The signed transaction will be output as JSON to the console, and, as above, we can save it to a file by appending `> signed_tx.json`. - -Some useful flags to consider in the `tx sign` command: - -- `--sign-mode`: you may use `amino-json` to sign the transaction using `SIGN_MODE_LEGACY_AMINO_JSON`, -- `--offline`: sign in offline mode. This means that the `tx sign` command doesn't connect to the node to retrieve the signer's account number and sequence, both needed for signing. In this case, you must manually supply the `--account-number` and `--sequence` flags. This is useful for offline signing, i.e. signing in a secure environment which doesn't have access to the internet. - -#### Signing with Multiple Signers - -::: warning -Please note that signing a transaction with multiple signers or with a multisig account, where at least one signer uses `SIGN_MODE_DIRECT`, is not possible as of yet. You may follow [this Github issue](https://github.com/cosmos/cosmos-sdk/issues/8141) for more info. -::: - -Signing with multiple signers is done with the `tx multisign` command. This command assumes that all signers use `SIGN_MODE_LEGACY_AMINO_JSON`. The flow is similar to the `tx sign` command flow, but instead of signing an unsigned transaction file, each signer signs the file signed by previous signer(s). The `tx multisign` command will append signatures to the existing transactions. It is important that signers sign the transaction **in the same order** as given by the transaction, which is retrievable using the `GetSigners()` method. - -For example, starting with the `unsigned_tx.json`, and assuming the transaction has 4 signers, we would run: - -```bash -# Let signer 1 sign the unsigned tx. -simd tx multisignsign unsigned_tx.json signer_key_1 --chain-id my-test-chain --keyring-backend test > partial_tx_1.json -# Signer 2 appends their signature. -simd tx multisignsign partial_tx_1.json signer_key_2 --chain-id my-test-chain --keyring-backend test > partial_tx_2.json -# Signer 3 appends their signature. -simd tx multisignsign partial_tx_2.json signer_key_3 --chain-id my-test-chain --keyring-backend test > partial_tx_3.json -# Signer 4 appends their signature. The final output is the fully signed tx. -simd tx multisignsign partial_tx_3.json signer_key_4 --chain-id my-test-chain --keyring-backend test > signed_tx.json -``` - -### Broadcasting a Transaction - -Broadcasting a transaction is done using the following command: - -```bash -simd tx broadcast tx_signed.json -``` - -You may optionally pass the `--broadcast-mode` flag to specify which response to receive from the node: - -- `block`: the CLI waits for the tx to be committed in a block. -- `sync`: the CLI waits for a CheckTx execution response only. -- `async`: the CLI returns immediately (transaction might fail). - -## Programmatically with Go - -It is possible to manipulate transactions programmatically via Go using the Cosmos SDK's `TxBuilder` interface. - -### Generating a Transaction - -Before generating a transaction, a new instance of a `TxBuilder` needs to be created. Since the SDK supports both Amino and Protobuf transactions, the first step would be to decide which encoding scheme to use. All the subsequent steps remain unchanged, whether you're using Amino or Protobuf, as `TxBuilder` abstracts the encoding mechanisms. In the following snippet, we will use Protobuf. - -```go -import ( - "github.com/line/lbm-sdk/v2/simapp" -) - -func sendTx() error { - // Choose your codec: Amino or Protobuf. Here, we use Protobuf, given by the - // following function. - encCfg := simapp.MakeTestEncodingConfig() - - // Create a new TxBuilder. - txBuilder := encCfg.TxConfig.NewTxBuilder() - - // --snip-- -} -``` - -We can also set up some keys and addresses that will send and receive the transactions. Here, for the purpose of the tutorial, we will be using some dummy data to create keys. - -```go -import ( - "github.com/line/lbm-sdk/v2/testutil/testdata" -) - -priv1, _, addr1 := testdata.KeyTestPubAddr() -priv2, _, addr2 := testdata.KeyTestPubAddr() -priv3, _, addr3 := testdata.KeyTestPubAddr() -``` - -Populating the `TxBuilder` can be done via its [methods](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/client/tx_config.go#L32-L45): - -```go -import ( - banktypes "github.com/line/lbm-sdk/v2/x/bank/types" -) - -func sendTx() error { - // --snip-- - - // Define two x/bank MsgSend messages: - // - from addr1 to addr3, - // - from addr2 to addr3. - // This means that the transactions needs two signers: addr1 and addr2. - msg1 := banktypes.NewMsgSend(addr1, addr3, types.NewCoins(types.NewInt64Coin("atom", 12))) - msg2 := banktypes.NewMsgSend(addr2, addr3, types.NewCoins(types.NewInt64Coin("atom", 34))) - - err := txBuilder.SetMsgs(msg1, msg2) - if err != nil { - return err - } - - txBuilder.SetGasLimit(...) - txBuilder.SetFeeAmount(...) - txBuilder.SetMemo(...) - txBuilder.SetTimeoutHeight(...) -} -``` - -At this point, `TxBuilder`'s underlying transaction is ready to be signed. - -### Signing a Transaction - -We chose our encoding config to use Protobuf, which will use `SIGN_MODE_DIRECT` by default. As per [ADR-020](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/docs/architecture/adr-020-protobuf-transaction-encoding.md), each signer needs to sign the `SignerInfo`s of all other signers. This means that we need to perform two steps sequentially: - -- for each signer, populate the signer's `SignerInfo` inside `TxBuilder`, -- once all `SignerInfo`s are populated, for each signer, sign the `SignDoc` (the payload to be signed). - -In the current `TxBuilder`'s API, both steps are done using the same method: `SetSignatures()`. The current API requires us to first perform a round of `SetSignatures()` _with empty signatures_, only to populate `SignerInfo`s, and a second round of `SetSignatures()` to actually sign the correct payload. - -```go -import ( - cryptotypes "github.com/line/lbm-sdk/v2/crypto/types" - "github.com/line/lbm-sdk/v2/types/tx/signing" - xauthsigning "github.com/line/lbm-sdk/v2/x/auth/signing" -) - -func sendTx() error { - // --snip-- - - privs := []cryptotypes.PrivKey{priv1, priv2} - accNums:= []uint64{..., ...} // The accounts' account numbers - accSeqs:= []uint64{..., ...} // The accounts' sequence numbers - - // First round: we gather all the signer infos. We use the "set empty - // signature" hack to do that. - var sigsV2 []signing.SignatureV2 - for i, priv := range privs { - sigV2 := signing.SignatureV2{ - PubKey: priv.PubKey(), - Data: &signing.SingleSignatureData{ - SignMode: encCfg.TxConfig.SignModeHandler().DefaultMode(), - Signature: nil, - }, - Sequence: accSeqs[i], - } - - sigsV2 = append(sigsV2, sigV2) - } - err := txBuilder.SetSignatures(sigsV2...) - if err != nil { - return err - } - - // Second round: all signer infos are set, so each signer can sign. - sigsV2 = []signing.SignatureV2{} - for i, priv := range privs { - signerData := xauthsigning.SignerData{ - ChainID: chainID, - AccountNumber: accNums[i], - Sequence: accSeqs[i], - } - sigV2, err := tx.SignWithPrivKey( - encCfg.TxConfig.SignModeHandler().DefaultMode(), signerData, - txBuilder, priv, encCfg.TxConfig, accSeqs[i]) - if err != nil { - return nil, err - } - - sigsV2 = append(sigsV2, sigV2) - } - err = txBuilder.SetSignatures(sigsV2...) - if err != nil { - return err - } -} -``` - -The `TxBuilder` is now correctly populated. To print it, you can use the `TxConfig` interface from the initial encoding config `encCfg`: - -```go -func sendTx() error { - // --snip-- - - // Generated Protobuf-encoded bytes. - txBytes, err := encCfg.TxConfig.TxEncoder()(txBuilder.GetTx()) - if err != nil { - return err - } - - // Generate a JSON string. - txJSONBytes, err := encCfg.TxConfig.TxJSONEncoder()(txBuilder.GetTx()) - if err != nil { - return err - } - txJSON := string(txJSONBytes) -} -``` - -### Broadcasting a Transaction - -The preferred way to broadcast a transaction is to use gRPC, though using REST (via `gRPC-gateway`) or the Tendermint RPC is also posible. An overview of the differences between these methods is exposed [here](../core/grpc_rest.md). For this tutorial, we will only describe the gRPC method. - -```go -import ( - "context" - "fmt" - - "google.golang.org/grpc" - - "github.com/line/lbm-sdk/v2/types/tx" -) - -func sendTx() error { - // --snip-- - - // Create a connection to the gRPC server. - grpcConn := grpc.Dial( - "127.0.0.1:9090", // Or your gRPC server address. - grpc.WithInsecure(), // The SDK doesn't support any transport security mechanism. - ) - defer grpcConn.Close() - - // Broadcast the tx via gRPC. We create a new client for the Protobuf Tx - // service. - txClient := tx.NewServiceClient(grpcConn) - // We then call the BroadcastTx method on this client. - grpcRes, err := txClient.BroadcastTx( - context.Background(), - &tx.BroadcastTxRequest{ - Mode: tx.BroadcastMode_BROADCAST_MODE_SYNC, - TxBytes: txBytes, // Proto-binary of the signed transaction, see previous step. - }, - ) - if err != nil { - return err - } - - fmt.Println(grpcRes.TxResponse.Code) // Should be `0` if the tx is successful - - return nil -} -``` - -#### Simulating a Transaction - -Before broadcasting a transaction, we sometimes may want to dry-run the transaction, to estimate some information about the transaction without actually committing it. This is called simulating a transaction, and can be done as follows: - -```go -import ( - "context" - "fmt" - "testing" - - "github.com/line/lbm-sdk/v2/client" - "github.com/line/lbm-sdk/v2/types/tx" - authtx "github.com/line/lbm-sdk/v2/x/auth/tx" -) - -func simulateTx() error { - // --snip-- - - // Simulate the tx via gRPC. We create a new client for the Protobuf Tx - // service. - txClient := tx.NewServiceClient(grpcConn) - // We then call the BroadcastTx method on this client. - protoTx := txBuilderToProtoTx(txBuilder) - if err != nil { - return err - } - grpcRes, err := txClient.Simulate( - context.Background(), - &tx.SimulateRequest{ - Tx: protoTx, - }, - ) - if err != nil { - return err - } - - fmt.Println(grpcRes.GasInfo) // Prints estimated gas used. - - return nil -} - -// txBuilderToProtoTx converts a txBuilder into a proto tx.Tx. -func txBuilderToProtoTx(txBuilder client.TxBuilder) (*tx.Tx, error) { // nolint - protoProvider, ok := txBuilder.(authtx.ProtoTxProvider) - if !ok { - return nil, fmt.Errorf("expected proto tx builder, got %T", txBuilder) - } - - return protoProvider.GetProtoTx(), nil -} -``` - -## Using REST - -It is not possible to generate or sign a transaction using REST, only to broadcast one. - -### Broadcasting a Transaction - -Broadcasting a transaction using the REST endpoint (served by `gRPC-gateway`) can be done by sending a POST request as follows, where the `txBytes` are the protobuf-encoded bytes of a signed transaction: - -```bash -curl -X POST \ - -H "Content-Type: application/json" - -d'{"tx_bytes":"{{txBytes}}","mode":"BROADCAST_MODE_SYNC"}' - localhost:1317/lbm/tx/v1beta1/txs -``` - -## Using CosmJS (JavaScript & TypeScript) - -CosmJS aims to build client libraries in JavaScript that can be embedded in web applications. Please see [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs) for more information. As of January 2021, CosmJS documentation is still work in progress. diff --git a/docs/spec/README.md b/docs/spec/README.md deleted file mode 100644 index b66a024ab1..0000000000 --- a/docs/spec/README.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -parent: - order: false ---- - -# Specifications - -This directory contains specifications for the modules of the Cosmos SDK as well as Interchain Standards (ICS) and other specifications. - -SDK applications hold this state in a Merkle store. Updates to -the store may be made during transactions and at the beginning and end of every -block. - -## SDK specifications - -- [Store](./store) - The core Merkle store that holds the state. -- [Bech32](./addresses/bech32.md) - Address format for Cosmos SDK applications. - -## Modules specifications - -Go the [module directory](../../x/README.md) - -## Tendermint - -For details on the underlying blockchain and p2p protocols, see -the [Tendermint specification](https://github.com/tendermint/spec/tree/master/spec). diff --git a/docs/spec/SPEC-SPEC.md b/docs/spec/SPEC-SPEC.md deleted file mode 100644 index fb95c3ab96..0000000000 --- a/docs/spec/SPEC-SPEC.md +++ /dev/null @@ -1,61 +0,0 @@ -# Specification of Specifications - -This file intends to outline the common structure for specifications within -this directory. - -## Tense - -For consistency, specs should be written in passive present tense. - -## Pseudo-Code - -Generally, pseudo-code should be minimized throughout the spec. Often, simple -bulleted-lists which describe a function's operations are sufficient and should -be considered preferable. In certain instances, due to the complex nature of -the functionality being described pseudo-code may the most suitable form of -specification. In these cases use of pseudo-code is permissible, but should be -presented in a concise manner, ideally restricted to only the complex -element as a part of a larger description. - -## Common Layout - -The following generalized file structure should be used to breakdown -specifications for modules. With the exception of README.md, `XX` at the -beginning of the file name should be replaced with a number to indicate -document flow (ex. read `01_state.md` before `02_state_transitions.md`). The -following list is nonbinding and all files are optional. - -- `README.md` - overview of the module -- `XX_concepts.md` - describe specialized concepts and definitions used throughout the spec -- `XX_state.md` - specify and describe structures expected to marshalled into the store, and their keys -- `XX_state_transitions.md` - standard state transition operations triggered by hooks, messages, etc. -- `XX_messages.md` - specify message structure(s) and expected state machine behaviour(s) -- `XX_begin_block.md` - specify any begin-block operations -- `XX_end_block.md` - specify any end-block operations -- `XX_hooks.md` - describe available hooks to be called by/from this module -- `XX_events.md` - list and describe event tags used -- `XX_params.md` - list all module parameters, their types (in JSON) and examples -- `XX_future_improvements.md` - describe future improvements of this module -- `XX_appendix.md` - supplementary details referenced elsewhere within the spec - -### Notation for key-value mapping - -Within `state.md` the following notation `->` should be used to describe key to -value mapping: - -``` -key -> value -``` - -to represent byte concatenation the `|` may be used. In addition, encoding -type may be specified, for example: - -``` -0x00 | addressBytes | address2Bytes -> amino(value_object) -``` - -Additionally, index mappings may be specified by mapping to the `nil` value, for example: - -``` -0x01 | address2Bytes | addressBytes -> nil -``` diff --git a/docs/spec/_ics/README.md b/docs/spec/_ics/README.md deleted file mode 100644 index 00e496000f..0000000000 --- a/docs/spec/_ics/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# Cosmos ICS - -- [ICS030 - Signed Messages](./ics-030-signed-messages.md) \ No newline at end of file diff --git a/docs/spec/_ics/ics-030-signed-messages.md b/docs/spec/_ics/ics-030-signed-messages.md deleted file mode 100644 index fee459a793..0000000000 --- a/docs/spec/_ics/ics-030-signed-messages.md +++ /dev/null @@ -1,193 +0,0 @@ -# ICS 030: Cosmos Signed Messages - ->TODO: Replace with valid ICS number and possibly move to new location. - -* [Changelog](#changelog) -* [Abstract](#abstract) -* [Preliminary](#preliminary) -* [Specification](#specification) -* [Future Adaptations](#future-adaptations) -* [API](#api) -* [References](#references) - -## Status - -Proposed. - -## Changelog - -## Abstract - -Having the ability to sign messages off-chain has proven to be a fundamental aspect -of nearly any blockchain. The notion of signing messages off-chain has many -added benefits such as saving on computational costs and reducing transaction -throughput and overhead. Within the context of the Cosmos, some of the major -applications of signing such data includes, but is not limited to, providing a -cryptographic secure and verifiable means of proving validator identity and -possibly associating it with some other framework or organization. In addition, -having the ability to sign Cosmos messages with a Ledger or similar HSM device. - -A standardized protocol for hashing, signing, and verifying messages that can be -implemented by the Cosmos SDK and other third-party organizations is needed. Such a -standardized protocol subscribes to the following: - -* Contains a specification of human-readable and machine-verifiable typed structured data -* Contains a framework for deterministic and injective encoding of structured data -* Utilizes cryptographic secure hashing and signing algorithms -* A framework for supporting extensions and domain separation -* Is invulnerable to chosen ciphertext attacks -* Has protection against potentially signing transactions a user did not intend to - -This specification is only concerned with the rationale and the standardized -implementation of Cosmos signed messages. It does **not** concern itself with the -concept of replay attacks as that will be left up to the higher-level application -implementation. If you view signed messages in the means of authorizing some -action or data, then such an application would have to either treat this as -idempotent or have mechanisms in place to reject known signed messages. - -## Preliminary - -The Cosmos message signing protocol will be parameterized with a cryptographic -secure hashing algorithm `SHA-256` and a signing algorithm `S` that contains -the operations `sign` and `verify` which provide a digital signature over a set -of bytes and verification of a signature respectively. - -Note, our goal here is not to provide context and reasoning about why necessarily -these algorithms were chosen apart from the fact they are the defacto algorithms -used in Tendermint and the Cosmos SDK and that they satisfy our needs for such -cryptographic algorithms such as having resistance to collision and second -pre-image attacks, as well as being [deterministic](https://en.wikipedia.org/wiki/Hash_function#Determinism) and [uniform](https://en.wikipedia.org/wiki/Hash_function#Uniformity). - -## Specification - -Tendermint has a well established protocol for signing messages using a canonical -JSON representation as defined [here](https://github.com/tendermint/tendermint/blob/master/types/canonical.go). - -An example of such a canonical JSON structure is Tendermint's vote structure: - -```go -type CanonicalJSONVote struct { - ChainID string `json:"@chain_id"` - Type string `json:"@type"` - BlockID CanonicalJSONBlockID `json:"block_id"` - Height int64 `json:"height"` - Round int `json:"round"` - Timestamp string `json:"timestamp"` - VoteType byte `json:"type"` -} -``` - -With such canonical JSON structures, the specification requires that they include -meta fields: `@chain_id` and `@type`. These meta fields are reserved and must be -included. They are both of type `string`. In addition, fields must be ordered -in lexicographically ascending order. - -For the purposes of signing Cosmos messages, the `@chain_id` field must correspond -to the Cosmos chain identifier. The user-agent should **refuse** signing if the -`@chain_id` field does not match the currently active chain! The `@type` field -must equal the constant `"message"`. The `@type` field corresponds to the type of -structure the user will be signing in an application. For now, a user is only -allowed to sign bytes of valid ASCII text ([see here](https://github.com/tendermint/tendermint/blob/master/libs/common/string.go#L61-L74)). -However, this will change and evolve to support additional application-specific -structures that are human-readable and machine-verifiable ([see Future Adaptations](#futureadaptations)). - -Thus, we can have a canonical JSON structure for signing Cosmos messages using -the [JSON schema](http://json-schema.org/) specification as such: - -```json -{ - "$schema": "http://json-schema.org/draft-04/schema#", - "$id": "cosmos/signing/typeData/schema", - "title": "The Cosmos signed message typed data schema.", - "type": "object", - "properties": { - "@chain_id": { - "type": "string", - "description": "The corresponding Cosmos chain identifier.", - "minLength": 1 - }, - "@type": { - "type": "string", - "description": "The message type. It must be 'message'.", - "enum": [ - "message" - ] - }, - "text": { - "type": "string", - "description": "The valid ASCII text to sign.", - "pattern": "^[\\x20-\\x7E]+$", - "minLength": 1 - } - }, - "required": [ - "@chain_id", - "@type", - "text" - ] -} -``` - -e.g. - -```json -{ - "@chain_id": "1", - "@type": "message", - "text": "Hello, you can identify me as XYZ on keybase." -} -``` - -## Future Adaptations - -As applications can vary greatly in domain, it will be vital to support both -domain separation and human-readable and machine-verifiable structures. - -Domain separation will allow for application developers to prevent collisions of -otherwise identical structures. It should be designed to be unique per application -use and should directly be used in the signature encoding itself. - -Human-readable and machine-verifiable structures will allow end users to sign -more complex structures, apart from just string messages, and still be able to -know exactly what they are signing (opposed to signing a bunch of arbitrary bytes). - -Thus, in the future, the Cosmos signing message specification will be expected -to expand upon it's canonical JSON structure to include such functionality. - - -## API - -Application developers and designers should formalize a standard set of APIs that -adhere to the following specification: - ------ - -### **cosmosSignBytes** - -Params: - -* `data`: the Cosmos signed message canonical JSON structure -* `address`: the Bech32 Cosmos account address to sign data with - -Returns: - -* `signature`: the Cosmos signature derived using signing algorithm `S` - ------ - -### Examples - -Using the `secp256k1` as the DSA, `S`: - -```javascript -data = { - "@chain_id": "1", - "@type": "message", - "text": "I hereby claim I am ABC on Keybase!" -} - -cosmosSignBytes(data, "cosmos1pvsch6cddahhrn5e8ekw0us50dpnugwnlfngt3") -> "0x7fc4a495473045022100dec81a9820df0102381cdbf7e8b0f1e2cb64c58e0ecda1324543742e0388e41a02200df37905a6505c1b56a404e23b7473d2c0bc5bcda96771d2dda59df6ed2b98f8" -``` - -## References diff --git a/docs/spec/_proposals/README.md b/docs/spec/_proposals/README.md deleted file mode 100644 index 213d6288cb..0000000000 --- a/docs/spec/_proposals/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# Spec Proposals - -- [F1 Fee Distribution](./f1-fee-distribution/f1_fee_distr.pdf) \ No newline at end of file diff --git a/docs/spec/_proposals/f1-fee-distribution/f1_fee_distr.pdf b/docs/spec/_proposals/f1-fee-distribution/f1_fee_distr.pdf deleted file mode 100644 index b999538695..0000000000 Binary files a/docs/spec/_proposals/f1-fee-distribution/f1_fee_distr.pdf and /dev/null differ diff --git a/docs/spec/_proposals/f1-fee-distribution/f1_fee_distr.tex b/docs/spec/_proposals/f1-fee-distribution/f1_fee_distr.tex deleted file mode 100644 index b6bb6b3265..0000000000 --- a/docs/spec/_proposals/f1-fee-distribution/f1_fee_distr.tex +++ /dev/null @@ -1,245 +0,0 @@ -\documentclass[]{article} -\usepackage{hyperref} - -%opening -\title{F1 Fee Distribution Draft-02} -\author{Dev Ojha} - -\begin{document} - -\maketitle - -\begin{abstract} - In a proof of stake blockchain, validators need to split the rewards gained from transaction fees each block. Furthermore, these fees must be fairly distributed to each of a validator's constituent delegators. They accrue this reward throughout the entire time they are delegated, and they have a special operation to withdraw accrued rewards. - - The F1 fee distribution scheme works for any algorithm to split funds between validators each block, with minimal iteration, and the only approximations being due to finite decimal precision. Per block there is a single iteration over the validator set, to enable reward algorithms that differ by validator. No iteration is required to delegate, or withdraw. The state usage is one state update per validator per block, and one state entry per active delegation. It can optionally handle arbitrary inflation schemes, and auto-bonding of rewards. -\end{abstract} - -\section{F1 Fee Distribution} - -\subsection{Context} -In a proof of stake blockchain, each validator has an associated stake. -Transaction fees get rewarded to validators based on the incentive scheme of the underlying proof of stake model. -The fee distribution problem occurs in proof of stake blockchains supporting delegation, as there is a need to distribute a validator's fee rewards to its delegators. -The trivial solution of just giving the rewards to each delegator every block is too expensive to perform on-chain. -So instead fee distribution algorithms have delegators perform a withdraw action, which when performed yields the same total amount of fees as if they had received them at every block. - -This details F1, an approximation-free, slash-tolerant fee distribution algorithm which allows validator commission-rates, inflation rates, and fee proportions, which can all efficiently change per validator, every block. -The algorithm requires iterating over the bonded validators every block, and withdraws require no iteration. -This is cheap, due to staking logic already requiring iteration over all validators, which causes the expensive state-reads to be cached. - -The key point of how F1 works is that it tracks how much rewards a delegator with 1 stake for a given validator would be entitled to if it had bonded at block 0 until the latest block. -When a delegator bonds at block $b$, the amount of rewards a delegator with 1 stake would have if bonded at block 0 until block $b$ is also persisted to state. -When the delegator withdraws, they receive the difference of these two values. -Since rewards are distributed according to stake-weighting, this amount of rewards can be scaled by the amount of stake a delegator had. -Section 1.2 describes this in more detail, with an argument for it being approximation free. -Section 2 details how to adapt this algorithm to handle commission rates, slashing, and inflation. - -\subsection{Base algorithm} -In this section, we show that the F1 base algorithm gives each delegator rewards identical to that which they'd receive in the naive and correct fee distribution algorithm that iterated over all delegators every block. - -Even distribution of a validators rewards amongst its validators weighted by stake means the following: -Suppose a delegator delegates $x$ stake to a validator $v$ at block $h$. -Let the amount of stake the validator has at block $i$ be $s_i$ and the amount of fees they receive at this height be $f_i$. -Then if a delegator contributing $x$ stake decides to withdraw at block $n$, the rewards they receive are -$$\sum_{i = h}^{n} \frac{x}{s_i}f_i = x \sum_{i = h}^{n} \frac{f_i}{s_i}$$ - -Note that $s_i$ does not change every block, -it only changes if the validator gets slashed, -or if any delegator alters the amount they have delegated. -We'll relegate handling of slashes to \autoref{ssec:slashing}, -and only consider the case with no slashing here. -We can change the iteration from being over every block, to instead being over the set of blocks between two changes in validator $v$'s total stake. -Let each of these set of blocks be called a period. -A new period begins every time that validator's total stake changes. -Let the total amount of stake for the validator in period $p$ be $n_p$. -Let $T_p$ be the total fees that validator $v$ accrued in period $p$. -Let $h$ be the start of period $p_{init}$, and height $n$ be the end of $p_{final}$. -It follows that -$$x \sum_{i = h}^{n} \frac{f_i}{s_i} = x \sum_{p = p_{init}}^{p_{final}} \frac{T_p}{n_p}$$ - -Let $p_0$ represent the period which begins when the validator first bonds. -The central idea to the F1 model is that at the end of the $k$th period, -the following is stored at a state location indexable by $k$: $\sum_{i=0}^{k}\frac{T_i}{n_i}$. -Let the index of the current period be $f$. -When a delegator wants to delegate or withdraw their reward, they first create a new entry in state to end the current period. -Then this entry is created using the previous entry as follows: -$$Entry_f = \sum_{i=0}^{f}\frac{T_i}{n_i} = \sum_{i=0}^{f-1}\frac{T_i}{n_i} + \frac{T_f}{n_f} = Entry_{f-1} + \frac{T_f}{n_f}$$ -Where $T_f$ is the fees the validator has accrued in period $f$, and $n_f$ is the validators total amount of stake in period $f$. - -The withdrawer's delegation object has the index $k$ for the period which they ended by bonding. (They start receiving rewards for period $k + 1$) -The reward they should receive when withdrawing is: - -$$x \sum_{i = k + 1}^{f} \frac{T_i}{n_i} = x\left(\left(\sum_{i=0}^{f}\frac{T_i}{n_i}\right) - \left(\sum_{i=0}^{k}\frac{T_i}{n_i}\right)\right) = x\left(Entry_f - Entry_k\right)$$ - -It is clear from the equations that this payout mechanism maintains correctness, and requires no iterations. It just needed the two state reads for these entries. - -$T_f$ is a separate variable in state for the amount of fees this validator has accrued since the last update to its power. -This variable is incremented at every block by however much fees this validator received that block. -On the update to the validators power, this variable is used to create the entry in state at $f$, and is then reset to 0. - -This fee distribution proposal is agnostic to how all of the blocks fees are divied up between validators. -This creates many nice properties, for example it is possible to only rewarding validators who signed that block. - -\section{Additional add-ons} -\subsection{Commission Rates} -Commission rates are the idea that a validator can take a fixed $x\%$ cut of all of their received fees, before redistributing evenly to the constituent delegators. -This can easily be done as follows: - -In block $h$ a validator receives $f_h$ fees. -Instead of incrementing that validators ``total accrued fees this period variable" by $f_h$, it is instead incremented by $(1 - commission\_rate) * f_p$. -Then $commission\_rate * f_p$ is deposited directly to the validator's account. -This allows for efficient updates to a validator's commission rate every block if desired. -More generally, each validator could have a function which takes their fees as input, and outputs a set of outputs to pay these fees too. (i.e. x\% going to themselves, y\% to delegators, z\% burnt) - -\subsection{Slashing} -\label{ssec:slashing} -Slashing is distinct from withdrawals, since it lowers the stake of all of the delegator's by a fixed percentage. -Since no one is charged gas for slashes, a slash cannot iterate over all delegators. -Thus we can no longer just multiply by $x$ over the difference in stake. -This section describes a simple solution that should suffice for most chains needs. An asymptotically optimal solution is provided in section 2.4. -TODO: Consider removing this section in favor of just using the current section 2.4? - -The solution here is to instead store each period created by a slash in the validators state. -Then when withdrawing, you must iterate over all slashes between when you started and ended. -Suppose you delegated at period $0$, a y\% slash occured at period $2$, and your withdrawal creates period $4$. -Then you receive funds from periods $0$ to $2$ as normal. -The equations for funds you receive for periods $2$ to $4$ now uses $(1 - y)x$ for your stake instead of just $x$ stake. -When there are multiple slashes, you just account for the accumulated slash factor. - -In practice this will not really be an efficiency hit, as the number of slashes is expected to be 0 or 1 for most validators. -Validators that get slashed more will naturally lose their delegators. -A malicious validator that gets itself slashed many times would increase the gas to withdraw linearly, but the economic loss of funds due to the slashes is expected to far out-weigh the extra overhead the honest withdrawer must pay for due to the gas. -(TODO: frame that above sentence in terms of griefing factors, as thats more correct) - -\subsection{Inflation} -Inflation is the idea that we want every staked coin to create more staking tokens as time progresses. -The purpose being to drive down the relative worth of unstaked tokens. -Each block, every staked token should produce $x$ staking tokens as inflation, where $x$ is calculated from a function $inflation$ which takes state and the block information as input. -Let $x_i$ represent the evaluation of $inflation$ in the $i$th block. -The goal of this section is to auto-bond inflation in the fee distribution model without iteration. -This is done by preserving the invariant that every state entry contains the rewards one would have if they had bonded one stake at genesis until that corresponding block. - -In state a variable should be kept for the number of tokens one would have now due to inflation, -given that they bonded one token at genesis. -This is $\prod_{0}^{now} (1 + x_i)$. -Each period now stores this total inflation product along with what it already stores per-period. - -Let $R_i$ be the fee rewards in block $i$, and $n_i$ be the total amount bonded to that validator in that block. -The correct amount of rewards which 1 token at genesis should have now is: -$$Reward(now) = \sum_{i = 0}^{now}\left(\prod_{j = 0}^{i} 1 + x_j \right) * \frac{R_i}{n_i}$$ -The term in the sum is the amount of stake one stake becomes due to inflation, multiplied by the amount of fees per stake. - -Now we cast this into the period frame of view. -Recall that we build the rewards by creating a state entry for the rewards of the previous period, and keeping track of the rewards within this period. -Thus we first define the correct amount of rewards for each successive period, proving correctness of this via induction. -We then show that the state entry that gets efficiently built up block by block is equal to this value for the latest period. - -Let $start, end$ denote the start/end of a period. - -Suppose that $\forall f > 0$, $Reward(end(f))$ is correctly constructed as -$$Reward(end(f)) = Reward(end(f-1)) + \sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ -and that for $f = 0$, $Reward(end(0)) = 0$. -(With period 1 being defined as the period that has the first bond into it) -It must be shown that assuming the supposition $\forall f \leq f_0$, $$Reward(end(f_0 + 1)) = Reward(end(f_0)) + \sum_{i = start(f_0 + 1)}^{end(f_0 + 1)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ -Using the definition of $Reward$, it follows that: -$$\sum_{i = 0}^{end(f_0 + 1)}\left(\prod_{j = 0}^{i} 1 + x_j \right) * \frac{R_i}{n_i} = \sum_{i = 0}^{end(f_0)}\left(\prod_{j = 0}^{i} 1 + x_j \right) * \frac{R_i}{n_i} + \sum_{i = start(f_0 + 1)}^{end(f_0 + 1)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ - -Since the first summation on the right hand side is $Reward(end(f_0))$, the supposition is proven true. -Consequently, the reward for just period $f$ adjusted for the amount of inflation 1 token at genesis would produce, is: -$$\sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ - -TODO: make this proof + pre-amble less verbose, and just wrap up into a lemma. -Maybe just leave this proof or the last part to the reader, since it easily follows from summation bounds. - -Now note that -$$\sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i} = \left(\prod_{j = 0}^{end(f - 1)} 1 + x_j \right)\sum_{i = start(f)}^{end(f)}\left(\prod_{j = start(f)}^{i} 1 + x_j \right) \frac{R_i}{n_i}$$ -By definition of period, and inflation being applied every block, \\ -$n_i = n_{start(f)}\left(\prod_{j = start(f)}^{i} 1 + x_j \right)$. This cancels out the product in the summation, therefore -$$\sum_{i = start(f)}^{end(f)}\left(\prod_{j = 0}^{i} 1 + x_j \right) \frac{R_i}{n_i} = \left(\prod_{j = 0}^{end(f - 1)} 1 + x_j \right)\frac{\sum_{i = start(f)}^{end(f)}R_i}{n_{start(f)}}$$ - -Thus every block, each validator just has to add the total amount of fees (The $R_i$ term) that goes to delegates to some per-period term. -When creating a new period, $n_{start(f)}$ can be cached in state, and the product is already stored in the previous periods state entry. -You then get the next period's $n_{start(f)}$ from the consensus' power entry for this validator. -This is thus extremely efficient per block. - -When withdrawing, you take the difference as before, -which yields the amount of rewards you would have obtained with $(\prod_0^{begin\ bonding\ period}1 + x)$ stake from the block you began bonding at until now. -$(\prod_0^{begin\ bonding\ period}1 + x)$ is known, since its included in the state entry for when you bonded. -You then divide the entitled fees by $(\prod_0^{begin\ bonding\ period}1 + x)$ to normalize it to being the amount of rewards you're entitled to from 1 stake at that block to now. -Then as before, you multiply by the amount of stake you had initially bonded. -\\TODO: (Does the difference equating to that make sense, or should it be shown explicitly) -\\TODO: Does this need to explain how the originally bonded tokens are refunded, or is that clear? - -The inflation function could vary per block, -and per validator if ever a need rose. -If the inflation rate is the same for everyone then there can be a single global store for the entries corresponding to the product of inflations. -Inflation creation can trivially be epoched as long as inflation isn't required within the epoch, through changes to the $inflation$ function. - -\subsection{Withdrawing with no iteration over slashes} -Notice that a slash is the same as a negative inflation rate for a validator in one block. -For example a $20\%$ slash is equivalent to a $-20\%$ inflation for a validator in a block. -Given correctness of auto-bonding inflation with different inflation rates per-validator, -it follows that handling slashes can be correctly done by simply subtracting the validators inflation factor in that block to be the negative of the slash factor. -This significantly simplifies the withdrawal procedure. - -\subsection{Auto bonding fees} -TODO: Fill this out. -Core idea: you use the same mechanism as previously, but you just don't take that optimization with $n_{i}$ and the $n_{start}$ relation. -Fairly simple to do. - -\subsection{Delegation updates} -Updating your delegation amount is equivalent to withdrawing earned rewards and a fully independent new delegation occurring in the same block. -The same applies for redelegation. -From the view of fee distribution, partial redelegation is the same as a delegation update + a new delegation. - -\subsection{Jailing / being kicked out of the validator set} -This basically requires no change. -In each block you only iterate over the currently bonded validators. -So you simply don't update the "total accrued fees this period" variable for jailed / non-bonded validators. -Withdrawing requires \textit{no} special casing here! - -\section{State Requirements} -State entries can be pruned quite effectively. -Suppose for the sake of exposition that there is at most one delegation / withdrawal to a particular validator in any given block. -Then each delegation is responsible for one addition to state. -Only the next period, and this delegator's withdrawal could depend on this entry. Thus once this delegator withdraws, this state entry can be pruned. -For the entry created by the delegator's withdrawal, that is only required by the creation of the next period. -Thus once the next period is created, that withdrawal's period can be deleted. - -This can be easily adapted to the case where there are multiple delegations / withdrawals per block, by maintaining a reference count in each period starting state entry. - -The slash entries for a validator can only be pruned when all of that validator's delegators have their bonding period starting after the slash. -This seems ineffective to keep track of, thus it is not worth it. -Each slash should instead remain in state until the validator unbonds and all delegators have their fees withdrawn. - -\section{Implementers Considerations} -TODO: Convert this section into a proper conclusion - -This is an extremely simple scheme with many nice benefits. -\begin{itemize} - \item The overhead per block is a simple iteration over the bonded validator set, which occurs anyway. (Thus it can be implemented ``for-free" with an optimized code-base) - \item Withdrawing earned fees only requires iterating over slashes since when you bonded. (Which is a negligible iteration) - \item There are no approximations in any of the calculations. (modulo minor errata resulting from fixed precision decimals used in divisions) - \item Supports arbitrary inflation models. (Thus could even vary upon block signers) - \item Supports arbitrary fee distribution amongst the validator set. (Thus can account for things like only online validators get fees, which has important incentivization impacts) - \item The above two can change on a live chain with no issues. - \item Validator commission rates can be changed every block - \item The simplicity of this scheme lends itself well to implementation -\end{itemize} - -Thus this scheme has efficiency improvements, simplicity improvements, and expressiveness improvements over the currently proposed schemes. With a correct fee distribution amongst the validator set, this solves the existing problem where one could withhold their signature for risk-free gain. - -\section{TO DOs} - -\begin{itemize} - \item A global fee pool can be described. - \item Mention storage optimization for how to prune slashing entries in the uniform inflation and iteration over slashing case - \item Add equation numbers - \item perhaps re-organize so that the no iteration - \item Section on decimal precision considerations (would unums help?), and mitigating errors in calculation with floats and decimals. -- This probably belongs in a corrollary markdown file in the implementation - \item Consider indicating that the withdraw action need not be a tx type and could instead happen 'transparently' when more coins are needed, if a chain desired this for UX / p2p efficiency. -\end{itemize} - - -\end{document} diff --git a/docs/spec/addresses/README.md b/docs/spec/addresses/README.md deleted file mode 100644 index fb7aa15bcd..0000000000 --- a/docs/spec/addresses/README.md +++ /dev/null @@ -1,3 +0,0 @@ -# Addresses spec - -- [Bech32](./bech32.md) \ No newline at end of file diff --git a/docs/spec/addresses/bech32.md b/docs/spec/addresses/bech32.md deleted file mode 100644 index 7f0babb144..0000000000 --- a/docs/spec/addresses/bech32.md +++ /dev/null @@ -1,24 +0,0 @@ -# Bech32 on Cosmos - -The Cosmos network prefers to use the Bech32 address format wherever users must handle binary data. Bech32 encoding provides robust integrity checks on data and the human readable part(HRP) provides contextual hints that can assist UI developers with providing informative error messages. - -In the Cosmos network, keys and addresses may refer to a number of different roles in the network like accounts, validators etc. - -## HRP table - -| HRP | Definition | -| ---------------- | ------------------------------------- | -| cosmos | Cosmos Account Address | -| cosmospub | Cosmos Account Public Key | -| cosmosvalcons | Cosmos Validator Consensus Address | -| cosmosvalconspub | Cosmos Validator Consensus Public Key | -| cosmosvaloper | Cosmos Validator Operator Address | -| cosmosvaloperpub | Cosmos Validator Operator Public Key | - -## Encoding - -While all user facing interfaces to Cosmos software should exposed Bech32 interfaces, many internal interfaces encode binary value in hex or base64 encoded form. - -To covert between other binary representation of addresses and keys, it is important to first apply the Amino encoding process before bech32 encoding. - -A complete implementation of the Amino serialization format is unnecessary in most cases. Simply prepending bytes from this [table](https://github.com/tendermint/spec/blob/master/spec/blockchain/encoding.md#public-key-cryptography) to the byte string payload before bech32 encoding will sufficient for compatible representation. diff --git a/docs/spec/circuit-breaker/01_concepts.md b/docs/spec/circuit-breaker/01_concepts.md deleted file mode 100644 index a0b9162a7f..0000000000 --- a/docs/spec/circuit-breaker/01_concepts.md +++ /dev/null @@ -1,17 +0,0 @@ -# Concepts - -The intention of the circuit breaker is to have a contingency plan for a -running network which maintains network liveness. This can be achieved through -selectively "pausing" functionality of specific modules on a running network. -The circuit breaker is intended to be enabled through either: - - - governance - - for emergencies a special subset of accounts selected by the state machine - - a transaction which proves the expected behaviour is broken - -## Pause state - -The basic pause state of any module simply disables all message routes to -that module. Beyond that, it may be a appropriate for different modules to -process begin-block/end-block in an altered "safe" way. - diff --git a/docs/spec/reserve-pool/TODO.md b/docs/spec/reserve-pool/TODO.md deleted file mode 100644 index b3232fef32..0000000000 --- a/docs/spec/reserve-pool/TODO.md +++ /dev/null @@ -1,5 +0,0 @@ -TODO - -The reserve pool is the pool of collected funds for use by governance taken via the `CommunityTax`. -Currently with the SDK, tokens collected by the CommunityTax are accounted for but unspendable. - diff --git a/docs/spec/store/README.md b/docs/spec/store/README.md deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/docs/using-the-sdk/README.md b/docs/using-the-sdk/README.md deleted file mode 100644 index 747dfd5005..0000000000 --- a/docs/using-the-sdk/README.md +++ /dev/null @@ -1,9 +0,0 @@ - - -# Using the SDK - -- [Modules](../../x/README.md) -- [Simulation](./simulation.md) diff --git a/docs/versions b/docs/versions deleted file mode 100644 index d5dc85eb28..0000000000 --- a/docs/versions +++ /dev/null @@ -1,2 +0,0 @@ -master master -launchpad/backports v0.39