From cff03a5bfe9e727e00013e7aee41fcd3c708719a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=B5=B7=E5=A8=81?= Date: Sun, 19 Dec 2021 21:18:27 +0900 Subject: [PATCH] add Japanese docs --- docs/ja/404.md | 26 +- docs/ja/README.md | 72 +-- docs/ja/architecture/PROCESS.md | 56 +- docs/ja/architecture/README.md | 118 ++-- .../ja/architecture/adr-002-docs-structure.md | 84 +-- .../adr-003-dynamic-capability-store.md | 226 ++++---- .../adr-004-split-denomination-keys.md | 124 ++--- .../adr-006-secret-store-replacement.md | 62 +-- .../adr-007-specialization-groups.md | 186 +++---- docs/ja/architecture/adr-008-dCERT-group.md | 342 ++++++------ .../architecture/adr-009-evidence-module.md | 173 +++--- .../adr-010-modular-antehandler.md | 212 ++++---- .../adr-011-generalize-genesis-accounts.md | 108 ++-- .../architecture/adr-012-state-accessors.md | 129 ++--- docs/ja/architecture/adr-013-metrics.md | 92 ++-- .../adr-014-proportional-slashing.md | 84 ++- ...dr-016-validator-consensus-key-rotation.md | 141 +++-- .../adr-017-historical-header-module.md | 56 +- .../adr-018-extendable-voting-period.md | 72 +-- .../adr-019-protobuf-state-encoding.md | 448 +++++++-------- .../adr-020-protobuf-transaction-encoding.md | 509 +++++++++--------- .../adr-021-protobuf-query-encoding.md | 267 +++++---- .../adr-022-custom-panic-handling.md | 151 +++--- .../architecture/adr-023-protobuf-naming.md | 371 +++++++------ docs/ja/architecture/adr-024-coin-metadata.md | 119 ++-- ...27-deterministic-protobuf-serialization.md | 384 ++++++------- .../adr-028-public-key-addresses.md | 314 +++++------ .../architecture/adr-029-fee-grant-module.md | 141 +++-- docs/ja/architecture/adr-030-authz-module.md | 192 ++++--- docs/ja/architecture/adr-031-msg-service.md | 184 ++++--- docs/ja/architecture/adr-032-typed-events.md | 148 ++--- .../adr-033-protobuf-inter-module-comm.md | 404 +++++++------- .../architecture/adr-034-account-rekeying.md | 63 ++- .../adr-035-rosetta-api-support.md | 228 ++++---- .../adr-036-arbitrary-signature.md | 107 ++-- .../ja/architecture/adr-037-gov-split-vote.md | 58 +- .../architecture/adr-038-state-listening.md | 320 ++++++----- .../architecture/adr-039-epoched-staking.md | 137 +++-- ...r-040-storage-and-smt-state-commitments.md | 283 +++++----- .../adr-041-in-place-store-migrations.md | 137 +++-- docs/ja/architecture/adr-042-group-module.md | 262 ++++----- docs/ja/architecture/adr-043-nft-module.md | 230 ++++---- .../adr-044-protobuf-updates-guidelines.md | 144 ++--- .../adr-045-check-delivertx-middlewares.md | 219 ++++---- docs/ja/architecture/adr-046-module-params.md | 193 ++++--- docs/ja/basics/README.md | 14 +- docs/ja/basics/accounts.md | 91 ++-- docs/ja/basics/app-anatomy.md | 232 ++++---- docs/ja/basics/gas-fees.md | 72 +-- docs/ja/basics/query-lifecycle.md | 116 ++-- docs/ja/basics/tx-lifecycle.md | 296 +++++----- docs/ja/building-modules/README.md | 26 +- .../building-modules/beginblock-endblock.md | 34 +- docs/ja/building-modules/errors.md | 54 +- docs/ja/building-modules/genesis.md | 38 +- docs/ja/building-modules/intro.md | 50 +- docs/ja/building-modules/invariants.md | 38 +- docs/ja/building-modules/keeper.md | 66 +-- .../building-modules/messages-and-queries.md | 104 ++-- docs/ja/building-modules/module-interfaces.md | 127 +++-- docs/ja/building-modules/module-manager.md | 152 +++--- docs/ja/building-modules/msg-services.md | 86 +-- docs/ja/building-modules/query-services.md | 52 +- docs/ja/building-modules/simulator.md | 118 ++-- docs/ja/building-modules/structure.md | 56 +- docs/ja/building-modules/upgrade.md | 34 +- docs/ja/core/README.md | 36 +- docs/ja/core/baseapp.md | 502 ++++++++--------- docs/ja/core/cli.md | 132 ++--- docs/ja/core/context.md | 110 ++-- docs/ja/core/encoding.md | 216 ++++---- docs/ja/core/events.md | 94 ++-- docs/ja/core/grpc_rest.md | 100 ++-- docs/ja/core/node.md | 56 +- docs/ja/core/ocap.md | 92 ++-- docs/ja/core/runtx_middleware.md | 38 +- docs/ja/core/simulation.md | 172 +++--- docs/ja/core/store.md | 168 +++--- docs/ja/core/telemetry.md | 84 +-- docs/ja/core/transactions.md | 132 ++--- docs/ja/core/upgrade.md | 74 +-- docs/ja/ibc/README.md | 18 +- docs/ja/ibc/custom.md | 284 +++++----- docs/ja/ibc/integration.md | 126 ++--- docs/ja/ibc/overview.md | 156 +++--- docs/ja/ibc/proposals.md | 64 +-- docs/ja/ibc/relayer.md | 62 +-- docs/ja/ibc/upgrades/README.md | 10 +- docs/ja/ibc/upgrades/developer-guide.md | 22 +- docs/ja/ibc/upgrades/quick-guide.md | 64 +-- docs/ja/intro/README.md | 14 +- docs/ja/intro/overview.md | 38 +- docs/ja/intro/sdk-app-architecture.md | 42 +- docs/ja/intro/sdk-design.md | 50 +- docs/ja/intro/why-app-specific.md | 72 +-- docs/ja/migrations/README.md | 8 +- docs/ja/migrations/chain-upgrade-guide-044.md | 81 ++- docs/ja/migrations/pre-upgrade.md | 16 +- docs/ja/migrations/rest.md | 22 +- docs/ja/modules/README.md | 40 +- docs/ja/modules/auth/01_concepts.md | 54 +- docs/ja/modules/auth/02_state.md | 41 +- docs/ja/modules/auth/03_antehandlers.md | 38 +- docs/ja/modules/auth/04_keepers.md | 10 +- docs/ja/modules/auth/05_vesting.md | 267 +++++---- docs/ja/modules/auth/06_params.md | 2 +- docs/ja/modules/auth/07_client.md | 16 +- docs/ja/modules/auth/README.md | 52 +- docs/ja/modules/authz/01_concepts.md | 34 +- docs/ja/modules/authz/02_state.md | 12 +- docs/ja/modules/authz/03_messages.md | 44 +- docs/ja/modules/authz/04_events.md | 4 +- docs/ja/modules/authz/05_client.md | 12 +- docs/ja/modules/authz/README.md | 36 +- docs/ja/modules/bank/01_state.md | 22 +- docs/ja/modules/bank/02_keepers.md | 44 +- docs/ja/modules/bank/03_messages.md | 24 +- docs/ja/modules/bank/04_events.md | 6 +- docs/ja/modules/bank/05_params.md | 20 +- docs/ja/modules/bank/06_client.md | 17 +- docs/ja/modules/bank/README.md | 120 ++--- docs/ja/modules/capability/01_concepts.md | 46 +- docs/ja/modules/capability/README.md | 48 +- docs/ja/modules/crisis/01_state.md | 18 +- docs/ja/modules/crisis/02_messages.md | 24 +- docs/ja/modules/crisis/03_events.md | 4 +- docs/ja/modules/crisis/04_params.md | 4 +- docs/ja/modules/crisis/05_client.md | 10 +- docs/ja/modules/crisis/README.md | 30 +- docs/ja/modules/distribution/01_concepts.md | 44 +- docs/ja/modules/distribution/02_state.md | 46 +- .../ja/modules/distribution/03_begin_block.md | 102 ++-- docs/ja/modules/distribution/04_messages.md | 64 +-- docs/ja/modules/distribution/05_hooks.md | 72 +-- docs/ja/modules/distribution/06_events.md | 4 +- docs/ja/modules/distribution/07_params.md | 4 +- docs/ja/modules/distribution/08_client.md | 22 +- docs/ja/modules/distribution/README.md | 190 +++---- docs/ja/modules/epoching/01_state.md | 32 +- docs/ja/modules/epoching/03_to_improve.md | 22 +- docs/ja/modules/epoching/README.md | 8 +- docs/ja/modules/evidence/01_concepts.md | 38 +- docs/ja/modules/evidence/02_state.md | 8 +- docs/ja/modules/evidence/03_messages.md | 20 +- docs/ja/modules/evidence/04_events.md | 4 +- docs/ja/modules/evidence/06_begin_block.md | 48 +- docs/ja/modules/evidence/07_client.md | 12 +- docs/ja/modules/evidence/README.md | 48 +- docs/ja/modules/feegrant/01_concepts.md | 60 +-- docs/ja/modules/feegrant/02_state.md | 12 +- docs/ja/modules/feegrant/03_messages.md | 12 +- docs/ja/modules/feegrant/04_events.md | 5 +- docs/ja/modules/feegrant/05_client.md | 22 +- docs/ja/modules/feegrant/README.md | 36 +- docs/ja/modules/gov/01_concepts.md | 268 ++++----- docs/ja/modules/gov/02_state.md | 112 ++-- docs/ja/modules/gov/03_messages.md | 74 +-- docs/ja/modules/gov/04_events.md | 4 +- docs/ja/modules/gov/05_future_improvements.md | 48 +- docs/ja/modules/gov/06_params.md | 4 +- docs/ja/modules/gov/07_client.md | 12 +- docs/ja/modules/gov/README.md | 100 ++-- docs/ja/modules/mint/01_concepts.md | 36 +- docs/ja/modules/mint/02_state.md | 16 +- docs/ja/modules/mint/03_begin_block.md | 22 +- docs/ja/modules/mint/04_params.md | 4 +- docs/ja/modules/mint/05_events.md | 4 +- docs/ja/modules/mint/06_client.md | 10 +- docs/ja/modules/mint/README.md | 34 +- docs/ja/modules/params/01_keeper.md | 5 +- docs/ja/modules/params/02_subspace.md | 44 +- docs/ja/modules/params/README.md | 28 +- docs/ja/modules/slashing/01_concepts.md | 53 +- docs/ja/modules/slashing/02_state.md | 58 +- docs/ja/modules/slashing/03_messages.md | 18 +- docs/ja/modules/slashing/04_begin_block.md | 44 +- docs/ja/modules/slashing/05_hooks.md | 22 +- docs/ja/modules/slashing/06_events.md | 5 +- docs/ja/modules/slashing/07_tombstone.md | 246 ++++----- docs/ja/modules/slashing/08_params.md | 4 +- docs/ja/modules/slashing/09_client.md | 8 +- docs/ja/modules/slashing/README.md | 58 +- docs/ja/modules/staking/01_state.md | 286 +++++----- .../modules/staking/02_state_transitions.md | 240 ++++----- docs/ja/modules/staking/03_messages.md | 170 +++--- docs/ja/modules/staking/04_begin_block.md | 16 +- docs/ja/modules/staking/05_end_block.md | 146 ++--- docs/ja/modules/staking/06_hooks.md | 10 +- docs/ja/modules/staking/07_events.md | 4 +- docs/ja/modules/staking/08_params.md | 4 +- docs/ja/modules/staking/09_client.md | 10 +- docs/ja/modules/staking/README.md | 66 +-- docs/ja/modules/upgrade/01_concepts.md | 121 +++-- docs/ja/modules/upgrade/02_state.md | 26 +- docs/ja/modules/upgrade/03_events.md | 6 +- docs/ja/modules/upgrade/04_client.md | 16 +- docs/ja/modules/upgrade/README.md | 36 +- docs/ja/run-node/README.md | 16 +- docs/ja/run-node/cosmovisor.md | 152 +++--- docs/ja/run-node/interact-node.md | 83 ++- docs/ja/run-node/keyring.md | 138 ++--- docs/ja/run-node/rosetta.md | 42 +- docs/ja/run-node/run-node.md | 68 +-- docs/ja/run-node/run-testnet.md | 44 +- docs/ja/run-node/txs.md | 122 ++--- docs/zh/architecture/README.md | 58 +- .../architecture/adr-009-evidence-module.md | 2 +- ...dr-016-validator-consensus-key-rotation.md | 2 +- .../architecture/adr-023-protobuf-naming.md | 2 +- .../adr-033-protobuf-inter-module-comm.md | 2 +- .../adr-035-rosetta-api-support.md | 4 +- .../adr-036-arbitrary-signature.md | 2 +- .../architecture/adr-039-epoched-staking.md | 2 +- docs/zh/core/encoding.md | 2 +- docs/zh/core/ocap.md | 2 +- docs/zh/modules/feegrant/01_concepts.md | 2 +- 216 files changed, 9307 insertions(+), 9357 deletions(-) diff --git a/docs/ja/404.md b/docs/ja/404.md index 8df83fbe7db3..3beaef8b13dc 100644 --- a/docs/ja/404.md +++ b/docs/ja/404.md @@ -4,30 +4,30 @@ layout: homepage title: 404 Lost in Space! description: You've been lost in space sections: - - title: 紹介 - desc: High-level overview of the Cosmos SDK. - url: /ja/intro/overview.html + - title: 介绍 + desc: 高级介绍 Cosmos SDK. + url: /zh/intro/overview.html icon: introduction - - title: 基本 + - title: 基础 desc: Anatomy of a blockchain, transaction lifecycle, accounts and more. icon: basics - url: /ja/basics/app-anatomy.html - - title: コアコンセプト + url: /zh/basics/app-anatomy.html + - title: 核心概念 desc: Read about the core concepts like baseapp, the store, or the server. icon: core - url: /ja/core/baseapp.html - - title: モジュール構築 + url: /zh/core/baseapp.html + - title: 模块构筑 desc: Discover how to build modules for the Cosmos SDK. icon: modules - url: /ja/building-modules/intro.html - - title: ノードを稼働する + url: /zh/building-modules/intro.html + - title: 运行一个节点 desc: Running and interacting with nodes using the CLI and API. icon: interfaces - url: /ja/run-node/ - - title: モジュール + url: /zh/run-node/ + - title: 模块 desc: Explore existing modules to build your application with. icon: specifications - url: /ja/modules/ + url: /zh/modules/ stack: - title: Cosmos Hub desc: The first of thousands of interconnected blockchains on the Cosmos Network. diff --git a/docs/ja/README.md b/docs/ja/README.md index 5e595ab14bc6..46536df7ae93 100644 --- a/docs/ja/README.md +++ b/docs/ja/README.md @@ -3,30 +3,30 @@ layout: homepage title: Cosmos SDK Documentation description: Cosmos SDK is the world’s most popular framework for building application-specific blockchains. sections: - - title: 紹介 - desc: High-level overview of the Cosmos SDK. - url: /ja/intro/overview.html + - title: 介绍 + desc: 高级介绍 Cosmos SDK. + url: /zh/intro/overview.html icon: introduction - - title: 基本 + - title: 基础 desc: Anatomy of a blockchain, transaction lifecycle, accounts and more. icon: basics - url: /ja/basics/app-anatomy.html - - title: コアコンセプト + url: /zh/basics/app-anatomy.html + - title: 核心概念 desc: Read about the core concepts like baseapp, the store, or the server. icon: core - url: /ja/core/baseapp.html - - title: モジュール構築 + url: /zh/core/baseapp.html + - title: 模块构筑 desc: Discover how to build modules for the Cosmos SDK. icon: modules - url: /ja/building-modules/intro.html - - title: ノードを稼働する + url: /zh/building-modules/intro.html + - title: 运行一个节点 desc: Running and interacting with nodes using the CLI and API. icon: interfaces - url: /ja/run-node/ - - title: モジュール + url: /zh/run-node/ + - title: 模块 desc: Explore existing modules to build your application with. icon: specifications - url: /ja/modules/ + url: /zh/modules/ stack: - title: Cosmos Hub desc: The first of thousands of interconnected blockchains on the Cosmos Network. @@ -43,39 +43,39 @@ footer: aside: false --> -# Cosmos SDK Documentation +# Cosmos SDK 文档 -## Get Started +## 开始 -- **[Cosmos SDK Intro](./intro/overview.md)**: High-level overview of the Cosmos SDK. -- **[Starport](https://docs.starport.network/)**: A developer-friendly interface to the Cosmos SDK to scaffold, launch, and maintain any crypto application on a sovereign and secured blockchain. -- **[SDK Tutorials](https://tutorials.cosmos.network/)**: Tutorials that showcase how to build Cosmos SDK-based blockchains from scratch and explain the basic Cosmos SDK principles in the process. +- **[Cosmos SDK Intro](./intro/overview.md)**:Cosmos SDK 的高级概述。 +- **[Starport](https://docs.starport.network/)**:Cosmos SDK 的开发人员友好界面，用于在主权和安全的区块链上搭建、启动和维护任何加密应用程序。 +- **[SDK 教程](https://tutorials.cosmos.network/)**:展示如何从头开始构建基于 Cosmos SDK 的区块链的教程，并解释了该过程中的基本 Cosmos SDK 原理。 -## Reference Docs +## 参考文档 -- **[Basics](./basics/)**: Basic concepts of the Cosmos SDK, including the standard anatomy of an application, the transaction lifecycle, and accounts management. -- **[Core](./core/)**: Core concepts of the Cosmos SDK, including `baseapp`, the `store`, or the `server`. -- **[Building Modules](./building-modules/)**: Important concepts for module developers like `message`, `keeper`, and `querier`. -- **[IBC](./ibc/)**: IBC protocol integration and concepts. -- **[Running a Node, API, CLI](./run-node/)**: How to run a node and interact with the node using the CLI and the API. -- **[Migrations](./migrations/)**: Migration guides for updating to newer versions of Cosmos SDK. +- **[Basics](./basics/)**:Cosmos SDK 的基本概念，包括应用的标准剖析、交易生命周期和账户管理。 +- **[Core](./core/)**:Cosmos SDK 的核心概念，包括`baseapp`、`store` 或`server`。 +- **[Building Modules](./building-modules/)**:模块开发人员的重要概念，如`message`、`keeper`和`querier`。 +- **[IBC](./ibc/)**:IBC 协议集成和概念。 +- **[运行节点、API、CLI](./run-node/)**:如何使用 CLI 和 API 运行节点并与节点交互。 +- **[Migrations](./migrations/)**:更新到新版本 Cosmos SDK 的迁移指南。 -## Other Resources +## 其他资源 -- **[Module Directory](../x/)**: Cosmos SDK module implementations and their respective documentation. -- **[Specifications](./spec/)**: Specifications of modules and other parts of the Cosmos SDK. -- **[Cosmos SDK API Reference](https://godoc.org/github.com/cosmos/cosmos-sdk)**: Godocs of the Cosmos SDK. -- **[REST and RPC Endpoints](https://cosmos.network/rpc/)**: List of endpoints to interact with a `gaia` full-node. -- **[Rosetta API](./run-node/rosetta.md)**: Rosetta API integration. +- **[模块目录](../x/)**:Cosmos SDK 模块实现及其各自的文档。 +- **[Specifications](./spec/)**:Cosmos SDK 的模块和其他部分的规范。 +- **[Cosmos SDK API 参考](https://godoc.org/github.com/cosmos/cosmos-sdk)**:Cosmos SDK 的 Godocs。 +- **[REST 和 RPC 端点](https://cosmos.network/rpc/)**:与`gaia` 全节点交互的端点列表。 +- **[Rosetta API](./run-node/rosetta.md)**:Rosetta API 集成。 ## Cosmos Hub -The Cosmos Hub (`gaia`) docs have moved to [github.com/cosmos/gaia](https://github.com/cosmos/gaia/tree/master/docs). +Cosmos Hub (`gaia`) 文档已移至 [github.com/cosmos/gaia](https://github.com/cosmos/gaia/tree/master/docs)。 -## Languages +## 开发语言 -The Cosmos SDK is 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. +Cosmos SDK 是用 [Golang](https://golang.org/) 编写的，尽管该框架可以用其他语言类似地实现。联系我们以获取有关为另一种语言的实施提供资金的信息。 -## Contribute +## 贡献 -See the [DOCS_README.md](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md) for details of the build process and considerations when making changes. +有关构建过程的详细信息和进行更改时的注意事项，请参阅 [DOCS_README.md](https://github.com/cosmos/cosmos-sdk/blob/master/docs/DOCS_README.md)。 \ No newline at end of file diff --git a/docs/ja/architecture/PROCESS.md b/docs/ja/architecture/PROCESS.md index 209beb0f72d1..f57939f86567 100644 --- a/docs/ja/architecture/PROCESS.md +++ b/docs/ja/architecture/PROCESS.md @@ -1,38 +1,38 @@ -# ADR Creation Process +# ADR作成プロセス -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. +1.`adr-template.md`ファイルをコピーします。次のファイル名パターンを使用します: `adr-next_number-title.md` +2.早期のフィードバックを受け取りたい場合は、ドラフトプルリクエストを作成してください。 +3.コンテキストとソリューションが明確で、十分に文書化されていることを確認します。 +4. [README](..README.md)ファイルのリストにエントリを追加します。 +5.プルリクエストを作成して、新しいADRを提案します。 -## ADR life cycle +## ADRライフサイクル -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. +ADRの作成は、**反復**プロセスです。単一のADRプルリクエストですべての決定を解決しようとするのではなく、最初に問題を理解し、GitHubの問題を通じてフィードバックを収集する必要があります。 -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. +1.各提案は、新しいGitHubの問題で開始するか、既存の問題の結果である必要があります。質問には、提案の短い要約のみを含める必要があります。 -2. Once the motivation is validated, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`. +2.動機が確認されると、GitHubプルリクエスト(PR)は `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. +3. ADRは、単一のPRで_accepted_状態の `master`に到達する必要はありません。動機が明確で解決策が合理的である場合、それをマージして_提案された_状態を維持できるはずです。長くて統合されていないプルリクエストではなく、反復的なアプローチを使用することをお勧めします。 -4. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue. +4. _proposed_ ADRがマージされる場合、ADRドキュメントまたはGitHubの問題で未解決の問題を明確に文書化する必要があります。 -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. +5.PRは常にマージする必要があります。 ADRの問題の場合でも、それを_rejected_ステータスとマージする傾向があります。 ADRをマージしてはならないのは、作成者がADRを放棄したときだけです。 -6. Merged ADRs SHOULD NOT be pruned. +6.結合されたADRはトリミングしないでください。 -### ADR status +### ADRステータス -Status has two components: +状態には2つの要素があります。 ``` {CONSENSUS STATUS} {IMPLEMENTATION STATUS} ``` -IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`. +実装ステータスは「実装済み」または「未実装」です。 -#### Consensus Status +#### コンセンサスステータス ``` DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED by ADR-xxx @@ -42,15 +42,15 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b 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. ++ `ドラフト`:[オプション] ADRは進行中ですが、まだ一般的なレビューの準備ができていません。 これは、初期の作業を示し、ドラフトプルリクエストフォームで早期のフィードバックを取得するためのものです。 ++ `提案`:完全なソリューションアーキテクチャをカバーするADRはまだ検討中です-プロジェクトの利害関係者はまだ合意に達していません。 ++ `LAST CALL <最後の呼び出しの日付>`:[オプション]更新を受け入れようとしていることを明確に通知します。 ステータスを「LASTCALL」に変更するということは、(Cosmos SDKメンテナの)社会的コンセンサスに達したことを意味します。それでも、コミュニティが反応または分析する時間を与えたいと考えています。 ++ `ACCEPTED`:ADRは、実装された、または実装される予定の現在のアーキテクチャ設計を表します。 ++ `拒否`:プロジェクトの利害関係者が合意に達した場合、ADRは提案または承認から拒否に変更できます。 ++ `SUPERSEEDED by ADR-xxx`:新しいADRに置き換えられたADR。 ++ `ABANDONED`:元の作者はADRを追求しなくなりました。 -## Language used in ADR +## ADRで使用される言語 -+ The context/background should be written in the present tense. -+ Avoid using a first, personal form. ++文脈/背景は現在形で書く必要があります。 ++最初の個人用フォームの使用は避けてください。 \ No newline at end of file diff --git a/docs/ja/architecture/README.md b/docs/ja/architecture/README.md index 2dd24a8a1343..0b73d9025d33 100644 --- a/docs/ja/architecture/README.md +++ b/docs/ja/architecture/README.md @@ -1,78 +1,78 @@ -# Architecture Decision Records (ADR) +# アーキテクチャ決定記録(ADR) -This is a location to record all high-level architecture decisions in the Cosmos-SDK. +これは、すべての高レベルのアーキテクチャ上の決定が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). +アーキテクチャー決定(** AD **)は、アーキテクチャー的に重要な機能要件または非機能要件を解決するために使用されるソフトウェア設計の選択です。 +アーキテクチャ上重要な要件(** ASR **)は、ソフトウェアシステムのアーキテクチャと品質に測定可能な影響を与える要件です。 +アーキテクチャ上の決定レコード(** ADR **)は、個人的なメモや議事録を作成するときによく行われることなど、単一のADをキャプチャします。プロジェクトで作成および維持されるADRのセットは、その決定ログを構成します。これらはすべて、建設知識管理(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). +ADRの概念について詳しくは、この[ブログ投稿](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: +ADRは、新しい機能設計と新しいプロセスを提案し、特定の問題に関するコミュニティの意見を収集し、設計上の決定を記録するための主要なメカニズムになることを目的としています。 +ADRは以下を提供する必要があります。 -- 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. +ADRと仕様の違いに注意してください。 ADRは、コンテキスト、直感、推論、および +構造を変更する理由、または何かの構造 +新着。仕様は、すべてのコンテンツのより圧縮された単純化された要約を提供します。 +今日は立っています。 -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 +## 新しいADRを作成する -Read about the [PROCESS](./PROCESS.md). +[PROCESS](..PROCESS.md)についてお読みください。 -#### Use RFC 2119 Keywords +#### RFC2119キーワードを使用する -When writing ADRs, follow the same best practices for writing RFCs. When writing RFCs, key words are used to signify the requirements in the specification. These words are often capitalized: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL. They are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). +ADRを作成するときは、RFCを作成するときと同じベストプラクティスに従ってください。 RFCを作成するとき、キーワードは仕様の要件を表すために使用されます。これらの単語は通常大文字で表記されます:「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」。それらは[RFC2119](https://datatracker.ietf.org/doc/html/rfc2119)で説明されているように説明されます。 -## ADR Table of Contents +## ADRディレクトリ -### Accepted +### 受け入れる -- [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 029: Fee Grant Module](./adr-029-fee-grant-module.md) -- [ADR 030: Message Authorization Module](./adr-030-authz-module.md) -- [ADR 031: Protobuf Msg Services](./adr-031-msg-service.md) +-[ADR 002:SDKドキュメント構造](..adr-002-docs-structure.md) +-[ADR 004:分割金種キー](..adr-004-split-denomination-keys.md) +-[ADR 006:シークレットストアの交換](..adr-006-secret-store-replacement.md) +-[ADR 009:エビデンスモジュール](..adr-009-evidence-module.md) +-[ADR 010:モジュラーAnteHandler](..adr-010-modular-antehandler.md) +-[ADR 019:プロトコルバッファ状態エンコーディング](..adr-019-protobuf-state-encoding.md) +-[ADR 020:プロトコルバッファトランザクションエンコーディング](..adr-020-protobuf-transaction-encoding.md) +-[ADR 021:プロトコルバッファクエリエンコーディング](..adr-021-protobuf-query-encoding.md) +-[ADR 023:プロトコルバッファの命名とバージョン管理](..adr-023-protobuf-naming.md) +-[ADR 029:料金付与モジュール](..adr-029-fee-grant-module.md) +-[ADR 030:メッセージ認証モジュール](..adr-030-authz-module.md) +-[ADR 031:Protobufメッセージサービス](..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 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 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 033: Inter-module RPC](./adr-033-protobuf-inter-module-comm.md) -- [ADR 035: Rosetta API Support](./adr-035-rosetta-api-support.md) -- [ADR 037: Governance Split Votes](./adr-037-gov-split-vote.md) -- [ADR 038: State Listening](./adr-038-state-listening.md) -- [ADR 039: Epoched Staking](./adr-039-epoched-staking.md) -- [ADR 040: Storage and SMT State Commitments](./adr-040-storage-and-smt-state-commitments.md) -- [ADR 046: Module Params](./adr-046-module-params.md) +-[ADR 003:動的機能ストア](..adr-003-dynamic-capability-store.md) +-[ADR 011:ジェネシスアカウントのプロモート](..adr-011-generalize-genesis-accounts.md) +-[ADR 012:州のアクセサー](..adr-012-state-accessors.md) +-[ADR 013:メトリクス](..adr-013-metrics.md) +-[ADR 016:検証者のコンセンサスキーローテーション](..adr-016-validator-consensus-key-rotation.md) +-[ADR 017:履歴ヘッダーモジュール](..adr-017-historical-header-module.md) +-[ADR 018:延長可能な投票期間](..adr-018-extendable-voting-period.md) +-[ADR 022:カスタムbaseappパニック処理](..adr-022-custom-panic-handling.md) +-[ADR 024:コインメタデータ](..adr-024-coin-metadata.md) +-[ADR 027:Deterministic Protobuf Serialization](..adr-027-deterministic-protobuf-serialization.md) +-[ADR 028:公開鍵アドレス](..adr-028-public-key-addresses.md) +-[ADR 032:型付きイベント](..adr-032-typed-events.md) +-[ADR 033:モジュール間RPC](..adr-033-protobuf-inter-module-comm.md) +-[ADR 035:Rosetta APIサポート](..adr-035-rosetta-api-support.md) +-[ADR 037:ガバナンス分割投票](..adr-037-gov-split-vote.md) +-[ADR 038:状態リスニング](..adr-038-state-listening.md) +-[ADR 039:Epoched Stakeing](..adr-039-epoched-staking.md) +-[ADR 040:ストレージとSMTの状態のコミットメント](..adr-040-storage-and-smt-state-commitments.md) +-[ADR 046:モジュールパラメータ](..adr-046-module-params.md) -### Draft +### 下書き -- [ADR 044: Guidelines for Updating Protobuf Definitions](./adr-044-protobuf-updates-guidelines.md) +-[ADR 044:Protobuf定義更新ガイド](..adr-044-protobuf-updates-guidelines.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-002-docs-structure.md b/docs/ja/architecture/adr-002-docs-structure.md index dd104acd7714..3a2f1ab24ac0 100644 --- a/docs/ja/architecture/adr-002-docs-structure.md +++ b/docs/ja/architecture/adr-002-docs-structure.md @@ -1,17 +1,17 @@ -# ADR 002: SDK Documentation Structure +# ADR 002:SDKドキュメント構造 -## Context +## 環境 -There is a need for a scalable structure of the Cosmos SDK documentation. Current documentation includes a lot of non-related Cosmos SDK material, is difficult to maintain and hard to follow as a user. +CosmosSDKドキュメントの拡張可能な構造が必要です。 現在のドキュメントには、Cosmos SDKに関連しない多くの資料が含まれています。これらの資料は、保守が難しく、ユーザーとしてフォローするのが困難です。 -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. +-開発フレームワークまたはツールに関連するすべてのドキュメントは、それぞれのgithubリポジトリにあります(sdkリポジトリにはsdkドキュメントが含まれ、ハブリポジトリにはハブドキュメントが含まれ、ローションリポジトリにはローションドキュメントが含まれます)。 +-他のすべてのドキュメント(FAQ、ホワイトペーパー、Cosmosに関する高度な資料)はWebサイトに保存されます。 -## Decision +## 決定 -Re-structure the `/docs` folder of the Cosmos SDK github repo as follows: +次のように、Cosmos SDKgithubリポジトリの `/docs`フォルダーを再構築します。 ``` docs/ @@ -37,50 +37,50 @@ docs/ └── 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 Cosmos SDK and then channel people to the resource they need. The [Cosmos 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 Cosmos 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 Cosmos 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. +-`README`:ドキュメントのランディングページ。 +-`intro`:紹介資料。目標は、Cosmos SDKの簡単な説明をしてから、必要なリソースに人々を導くことです。 [Cosmos SDKチュートリアル](https://github.com/cosmos/sdk-application-tutorial/)と `godocs`が強調表示されます。 +-`concepts`:CosmosSDK抽象化の高レベルの説明が含まれています。特定のコード実装は含まれておらず、頻繁に更新する必要はありません。 **これはインターフェースのAPI仕様ではありません**。 API仕様は `godoc`です。 +-`clients`:さまざまなCosmosSDKクライアントに関する仕様と情報が含まれています。 +-`spec`:モジュール仕様などが含まれます。 +-`modules`: `godocs`とモジュール仕様へのリンクが含まれています。 +-`architecture`:現在のアーキテクチャに関連するドキュメントが含まれています。 +-`translations`:ドキュメントのさまざまな翻訳が含まれています。 -Website docs sidebar will only include the following sections: +Webサイトのドキュメントのサイドバーには、次のセクションのみが含まれます。 -- `README` -- `intro` -- `concepts` -- `clients` +-`Readme` +-`はじめに ` +-`コンセプト ` +-`顧客 ` -`architecture` need not be displayed on the website. +「アーキテクチャ」をウェブサイトに表示する必要はありません。 -## Status +## ステータス -Accepted +受け入れられました -## Consequences +## 結果 -### Positive +### 目的 -- Much clearer organisation of the Cosmos SDK docs. -- The `/docs` folder now only contains Cosmos SDK and gaia related material. Later, it will only contain Cosmos 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) +-CosmosSDKドキュメントの構成がより明確になりました。 +-`/docs`フォルダーには、CosmosSDKとgaia関連の資料のみが含まれるようになりました。後で、CosmosSDK関連の資料のみが含まれるようになります。 +-開発者は、PRを開くときに `/docs`フォルダを更新するだけで済みます(たとえば、`/examples`ではありません)。 +-再設計されたアーキテクチャのおかげで、開発者はドキュメントで更新する必要があるものを簡単に見つけることができます。 +-Webサイトドキュメント用のよりクリーンなvuepressビルド。 +-実行可能ドキュメントの作成に役立ちます(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` +-廃止されたものの束を `/_attic`フォルダに移動する必要があります。 +-`docs/sdk/docs/core`のコンテンツを `concepts`に統合する必要があります。 +-現在 `docs`に存在し、新しい構造に適していないすべてのもの(` lotion`、紹介資料、ホワイトペーパーなど)をWebサイトリポジトリに移動する必要があります。 +-`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 +-https://github.com/cosmos/cosmos-sdk/issues/1460 +-https://github.com/cosmos/cosmos-sdk/pull/2695 +-https://github.com/cosmos/cosmos-sdk/issues/2611 \ No newline at end of file diff --git a/docs/ja/architecture/adr-003-dynamic-capability-store.md b/docs/ja/architecture/adr-003-dynamic-capability-store.md index b392404e0eba..27e5c367f993 100644 --- a/docs/ja/architecture/adr-003-dynamic-capability-store.md +++ b/docs/ja/architecture/adr-003-dynamic-capability-store.md @@ -1,51 +1,51 @@ -# ADR 3: Dynamic Capability Store +# ADR 3:動的容量ストレージ -## Changelog +## 変更ログ -- 12 December 2019: Initial version -- 02 April 2020: Memory Store Revisions +-2019年12月12日:初期バージョン +-2020年4月2日:メモリストレージの改訂 -## Context +## 環境 -Full implementation of the [IBC specification](https://github.com/cosmos/ibs) 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/ibc/tree/master/spec/core/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. +[IBC仕様](https://github.com/cosmos/ibs)の完全な実装では、実行時(つまり、トランザクションの実行中)にオブジェクト機能キーを作成および検証できる必要があります。 +[ICS 5](https://github.com/cosmos/ibc/tree/master/spec/core/ics-005-port-allocation#technical-specification)で説明されているように。 IBC仕様では、新しく初期化されたものごとに +ポートとチャネルは、ポートまたはチャネルの将来の使用状況を確認するために使用されます。チャネルと潜在的なポートはトランザクションの実行中に初期化できるため、ステートマシンは作成できる必要があります +このときのオブジェクトファンクションキー。 -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). +現在、CosmosSDKにはこれを行う機能がありません。オブジェクトファンクションキーは、現在、アプリケーションの初期化時に `app.go`で作成される` StoreKey`構造のポインタ(メモリアドレス)です([例](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app .go#L132)) +そして、それを固定パラメーターとしてKeepers([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L160))に渡します。キーパーは、トランザクションの実行中にファンクションキーを作成または保存することはできませんが、 `NewKVStoreKey`を呼び出して、メモリアドレスを取得することはできます。 +返された構造については、各マシンのメモリアドレスが異なるため、Merklisedストレージに保存すると、コンセンサスエラーが発生します(これは意図的なものです。そうでない場合、キーは予測可能であり、使用できません。オブジェクト機能) 。 -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. +キーパーには、トランザクションの実行中に変更できるストレージキーのプライベートマッピングを保存する方法、アプリケーションの起動時または再起動時にこのマッピングで一意のメモリアドレス(ファンクションキー)を再生成するための適切なメカニズム、およびメカニズムが必要です。 txが失敗したときに作成する機能を復元します。 +このADRは、そのようなインターフェースとメカニズムを提案します。 -## Decision +## 決定 -The Cosmos 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. +Cosmos SDKには、新しい「CapabilityKeeper」抽象化が含まれます。 +実行時に機能を追跡および検証します。 app.goでのアプリケーションの初期化中に、 +`CapabilityKeeper`は、一意の関数リファレンスを介してモジュールに接続します +( `ScopeToModule`を呼び出すことにより、次のように定義されます)後で呼び出し元のモジュールを識別するため +移行。 -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. +ディスクから初期状態をロードする場合、 `CapabilityKeeper`の` Initialise`関数が作成します +以前に割り当てられたすべての機能識別子の新しい機能キー(実行中に割り当てられた) +過去のトランザクションと特定のパターンに割り当てられたもの)をメモリのみのストレージに保存し、 +チェーンが実行されています。 -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. +`CapabilityKeeper`には、永続的な` KVStore`、 `MemoryStore`、およびメモリマップが含まれます。 +永続性「KVStore」は、どの機能がどのモジュールによって所有されているかを追跡します。 +`MemoryStore`は、モジュール名、機能タプルから機能名、および +モジュール名と関数名から関数インデックスへの逆マッピング。 +機能のメモリ位置を変更せずに機能を `KVStore`にグループ化およびグループ解除することはできないため、 +KVStoreの逆マッピングは、単にインデックスにマッピングされます。このインデックスは、一時ファイルのキーとして使用できます +Go-mapは、元のメモリ位置にある関数を取得します。 -The `CapabilityKeeper` will define the following types & functions: +`CapabilityKeeper`は、次のタイプと関数を定義します。 -The `Capability` is similar to `StoreKey`, but has a globally unique `Index()` instead of -a name. A `String()` method is provided for debugging. +`Capability`は` StoreKey`に似ていますが、代わりにグローバルに一意の `Index()`を持っています +名前。デバッグ用に `String()`メソッドが用意されています。 -A `Capability` is simply a struct, the address of which is taken for the actual capability. +`Capability`は単なる構造であり、そのアドレスは実際の機能に使用されます。 ```golang type Capability struct { @@ -53,7 +53,7 @@ type Capability struct { } ``` -A `CapabilityKeeper` contains a persistent store key, memory store key, and mapping of allocated module names. +「CapabilityKeeper」には、永続ストレージキー、メモリストレージキー、および割り当てられたモジュール名のマッピングが含まれています。 ```golang type CapabilityKeeper struct { @@ -65,11 +65,11 @@ type CapabilityKeeper struct { } ``` -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. +`CapabilityKeeper`は、*スコープ*サブマネージャーを作成する機能を提供します。 +特定のモジュール名。 これらの `ScopedCapabilityKeeper`は、アプリケーションの初期化時に作成する必要があります +そしてモジュールに渡されると、モジュールはそれらを使用して、受信および取得する関数を宣言できます +新しい機能と認証機能を作成することに加えて、それらが名前で所有する機能 +他のモジュールを介して。 ```golang type ScopedCapabilityKeeper struct { @@ -80,8 +80,8 @@ type ScopedCapabilityKeeper struct { } ``` -`ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique. -It MUST be called before `InitialiseAndSeal`. +`ScopeToModule`は、一意である必要がある特定の名前でスコープサブマネージャーを作成するために使用されます。 +`InitialiseAndSeal`の前に呼び出す必要があります。 ```golang func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper { @@ -105,10 +105,10 @@ func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeep } ``` -`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. +`InitialiseAndSeal`は初期状態をロードし、すべてを作成する必要があります +新しく作成されたメモリで埋めるために必要な「ScopedCapabilityKeeper」 +特定のモジュールによって以前に宣言されたキーの機能キーに従って、 +新しい「ScopedCapabilityKeeper」を作成します。 ```golang func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { @@ -119,7 +119,7 @@ func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { persistentStore := ctx.KVStore(ck.persistentKey) map := ctx.KVStore(ck.memKey) - // initialise memory store for all names in persistent store +./initialise memory store for all names in persistent store for index, value := range persistentStore.Iter() { capability = &CapabilityKey{index: index} @@ -136,97 +136,97 @@ func (ck CapabilityKeeper) InitialiseAndSeal(ctx Context) { } ``` -`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`. +どのモジュールも「NewCapability」を呼び出して、新しい独自の偽造不可能なオブジェクト機能を作成できます +参照する。 新しく作成された機能は自動的に保持されます。モジュールを呼び出す必要はありません +`ClaimCapability`を呼び出します。 ```golang func (sck ScopedCapabilityKeeper) NewCapability(ctx Context, name string) (Capability, error) { - // check name not taken in memory store +./check name not taken in memory store if capStore.Get("rev/" + name) != nil { return nil, errors.New("name already taken") } - // fetch the current index +./fetch the current index index := persistentStore.Get("index") - // create a new capability +./create a new capability capability := &CapabilityKey{index: index} - // set persistent store +./set persistent store persistentStore.Set(index, Set.singleton(sck.moduleName + "/" + name)) - // update the index +./update the index index++ persistentStore.Set("index", index) - // set forward mapping in memory store from capability to name +./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 +./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 +./set the in-memory mapping from index to capability pointer capMap[index] = capability - // return the newly created 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. +どのモジュールでもAuthenticateCapabilityを呼び出して、機能を確認できます +実際には特定の名前に対応しています(名前は信頼できないユーザー入力である可能性があります) +モジュールを呼び出す前に、モジュールに関連付けられています。 ```golang func (sck ScopedCapabilityKeeper) AuthenticateCapability(name string, capability Capability) bool { - // return whether forward mapping in memory store matches name +./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`を使用すると、モジュールは別のモジュールから受け取った機能キーを宣言できます +その後、将来の `GetCapability`呼び出しは成功します。 -`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. +受信機能モジュールが名前でアクセスする場合は、 `ClaimCapability`を呼び出す必要があります +将来。 機能は複数所有者であるため、複数のモジュールに単一の「機能」参照がある場合、 +彼らは皆それを持っているでしょう。 ```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 +./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 +./set reverse mapping in memory store from name to capability memStore.Set(sck.moduleName + "/rev/" + name, capability) - // update owner set in persistent store +./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. +`GetCapability`を使用すると、モジュールは以前に宣言された機能を名前で取得できます。 +モジュールは、モジュールに属していない関数を取得することはできません。 ```golang func (sck ScopedCapabilityKeeper) GetCapability(ctx Context, name string) (Capability, error) { - // fetch the index of capability using reverse mapping in memstore +./fetch the index of capability using reverse mapping in memstore index := memStore.Get(sck.moduleName + "/rev/" + name) - // fetch capability from go-map using index +./fetch capability from go-map using index capability := capMap[index] - // return the capability +./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. +`ReleaseCapability`を使用すると、モジュールは以前に宣言された機能を解放できます。 そうでない場合 +所有者がさらにいる場合、その能力はグローバルに削除されます。 ```golang func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capability) err { @@ -237,65 +237,65 @@ func (sck ScopedCapabilityKeeper) ReleaseCapability(ctx Context, capability Capa return error("capability not owned by module") } - // delete forward mapping in memory store +./delete forward mapping in memory store memoryStore.Delete(sck.moduleName + "/fwd/" + capability, name) - // delete reverse mapping in memory store +./delete reverse mapping in memory store memoryStore.Delete(sck.moduleName + "/rev/" + name, capability) - // update owner set in persistent store +./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 + ./there are still other owners, keep the capability around persistentStore.Set(capability.Index(), owners) } else { - // no more owners, delete the capability + ./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`: +動的関数を使用するモジュールは、app.goでScopedCapabilityKeeperを提供する必要があります。 ```golang ck := NewCapabilityKeeper(persistentKey, memoryKey) mod1Keeper := NewMod1Keeper(ck.ScopeToModule("mod1"), ....) mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....) -// other initialisation logic ... +//other initialisation logic ... -// load initial state... +//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: +「mod1」が能力を作成し、それを名前でリソース(IBCチャネルなど)に関連付けてから、それを「mod2」に渡し、後でそれを使用する状況を考えてみます。 -Module 1 would have the following code: +モジュール1には次のコードが含まれます。 ```golang capability := scopedCapabilityKeeper.NewCapability(ctx, "resourceABC") mod2Keeper.SomeFunction(ctx, capability, args...) ``` -`SomeFunction`, running in module 2, could then claim the capability: +`SomeFunction`は、モジュール2で実行され、関数を宣言できます。 ```golang func (k Mod2Keeper) SomeFunction(ctx Context, capability Capability) { k.sck.ClaimCapability(ctx, capability, "resourceABC") - // other logic... +./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: +後で、モジュール2は名前で関数を取得し、それをモジュール1に渡すことができます。モジュール1は、リソースに基づいて関数を認証します。 ```golang func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) { @@ -304,41 +304,41 @@ func (k Mod2Keeper) SomeOtherFunction(ctx Context, name string) { } ``` -Module 1 will then check that this capability key is authenticated to use the resource before allowing module 2 to use it: +モジュール2にリソースの使用を許可する前に、モジュール1は、この機能キーがリソースを使用するために認証されているかどうかを確認します。 ```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 +./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). +モジュール2がファンクションキーをモジュール3に渡すと、モジュール3はそれを宣言し、モジュール2のようにモジュール1を呼び出すことができます。 +(この場合、モジュール1、モジュール2、およびモジュール3はすべてこの機能を使用できます)。 -## 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. +-動的機能のサポート。 +-txが失敗したときに、メモリ内の永続的な「KVStore」および「MemoryStore」への書き込みを回復しながら、CapabilityKeeperがgo-mapから同じ機能ポインタを返すことを許可します。 -### 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 +-追加のゴールキーパーが必要です。 +-既存の「StoreKey」システムとの重複があります(これはスーパーセット関数であるため、将来的にマージできます)。 +-メモリストアはインデックスにマップする必要があり、実際の関数を取得するためにgoマップのキーとして使用する必要があるため、リバースマッピングでは追加レベルの間接参照が必要です。 -### Neutral +### ニュートラル -(none known) +(誰も知らない) -## References +## 参照する -- [Original discussion](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513) +-[元のディスカッション](https://github.com/cosmos/cosmos-sdk/pull/5230#discussion_r343978513) \ No newline at end of file diff --git a/docs/ja/architecture/adr-004-split-denomination-keys.md b/docs/ja/architecture/adr-004-split-denomination-keys.md index ae192c63226c..02159691bc78 100644 --- a/docs/ja/architecture/adr-004-split-denomination-keys.md +++ b/docs/ja/architecture/adr-004-split-denomination-keys.md @@ -1,54 +1,54 @@ -# ADR 004: Split Denomination Keys +# ADR 004:分割金種キー -## 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 +-2020-01-08:初期バージョン +-2020-01-09:アトリビューションアカウントの変更処理 +-2020-01-14:コメントフィードバックの更新 +-2020-01-30:実装の更新 -### 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. +許可なくIBCを使用すると、誰でも他のアカウントに任意の金額を送信できます。現在、ゼロ以外のすべての残高はアカウントとともに「sdk.Coins」構造で保存されます。これにより、アカウントが変更されるたびに多くの金種を読み込んで保存するのに費用がかかるため、サービス拒否の問題が発生する可能性があります。その他のコンテキストの場合、問題[5467](https://github.com/cosmos/cosmos-sdk/issues/5467)および[4982](https://github.com/cosmos/cosmos-sdk/issues/4982)を参照してください。 。 -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). +金種の数の制限後に預金を拒否するだけでは、悲しみのベクトルが開かれるため、機能しません。誰かがIBCを介してユーザーに無意味なコインを大量に送信し、ユーザーが実際の金種を受け取らないようにすることができます(賭けの報酬として)。 -## 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. +残高は、特定の金種の特定の口座残高へのO(1)読み取りおよび書き込みアクセスを実現するために、口座および金種に応じた口座の金種および一意のキーの下に保存する必要があります。 -### Account interface (x/auth) +### アカウントインターフェース(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. +コインの残高が増えるため、 `GetCoins()`と `SetCoins()`はアカウントインターフェースから削除されます +これで、bankモジュールに保存され、管理されます。 -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. +アトリビューションアカウントインターフェイスは、「LockedCoins」をサポートするために「SpendableCoins」に置き換わります +アカウントの残高は不要になりました。さらに、 `TrackDelegation()`はこれを受け入れるようになります +全体をロードするのではなく、既得残高で表示されるすべてのトークンのアカウント残高 +勘定残高。 -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) +### 銀行管理者(x/bank) -The following APIs will be added to the `x/bank` keeper: +次のAPIが `x/bank`キーパーに追加されます。 -- `GetAllBalances(ctx Context, addr AccAddress) Coins` -- `GetBalance(ctx Context, addr AccAddress, denom string) Coin` +-`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. +反復とアクセシビリティを促進するためにAPIを追加する場合があります +コア機能または永続性。 -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") @@ -69,52 +69,52 @@ func (k Keeper) SetBalance(ctx Context, addr AccAddress, balance Coin) error { } ``` -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. +`DelegateCoins()`と `UndelegateCoins()`は、全員をロードするように変更されます +(非)委託額に見られる金種別の口座残高。したがって、 +口座残高の変更は、金種によって行われます。 -`SubtractCoins()` and `AddCoins()` will be altered to read & write the balances -directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist). +`SubtractCoins()`と `AddCoins()`は、読み取りと書き込みのバランスに変更されます +`GetCoins()`/`SetCoins()`を呼び出す代わりに直接(もう存在しません)。 -`trackDelegation()` and `trackUndelegation()` will be altered to no longer update -account balances. +`trackDelegation()`と `trackUndelegation()`は更新されないように変更されます +勘定残高。 -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. +外部APIは、下位互換性を維持するために、アカウントの下のすべての残高をスキャンする必要があります。それ +次の状況では、これらのAPIで `GetAllBalances`の代わりに` GetBalance`と `SetBalance`を使用することをお勧めします +アカウントの残高全体が読み込まれない場合があります。 -### 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. +供給モジュールは、総供給不変量を達成するために、現在、 +すべてのアカウントをスキャンし、 `x/bank`キーパーを使用して` GetAllBalances`を呼び出し、合計します +バランスを取り、予想される総供給量と一致するかどうかを確認します。 -## 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. +-O(1)読み書き残高(金種番号について) +アカウントの1つにゼロ以外の残高があります)。これは実際の状況とは関係がないことに注意してください +必要な直接読み取りの総数ではなく、I/Oコスト。 -### 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 +-参照:https://github.com/cosmos/cosmos-sdk/issues/4982 +-参照:https://github.com/cosmos/cosmos-sdk/issues/5467 +-参照:https://github.com/cosmos/cosmos-sdk/issues/5492 \ No newline at end of file diff --git a/docs/ja/architecture/adr-006-secret-store-replacement.md b/docs/ja/architecture/adr-006-secret-store-replacement.md index 0b1d88d9e397..54468eee6a5e 100644 --- a/docs/ja/architecture/adr-006-secret-store-replacement.md +++ b/docs/ja/architecture/adr-006-secret-store-replacement.md @@ -1,54 +1,54 @@ -# ADR 006: Secret Store Replacement +# ADR 006:シークレットストレージの交換 -## Changelog +## 変更ログ -- July 29th, 2019: Initial draft -- September 11th, 2019: Work has started -- November 4th: Cosmos SDK changes merged in -- November 18th: Gaia changes merged in +-2019年7月29日:最初のドラフト +-2019年9月11日:作業が開始されました +-11月4日:CosmosSDKの変更がマージ +-11月18日:ガイアの変更がマージ -## Context +## 環境 -Currently, a Cosmos 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. +現在、Cosmos SDKアプリケーションのCLIディレクトリには、ユーザーのホームディレクトリにあるプレーンテキストデータベースに主要な資料とメタデータが格納されています。キーマテリアルはパスワードで暗号化され、bcryptハッシュアルゴリズムで保護されています。メタデータ(アドレス、公開鍵、鍵ストレージの詳細など)はプレーンテキストで提供されます。 -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. +最新のデスクトップコンピューターオペレーティングシステム(Ubuntu、Debian、MacOS、Windows)はすべて、アプリケーションが他のすべてのアプリケーションから分離された情報を保存し、データにアクセスするためにパスワードを必要とするように設計された組み込みのシークレットストレージを提供します。 -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. +LevelDBに基づく現在のKeybaseバックエンドを99デザインの[Keyring](https://github.com/99designs/keyring)に置き換えることをお勧めします。このアプリケーションは、多くのシークレットストア間で共通の抽象化と統一されたインターフェースを提供するように設計されており、99-designsアプリケーションによってAWSVaultアプリケーションによって使用されます。 -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. +Macでローカルにテストを実行するには、パスワードを複数回再入力する必要があります。 -### 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_] +-#4754シークレットストレージをキーリングシークレットストレージに切り替えます(@poldsamの元のPR)[__ CLOSED__] +-#5029 github.com/99designs/keyring-backed keystore [__ MERGED__]のサポートを追加 +-#5097キー移行コマンドの追加[__MERGED__] +-#5180キーリングをサポートするためにディスクキーストアを削除します[_PENDING_REVIEW_] +-cosmos/gaia#164キーリングをサポートするためにディスクキーストアを削除します(gaiaの変更)[_ PENDING_REVIEW_] \ No newline at end of file diff --git a/docs/ja/architecture/adr-007-specialization-groups.md b/docs/ja/architecture/adr-007-specialization-groups.md index 8055fc5a2115..eae5c37d7ec5 100644 --- a/docs/ja/architecture/adr-007-specialization-groups.md +++ b/docs/ja/architecture/adr-007-specialization-groups.md @@ -1,30 +1,30 @@ -# ADR 007: Specialization Groups +# ADR 007:スペシャライゼーショングループ -## Changelog +## 変更ログ -- 2019 Jul 31: Initial Draft +-2019年7月31日:最初のドラフト -## 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". +アイデアはもともと満足することでした +分散型コンピュータ緊急対応チーム(dCERT)を作成します。 +メンバーはガバナンスコミュニティによって選出され、職務を遂行します +緊急事態でコミュニティを調整します。 このような考え方 +「ブロックチェーンスペシャライゼーション」の概念としてさらに抽象化できます +グループ"。 -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 @@ -44,96 +44,96 @@ A specialization group can be broadly broken down into the following functions - 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. +専門グループへの会員アクセスは、幅広い範囲で実施できます。 +複数のメカニズム。 最も明白な例は +コミュニティ全体ですが、一部のシステムでは、コミュニティは許可したい場合があります +専門家グループ内で新会員を選出した会員、 +または、コミュニティが特定の職業に権限を割り当てる場合があります +このグループは、他のサードパーティグループにメンバーを任命します。 空は本当に限界です +メンバーシップアクセスを構成する方法について。 キャプチャしようとします +それらのいくつかは、「選挙人」と呼ばれる共通のインターフェースに表示される場合があります。 にとって +このADRの一部として、一般的なものをお勧めします +選挙の抽象化( `Electionator`)と基本的な +この抽象化の実装により、継続的な選択が可能になります +プロチームのメンバー。 ``` golang -// The Electionator abstraction covers the concept space for -// a wide variety of election kinds. +//The Electionator abstraction covers the concept space for +//a wide variety of election kinds. type Electionator interface { - // is the election object accepting votes. + ./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. + ./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 + ./here lies all functionality to authenticate and execute changes for + ./when a member accepts being elected AcceptElection(sdk.AccAddress) - // Register a revoker object + ./Register a revoker object RegisterRevoker(Revoker) - // No more revokers may be registered after this function is called + ./No more revokers may be registered after this function is called SealRevokers() - // register hooks to call when an election actions occur + ./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 + ./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. + ./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. +//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. +//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. +//When revoking the "cause" bytes may be arbitrarily marshalled into evidence, +//memos, etc. type Revoker interface { - RevokeName() string // identifier for this revoker type + 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. +既存のコード間にいくつかの共通点があるかもしれません +`x/governance`と選挙に必要な機能。 この一般的な +関数は、実現プロセスで抽象化する必要があります。 それぞれ同じ +クライアントCLI/REST関数を実装するための投票を抽象化する必要があります +複数の選挙に再利用できます。 -The specialization group abstraction firstly extends the `Electionator` -but also further defines traits of the group. +専門グループの抽象化は、最初に `Electionator`を拡張します +しかし、それはまた、グループの特徴をさらに定義します。 ``` golang type SpecializationGroup interface { @@ -141,37 +141,37 @@ type SpecializationGroup interface { GetName() string GetDescription() string - // general soft contract the group is expected - // to fulfill with the greater community + ./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 + ./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. + ./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 +-ブロックチェーンの専門化能力を向上させる +-`x/gov/`の抽象化を改善して、特殊化グループで使用できるようにします -### Negative +### ネガティブ -- could be used to increase centralization within a community +-コミュニティ内の集中化を強化するために使用できます -### Neutral +### ニュートラル -## References +## 参照 -- [dCERT ADR](./adr-008-dCERT-group.md) +-[dCERT ADR](./adr-008-dCERT-group.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-008-dCERT-group.md b/docs/ja/architecture/adr-008-dCERT-group.md index a6f0dfb198c8..b1ad63f2f02f 100644 --- a/docs/ja/architecture/adr-008-dCERT-group.md +++ b/docs/ja/architecture/adr-008-dCERT-group.md @@ -1,171 +1,171 @@ -# 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) +# ADR 008:分散コンピューター緊急対応チーム(dCERT)チーム + +## 変更ログ + +-2019年7月31日:最初のドラフト + +## 環境 + +機密情報の取り扱いに関与する当事者の数を減らすため +緊急情報の場合は、作成することをお勧めします +分散型コンピュータ緊急対応チームと呼ばれる専門チーム +(dCERT)。当初、このグループの役割はコーディネーターとしてでした。 +バリデーターなど、ブロックチェーンコミュニティのさまざまな参加者間 +脆弱性ハンターと開発者。危機の時には、dCERTチームは +さまざまな利害関係者の意見を収集して開発者に転送する +ソフトウェアのパッチを積極的に設計しているため、機密情報 +公開する必要はなく、コミュニティからの意見によっては +まだ利益があります。 + +さらに、dCERTグループに特別な特権が提案されました:容量 +特定のメッセージパスを「中断」(別名、一時的に無効)します。ノート +この特権は、ガバナンスを通じてグローバルに有効化/無効化する必要があります +この権限を無効にして後で有効にできるようにするためのパラメータ +dCERTグループが確立された後、パラメータを変更することが提案されます。 + +コミュニティが将来的に役割を拡大したいと思うかもしれないことは予見可能です +「事前承認」などのdCERTの責任 +完全なコミュニティの前に、コミュニティに代わってセキュリティ更新を実行します +その前に、広範な投票、機密情報が開示されます +リアルタイムネットワークの脆弱性にパッチが適用されています。 + +## 決定 + +dCERTグループに「SpecializationGroup」の実装を含めることをお勧めします +[ADR 007](./adr-007-specialization-groups.md)で定義されています。これには以下が含まれます +実装: + +-継続的な投票 +-ソフト契約違反のために削減 +-ソフト契約違反による会員資格の取り消し +-dCERTチーム全体を緊急に解散する(悪意のある共謀など) +-コミュニティプールまたは他の方法から決定された補償手当 + ガバナンス + +システムには、次の新しいパラメータが必要です。 + +-各dCERTメンバーの通常の手当 +-dCERTメンバーの最大数 +-各dCERTメンバーは、スラッシュ可能なトークンを誓約する必要があります +-特定のメンバーの定足数を一時停止します +-dCERTチームを解散するための提案された賭け +-dCERTメンバーの移行の安定期間 +-開回路dCERT許可が有効になっている + +これらのパラメータは、たとえばパラメータキーパーを介して実装されることが期待されます +このガバナンスはいつでもそれらを変更する可能性があります。 + +### 連続投票選挙人 + +`Electionator`オブジェクトは、継続的な投票として実装されます。 +次の仕様: + +-すべての委任アドレスは、いつでも投票を送信して更新できます + dCERTチームの優先代表。 +-最初の選択肢は、アドレスを任意に分割できることを意味します(例:50％ + ジョン、サリーは25％、キャロルは25％) +-dCERTグループに新しいメンバーを追加するには、メンバーは + 承認したトランザクションを送信して受け入れます。これは現時点で有効です。 + 彼らの入場はまだ確認されていません。 + -dCERTグループにメンバーが追加されると、シリアル番号が割り当てられます。 + メンバーがdCERTグループを離れて再入場した場合、新しいシリアル番号 + 手配しました。 +-優先表現の最大数を制御するアドレスは + dCERTグループに参加する資格があります(最大_dCERTメンバーの最大数_)。 + dCERTグループが満員で、新しいメンバーが許可されている場合、既存のメンバーは + 投票数が最も少ないdCERTメンバーは、dCERTグループから追い出されます。 + -dCERTグループが満員であるが、競合する候補者が分割されている場合 + 既存のdCERTメンバーと同じ投票数、既存の + メンバーは自分のステータスを維持する必要があります。 + -誰かが追い出されなければならないが、2人が追い出されるという分割された状況 + 投票数が最も少ない住所の投票数は同じですが、 + シリアル番号が最小のアドレスがその位置を維持します。 +-オプションで、安定化期間を含めて削減します + dCERTメンバーのテールメンバーの「フリップ」。安定している場合 + 次の理由でメンバーが追い出された場合は、0より大きい期間を指定してください + サポートが不十分な場合、どのメンバーが + 交換する他のメンバー。このアイテムがキューにある場合、新しいアイテムはありません + 同じdCERTメンバーを蹴ることができます。エントリが + 安定化期間の期間、新しいメンバーがインスタンス化され、古いメンバーがインスタンス化されます + メンバーが蹴った。 + +### 杭打ち/カット + +dCERTグループのすべてのメンバーは、維持するために_特に_住宅ローントークンを保持する必要があります +dCERTメンバーシップ。これらのトークンは、競合他社が直接抵当に入れることができます +dCERTメンバーまたは第三者が誠意を持って(チェーン上で取得することは許可されていません) +そうすることの利点)。この住宅ローンのメカニズムは、既存のグローバルを使用する必要があります +ネットワークバリデーターのセキュリティのために約束されたトークンのアンバンドリング時間。 dCERTメンバー +_onlyは、ここで必要なトークンを誓約している場合に限り、メンバーになることができます +機構。これらのトークンが関連付けられていない場合、dCERTメンバーは +グループを自動的にキックアウトします。 + +ソフト契約の違反により特定のdCERTメンバーを削減する必要があります +各メンバーのサイズに基づいてガバナンスによって実装されます +違反。このプロセスは、dCERTメンバーの停止になると予想されます +これは、ガバナンスによって削減される前に、dCERTチームによって実装されます。 + +dCERTグループのメンバーシップの停止は、投票プロセスを通じて行われます。 +dCERTチームのメンバー。この停止が発生した後、ガバナンス +提案がない場合は、dCERTのメンバーシップを減らす提案を提出する必要があります +取り消されたメンバーがバインド解除を完了したときに承認を取得します +トークン、トークンはもはや誓約されておらず、減らすことはできません。 + +さらに、共謀的で悪意のある緊急事態が発生した場合 +dCERTチーム、コミュニティにはdCERT全体を解散する能力が必要です +グループ化し、完全にカットする場合があります。これは、特別な新しい +提案タイプ(一般的なガバナンス提案として実施)は廃止されます +提案が終了するまでのdCERTチームの機能。この +特別な提案の種類もかなりの利害関係を必要とする場合があります +プロポーザルの作成者が悪意のある場合は、カットされる可能性があります。大きな理由 +提案が行われると、賭けを要求する必要があります。 +dCERTグループがメッセージルーティングを停止できるようにする +一時停止。これは、そのような提案を作成する悪意のあるアクターが +次に、dCERTグループがない場合、この期間中にエラーが悪用される可能性があります +使用可能なメッセージルーティングを閉じる機能。 + +### dCERTメンバートランザクション + +アクティブなdCERTメンバー + +-dCERTグループの説明を変更します +-壊れたメッセージルーティング +-dCERTメンバーを一時停止するための投票。 + +ここでの回路遮断とは、メッセージのグループを無効にする機能を指します。 +たとえば、これは「すべての誓約委任メッセージを無効にする」、または +「すべての配布メッセージを無効にする」。これは検証で行うことができます +CheckTx時のメッセージルーティング( +`baseapp/baseapp.go`)。 + +「中断のない」回路は、ハードフォークのアップグレード中にのみ発生すると予想されます +これは、メッセージルーティングをリアルタイムチェーンでオンにできないことを意味します +必須。 + +また、ガバナンスの投票に問題がある場合(例: +複数回投票する能力)その後、ガバナンスは破られ、 +このメカニズムを使用して停止し、バリデーターによって次のように設定されます +ソフトウェアのパッチバージョンへの調整とハードフォークのアップグレード。 +ガバナンスを再度有効化(および修復)します。 dCERTグループがこの特権を悪用した場合 +それらはすべて厳しくカットする必要があります。 + +## 状態 + +>提案 + +## 結果 + +### ポジティブ + +-緊急時に調整する必要のある当事者の数を減らすことが可能です +-機密情報が悪意のある第三者に漏洩する可能性を減らします + +### ネガティブ + +-集中化のリスク + +### ニュートラル + +## 参照 + + [スペシャライゼーショングループADR](./adr-007-specialization-groups.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-009-evidence-module.md b/docs/ja/architecture/adr-009-evidence-module.md index f6f47170c9f1..ca45d9acac1d 100644 --- a/docs/ja/architecture/adr-009-evidence-module.md +++ b/docs/ja/architecture/adr-009-evidence-module.md @@ -1,55 +1,55 @@ -# ADR 009: Evidence Module +# ADR 009:証拠モジュール -## Changelog +## 変更ログ -- 2019 July 31: Initial draft -- 2019 October 24: Initial implementation +-2019年7月31日:最初のドラフト +-2019年10月24日:初期実装 -## 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. +安全性が高く、堅牢で相互運用可能なブロックチェーンの構築をサポートするため +アプリケーション、CosmosSDKがメカニズムを公開することは非常に重要です。 +証拠を提出、評価、検証して、コンセンサスに達することができます +あいまいさ(二重投票)など、検証者による不正行為に対する罰則、 +バインドされていない場合の署名、署名が正しくない場合の状態遷移(将来)など。 +さらに、このメカニズムはすべての人に効果的です +[IBC](https://github.com/cosmos/ics/blob/master/ibc/2_IBC_ARCHITECTURE.md)または +機能をサポートするためのクロスチェーン検証プロトコルの実装 +住宅ローンチェーンからメインチェーンに不適切な動作を渡します +あいまいなバリデーターをカットできるようにチェーンします。 -## Decision +## 決定 -We will implement an evidence module in the Cosmos SDK supporting the following -functionality: +次の機能をサポートする証拠モジュールをCosmosSDKに実装します +特徴: -- 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. +まず、 `Evidence`インターフェースタイプを定義します。 `x/evidence`モジュールを実装できます +独自のタイプは、多くのチェーンで使用できます(例: `CounterFactualEvidence`)。 +さらに、他のモジュールも同様の方法で独自の「証拠」タイプを実装できます。 +スケーラブルな方法でのガバナンス。特定のことに注意を払うことが重要です +`Evidence`インターフェースを実装するタイプには、たとえば任意のフィールドが含まれる場合があります +違反時間。 `Evidence`タイプは可能な限り柔軟なままにしておく必要があります。 -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. +`x/evidence`モジュールに証拠を提出するときは、特定のタイプを提供する必要があります +検証者のコンセンサスアドレス。これは `x/slashing`で認識されている必要があります +モジュール(違反が有効であると仮定)、違反の高さ +発生し、検証者のパワーは違反が発生したのと同じ高さになります。 ```go type Evidence interface { @@ -59,24 +59,24 @@ type Evidence interface { Hash() HexBytes ValidateBasic() error - // The consensus address of the malicious validator at time of infraction +./The consensus address of the malicious validator at time of infraction GetConsensusAddress() ConsAddress - // Height at which the infraction occurred +./Height at which the infraction occurred GetHeight() int64 - // The total power of the malicious validator at time of infraction +./The total power of the malicious validator at time of infraction GetValidatorPower() int64 - // The total validator set power at time of infraction +./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. +各「証拠」タイプは、特定の一意のルートにマッピングされ、登録されている必要があります +`x/evidence`モジュール。 これは、 `Router`の実装を通じて実現されます。 ```go type Router interface { @@ -87,16 +87,16 @@ type Router interface { } ``` -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. +`x/evidence`モジュールを正常にルーティングした後、` Evidence`タイプ +`Handler`によって渡されます。 この `ハンドラー`はすべてを実行する責任があります +証拠が有効であることを確認するために必要な対応するビジネスロジック。 存在 +さらに、 `ハンドラー`は必要なカットと潜在的な投獄を実行することができます。 +スラッシュスコアは通常、何らかの形の静的関数によって生成されるため、 +`Handler`にそうすることを許可することは、最大の柔軟性を提供します。 例はできます +`k * Estate.GetValidatorPower()`です。ここで、 `k`は制御されたチェーンパラメータです。 +ガバナンスを通じて。 `Evidence`タイプは、すべての外部情報を提供する必要があります +これは、「処理プログラム」が必要な状態遷移を実行するために必要です。 +エラーが返されない場合、「証拠」は有効であると見なされます。 ```go type Handler func(Context, Evidence) error @@ -104,8 +104,8 @@ 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`. +`Evidence`は、内部の` MsgSubmitEvidence`メッセージタイプを介して送信されます +これは、 `x/evidence`モジュールの` SubmitEvidence`によって処理されます。 ```go type MsgSubmitEvidence struct { @@ -117,17 +117,17 @@ func handleMsgSubmitEvidence(ctx Context, keeper Keeper, msg MsgSubmitEvidence) return err.Result() } - // emit events... +./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. +`x/evidence`モジュールのキーパーは、` Evidence`をと接続する責任があります +モジュールのルーターであり、対応する `Handler`を呼び出します。 +バリデーターをカットして投獄します。 成功後、提出された証拠は保持されます。 ```go func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { @@ -141,13 +141,13 @@ func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { } ``` -### 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. +最後に、 `x/evidence`モジュールの作成状態を表す必要があります。 この +モジュールには、送信されたすべての有効な違反と必要なパラメーターのリストのみが必要です。 +モジュールは提出された証拠を処理する必要があります。 `x/証拠` +モジュールは、最も必要なローカル証拠のタイプを自然に定義してルーティングします +ペナルティ定数を減らす必要があるかもしれません。 ```go type GenesisState struct { @@ -156,27 +156,26 @@ type GenesisState struct { } ``` -## 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) +-[ICS](https://github.com/cosmos/ics) +-[IBCアーキテクチャ](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_ARCHITECTURE.md) +-[テンダーミントフォークの説明責任](https://github.com/tendermint/spec/blob/7b3138e69490f410768d9b1ffc7a17abc23ea397/spec/consensus/fork-accountability.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-010-modular-antehandler.md b/docs/ja/architecture/adr-010-modular-antehandler.md index c0be2c4d8e64..a917c33c51fd 100644 --- a/docs/ja/architecture/adr-010-modular-antehandler.md +++ b/docs/ja/architecture/adr-010-modular-antehandler.md @@ -1,94 +1,94 @@ -# ADR 010: Modular AnteHandler +# ADR 010:モジュラーAnteHandler -## Changelog +## 変更ログ -- 2019 Aug 31: Initial draft -- 2021 Sep 14: Superseded by ADR-045 +-2019年8月31日:最初のドラフト +-2021年9月14日:ADR-045に置き換えられました -## Status +## 状態 -SUPERSEDED by ADR-045 +ADR-045に置き換えられました -## 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. +現在のAnteHandlerの設計では、ユーザーは `x/auth`で提供されるデフォルトのAnteHandlerを使用するか、独自のAnteHandlerを最初から作成できます。理想的には、AnteHandler関数は複数のモジュラー関数に分割され、カスタムante-functionとリンクできるため、ユーザーはカスタム動作を実装するときに共通のantehandlerロジックを書き直す必要がありません。 -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. +たとえば、ユーザーがカスタム署名検証ロジックを実装したいとします。現在のコードベースでは、ユーザーは、主に同じコードのほとんどを再実装し、baseappで独自のカスタムモノリシックアンティハンドラーを設定することにより、独自のアンティハンドラーを最初から作成する必要があります。代わりに、ユーザーが必要に応じてカスタム動作を指定できるようにし、可能な限りモジュール化された柔軟な方法で、それらをデフォルトのアンティハンドラー機能と組み合わせたいと考えています。 -## Proposals +## 提案 -### Per-Module AnteHandler +### モジュールごとの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. +1つの方法は、[ModuleManager](https://godoc.org/github.com/cosmos/cosmos-sdk/types/module)を使用し、カスタムのアンティハンドラロジックが必要な場合は、各モジュールに独自のアンティハンドラを実装させることです。次に、ModuleManagerは、BeginBlockersおよびEndBlockersのシーケンスと同じ方法でAnteHandlerシーケンスで渡すことができます。 ModuleManagerはAnteHandler関数を返します。この関数は、txを受け取り、指定された順序で各モジュールの `AnteHandle`を実行します。モジュールマネージャーのAnteHandlerは、baseappのAnteHandlerに設定されます。 -Pros: +アドバンテージ: -1. Simple to implement -2. Utilizes the existing ModuleManager architecture +1.実装が簡単 +2.既存のModuleManagerアーキテクチャを活用する -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. +1.粒度を改善しましたが、それでも各モジュールよりも細かい粒度を取得することはできません。たとえば、authの `AnteHandle`関数がメモと署名の検証を担当している場合、ユーザーはauthの残り​​の` AnteHandle`関数を保持したまま署名チェック機能を交換することはできません。 +2.モジュールAnteHandlerが次々に実行されます。 1つのAnteHandlerは、別のAnteHandlerをラップまたは「装飾」することはできません。 -### 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: +[Weave Project](https://github.com/iov-one/weave)AnteHandlerのモジュール性は、デコレータパターンを使用して実現されています。インターフェイスのデザインは次のとおりです。 ```go -// Decorator wraps a Handler to provide common functionality -// like authentication, or fee-handling, to many Handlers +//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 Cosmos 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. +各デコレータは、モジュラーCosmos SDK前処理関数のように機能しますが、「next」パラメータを受け取ることができます。これは、別のデコレータまたはハンドラ(次のパラメータを受け取らない)の場合があります。 これらのデコレータは一緒にチェーンすることができ、1つのデコレータがチェーン内の前のデコレータの「次の」パラメータとして渡されます。 チェーンはルーターで終わります。ルーターはtxを受け入れ、適切なmsgハンドラーにルーティングできます。 -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: +このアプローチの主な利点の1つは、デコレータがその内部ロジックを次のチェッカー/デリバラにラップできることです。 ブレードデコレータは次のことを実行できます。 ```go -// Example Decorator's Deliver function +//Example Decorator's Deliver function func (example Decorator) Deliver(ctx Context, store KVStore, tx Tx, next Deliverer) { - // Do some pre-processing logic + ./Do some pre-processing logic res, err := next.Deliver(ctx, store, tx) - // Do some post-processing logic given the result and error + ./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. +1. Weaveデコレータは、チェーン内の次のデコレータ/ハンドラをラップできます。場合によっては、前処理機能と後処理機能が役立つことがあります。 +2.上記のソリューションでは実現できないネストされたモジュラー構造を提供すると同時に、上記のソリューションのような線形の1つずつの構造を可能にします。 -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. +1.一見すると、特定の `ctx`、` store`、および `tx`のデコレータが実行された後に発生するステータスの更新を理解するのは困難です。デコレータは、関数本体でネストされたデコレータをいくつでも呼び出すことができ、各デコレータは、チェーン内の次のデコレータを呼び出す前に、前処理と後処理を実行できます。したがって、デコレータが何をしているのかを理解するには、チェーン内の他のデコレータも何をしているのかを理解する必要があります。これは理解するのが非常に難しくなる可能性があります。線形の1つずつの方法はそれほど強力ではありませんが、推論する方が簡単な場合があります。 -### 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. +Weaveメソッドの利点は、デコレータが非常に簡潔になり、チェーン化されたときに最大限のカスタマイズを実現できることです。ただし、ネスト構造は非常に複雑になる可能性があるため、推論が困難になります。 -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. +もう1つのアプローチは、ModuleManagerメソッドからの1つずつの順序を維持しながら、AnteHandler関数を厳密にスコープされた「マイクロ関数」に分割することです。 -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. +次に、これらのマイクロ関数をリンクして、次々に実行する方法を用意できます。モジュールは複数のアンティマイクロ関数を定義でき、次にこれらのマイクロ関数のデフォルトの推奨順序を実装するためのデフォルトのモジュールごとのAnteHandlerも提供します。 -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). +ユーザーは、ModuleManagerを使用するだけでAnteHandlerを簡単に注文できます。 ModuleManagerは、AnteHandlerのリストを受け取り、提供されたリストの順序で各AnteHandlerを実行する単一のAnteHandlerを返します。ユーザーが各モジュールのデフォルトの順序に満足している場合は、各モジュールのアンティハンドラーのリストを提供するだけです(BeginBlockerおよび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. +これは、ユーザーがカスタムマイクロ関数を作成しないことを選択したAnteHandlerの例です。 -##### Cosmos SDK code +##### CosmosSDKコード ```go -// Chains together a list of AnteHandler micro-functions that get run one after the other. -// Returned AnteHandler will abort on first error. +//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 { @@ -103,41 +103,41 @@ func Chainer(order []AnteHandler) AnteHandler { ``` ```go -// AnteHandler micro-function to verify signatures +//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 + ./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 +//AnteHandler micro-function to validate memo func ValidateMemo(ctx Context, tx Tx, simulate bool) (newCtx Context, err error) { - // validate memo + ./validate memo } -// Auth defines its own default ante-handler by chaining its micro-functions in a recommended order +//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 +//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 + ./Deduct fees from tx + ./Abort if insufficient funds in account to pay for fees } -// Distribution micro-function to check if fees > mempool parameter +//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 + ./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 +//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 + ./other fields AnteHandlerOrder []AnteHandler } @@ -149,61 +149,61 @@ func (mm ModuleManager) GetAnteHandler() AnteHandler { ##### 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 +//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 +//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 + ./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 +//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 +1.アンティ機能を可能な限りモジュール化できるようにします。 +2.前処理プログラムをカスタマイズする必要がないユーザーの場合、前処理プログラムの動作モードは、ModuleManagerのBeginBlockおよびEndBlockの動作モードとほぼ同じです。 +3.それでも理解しやすい -Cons: +欠点: -1. Cannot wrap antehandlers with decorators like you can with Weave. +1.アンティハンドラをWeaveのようなデコレータでラップすることはできません。 -### Simple Decorators +### シンプルなデコレータ -This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the Cosmos 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`. +このアプローチは、Cosmos SDKの主要な変更を最小限に抑え、簡素化を最小限に抑えながら、Weaveのデコレータ設計からインスピレーションを得ています。 Weaveデコレータと同様に、このメソッドを使用すると、AnteDecoratorで次のAnteHandlerをラップして、結果を前処理および後処理できます。これは、AnteHandlerが戻った後、デコレータが事前に遅延/クリーンアップしていくつかの設定を実行できるため便利です。 Weaveデコレータとは異なり、これらの `AnteDecorator`関数は、ハンドラ実行パス全体ではなく、AnteHandlerのみをラップできます。さまざまなモジュールのデコレータに「tx」の認証/検証を実行させたいため、これは意図的なものです。ただし、デコレータが `MsgHandler`の結果をラップして変更できるようにする必要はありません。 -In addition, this approach will not break any core Cosmos 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. +さらに、このメソッドはコアCosmos SDKAPIを壊しません。 AnteHandlerの概念を維持し、baseappで単一のAnteHandlerを設定しているため、デコレータは、さらにカスタマイズが必要なユーザーのための単なる追加のメソッドです。モジュールのAPI(つまり、 `x/auth`)はこのメソッドによって中断される可能性がありますが、コアAPIは変更されません。 -Allow Decorator interface that can be chained together to create a Cosmos SDK AnteHandler. +デコレータインターフェイスをチェーン接続して、Cosmos SDKAnteHandlerを作成できるようにします。 -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 the Cosmos SDK provided decorators in the order they wish. +これにより、ユーザーはAnteHandlerを独自に実装するか、基本アプリケーションで設定するかを選択できます。または、デコレータパターンを使用して、カスタムデコレータをCosmosSDKが提供するデコレータに必要な順序でリンクできます。 ```go -// An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler +//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. +//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) { @@ -216,75 +216,75 @@ func ChainAnteDecorators(chain ...AnteDecorator) AnteHandler { } ``` -#### Example Code +#### サンプルコード -Define AnteDecorator functions +AnteDecorator関数を定義します ```go -// Setup GasMeter, catch OutOfGasPanic and handle appropriately +//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 + ./recover from OutOfGas panic and handle appropriately } return next(ctx, tx, simulate) } -// Signature Verification decorator. Verify Signatures and move on +//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 + ./verify sigs. Return error if invalid - // call next antehandler if sigs ok + ./call next antehandler if sigs ok return next(ctx, tx, simulate) } -// User-defined Decorator. Can choose to pre- and post-process on AnteHandler +//User-defined Decorator. Can choose to pre- and post-process on AnteHandler type UserDefinedDecorator struct{ - // custom fields + ./custom fields } func (udd UserDefinedDecorator) AnteHandle(ctx Context, tx Tx, simulate bool, next AnteHandler) (newCtx Context, err error) { - // pre-processing logic + ./pre-processing logic ctx, err = next(ctx, tx, simulate) - // post-processing logic + ./post-processing logic } ``` -Link AnteDecorators to create a final AnteHandler. Set this AnteHandler in baseapp. +AnteDecoratorsをリンクして、最終的なAnteHandlerを作成します。 このAnteHandlerをbaseappで設定します。 ```go -// Create final antehandler by chaining the decorators together +//Create final antehandler by chaining the decorators together antehandler := ChainAnteDecorators(NewSetUpContextDecorator(), NewSigVerifyDecorator(), NewUserDefinedDecorator()) -// Set chained Antehandler in the baseapp +//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. +1. Weaveデザインと同様に、デコレータが次のAnteHandlerを前処理および後処理できるようにします。 +2. baseappAPIを壊す必要はありません。 ユーザーが必要に応じて、単一のAnteHandlerを設定することもできます。 -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. +1.デコレータパターンは、理解しにくい深いネスト構造を持っている可能性があります。これは、 `ChainAnteDecorators`関数にデコレータの順序を明示的にリストすることで軽減できます。 +2.ModuleManagerデザインを使用しないでください。 これはBeginBlocker/EndBlockerに使用されているため、提案はデザインパターンと矛盾しているようです。 -## 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) +-[#4572](https://github.com/cosmos/cosmos-sdk/issues/4572):モジュラーAnteHandlerの問題 +-[#4582](https://github.com/cosmos/cosmos-sdk/pull/4583):モジュールごとのAnteHandlerアプローチの初期実装 +-[ウィーブデコレータコード](https://github.com/iov-one/weave/blob/master/handler.go#L35) +-[織りデザインビデオ](https://vimeo.com/showcase/6189877) \ No newline at end of file diff --git a/docs/ja/architecture/adr-011-generalize-genesis-accounts.md b/docs/ja/architecture/adr-011-generalize-genesis-accounts.md index 60964f95b90c..1f6258e81149 100644 --- a/docs/ja/architecture/adr-011-generalize-genesis-accounts.md +++ b/docs/ja/architecture/adr-011-generalize-genesis-accounts.md @@ -1,47 +1,47 @@ -# ADR 011: Generalize Genesis Accounts +# ADR 011:ジェネシスアカウントを宣伝する -## Changelog +## 変更ログ -- 2019-08-30: initial draft +-2019-08-30:最初のドラフト -## Context +## 環境 -Currently, the Cosmos 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`). +現在、Cosmos SDKはカスタムアカウントタイプを許可しています。`auth`キーパーは、その `Account`インターフェイスを満たすすべてのタイプを保存します。ただし、 `auth`はジェネシスファイルからのアカウントのエクスポートまたはロードを処理しません。これは、4つの特定のアカウントタイプ(` BaseAccount`、 `ContinuousVestingAccount`、` DelayedVestingAccount`、および `ModuleAccount)のみを処理する` genaccounts`によって行われます。 `)。 -Projects desiring to use custom accounts (say custom vesting accounts) need to fork and modify `genaccounts`. +カスタムアカウント(カスタムアトリビューションアカウントなど)を使用するプロジェクトは、「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. +全体として、「genaccounts」の「GenesisAccount」タイプに変換する代わりに、アミノを使用してすべてのアカウント(インターフェースタイプ)を直接グループ化します(キャンセル)。そうすることで `genaccounts`のコードのほとんどが削除されるので、` genaccounts`を `auth`にマージします。グループ化されたアカウントは、「auth」の作成状態で保存されます。 -Detailed changes: +詳細な変更: -### 1) (Un)Marshal accounts directly using amino +### 1)(Un)マーシャルアカウントはアミノを直接使用します -The `auth` module's `GenesisState` gains a new field `Accounts`. Note these aren't of type `exported.Account` for reasons outlined in section 3. +`auth`モジュールの` GenesisState`は、新しいフィールド `Accounts`を取得しました。セクション3で概説されている理由により、これらはタイプ `exported.Account`ではないことに注意してください。 ```go -// GenesisState - all auth state that must be provided at genesis +//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. +これで、 `auth`と定義されたパラメータの` InitGenesis`と `ExportGenesis`(非)マーシャルアカウントが作成されました。 ```go -// InitGenesis - Init store state from genesis data +//InitGenesis - Init store state from genesis data func InitGenesis(ctx sdk.Context, ak AccountKeeper, data GenesisState) { ak.SetParams(ctx, data.Params) - // load the accounts + ./load the accounts for _, a := range data.Accounts { - acc := ak.NewAccount(ctx, a) // set account number + acc := ak.NewAccount(ctx, a)//set account number ak.SetAccount(ctx, acc) } } -// ExportGenesis returns a GenesisState for a given context and keeper +//ExportGenesis returns a GenesisState for a given context and keeper func ExportGenesis(ctx sdk.Context, ak AccountKeeper) GenesisState { params := ak.GetParams(ctx) @@ -56,16 +56,16 @@ func ExportGenesis(ctx sdk.Context, ak AccountKeeper) GenesisState { } ``` -### 2) Register custom account types on the `auth` codec +### 2) `auth`コーデックにカスタムアカウントタイプを登録します -The `auth` codec must have all custom account types registered to marshal them. We will follow the pattern established in `gov` for proposals. +`auth`コーデックは、それらをグループ化するためにすべてのカスタムアカウントタイプを登録する必要があります。 「政府」で確立された提案モデルに従います。 -An example custom account definition: +カスタムアカウント定義の例: ```go import authtypes "github.com/cosmos/cosmos-sdk/x/auth/types" -// Register the module account type with the auth module codec so it can decode module accounts stored in a genesis file +//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{}, "cosmos-sdk/ModuleAccount") } @@ -74,29 +74,29 @@ type ModuleAccount struct { ... ``` -The `auth` codec definition: +`auth`コーデックの定義: ```go var ModuleCdc *codec.LegacyAmino func init() { ModuleCdc = codec.NewLegacyAmino() - // register module msg's and Account interface + ./register module msg's and Account interface ... - // leave the codec unsealed + ./leave the codec unsealed } -// RegisterAccountTypeCodec registers an external account type defined in another module for the internal ModuleCdc. +//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 +### 3)カスタムアカウントタイプの作成検証 -Modules implement a `ValidateGenesis` method. As `auth` does not know of account implementations, accounts will need to validate themselves. +モジュールは `ValidateGenesis`メソッドを実装します。 「auth」はアカウントの実現を知らないため、アカウントを自己確認する必要があります。 -We will unmarshal accounts into a `GenesisAccount` interface that includes a `Validate` method. +アカウントを、Validateメソッドを含むGenesisAccountインターフェースにグループ解除します。 ```go type GenesisAccount interface { @@ -105,27 +105,27 @@ type GenesisAccount interface { } ``` -Then the `auth` `ValidateGenesis` function becomes: +次に、 `auth``ValidateGenesis`関数は次のようになります。 ```go -// ValidateGenesis performs basic validation of auth genesis data returning an -// error for any failed validation criteria. +//ValidateGenesis performs basic validation of auth genesis data returning an +//error for any failed validation criteria. func ValidateGenesis(data GenesisState) error { - // Validate params + ./Validate params ... - // Validate accounts + ./Validate accounts addrMap := make(map[string]bool, len(data.Accounts)) for _, acc := range data.Accounts { - // check for duplicated 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 + ./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()) } @@ -135,36 +135,36 @@ func ValidateGenesis(data GenesisState) error { } ``` -### 4) Move add-genesis-account cli to `auth` +### 4)add-genesis-accountcliを `auth`に移動します -The `genaccounts` module contains a cli command to add base or vesting accounts to a genesis file. +`genaccounts`モジュールには、ジェネシスファイルに基本アカウントまたは帰属アカウントを追加するためのcliコマンドが含まれています。 -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. +これは `auth`に移動されます。 カスタムアカウントを追加するための独自のコマンドを作成するのはプロジェクトに任せます。 `gov`に似た拡張可能なCLIハンドラーを作成することは可能ですが、この2番目のユースケースでは、複雑さはそれだけの価値はありません。 -### 5) Update module and vesting accounts +### 5)モジュールとアトリビューションアカウントを更新する -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 +-`auth`のコーデックでのタイプ登録(上記のように) +-「アカウント」の特定のタイプごとに「検証」メソッド -## Status +## 状態 -Proposed +提案 -## Consequences +## 結果 -### Positive +### ポジティブ -- custom accounts can be used without needing to fork `genaccounts` -- reduction in lines of code +-カスタムアカウントを使用するために `genaccounts`をフォークする必要はありません +-コードの行数を減らす -### 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` +-`genaccounts`モジュールはもう存在しません +-ジェネシスファイルのアカウントは、「genaccounts」モジュールではなく、「auth」の「accounts」の下に保存されます。 +-`add-genesis-account`cliコマンドが `auth`になりました -## References +## 参照 \ No newline at end of file diff --git a/docs/ja/architecture/adr-012-state-accessors.md b/docs/ja/architecture/adr-012-state-accessors.md index 8b2a9b3f430f..844b24f31dd9 100644 --- a/docs/ja/architecture/adr-012-state-accessors.md +++ b/docs/ja/architecture/adr-012-state-accessors.md @@ -1,30 +1,30 @@ -# ADR 012: State Accessors +# ADR 012:ステータスアクセサー -## Changelog +## 変更ログ -- 2019 Sep 04: Initial draft +-2019年9月4日:最初のドラフト -## Context +## 環境 -Cosmos 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. +Cosmos SDKモジュールは現在、 `KVStore`インターフェースと` Codec`を使用してそれぞれの状態にアクセスしています。でも +これは、モジュール開発者に多くの自由を提供し、モジュール化が困難であり、UX +平凡。 -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. +まず、モジュールが状態にアクセスしようとするたびに、値をマーシャリングし、設定または取得する必要があります +値を付け、最後にグループ化を解除します。通常、これは `Keeper.GetXXX`関数と` Keeper.SetXXX`関数を宣言することによって行われます。 +それらは反復的であり、維持するのが困難です。 -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. +次に、これにより、オブジェクト機能の定理であるアクセスとの整合がより困難になります。 +状態は「StoreKey」として定義され、Merkleツリー全体へのフルアクセスを提供するため、モジュールはできません +特定のキーと値のペア(またはキーと値のペアのセット)のアクセス権を別のモジュールに安全に送信します。 -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). +最後に、getter/setter関数は、モジュールの `Keeper`のメソッドとして定義されているため、レビュー担当者は +状態の任意の部分にアクセスする関数を見るときは、マークルツリー空間全体を考慮する必要があります。 +関数がアクセスしている状態の部分(アクセスしていない部分)を静的に知る方法はありません。 -## Decision +## 決断 -We will define a type named `Value`: +「値」と呼ばれるタイプを定義します。 ```go type Value struct { @@ -33,10 +33,10 @@ type Value struct { } ``` -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. +`Value` 用作状态中键值对的引用，其中 `Value.m` 定义键值 +它将访问的空间和 `Value.key` 定义引用的确切键。 -We will define a type named `Mapping`: +我们将定义一个名为 `Mapping` 的类型: ```go type Mapping struct { @@ -46,73 +46,73 @@ type Mapping struct { } ``` -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. +`Mapping` 用作状态中键值空间的引用，其中 `Mapping.storeKey` 定义 +IAVL(子)树和`Mapping.prefix` 定义了可选的子空间前缀。 -We will define the following core methods for the `Value` type: +我们将为 `Value` 类型定义以下核心方法: ```go -// Get and unmarshal stored data, noop if not exists, panic if cannot unmarshal +//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 +//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 +//Get stored data as raw byte slice func (Value) GetRaw(ctx Context) []byte {} -// Marshal and set a raw value +//Marshal and set a raw value func (Value) Set(ctx Context, o interface{}) {} -// Check if a raw value exists +//Check if a raw value exists func (Value) Exists(ctx Context) bool {} -// Delete a raw value value +//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 +//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 +//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 +//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 +//Get stored data as raw byte slice func (Mapping) GetRaw(ctx Context, key []byte) []byte {} -// Marshal and set a raw value +//Marshal and set a raw value func (Mapping) Set(ctx Context, key []byte, o interface{}) {} -// Check if a raw value exists +//Check if a raw value exists func (Mapping) Has(ctx Context, key []byte) bool {} -// Delete a raw value value +//Delete a raw value value func (Mapping) Delete(ctx Context, key []byte) {} ``` -Each method of the `Mapping` type that is passed the arguments `ctx`, `key`, and `args...` will proxy -the call to `Mapping.Value(key)` with arguments `ctx` and `args...`. +パラメータ `ctx`、` key`、および `args ...`を渡す `Mapping`タイプの各メソッドはプロキシします +パラメータctxおよびargsを使用したMapping.Value(key)の呼び出し... -In addition, we will define and provide a common set of types derived from the `Value` type: +さらに、 `Value`型から派生したジェネリック型のセットを定義して提供します。 ```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. +エンコード方式が異なる場合は、コアメソッドの `o`パラメーターを入力し、` ptr`パラメーターを入力します。 +コアメソッドの明示的な戻り型に置き換えられました。 -Finally, we will define a family of types derived from the `Mapping` type: +最後に、マッピングタイプから派生した一連のタイプを定義します。 ```go type Indexer struct { @@ -121,35 +121,36 @@ type Indexer struct { } ``` -Where the `key` argument in core method is typed. +コアメソッドの「key」パラメータの場所を入力します。 -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 +-状態アクセスは、パラメータとして `Context`を使用して関数を呼び出す場合にのみ発生します +-アクセサータイプの構造体は、構造体によって参照される状態へのアクセスのみを許可し、他のアクセス許可は許可しません +-マーシャリング/アンマーシャリングはコアメソッドで暗黙的に発生します -## 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) +-[#4554](https://github.com/cosmos/cosmos-sdk/issues/4554) \ No newline at end of file diff --git a/docs/ja/architecture/adr-013-metrics.md b/docs/ja/architecture/adr-013-metrics.md index cf27d89648ce..f35aedc9b91b 100644 --- a/docs/ja/architecture/adr-013-metrics.md +++ b/docs/ja/architecture/adr-013-metrics.md @@ -1,34 +1,34 @@ -# ADR 013: Observability +# ADR 013:可観測性 -## Changelog +## 変更ログ -- 20-01-2020: Initial Draft +-20-01-2020:最初のドラフト -## 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. +テレメトリは、アプリケーションが実行していることと、アプリケーションがどのように進行しているかをデバッグおよび理解するために不可欠です。 +パフォーマンス。私たちの目標は、CosmosSDKのモジュールおよびその他のコア部分からのインジケーターを公開することです。 -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. +さらに、私たちの目標は、オペレーターが選択できる複数の構成可能な受信機をサポートすることです。 +デフォルトでは、テレメトリが有効になっている場合、アプリはメトリクスを追跡して公開する必要があります +メモリに保存されます。オペレーターは追加の受信機を有効にすることを選択できます。サポートするのは +[Prometheus](https://prometheus.io/)これで、実際の戦闘でテストされたため、セットアップとオープンソースが簡単になりました。 +そして、豊富なエコシステムツールがあります。 -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. +また、インジケーターをCosmos SDKに最もシームレスな方法で統合して、 +インジケーターは、あまり摩擦することなく、自由に追加または削除できます。このために使用します +[go-metrics](https://github.com/armon/go-metrics)ライブラリ。 -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. +最後に、オペレーターはテレメトリと特定の構成オプションを有効にできます。有効になっている場合、インジケーター +`/metrics？format = {text | prometheus}`を介してAPIサーバーを介して公開されます。 -## Decision +## 決定 -We will add an additional configuration block to `app.toml` that defines telemetry settings: +テレメトリ設定を定義するために、 `app.toml`に追加の構成ブロックを追加します。 ```toml ############################################################################### @@ -58,23 +58,23 @@ enable-service-label = {{ .Telemetry.EnableServiceLabel }} 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. +指定された構成では、メモリ内とPrometheusの2つのシンクが可能です。 `メトリクス`を作成します +オペレーターのすべてのブートストラップを実行するタイプであるため、メトリックのキャプチャーはシームレスになります。 ```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. +//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. +//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: @@ -92,16 +92,16 @@ func (m *Metrics) Gather(format string) (GatherResponse, error) { } ``` -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. +さらに、「メトリクス」を使用すると、任意の時点で現在のメトリクスのセットを収集できます。 一 +オペレーターは、信号SIGUSR1を送信して、フォーマットされた標識を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. +アプリケーションの起動およびビルドフェーズで、「Telemetry.Enabled」が「true」の場合、 +APIサーバーは、 `Metrics`オブジェクトへの参照インスタンスを作成し、メトリックを登録します +対応する処理手順。 ```go func (s *Server) Start(cfg config.Config) error { - // ... +./... if cfg.Telemetry.Enabled { m, err := telemetry.New(cfg.Telemetry) @@ -113,7 +113,7 @@ func (s *Server) Start(cfg config.Config) error { s.registerMetrics() } - // ... +./... } func (s *Server) registerMetrics() { @@ -134,24 +134,24 @@ func (s *Server) registerMetrics() { } ``` -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/ja/architecture/adr-014-proportional-slashing.md b/docs/ja/architecture/adr-014-proportional-slashing.md index f7a063930253..7d296a50336b 100644 --- a/docs/ja/architecture/adr-014-proportional-slashing.md +++ b/docs/ja/architecture/adr-014-proportional-slashing.md @@ -1,55 +1,54 @@ -# ADR 14: Proportional Slashing +# ADR 14:比率の削減 -## 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 +-2019-10-15:最初のドラフト +-2020-05-25:関連するルートカットを削除しました +-2020-07-01:線形関数の代わりにSカーブ関数を含めるように更新 -## 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 +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 +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. +ここで、誰かが10％のバリデーターを2つの5％のバリデーターに分割し、それぞれがミスを犯した場合、それらはすべて同じ時間枠でミスを犯し、すべて10％削減されます。 -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. +ただし、実際には、誤ったエクイティの量とエクイティの割合を減らすことの間の線形関係を望まない場合があります。特に、エクイティのわずか5％の二重署名は、実際にはセキュリティに大きな脅威をもたらすことはなく、エクイティの30％のエラーは、テンダーミントのセキュリティのポイントに非常に近いため、明らかに大幅に削減する価値があります。脅かされています。線形関係では、2つの間に6倍のギャップが必要になり、ネットワークへのリスクにははるかに大きな違いがあります。この問題を解決するには、Sカーブ(公式には[論理関数](https://en.wikipedia.org/wiki/Logistic_function))を使用することをお勧めします。 Sカーブは、必要な標準を非常によく捉えています。それらは、小さな値の減少係数を最小化することを可能にし、その後、もたらされるリスクが重要になる特定のしきい値ポイントの近くで急速に成長します。 +パラメータ化する#### -#### Parameterization +これには、パラメーター化された論理関数が必要です。これをパラメータ化する方法をよく理解している。 4つのパラメータがあります。 -This requires parameterizing a logistic function. It is very well understood how to parameterize this. It has four parameters: +1)最小削減係数 +2)最大削減係数 +3)S曲線の変曲点(基本的にSを置きたい場所) +4)S曲線の成長率(Sの伸び度) -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 occurred within the last `unbonding period`. For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`. +スラッシュモジュールでは、最近のすべてのスラッシュイベントを追跡するために2つのキューを追加します。ダブルシンボル障害の場合、「最近のスラッシュ」は、最後の「バインド解除期間」中に発生したスラッシュとして定義されます。活気エラーについては、「最近のスラッシュ」を最後の「投獄期間」中に発生したスラッシュと定義します。 ``` type SlashEvent struct { @@ -59,27 +58,26 @@ type SlashEvent struct { } ``` -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. +新しいスラッシュが表示されるたびに、失敗したバリデーターの投票率が0であるSlashEvent構造が作成されます。バリデーターには、同じキューに同時に複数のSlashEventがあります。 -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 occurred, so that we slash the right amount of tokens). We then set `SlashEvent.SlashedSoFar` amount to `NewSlashPercent`. +次に、キュー内のすべてのSlashEventを繰り返し、それらのValidatorVotingPercentを追加して、上記で紹介した「ルート合計の2乗」式を使用して、キュー内のすべてのバリデーターを減らす新しいパーセンテージを計算します。 -## Status +`NewSlashPercent`を取得したら、キュー内のすべての` SlashEvent`を再度トラバースします。SlashEventの `NewSlashPercent> SlashedSoFar`の場合、` staking.Slash(slashEvent.Address、slashEvent.Power、Math.Min(Math .Max(minSlashPercent、NewSlashPercent-SlashedSoFar)、maxSlashPercent) `(正しい数のトークンをカットできるように、スラッシュが発生する前にバリデーターのパワーを渡します)。次に、`SlashEvent。SlashedSoFar`を `と同等に設定します。 NewSlashPercent`。 +## 状態 -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. +-現在の実装よりも高価な計算。チェーンの「最近のカット」に関するより多くのデータを保存します。 \ No newline at end of file diff --git a/docs/ja/architecture/adr-016-validator-consensus-key-rotation.md b/docs/ja/architecture/adr-016-validator-consensus-key-rotation.md index 6cc1e5ce7a20..a4f9bfdb05a3 100644 --- a/docs/ja/architecture/adr-016-validator-consensus-key-rotation.md +++ b/docs/ja/architecture/adr-016-validator-consensus-key-rotation.md @@ -1,58 +1,58 @@ -# ADR 016: Validator Consensus Key Rotation +# ADR 016:ベリファイアコンセンサスキーローテーション -## Changelog +## 変更ログ -- 2019 Oct 23: Initial draft -- 2019 Nov 28: Add key rotation fee +-2019年10月23日:最初のドラフト +-2019年11月28日:キーローテーション料金を引き上げます -## 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. +より安全なベリファイアキー管理戦略(https://github.com/tendermint/tendermint/issues/1136など)のために、ベリファイアコンセンサスキーローテーション機能が長い間議論され、要求されてきました。したがって、CosmosSDKでバリデーターコンセンサスキーローテーションの最も単純な実装の1つを使用することをお勧めします。 -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. +Tendermintにはコンセンサスキーとベリファイアオペレータキーの間のマッピング情報がないため、Tendermintのコンセンサスロジックを更新する必要はありません。つまり、Tendermintの観点からは、ベリファイアのコンセンサスキーローテーションは交換別のコンセンサスキー。 -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. +さらに、このADRには、最も単純な形式のコンセンサスキーローテーションのみが含まれ、複数のコンセンサスキーの概念は考慮されていないことに注意してください。複数のコンセンサスキーのこの概念は、TendermintおよびCosmosSDKの長期的な目標であり続けます。 -## 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. +-新しいランダムコンセンサスキーを作成します。 +-「MsgRotateConsPubKey」を使用して、新しいコンセンサスキーがバリデーターオペレーターと結合され、バリデーターオペレーターキーからの署名があることを宣言するトランザクションを作成してブロードキャストします。 +-チェーンのキーマッピングステータスが更新された直後は、古いコンセンサスキーをコンセンサスに参加させることはできません。 +-検証のために新しいコンセンサスキーの使用を開始します。 +-`MsgRotateConsPubKey`がブロックチェーンに送信されると、HSMとKMSを使用するバリデーターは、 `h`の高さの後に新しいローテーションキーを使用するようにHSMのコンセンサスキーを更新する必要があります。 -### 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) +-コンセンサスキーマッピング情報管理戦略 + -各キーマッピングの変更の履歴をkvstoreに保存します。 + -ステートマシンは、最新のバインド解除期間中に、特定のバリデーターオペレーターとペアになっている任意の高さの対応するコンセンサスキーを検索できます。 + -ステートマシンは、バインド解除期間を超えて履歴マッピング情報を必要としません。 +-LCDおよびIBCに関連するキーローテーションコスト + -LCDとIBCは、電源が頻繁に変更されると、フロー/計算の負担が発生します + -現在のテンダーミントの設計では、コンセンサスキーの回転は、LCDまたはIBCの観点からは電力の変化と見なされます + -したがって、不必要な頻繁なキーローテーション動作を最小限に抑えるために、最新のバインド解除期間中の最大ローテーション数を制限し、指数関数的に増加したローテーション料金も適用しました +-制限 + -バリデーターは、スパムを防ぐために、バインド解除期間中、コンセンサスキーを `MaxConsPubKeyRotations`より長くローテーションすることはできません。 + -パラメータはガバナンスによって決定され、ジェネシスファイルに保存されます。 +-キーローテーション料金 + -検証者は、コンセンサスキーをローテーションするために `KeyRotationFee`を支払う必要があります。これは、次のように計算されます。 + -`KeyRotationFee` =(max( `VotingPowerPercentage` * 100、1)*` InitialKeyRotationFee`)* 2 ^(最新のバインド解除中の `ConsPubKeyRotationHistory`の回転数) +-証​​拠モジュール + -証​​拠モジュールは、スラッシュキーパーから任意の高さの対応するコンセンサスキーを検索できるため、特定の高さに使用するコンセンサスキーを決定できます。 +-abci.ValidatorUpdate + -Tendermintは、ABCI通信( `ValidatorUpdate`)を介してコンセンサスキーを変更できるようになりました。 + -ベリファイアのコンセンサスキーの更新は、パワーをゼロに変更して新しいものを作成し、古いものを削除することで実行できます。 + -したがって、この機能を実現するために、テンダーミントのコードベースを変更する必要さえないことを願っています。 +-`stakeing`モジュールの新しい作成パラメータ + -`MaxConsPubKeyRotations`:バリデーターが最新のバインド解除期間中に実行できる回転の最大数。デフォルト値の10を使用することをお勧めします(11番目のキーローテーションは拒否されます) + -`InitialKeyRotationFee`:直近のバインド解除期間中にキーローテーションが発生しなかった場合の初期キーローテーション料金。デフォルト値の1atomを使用することをお勧めします(最近のバインド解除期間中の最初のキーローテーションのコストは1atomです) -### 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 +1.ベリファイアは、新しいコンセンサスキーペアを生成します。 +2.バリデーターは、オペレーターキーと新しいConsPubKeyを使用して、 `MsgRotateConsPubKey`txを生成して署名します。 ```go type MsgRotateConsPubKey struct { @@ -61,16 +61,16 @@ Also, it should be noted that this ADR includes only the simplest form of consen } ``` -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 +3.`handleMsgRotateConsPubKey`は `MsgRotateConsPubKey`を取得し、emitsイベントで` RotateConsPubKey`を呼び出します +4.`RotateConsPubKey` + -`NewPubKey`が `ValidatorsByConsAddr`に複製されていないかどうかを確認します + -`ConsPubKeyRotationHistory`を繰り返して、バリデーターがパラメーター `MaxConsPubKeyRotations`を超えていないかどうかを確認します。 + -署名アカウントに `KeyRotationFee`を支払うのに十分な残高があるかどうかを確認します + -コミュニティ基金に `KeyRotationFee`を支払う + -`validator.ConsPubKey`の `NewPubKey`をオーバーライドします + -古い `ValidatorByConsAddr`を削除します + -`NewPubKey`の `SetValidatorByConsAddr` + -回転を追跡するために `ConsPubKeyRotationHistory`を追加しました ```go type ConsPubKeyRotationHistory struct { @@ -81,7 +81,7 @@ Also, it should be noted that this ADR includes only the simplest form of consen } ``` -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 +5. `ApplyAndReturnValidatorSetUpdates`は、` ConsPubKeyRotationHistory`と `ConsPubKeyRotationHistory.RotatedHeight == ctx.BlockHeight()`があるかどうかをチェックします。 ```go abci.ValidatorUpdate{ @@ -95,31 +95,30 @@ Also, it should be noted that this ADR includes only the simplest form of consen } ``` -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` +6.`AllocateTokens`の `previousVotes`の反復ロジックでは、` previousVote`は `OldConsPubKey`を使用して` ConsPubKeyRotationHistory`と一致し、トークン配布のバリデーターを置き換えます +7.`ValidatorSigningInfo`と `ValidatorMissedBlockBitArray`を` OldConsPubKey`から `NewConsPubKey`に移行します -- Note : All above features shall be implemented in `staking` module. +-注:上記のすべての関数は、 `stakeing`モジュールに実装する必要があります。 -## 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) +-検証者は、セキュリティポリシーを向上させるために、コンセンサスキーを即座にまたは定期的にローテーションできます +-バリデーターが古いコンセンサスキーを破棄するため、リモート攻撃に対するセキュリティが向上しました(https://nearprotocol.com/blog/long-range-attacks-and-a-new-fork-choice-rule) -### 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 +-テンダーミントリポジトリ:https://github.com/tendermint/tendermint/issues/1136 +-cosmos-sdkリポジトリ:https://github.com/cosmos/cosmos-sdk/issues/5231 +-複数のコンセンサスキーについて:https://github.com/tendermint/tendermint/issues/1758#issuecomment-545291698 \ No newline at end of file diff --git a/docs/ja/architecture/adr-017-historical-header-module.md b/docs/ja/architecture/adr-017-historical-header-module.md index 8c5a1f6cd65e..8139a7a05497 100644 --- a/docs/ja/architecture/adr-017-historical-header-module.md +++ b/docs/ja/architecture/adr-017-historical-header-module.md @@ -1,61 +1,61 @@ -# ADR 17: Historical Header Module +# ADR 17:ヒストリカルタイトルモジュール -## Changelog +## 変更ログ -- 26 November 2019: Start of first version -- 2 December 2019: Final draft of first version +-2019年11月26日:最初のバージョンが始まります +-2019年12月2日:初版の最終ドラフト -## Context +## 環境 -In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the Cosmos 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. +Cosmos SDKが[IBC仕様](https://github.com/cosmos/ics)を実装するには、Cosmos SDKのモジュールが最新のコンセンサス状態(バリデーターセットとコミットメントルート)を次のようにイントロスペクトできる必要があります。ハンドシェイク中にチェックする必要がある証明これらの値は他のチェーンにあります。 -## 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. +アプリケーションは、最新の `n`ヘッダーを永続ストレージに保存する必要があります。 最初は、このストアは現在のMerklisedストアである可能性があります。 証明が必要ないため、Merklised以外のストレージを将来使用できます。 -The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`: +アプリケーションは、 `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 + 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 + ..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 Cosmos 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`送信されたヘッダーを、` Keeper`の `GetHistoricalInfo`関数を介してCosmosSDKモジュールによるクエリに使用できるようにする必要があります。これは、新しいモジュールに実装することも、既存のモジュール(おそらく、 `x .stakeing`または` 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. +`n`はパラメータ保存パラメータとして設定できます。この場合、` ParameterChangeProposal`sで変更できますが、 `n`を追加すると、保存された情報に追いつくためにいくつかのブロックが必要になります。 -## Status +## 状態 -Proposed. +提案。 -## Consequences +## 結果 -Implementation of this ADR will require changes to the Cosmos SDK. It will not require changes to Tendermint. +このADRを実装するには、CosmosSDKを変更する必要があります。 Tendermintを変更する必要はありません。 -### Positive +### ポジティブ -- Easy retrieval of headers & state roots for recent past heights by modules anywhere in the Cosmos SDK. -- No RPC calls to Tendermint required. -- No ABCI alterations required. +-Cosmos SDKの任意の場所にあるモジュールを介して、最近の過去の高さのヘッダーと状態ルートを簡単に取得できます。 +-TendermintにRPC呼び出しを行う必要はありません。 +-ABCIの変更は必要ありません。 -### 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. +-Tendermintとアプリケーションの `n`ヘッダーデータをコピーします(追加のディスク使用量)-長期的には、[this](https://github.com/tendermint/tendermint/issues/4210)のような方法が望ましい場合があります。 -### Neutral +### ニュートラル -(none known) +(不明) -## References +## 参照 -- [ICS 2: "Consensus state introspection"](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection) +-[ICS 2:「コンセンサス状態のイントロスペクション」](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics#consensus-state-introspection) \ No newline at end of file diff --git a/docs/ja/architecture/adr-018-extendable-voting-period.md b/docs/ja/architecture/adr-018-extendable-voting-period.md index edd392b5e739..6ab91eba29c4 100644 --- a/docs/ja/architecture/adr-018-extendable-voting-period.md +++ b/docs/ja/architecture/adr-018-extendable-voting-period.md @@ -1,66 +1,66 @@ -# ADR 18: Extendable Voting Periods +# ADR 18:延長可能な投票期間 -## Changelog +## 変更ログ -- 1 January 2020: Start of first version +-2020年1月1日:最初のバージョンが始まります -## 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. +ただし、最初の投票期間の長さを決定するための質問をプッシュするだけなので、投票期間の長さを決定するための完全な2番目の投票プロセスを作成することは避けたいと思います。 -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`. +-現在のgovパラメータ `VotingPeriod`は` MinVotingPeriod`パラメータに置き換えられます。これは、すべてのガバナンス提案の投票期間を開始するデフォルトの投票期間です。 +-「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. +「MsgExtendVotingPeriod」と呼ばれる新しい「Msg」タイプがあります。これは、提案の投票期間中に任意の質権アカウントから送信できます。これにより、送信者は「MaxVotingPeriodExtension *送信者の議決権のシェア」を通じて一方的に投票期間を延長することができます。各アドレスは、プロポーザルごとに1回だけ `MsgExtendVotingPeriod`を呼び出すことができます。 -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`. +たとえば、「MaxVotingPeriodExtension」が100日に設定されている場合、議決権の1％を持っている人は誰でも、議決権を1日延長できます。議決権の33％にメッセージが送信された場合、議決権の期間は33日延長されます。したがって、絶対に全員が投票期間を延長することを選択した場合、絶対最大投票期間は `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つあります。投票中の再承認/バインド解除の処理方法。株式保有者の5％が `MsgExtendVotingPeriod`を呼び出してからバインドを解除した場合、投票期間はさらに5日間短縮されますか？これは、決定を下すのにどれくらいの時間がかかるかを人々に誤って考えさせるため、良くありません。このため、投票期間を短縮するのではなく、延長するように設計したいと考えています。このため、現在の延期額は、いつでも延期された投票の最も高い割合に基づいています。これは例によって最もよく説明されます: -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. +1. 4％と3％の議決権を持つ2人のスタッカーが延長に投票すると仮定します。投票期間は7日間延長されます。 +2.現在、スタッカーの3％が、投票期間が終了する前にバインドを解除することを決定しています。投票期間はまだ7日間に延長されています。 +3.ここで、2％の議決権を持つ別の利害関係者が、議決権の期間を延長することを決定したとします。現在、拡張機能を選択するためのアクティブな投票権の6％があります。議決権は7日間残ります。 +4. 4番目の利害関係者の10％が延期することを選択した場合、延期を希望するアクティブな議決権の合計は16％になります。投票期間は16日間に延長されます。 -### 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) +-[アイデアが最初に生まれたコスモスフォーラムの投稿](https://forum.cosmos.network/t/proposal-draft-reduce-governance-voting-period-to-7-days/3032/9) \ No newline at end of file diff --git a/docs/ja/architecture/adr-019-protobuf-state-encoding.md b/docs/ja/architecture/adr-019-protobuf-state-encoding.md index 657e5b386e12..0c54e9fb0d21 100644 --- a/docs/ja/architecture/adr-019-protobuf-state-encoding.md +++ b/docs/ja/architecture/adr-019-protobuf-state-encoding.md @@ -1,109 +1,109 @@ -# ADR 019: Protocol Buffer State Encoding +# ADR 019:プロトコルバッファステータスコード -## 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.Codec` interface. -- 2021 Feb 24: Remove mentions of `HybridCodec`, which has been abandoned in [#6843](https://github.com/cosmos/cosmos-sdk/pull/6843). +-2020年2月15日:最初のドラフト +-2020年2月24日:インターフェースフィールドを使用したメッセージの処理を更新 +-2020年4月27日:インターフェースの `oneof`の使用法を` Any`に変換します +-2020年5月15日:「cosmos_proto」拡張機能とアミノ互換性について説明する +-2020年12月4日:「MarshalAny」と「UnmarshalAny」を「codec.Codec」インターフェースに移動して名前を変更します。 +-2021年2月24日:[#6843](https://github.com/cosmos/cosmos-sdk/pull/6843)で放棄された「HybridCodec」の言及を削除します。 -## 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. +現在、Cosmos SDKはバイナリに[go-amino](https://github.com/tendermint/go-amino/)を使用しています +また、JSONオブジェクトエンコーディングは、ワイヤーを介して論理オブジェクトと永続オブジェクトの間に同等性をもたらします。 -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はオブジェクトエンコーディング仕様です。これは、インターフェイス拡張機能を備えたProto3のサブセットです。 +>サポート。詳細については、[Proto3仕様](https://developers.google.com/protocol-buffers/docs/proto3)を参照してください。 +> Proto3に関する情報に関しては、Aminoはほぼ互換性があります(Proto2は互換性がありません)。 +>> +> Aminoエンコーディングプロトコルの目標は、論理オブジェクトと永続オブジェクトにパリティを導入することです。 -Amino also aims to have the following goals (not a complete list): +Aminoは、次の目標の達成も目​​指しています(完全なリストではありません)。 -- 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. +しかし、アミノはこれらの目標を完全には達成しておらず、完全に満足しているわけでもありません。 +CosmosSDKの非常に柔軟なクロスランゲージおよびマルチクライアント互換のエンコーディングプロトコル要件。 +言い換えれば、Aminoは、クロスオブジェクトのシリアル化をサポートする上で大きな問題点であることが証明されています。 +クライアントはさまざまな言語で書かれており、実際のフォールバックはほとんどありません。 +互換性とアップグレード性。さらに、分析とさまざまなベンチマークテストを通じて、Aminoは +これは、Cosmos SDK 1 <.sup>の非常に大きなパフォーマンスのボトルネックであることが判明しました。これは +主にシミュレーションパフォーマンスとアプリケーショントランザクションスループットに反映されます。 -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. +Aminoからの移行は、状態とクライアントのコーディングという2つのアプローチと見なす必要があることに注意してください。 +このADRは、CosmosSDKステートマシンでの状態のシリアル化に焦点を当てています。対応するADRは +クライアントコーディングを解決するために使用されます。 -## 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 two concrete implementations of the `Marshaler` interface: `AminoCodec` and `ProtoCodec`. +シリアル化には[ProtocolBuffers](https://developers.google.com/protocol-buffers)を使用します +Cosmos SDKで構造化データを永続化すると同時に、 +Aminoのアプリケーションを引き続き使用したいと考えています。モジュールを更新することにより、このメカニズムを提供します +特定のAminoコーデックではなく、コーデックインターフェイス `Marshaler`を受け入れます。さらに、Cosmos SDK +`Marshaler`インターフェースの2つの具体的な実装が提供されます:` AminoCodec`と `ProtoCodec`。 -- `AminoCodec`: Uses Amino for both binary and JSON encoding. -- `ProtoCodec`: Uses Protobuf for both binary and JSON encoding. +-`AminoCodec`:バイナリおよびJSONエンコーディングにAminoを使用します。 +-`ProtoCodec`:バイナリおよびJSONエンコーディングにProtobufを使用します。 -Modules will use whichever codec that is instantiated in the app. By default, the Cosmos SDK's `simapp` -instantiates a `ProtoCodec` as the concrete implementation of `Marshaler`, inside the `MakeTestEncodingConfig` -function. This can be easily overwritten by app developers if they so desire. +モジュールは、アプリケーションでインスタンス化されたコーデックを使用します。デフォルトでは、CosmosSDKの `simapp` +`Marshaler`の具体的な実装として、` MakeTestEncodingConfig`で `ProtoCodec`をインスタンス化します +特徴。必要に応じて、これはアプリケーション開発者が簡単に上書きできます。 -The ultimate goal will be to replace Amino JSON encoding with Protobuf encoding and thus have -modules accept and/or extend `ProtoCodec`. Until then, Amino JSON is still provided for legacy use-cases. -A handful of places in the Cosmos SDK still have Amino JSON hardcoded, such as the Legacy API REST endpoints -and the `x/params` store. They are planned to be converted to Protobuf in a gradual manner. +最終的な目標は、AminoJSONエンコーディングをProtobufエンコーディングに置き換えることです。 +モジュールは `ProtoCodec`を受け入れたり拡張したりします。それまでは、AminoJSONはレガシーユースケースで引き続き利用できます。 +Cosmos SDKのいくつかの場所は、Legacy APIRESTエンドポイントなどのAminoJSONを使用してハードコーディングされています +そして `x .params`ストレージ。彼らは徐々にProtobufに変換することを計画しています。 -### 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 `ProtoCodec`. This migration is simple as things will just work as-is. +インターフェイスモジュール、Protobufパスを処理およびシリアル化できる必要はありません +移行は非常に簡単です。これらのモジュールは、既存のタイプを単純に移行するためのものです +Protobufを特定のAminoコーデックでエンコードして永続化し、管理者に受け入れさせます +`Marshaler`は` ProtoCodec`になります。物事はそのまま実行されるため、この移行は簡単です。 -Note, any business logic that needs to encode primitive types like `bool` or `int64` should use -[gogoprotobuf](https://github.com/gogo/protobuf) Value types. +基本型(「bool」や「int64」など)をエンコードする必要があるビジネスロジックを使用する必要があることに注意してください +[gogoprotobuf](https://github.com/gogo/protobuf)値のタイプ。 -Example: +例: ```go ts, err := gogotypes.TimestampProto(completionTime) if err != nil { - // ... + ..... } bz := cdc.MustMarshal(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. +ただし、モジュールの目的と設計は大きく異なる可能性があるため、モジュールの機能をサポートする必要があります +インターフェイス( `Account`や` Content`など)をコーディングして使用する機能。 これらのモジュールの場合、 +`Marshaler`を拡張するには、独自のコーデックインターフェイスを定義する必要があります。 これらの特定のインターフェースは一意です +モジュールに、必要なインターフェースをシリアル化する方法を知っているメソッドコントラクトが含まれます。 -Example: +例: ```go -// x/auth/types/codec.go +/.x/auth/types/codec.go type Codec interface { codec.Codec @@ -116,104 +116,104 @@ type Codec interface { } ``` -### 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 Cosmos 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: +### `Any`を使用してインターフェースをエンコードします + +通常、モジュールレベルの.protoファイルは、インターフェイスをエンコードするメッセージを定義する必要があります +[`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto)を使用します。 +[拡張ディスカッション]後(https://github.com/cosmos/cosmos-sdk/issues/6030)、 +これは、アプリケーションレベルの「oneof」の推奨される代替手段として選択されました。 +オリジナルのprotobufデザインと同じように。 「Any」の引数は次のようになります +次のように要約します。 + +* `Any`は、よりシンプルで一貫性のあるクライアントユーザーエクスペリエンスを提供します +アプリケーションレベルの `oneof`よりも多くの調整されたインターフェースが必要 +アプリケーションを慎重にクロスします。一般的なトランザクションを作成する +`oneof`署名ライブラリの使用は面倒であり、重要なロジックが必要になる場合があります +各チェーンの再実装 +* `Any`は` oneof`よりもヒューマンエラーに対して耐性があります +* `Any`は通常、モジュールとアプリケーションに実装する方が簡単です + +「Any」を使用することへの主な反対意見は、その余分なスペースを中心に展開します +そして、可能なパフォーマンスのオーバーヘッド。処理スペースのオーバーヘッド +将来の永続層の圧縮とパフォーマンスへの影響 +小さいかもしれません。したがって、 `Any`を使用しないことは時期尚早の最適化のようです。 +ユーザーエクスペリエンスをより高いレベルの懸念事項と見なします。 + +Cosmos SDKは、説明されている「コーデック」インターフェイスを採用することを決定したため、注意してください +上記では、アプリケーションは引き続き `oneof`を使用してステータスとトランザクションをエンコードすることを選択できます +ただし、これは推奨される方法ではありません。アプリケーションが `oneof`の使用を選択した場合 +「any」の代わりに、クライアントアプリケーションとの互換性が失われる可能性があります +複数のチェーンをサポートします。したがって、開発者は慎重に検討する必要があります +彼らは、時期尚早の最適化やエンドユーザーの可能性についてより懸念しています +そしてクライアント開発者のUX。 + +### `Any`の安全な使用 + +デフォルトでは、[gogoprotobufは `Any`を実装します](https://godoc.org/github.com/gogo/protobuf/types) +[グローバルタイプ登録](https://github.com/gogo/protobuf/blob/master/proto/properties.go#L540)を使用します +「Any」にパックされた値を具象にデコードします +タイプに移動します。これにより、悪意のあるモジュールが存在する脆弱性が発生します +グローバルprotobufレジストリを使用して、依存関係ツリーにタイプを登録できます +そして、参照されるトランザクションをロードしてマーシャリング解除します +これは `type_url`フィールドにあります。 + +これを防ぐために、「Any」をデコードするための型登録メカニズムを導入しました +`InterfaceRegistry`インターフェースを介して値を具象型に変換します +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 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 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. +ホワイトリストであることに加えて、InterfaceRegistryは次のように使用することもできます +クライアントインターフェイスを満たす特定のタイプのリストを伝達します。 -In .proto files: +.protoファイル内: -* 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` +*インターフェースを受け入れるフィールドには、 `cosmos_proto.accepts_interface`の注釈を付ける必要があります +`protoName`と同じ完全修飾名を使用して、` InterfaceRegistry.RegisterInterface`に渡します +*インターフェースの実装には `cosmos_proto.implements_interface`の注釈を付ける必要があります +`protoName`と同じ完全修飾名を使用して、` InterfaceRegistry.RegisterInterface`に渡します -In the future, `protoName`, `cosmos_proto.accepts_interface`, `cosmos_proto.implements_interface` -may be used via code generation, reflection &/or static linting. +将来的には、 `protoName`、` cosmos_proto.accepts_interface`、 `cosmos_proto.implements_interface` +これは、コード生成、リフレクション、および/または静的リンティングを通じて使用できます。 -The same struct that implements `InterfaceRegistry` will also implement an -interface `InterfaceUnpacker` to be used for unpacking `Any`s: +`InterfaceRegistry`を実装する同じ構造は、 +インターフェイス `InterfaceUnpacker`は、` Any`を解凍するために使用されます。 ```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 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`の使用法は標準のprotobufから逸脱しないことに注意してください +`Any`の使用法、それはただのためです +golangの使用法。 -`InterfaceRegistry` will be a member of `ProtoCodec` -described above. In order for modules to register interface types, app modules -can optionally implement the following interface: +`InterfaceRegistry`は` ProtoCodec`のメンバーになります +上記のように。 モジュールがインターフェースタイプを登録するために、アプリケーションモジュール +次のインターフェースを実装することを選択できます。 ```go type InterfaceModule interface { @@ -221,17 +221,17 @@ type InterfaceModule interface { } ``` -The module manager will include a method to call `RegisterInterfaceTypes` on -every module that implements it in order to populate the `InterfaceRegistry`. +モジュールマネージャーには、 `RegisterInterfaceTypes`を呼び出すメソッドが含まれます +それを実装するすべてのモジュールは、 `InterfaceRegistry`にデータを入力します。 -### Using `Any` to encode state +### `Any`を使用して状態をエンコードします -The Cosmos SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization. +Cosmos SDKは、サポートメソッド `MarshalInterface`と` UnmarshalInterface`を提供して、インターフェイスタイプを `Any`にラップする複雑さを隠し、簡単にシリアル化できるようにします。 ```go import "github.com/cosmos/cosmos-sdk/codec" -// note: eviexported.Evidence is an interface type +/.note: eviexported.Evidence is an interface type func MarshalEvidence(cdc codec.BinaryCodec, e eviexported.Evidence) ([]byte, error) { return cdc.MarshalInterface(e) } @@ -243,14 +243,14 @@ func UnmarshalEvidence(cdc codec.BinaryCodec, bz []byte) (eviexported.Evidence, } ``` -### Using `Any` in `sdk.Msg`s +### `sdk.Msg`sで` Any`を使用する -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: +同様の概念が、インターフェースフィールドを含むメッセージにも当てはまります。 +たとえば、 `MsgSubmitEvidence`を次のように定義できます。ここで` Evidence`は +インターフェース: ```protobuf -// x/evidence/types/types.proto +/.x/evidence/types/types.proto message MsgSubmitEvidence { bytes submitter = 1 @@ -261,17 +261,17 @@ message MsgSubmitEvidence { } ``` -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. +`Any`から証拠を抽出するには、引用する必要があることに注意してください +`インターフェース登録`。 メソッド内の証拠を参照するために、例えば +`ValidateBasic`は` InterfaceRegistry`を知らないはずです。 +逆シリアル化して解凍するための `UnpackInterfaces`ステージを導入します +インターフェースは必要になる前にあります。 -### 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: +解凍と逆シリアル化を実装するための `UnpackInterfaces`ステージ +`Any`でラップされたインターフェースが必要になる前に、インターフェースを作成します +`sdk.Msg`sおよびその他のタイプを実装できます。 ```go type UnpackInterfacesMessage interface { @@ -279,26 +279,26 @@ type UnpackInterfacesMessage interface { } ``` -We also introduce a private `cachedValue interface{}` field onto the `Any` -struct itself with a public getter `GetCachedValue() interface{}`. +また、 `Any`にプライベート` cachedValue interface {} `フィールドを導入しました +パブリックゲッター `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. +`UnpackInterfaces`メソッドは、メッセージの逆シリアル化中に呼び出されます +`Unmarshal`にあり、` Any`にカプセル化されているインターフェイス値はすべてデコードされます +そして、将来の参照のためにそれを `cachedValue`に保存します。 -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. +その後、解凍されたインターフェイス値を任意のコードで安全に使用できます +`InterfaceRegistry`がわからない +そして、メッセージは、キャッシュされた値をに変換するための簡単なゲッターを紹介することができます +正しいインターフェイスタイプ。 -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. +これには、 `Any`値のアンマーシャリングが1回だけ発生するという追加の利点があります +値が読み取られるたびではなく、最初の逆シリアル化中。 また、 +Any値が初めてパックされたとき(例: +`NewMsgSubmitEvidence`)を使用して、元のインターフェイス値をキャッシュし、 +もう一度読むには、アンマーシャリングは必要ありません。 -`MsgSubmitEvidence` could implement `UnpackInterfaces`, plus a convenience getter -`GetEvidence` as follows: +`MsgSubmitEvidence`は` UnpackInterfaces`と便利なゲッターを実装できます +`GetEvidence`は次のとおりです。 ```go func (msg MsgSubmitEvidence) UnpackInterfaces(ctx sdk.InterfaceRegistry) error { @@ -311,69 +311,69 @@ func (msg MsgSubmitEvidence) GetEvidence() 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). +使用する場合、カスタムの `Any`実装をAminoで透過的に使用できます +正しいコーデックインスタンスを使用してください。これは、インターフェースがにカプセル化されていることを意味します +`Any`は、通常のAminoインターフェースのようにアミノマーシャリングされます( +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`. +-**すべてのレガシーコードは、 `* amino.Codec`の代わりに` * codec.LegacyAmino`を使用する必要があります。 + `Any` **を正しく処理できるラッパーになりました +-**すべての新しいコードは、アミノと組み合わせた `Marshaler`を使用する必要があります + プロトタイプバッファー** +-さらに、v0.39より前では、 `codec.LegacyAmino`は` codec.LegacyAmino`に名前が変更されます。 -### Why Wasn't X Chosen Instead +### Xを選んでみませんか -For a more complete comparison to alternative protocols, see [here](https://codeburst.io/json-vs-protocol-buffers-vs-flatbuffers-a4247f8bda6f). +代替プロトコルとのより完全な比較については、[ここ](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. +[Cap'n Proto](https://capnproto.org/)はProtobufの好ましい代替手段のようですが +インターフェイス/ジェネリックスのネイティブサポートと組み込みの正規化のために、それは本当に欠けています +Protobufと比較すると、リッチクライアントエコシステムは十分に成熟していません。 ### 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. +[FlatBuffers](https://google.github.io/flatbuffers/)も、 +主な違いは、FlatBuffersは補助的な解析/解凍手順を必要としないことです +データにアクセスする前に、通常、各オブジェクトのメモリ割り当てと組み合わされます。 -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. +ただし、これには多くの調査と移行の範囲の完全な理解が必要です。 +そして今後の方向性-これはまだあまり明確ではありません。さらに、FlatBuffersは +信頼できない入力。 -## 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. +将来的には、永続性のすぐ上に圧縮レイヤーを追加することを検討する可能性があります +txまたはMerkelツリーハッシュのレベルを変更しませんが、ストレージを削減します +`Any`のオーバーヘッド。さらに、protobuf命名規則を採用する場合があります +わかりやすくしながら、タイプURLをより簡潔にします。 -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. +`Any`の使用を取り巻く追加のコード生成サポートは +Go開発者により多くのユーザーエクスペリエンスを提供するために、将来的に検討することもできます +シームレス。 -## 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 +-Protobufメッセージを理解して実装するために必要な学習曲線。 +-`Any`を使用しているため、メッセージサイズはわずかに大きくなりますが、これは相殺できます + 圧縮層 -### Neutral +### ニュートラル -## References +## 参照 1. https://github.com/cosmos/cosmos-sdk/issues/4977 -2. https://github.com/cosmos/cosmos-sdk/issues/5444 +2. https://github.com/cosmos/cosmos-sdk/issues/5444 \ No newline at end of file diff --git a/docs/ja/architecture/adr-020-protobuf-transaction-encoding.md b/docs/ja/architecture/adr-020-protobuf-transaction-encoding.md index e50fe6704fa9..9340ca21636e 100644 --- a/docs/ja/architecture/adr-020-protobuf-transaction-encoding.md +++ b/docs/ja/architecture/adr-020-protobuf-transaction-encoding.md @@ -1,95 +1,96 @@ -# ADR 020: Protocol Buffer Transaction Encoding +# ADR 020:プロトコルバッファトランザクションコーディング -## 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. -- 2021 Feb 24: The Cosmos SDK does not use Tendermint's `PubKey` interface anymore, but its own `cryptotypes.PubKey`. Updates to reflect this. -- 2021 May 3: Rename `clientCtx.JSONMarshaler` to `clientCtx.JSONCodec`. -- 2021 June 10: Add `clientCtx.Codec: codec.Codec`. +-2020年3月6日:最初のドラフト +-2020年3月12日:APIアップデート +-2020年4月13日:「oneof」インターフェースの処理に関する詳細情報を追加 +-2020年4月30日:「任意」に切り替えます +-2020年5月14日:公開鍵のエンコーディングについて説明する +-2020年6月8日:「TxBody」と「AuthInfo」をバイトとして「SignDoc」に保存します。ドキュメント「TxRaw」をブロードキャストおよびストレージタイプとして保存します。 +-2020年8月7日:ADR027を使用して `SignDoc`をシリアル化します。 +-2020年8月19日:[#6966](https://github.com/cosmos/cosmos-sdk/issues/6966)の説明に従って、シーケンスフィールドを `SignDoc`から` SignerInfo`に移動します。 +-2020年9月25日:「PublicKey」タイプを削除し、「secp256k1.PubKey」、「ed25519.PubKey」、「multisig.LegacyAminoPubKey」に置き換えます。 +-2020年10月15日:「AccountRetriever」インターフェースに「GetAccount」メソッドと「GetAccountWithHeight」メソッドを追加しました。 +-2021年2月24日:Cosmos SDKはTendermintの `PubKey`インターフェースを使用しなくなりましたが、独自の` cryptotypes.PubKey`を使用しています。これを反映するように更新します。 +-2021年5月3日: `clientCtx.JSONMarshaler`の名前を` clientCtx.JSONCodec`に変更しました。 +-2021年6月10日: `clientCtx.Codec:codec.Codec`を追加します。 -## 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. +ADRは +[ADR 019](..adr-019-protobuf-state-encoding.md)、つまり、私たちの目標は設計することです +CosmosSDKクライアントのプロトコルバッファ移行パス。 -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). +具体的には、クライアント移行パスには主にtx生成と +署名、メッセージの作成とルーティング、およびCLIとRESTハンドラーと +ビジネスロジック(つまり、クエリア)。 -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. +これを念頭に置いて、2つの主要な領域であるtxsと +お問い合わせください。ただし、このADRはトランザクションのみに焦点を当てています。クエリは +これは将来のADRで解決される予定ですが、これらの推奨事項に基づいている必要があります。 -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. +詳細なディスカッションに基づく([\#6030](https://github.com/cosmos/cosmos-sdk/issues/6030) +そして[\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078))、オリジナル +トランザクションの設計は、 `oneof` .JSON署名から大幅に変更されました +以下に説明する方法の方法。 -## 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. +インターフェイス値は、状態で `google.protobuf.Any`を使用してエンコードされるため([ADR 019](adr-019-protobuf-state-encoding.md)を参照)、 +`sdk.Msg`sは、トランザクションでのエンコードに` Any`を使用します。 -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. +`Any`を使用してインターフェース値をエンコードする主な目標の1つは、 +アプリケーションが再利用するタイプのコアセット +クライアントは、可能な限り多くのチェーンと安全に互換性があります。 -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. +柔軟なクロスチェーントランザクションを提供することは、この仕様の目標の1つです。 +クライアントを壊すことなく、さまざまなユースケースにサービスを提供できるフォーマット +互換性。 + +署名を容易にするために、トランザクションは `TxBody`に分割されます。 +次の `SignDoc`と` signatures`はそれを再利用します: -In order to facilitate signing, transactions are separated into `TxBody`, -which will be re-used by `SignDoc` below, and `signatures`: ```proto -// types/types.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. + ..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. +/.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. + ..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. + ..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. + ..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. + ..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; @@ -97,24 +98,24 @@ message TxBody { } 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. + ..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. + ..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. + ..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 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. + ..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; } @@ -124,18 +125,18 @@ message ModeInfo { 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 + ..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 + ..Multi is the mode info for a multisig public key message Multi { - // bitarray specifies which keys within the multisig are signing + ..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 + ..mode_infos is the corresponding modes of the signers of the multisig + ..which could include nested multisig public keys repeated ModeInfo mode_infos = 2; } } @@ -151,149 +152,148 @@ enum SignMode { } ``` -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. +以下で説明するように、できるだけ多くの「Tx」を含めるために +`SignDoc`では、` SignerInfo`は署名から分離されているため、 +元の署名自体は、署名されたコンテンツの外部に存在します。 -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. +私たちの目標は柔軟でスケーラブルなクロスチェーントランザクションであるため +フォーマット、新しいトランザクション処理オプションをできるだけ早く `TxBody`に追加する必要があります +これらのユースケースは、まだ実現されていなくても発見されています。 -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`. +ここには調整のオーバーヘッドがあるため、 `TxBody`には +`extension_options`フィールドは、任意のトランザクションに使用できます +オプションはまだカバーされていません。それでも、アプリケーション開発者は +「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 +-**可鍛性なし**:一度取引すると、 `TxBody`と` AuthInfo`は変更できません + 署名 +-**予測可能なガス**:料金を支払う取引に署名する場合、 + 最終的なガスは私が署名したものに完全に依存します -These guarantees give the maximum amount confidence to message signers that -manipulation of `Tx`s by intermediaries can't result in any meaningful changes. +これらの保証は、メッセージ署名者に最大の自信を提供します +仲介者による「Tx」の操作は、意味のある変更を引き起こしません。 #### `SIGN_MODE_DIRECT` -The "direct" signing behavior is to sign the raw `TxBody` bytes as broadcast over -the wire. This has the advantages of: +「直接」署名動作は、元の「TxBody」バイトをブロードキャストとして署名することです。 +電線。これには次の利点があります。 -- 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: +署名は次の `SignDoc`で構成され、再利用されます +`TxBody`と` AuthInfo`は、署名に必要なフィールドのみを追加します。 ```proto -// types/types.proto +/.types/types.proto message SignDoc { - // A protobuf serialization of a TxBody that matches the representation in TxRaw. + ..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. + ..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. +1.有効なprotobufを使用して、 `TxBody`と` AuthInfo`をシリアル化します。 +2. `SignDoc`を作成し、[ADR 027](..adr-027-deterministic-protobuf-serialization.md)を使用してシリアル化します。 +3.エンコードされた `SignDoc`バイトに署名します。 +4. `TxRaw`を作成し、ブロードキャスト用にシリアル化します。 -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). +署名の検証は、より原始的な「TxBody」と「AuthInfo」に基づいています +`TxRaw`でエンコードされたバイトは、["正規化 "](https://github.com/regen-network/canonical-proto3)に基づいていません。 +防止することに加えて +アップグレード可能性のいくつかの形式(このドキュメントの後半で説明します)。 -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`. +1. `TxRaw`を逆シリアル化し、` body`と `auth_info`を引き出します。 +2.メッセージに基づいて必要な署名者アドレスのリストを作成します。 +3.必要な署名者ごとに: + -ステータスからアカウント番号とシーケンスを抽出します。 + -状態または `AuthInfo`の` signer_infos`から公開鍵を取得します。 + -`SignDoc`を作成し、[ADR 027](..adr-027-deterministic-protobuf-serialization.md)を使用してシリアル化します。 + -シリアル化された「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. +古いウォレットと交換をサポートするために、AminoJSONは一時的に +トランザクション署名をサポートします。ウォレットとエクスチェンジが +protobufベースの署名にアップグレードする機会がある場合、このオプションは無効になります。存在 +同時に、現在のAmino署名を無効にすると、次のようになることが予測されます。 +あまりにも多くの破損は実行可能ではありません。これは主に要件であることに注意してください +Cosmos Hubおよびその他のチェーンは、Amino署名をすぐに無効にすることを選択できます。 -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. +古い顧客は、現在のAminoを使用してトランザクションに署名できるようになります +JSON形式で、REST `.tx .encode`を使用してprotobufとしてエンコードします +ブロードキャスト前のエンドポイント。 #### `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). +[\#6078](https://github.com/cosmos/cosmos-sdk/issues/6078)で詳しく説明されているように、 +人間が読める署名エンコーディング、特にハードウェアが必要 +[元帳](https://www.ledger.com)のように表示されるウォレット +トランザクションの内容は、署名する前にユーザーに通知されます。 JSONは試みですが、 +理想に達していません。 -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. +`SIGN_MODE_TEXTUAL`は、人間が読める形式のプレースホルダーとして意図されています +アミノJSONのエンコーディングが置き換えられます。この新しいエンコーディングはもっと必要です +読みやすさはJSONよりも重要であり、次のようなフォーマットされた文字列に基づいている場合があります。 +[メッセージ形式](http://userguide.icu-project.org/formatparse/messages)。 -Multiple human-readable formats (maybe even localized messages) may be supported -by `SIGN_MODE_TEXTUAL` when it is implemented. +新しい人間が読める形式が影響を受けないようにするため +トランザクションの可鍛性の問題、 `SIGN_MODE_TEXTUAL` +_人間が読めるバイトと元の `SignDoc`_を連結する必要があります +シンボルバイトを生成します。 -### Unknown Field Filtering +複数の人間が読める形式をサポートする可能性があります(おそらくローカライズされたメッセージでさえ) +実装中に `SIGN_MODE_TEXTUAL`を渡します。 -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`) +protobufメッセージの不明なフィールドは、通常、トランザクションによって拒否されます。 +プロセッサの理由: -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. +-重要なデータが不明なフィールドに存在する可能性があります。省略した場合は、 + 顧客の予期しない行動を引き起こす +-彼らは、攻撃者がtxサイズを膨らませることができる可鍛性の抜け穴を提案しました + 説明されていないランダムなデータを署名されていないコンテンツ(つまり、メインの「Tx」)に追加することにより、 + `TxBody`ではありません) -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. +未知のフィールドを安全に無視することを選択できるシナリオがまだいくつかあります +(https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-624400188)から +新しいクライアントとのエレガントな上位互換性を提供します。 -To handle this we will need a unknown field filter that: +11番目のフィールド番号を設定することをお勧めします(ほとんどのユースケースでは、これは +1024〜2047の範囲)は、安全で重要ではない領域と見なされます +不明な場合は無視してください。 -- 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. +-署名されていないコンテンツの不明なフィールドを常に拒否します(つまり、トップレベルの `Tx`と + `AuthInfo`の符号なし部分(署名モードに基づいて存在する場合) +-すべてのメッセージ(ネストされた `Any`を含む)の不明なフィールドを拒否します。 + 11番目のビットが設定されたフィールド -### Public Key Encoding +これには、メッセージバイトを受け入れるカスタムprotobufパーサーを渡す必要がある場合があります +そして `FileDescriptor`sとブール結果を返します。 -Public keys in the Cosmos SDK implement the `cryptotypes.PubKey` interface. -We propose to use `Any` for protobuf encoding as we are doing with other interfaces (for example, in `BaseAccount.PubKey` and `SignerInfo.PublicKey`). -The following public keys are implemented: secp256k1, secp256r1, ed25519 and legacy-multisignature. +### 公開鍵エンコーディング -Ex: +Cosmos SDKの公開鍵は、 `cryptotypes.PubKey`インターフェースを実装します。 +他のインターフェース(たとえば、 `BaseAccount.PubKey`や` SignerInfo.PublicKey`)を使用するのと同じように、protobufエンコーディングには `Any`を使用することをお勧めします。 +次の公開鍵が実装されています:secp256k1、secp256r1、ed25519およびlegacy-multisignature。 +Ex: ```proto message PubKey { @@ -301,21 +301,21 @@ message PubKey { } ``` -`multisig.LegacyAminoPubKey` has an array of `Any`'s member to support any -protobuf public key type. +`multisig.LegacyAminoPubKey`には、任意のをサポートするための` Any`のメンバー配列があります +protobuf公開鍵タイプ。 -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 +### 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. +現在、RESTおよびCLIハンドラーは、Aminoを介してタイプとTXをエンコードおよびデコードします +特定のAminoコーデックのJSONエンコーディングを使用します。 特定の種類の処理のため +[ADR 019](..adr-019-protobuf-state-encoding.md)で説明したのと同様に、クライアントのインターフェイスにすることができます。 +クライアントロジックは、次の方法を知っているだけでなく、コーデックインターフェイスを採用する必要があります。 +すべてのタイプを処理しますが、トランザクション、署名、 +そしてニュース。 ```go type AccountRetriever interface { @@ -345,13 +345,13 @@ type TxBuilder interface { } ``` -We then update `Context` to have new fields: `Codec`, `TxGenerator`, -and `AccountRetriever`, and we update `AppModuleBasic.GetTxCmd` to take -a `Context` which should have all of these fields pre-populated. +次に、 `Context`を更新して、新しいフィールドを取得します:` Codec`、 `TxGenerator`、 +そして `AccountRetriever`、` AppModuleBasic.GetTxCmd`を更新します +「コンテキスト」。これらすべてのフィールドに事前入力する必要があります。 -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: +次に、各クライアントメソッドは「Init」メソッドの1つを使用して再初期化する必要があります +事前入力された「コンテキスト」。 `tx.GenerateOrBroadcastTx`を使用できます +トランザクションを生成またはブロードキャストします。 例えば: ```go import "github.com/spf13/cobra" @@ -369,96 +369,95 @@ func NewCmdDoSomething(clientCtx client.Context) *cobra.Command { } ``` -## Future Improvements +## 将来の改善 -### `SIGN_MODE_TEXTUAL` specification +### `SIGN_MODE_TEXTUAL`仕様 -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_TEXTUAL」の特定の仕様と実装は、 +元帳アプリケーションやその他のウォレットを可能にするための短期的な将来の改善として +AminoJSONから正常に移行できます。 ### `SIGN_MODE_DIRECT_AUX` -(\*Documented as option (3) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933) +(\ * https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933にオプション(3)として記録されています) -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. +モード `SIGN_MODE_DIRECT_AUX`を追加できます +複数の署名シナリオをサポートする +単一のトランザクションに収集されていますが、メッセージエディタは収集されません +最終的なトランザクションにどの署名が含まれるかもわかっています。例えば、 +3/5のマルチシグニチャウォレットを持っていて、5人全員に「TxBody」を送信したい場合があります +署名者は、誰が最初に署名するかを確認します。署名が3つあるとすぐに行きます +完全なトランザクションを進めて確立します。 -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`を使用するには、各署名者は +すべての署名者の完全なリストを含む完全な「AuthInfo」に署名し、 +それらの署名モードは、上記のシナリオを非常に困難にします。 -`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. +`SIGN_MODE_DIRECT_AUX`は、「補助」署名者が署名を作成できるようにします +`TxBody`と独自の` PublicKey`のみを使用してください。これにより、完全なリストが可能になります +AuthInfoの署名者は、署名が収集されるまで遅延されます。 -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`. +「セカンダリ」署名者は、メイン署名者以外の署名者です。 +料金。メインの署名者の場合、ガスと料金を計算するには、実際には完全なAuthInfoが必要です +署名者の数と、キーの種類と署名によって異なります。 +彼らが使用しているモード。ただし、二次署名者は心配する必要はありません +コストまたはガソリンなので、「TxBody」に署名するだけです。 -To generate a signature in `SIGN_MODE_DIRECT_AUX` these steps would be followed: +「SIGN_MODE_DIRECT_AUX」で署名を生成するには、次の手順に従います。 -1. Encode `SignDocAux` (with the same requirement that fields must be serialized - in order): +1. `SignDocAux`のエンコード(フィールドをシリアル化する必要があるという要件と同じ) + にとって): ```proto -// types/types.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 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 - +2.エンコードされた `SignDocAux`バイトに署名します +3.署名と `SignerInfo`をメインの署名者に送信すると、 + 最終トランザクションに署名してブロードキャストします(「SIGN_MODE_DIRECT」と「AuthInfo」を使用) + 追加)十分な数の署名が収集されたら ### `SIGN_MODE_DIRECT_RELAXED` -(_Documented as option (1)(a) in https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_) +(_https://github.com/cosmos/cosmos-sdk/issues/6078#issuecomment-628026933_のオプション(1)(a)として文書化されています) -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. +これは「SIGN_MODE_DIRECT」の変形であり、複数の署名者は必要ありません +公開鍵と署名モードを事前に調整します。これには代替手段が含まれます +`SignDoc`は上記の` SignDocAux`と似ていますが、有料です。これは将来追加することができます +クライアント開発者が公開鍵とパターンを事前に収集する負担を見つけた場合 +面倒すぎる。 -## 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. +-`google.protobuf.Any`タイプのURLはトランザクションサイズを増やします + それは無視できるかもしれません、または圧縮はそれを軽減することができます。 -### Neutral +### ニュートラル -## References +## 参照 \ No newline at end of file diff --git a/docs/ja/architecture/adr-021-protobuf-query-encoding.md b/docs/ja/architecture/adr-021-protobuf-query-encoding.md index 443b506101f1..b3180b8a07f6 100644 --- a/docs/ja/architecture/adr-021-protobuf-query-encoding.md +++ b/docs/ja/architecture/adr-021-protobuf-query-encoding.md @@ -1,38 +1,38 @@ -# ADR 021: Protocol Buffer Query Encoding +# ADR 021:プロトコルバッファクエリコード -## Changelog +## 変更ログ -- 2020 March 27: Initial Draft +-2020年3月27日:最初のドラフト -## 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. +ADRは +[ADR 019](./adr-019-protobuf-state-encoding.md)および +[ARD 020](./adr-019-protobuf-transaction-encoding.md)、つまり、私たちの目標は設計することです +CosmosSDKクライアントのプロトコルバッファ移行パス。 -This ADR continues from [ARD 020](./adr-020-protobuf-transaction-encoding.md) -to specify the encoding of queries. +このADRは[ARD020](./adr-020-protobuf-transaction-encoding.md)から継続します +クエリのエンコーディングを指定します。 -## 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. +モジュールは、プロトコルバッファの「サービス」定義を介してカスタムクエリを定義します。 +これらの「サービス」の定義は通常、 +GRPCプロトコル。 ただし、プロトコルバッファの仕様には次のように記載されています。 +これらは、使用される任意の要求/応答プロトコルでより一般的に使用できます。 +プロトコルバッファエンコーディング。 したがって、 `service`定義を使用して指定できます +ABCIクエリをカスタマイズし、多くのGRPCインフラストラクチャを再利用することもできます。 -Each module with custom queries should define a service canonically named `Query`: +カスタムクエリを使用するすべてのモジュールは、Queryという名前のサービスを正規に定義する必要があります。 ```proto -// x/bank/types/types.proto +/.x/bank/types/types.proto service Query { rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { } @@ -40,22 +40,22 @@ service Query { } ``` -#### 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. +インターフェイスタイプを使用し、真にポリモーフィックである必要があるモジュールは、通常、強制されます +特定の実装アプリケーションレベルのセットを提供するまでの `oneof` +アプリケーションでサポートされているインターフェース。 ウェルカムアプリケーションは +アプリケーションレベルのクエリサービスのクエリと実装、モジュールの提案 +`google.protobuf.Any`を介してこれらのインターフェースを公開するクエリメソッドを提供します。 +トランザクションレベルで問題があります。つまり、 `Any`のオーバーヘッドが大きすぎます。 +その使用を正当化するために高い。 しかし、クエリの場合、これは問題ではありません。 +「Any」を使用して一般的なモジュールレベルのクエリを提供しても、アプリケーションは除外されません +また、アプリケーションレベルの `oneof`の使用を返すアプリケーションレベルのクエリも提供します。 -A hypothetical example for the `gov` module would look something like: +`gov`モジュールの架空の例は次のとおりです。 ```proto -// x/gov/types/types.proto +/.x/gov/types/types.proto import "google/protobuf/any.proto"; @@ -69,11 +69,11 @@ message AnyProposal { } ``` -### 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: +为了实现查询服务，我们可以复用现有的[gogo protobuf](https://github.com/gogo/protobuf) +grpc 插件，它为名为 `Query` 的服务生成一个名为的接口 +`QueryServer` 如下: ```go type QueryServer interface { @@ -82,17 +82,17 @@ type QueryServer interface { } ``` -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 Cosmos SDK should provide a function -`sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided -`context.Context`. +この生成されたインターフェースの最初のパラメーターは、一般的な `context.Context`です。 +クエリアメソッドは通常、読み取るために `sdk.Context`のインスタンスを必要とします +ストレージから。 `context.Context`には任意の値を追加できるため +`WithValue`および` Value`メソッドを使用して、CosmosSDKは関数を提供する必要があります +`sdk.UnwrapSDKContext`は、提供されたオブジェクトから` sdk.Context`を取得します +`コンテキスト。 コンテキスト `。 -An example implementation of `QueryBalance` for the bank module as above would -look something like: +上記の銀行モジュールの `QueryBalance`の実装例は次のようになります。 +のように見える: ```go type Querier struct { @@ -105,62 +105,62 @@ func (q Querier) QueryBalance(ctx context.Context, params *types.QueryBalancePar } ``` -### 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: +上記のクエリサーバーの実装は `AppModule`sに登録されます +簡単に実装できる新しいメソッド `RegisterQueryService(grpc.Server)` +次のように: ```go -// x/bank/module.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. +舞台裏では、新しいメソッド `RegisterService(sd * grpc.ServiceDesc、handler interface {})` +クエリをカスタムに追加するために、既存の `baseapp.QueryRouter`に追加されます +ルーティングテーブルを照会します(ルーティング方法については以下で説明します)。 +このメソッドのシグネチャは、既存のメソッドと一致します +GRPCの `Server`タイプの` RegisterServer`メソッド。`handler`はカスタムです。 +上記のクエリサーバーの実装。 + +GRPCのようなリクエストは、サービス名でルーティングされます(例: `cosmos_sdk.x.bank.v1.Query`) +そして、メソッド名(例: `QueryBalance`)を`/`と組み合わせて、完全なものを形成します +メソッド名(例: `/cosmos_sdk.x.bank.v1.Query/QueryBalance`)。これは翻訳されています +「custom/cosmos_sdk.x.bank.v1.Query/QueryBalance」などのABCIクエリを入力します。サービスハンドラ +`QueryRouter.RegisterService`に登録すると、この方法でルーティングされます。 + +メソッド名に加えて、GRPCリクエストはprotobufでエンコードされたペイロードも運びます。これは自然にマッピングされます +`RequestQuery.Data`に移動し、protobufでエンコードされた応答またはエラーを受け取ります。したがって +GRPCに似たrpcメソッドは、既存のものに非常に自然にマッピングされます +`sdk.Query`および` QueryRouter`インフラストラクチャ。 + +この基本仕様により、プロトコルバッファの「サービス」定義を再利用できます。 +ABCIカスタムクエリ、手動デコード、および +queryメソッドでのエンコード。 + +### GRPCプロトコルのサポート + +ABCIクエリパスを提供するだけでなく、GRPCも簡単に提供できます +ABCIクエリリクエストの場合、GRPCプロトコルのリクエストをプロキシサーバーにルーティングします +フードの下。このようにして、顧客は既存のホスト言語を使用できます +GRPCを使用して、CosmosSDKアプリケーションの直接クエリを実装します +これらの「サービス」が定義されています。このサーバーを機能させるには、 `QueryRouter` +BaseAppに公的に登録する必要があるサービスハンドラー +`QueryRouter.RegisterService`をプロキシサーバーの実装に追加します。ノードはできます +ABCIアプリケーションと同じプロセスで別のポートでプロキシサーバーを起動します +コマンドラインフラグ付き。 + +### RESTクエリとSwaggerの生成 + +[grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway)はプロジェクトです +サービスで特別なアノテーションを使用して、REST呼び出しをGRPC呼び出しに変換します +方法。 RESTクエリを公開するモジュールは、 `google.api.http`を追加する必要があります +以下の例に示すように、それらの `rpc`メソッドについてコメントします。 ```proto -// x/bank/types/types.proto +/.x/bank/types/types.proto service Query { rpc QueryBalance(QueryBalanceParams) returns (cosmos_sdk.v1.Coin) { @@ -176,26 +176,26 @@ service Query { } ``` -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. +grpc-gatewayは、上記のGRPCプロキシに対して直接機能します。 +バックグラウンドでリクエストをABCIクエリに変換します。 grpc-gatewayも利用可能です +Swagger定義は自動的に生成されます。 -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. +現在のRESTクエリの実装では、各モジュールを実装する必要があります +ABCI Queryerメソッドに加えて、RESTクエリも手動で実行されます。 grpcゲートウェイを使用する +メソッド、個別のRESTクエリハンドラーを生成する必要はありません。 +上記のクエリサーバーは、protobuf変換を処理するためのgrpc-gatewayとして使用されます +RESTとSwaggerの定義に。 -The Cosmos 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. +Cosmos SDKは、アプリケーションがGRPCゲートウェイを開始するためのCLIコマンドを提供する必要があります +別のプロセスまたはABCIアプリケーションと同じプロセスであり、 +grpc-gatewayプロキシの `.proto`ファイルと` swagger.json`を生成するためのコマンド +資料。 -### 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: +gogo protobuf grpcプラグインは、サーバーに加えてクライアントインターフェイスを生成します +インターフェース。 上で定義した `Query`サービスの場合、` QueryClient`を取得します +次のようなインターフェース: ```go type QueryClient interface { @@ -204,16 +204,15 @@ type QueryClient interface { } ``` -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. +小さなパッチをgogoprotobufに渡します([gogo/protobuf#675](https://github.com/gogo/protobuf/pull/675)) +具体的なタイプの代わりにインターフェースを使用するようにgrpcコードジェネレーターを調整しました +生成されたクライアント構造の場合。 これにより、GRPCインフラストラクチャも再利用できます +ABCIクライアントクエリに使用されます。 -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: +1Context`は、 `ClientConn`を返す新しいメソッド` QueryConn`を受け取ります +ABCIクエリへの通話のルーティング +クライアント(CLIメソッドなど)は、次のようなクエリメソッドを呼び出すことができます。 ```go clientCtx := client.NewContext() queryClient := types.NewQueryClient(clientCtx.QueryConn()) @@ -223,8 +222,8 @@ 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: +テストでは、キーパーと `sdk.Context`から直接クエリクライアントを作成できます。 +「QueryServerTestHelper」を使用するための参照は次のとおりです。 ```go queryHelper := baseapp.NewQueryServerTestHelper(ctx) @@ -232,25 +231,25 @@ 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 +*クエリャーの実装を大幅に簡素化します(手動でエンコード/デコードする必要はありません) +*クライアント生成を簡単に照会できます(既存のgrpcおよびswaggerツールを使用できます) +* RESTクエリを実装する必要はありません +*タイプセーフなクエリメソッド(grpcプラグインによって生成) +*先に進むと、クエリメソッドの中断が少なくなります。 +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 +*既存のABCI/RESTクエリを使用するすべてのクライアントをリファクタリングする必要があります +新しいGRPC/RESTクエリパスとprotobuf/proto-jsonエンコーディングの場合 +データですが、これはprotobufの再構築では多かれ少なかれ避けられません -### Neutral +### ニュートラル -## References +## 参照 \ No newline at end of file diff --git a/docs/ja/architecture/adr-022-custom-panic-handling.md b/docs/ja/architecture/adr-022-custom-panic-handling.md index aec42f861ccc..1ec1c89543e3 100644 --- a/docs/ja/architecture/adr-022-custom-panic-handling.md +++ b/docs/ja/architecture/adr-022-custom-panic-handling.md @@ -1,62 +1,61 @@ -# ADR 022: Custom BaseApp panic handling +#ADR 022:カスタムBaseAppパニック処理 -## Changelog +##変更ログ -- 2020 Apr 24: Initial Draft -- 2021 Sep 14: Superseded by ADR-045 +-2020年4月24日:最初のドラフト +-2021年9月14日:ADR-045に置き換えられました -## Status +## 状態 -SUPERSEDED by ADR-045 +ADR-045に置き換えられました -## Context +## 環境 -The current implementation of BaseApp does not allow developers to write custom error handlers during panic recovery +BaseAppの現在の実装では、開発者はパニックリカバリ中にカスタムエラーハンドラーを作成できません。 [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 Cosmos 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. +方法。この方法はより柔軟で、CosmosSDKユーザーにカスタマイズオプションを提供できると考えています。 +BaseApp全体を書き直す必要があります。 `sdk.ErrorOutOfGas`エラー処理の特殊なケースがあります。これはケースです。 +他の方法と一緒に「標準」の方法(ミドルウェア)で処理される場合があります。 -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; +*外部ログレコードを追加します(レポートが[Sentry](https://sentry.io)などの外部サービスに送信されると想定)。 +*特定のエラー状態に対してパニックを引き起こします。 -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)). +また、 `OutOfGas`ケースと` default`ケースをミドルウェアの1つにします。 +`Default`の場合は、リカバリオブジェクトをエラーとしてラップし、それを記録します([Sample 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. +私たちのプロジェクトには、ブロックチェーンノード(スマートコントラクト仮想マシン)で実行されるサイドカーサービスがあります。それは +ノード<->サイドカー接続は、TX処理の安定性に不可欠です。したがって、通信が中断された場合、 +ノードをクラッシュさせ、問題が解決した後で再起動します。この動作により、ノードのステートマシンが実行されます +決定論的。 runTxの `defer()`ハンドラーがすべてのキーパーパニックをキャッチしたため、BaseAppコードを調整する必要があります +それをカスタマイズするために。 +## 決断 -## Decision +### 設計 -### Design +#### 概要 -#### Overview +カスタムエラー処理をBaseAppにハードコーディングする代わりに、カスタマイズ可能なミドルウェアのセットを使用することをお勧めします +外部であり、開発者は必要な数のカスタムエラーハンドラーを使用できます。テストによって達成 +ここ(https://github.com/cosmos/cosmos-sdk/pull/6053)にあります。 -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. +新しい「RecoveryHandler」タイプが追加されました。 `recoveryObj`入力パラメータは、標準のGo関数によって返されるオブジェクトです。 +`builtin`パッケージから` recover() `。 ```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. +ハンドラーは、オブジェクトにアサーション(または他のメソッド)を入力して、オブジェクトを処理する必要があるかどうかを定義する必要があります。 +入力オブジェクトがその `RecoveryHandler`(ハンドラーのターゲットタイプではない)で処理できない場合は、` nil`を返す必要があります。 +入力オブジェクトが処理され、ミドルウェアチェーンの実行を停止する必要がある場合、「nil」エラーは返されません。 -An example: +一例: ```go func exampleErrHandler(recoveryObj interface{}) error { @@ -71,14 +70,13 @@ func exampleErrHandler(recoveryObj interface{}) error { } ``` -This example breaks the application execution, but it also might enrich the error's context like the `OutOfGas` handler. - -##### Recovery middleware +この例では、アプリケーションの実行が中断されますが、 `OutOfGas`ハンドラーなどのエラーコンテキストが強化される場合もあります。 -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. +##### リカバリミドルウェア +ミドルウェアタイプ(デコレータ)も追加しました。 この関数型は `RecoveryHandler`をラップし、次のミドルウェアを返します +実行チェーンとハンドラーの「エラー」。 タイプは、 `recovery()`オブジェクトの実際の処理をミドルウェアから分離するために使用されます +チェーン処理。 ```go type recoveryMiddleware func(recoveryObj interface{}) (recoveryMiddleware, error) @@ -92,14 +90,13 @@ func newRecoveryMiddleware(handler RecoveryHandler, next recoveryMiddleware) rec } ``` -Function receives a `recoveryObj` object and returns: +この例では、アプリケーションの実行が中断されますが、 `OutOfGas`ハンドラーなどのエラーコンテキストが強化される場合もあります。 -* (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: +ミドルウェアタイプ(デコレータ)も追加しました。 この関数型は `RecoveryHandler`をラップし、次のミドルウェアを返します +実行チェーンとハンドラーの「エラー」。 タイプは、 `recovery()`オブジェクトの実際の処理をミドルウェアから分離するために使用されます +チェーン処理。 ```go func newOutOfGasRecoveryMiddleware(gasWanted uint64, ctx sdk.Context, next recoveryMiddleware) recoveryMiddleware { @@ -118,7 +115,7 @@ func newOutOfGasRecoveryMiddleware(gasWanted uint64, ctx sdk.Context, next recov } ``` -`Default` middleware example: +`default`ミドルウェアの例: ```go func newDefaultRecoveryMiddleware() recoveryMiddleware { @@ -132,9 +129,9 @@ func newDefaultRecoveryMiddleware() recoveryMiddleware { } ``` -##### Recovery processing +##### 回復処理 -Basic chain of middlewares processing would look like: +ミドルウェア処理の基本的なチェーンは次のとおりです。 ```go func processRecovery(recoveryObj interface{}, middleware recoveryMiddleware) error { @@ -148,26 +145,26 @@ func processRecovery(recoveryObj interface{}, middleware recoveryMiddleware) err } ``` -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`. +このようにして、左から右に実行されるミドルウェアチェーンを作成できます。右端のミドルウェアは +`default`ハンドラーは` error`を返す必要があります。 -##### BaseApp changes +##### BaseAppの変更 -The `default` middleware chain must exist in a `BaseApp` object. `Baseapp` modifications: +`default`ミドルウェアチェーンは` BaseApp`オブジェクトに存在する必要があります。 `Baseapp`の変更: ```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) @@ -176,11 +173,11 @@ func (app *BaseApp) runTx(...) { 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: +開発者は、BaseAppオプションパラメーターとして `AddRunTxRecoveryHandler`を` NewBaseapp`コンストラクターに提供することにより、カスタムの `RecoveryHandler`を追加できます。 ```go func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) { @@ -190,29 +187,29 @@ func (app *BaseApp) AddRunTxRecoveryHandler(handlers ...RecoveryHandler) { } ``` -This method would prepend handlers to an existing chain. +このメソッドは、ハンドラーを既存のチェーンに追加します。 -## 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; +-Cosmos SDKベースのプロジェクトの開発者は、カスタムパニックハンドラーを次の場所に追加できます。 + *カスタムパニックソース(カスタムキーパー内のパニック)にエラーコンテキストを追加します。 + * `panic()`を発行します:リカバリオブジェクトをTendermintコアに渡します。 + *その他の必要な処理。 +-開発者は、プロジェクトで書き直す代わりに、標準のCosmos SDK`BaseApp`実装を使用できます。 +-提案されたソリューションは、現在の「標準」の `runTx()`プロセスを中断しません。 -### 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; +-`OutOfGas`エラーハンドラーはミドルウェアの1つになります。 +-デフォルトのパニックハンドラーはミドルウェアの1つになります。 -## 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) +-[提案されたソリューションを使用したPR-6053](https://github.com/cosmos/cosmos-sdk/pull/6053) +-[同様のソリューション。ADR-010モジュラーAnteHandler](https://github.com/cosmos/cosmos-sdk/blob/v0.38.3/docs/architecture/adr-010-modular-antehandler.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-023-protobuf-naming.md b/docs/ja/architecture/adr-023-protobuf-naming.md index f4425243e158..10c6e3800c25 100644 --- a/docs/ja/architecture/adr-023-protobuf-naming.md +++ b/docs/ja/architecture/adr-023-protobuf-naming.md @@ -1,263 +1,262 @@ -# ADR 023: Protocol Buffer Naming and Versioning Conventions +# ADR 023:プロトコルバッファの命名とバージョン規則 -## Changelog +## 変更ログ -- 2020 April 27: Initial Draft -- 2020 August 5: Update guidelines +-2020年4月27日:最初のドラフト +-2020年8月5日:ガイドラインを更新 -## 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. +Protocol Buffersは、基本的な[スタイルガイド](https://developers.google.com/protocol-buffers/docs/style)を提供します +[Buf](https://buf.build/docs/style-guide)これに基づいています。到着 +可能な場合は、業界で認められたガイドラインと知恵に従うことを望んでいます +protobufの効果的な使用は、明確な場合にのみそれらから逸脱します +ユースケースの基本原則。 -### Adoption of `Any` +### `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. +推奨されるエンコード方法として「google.protobuf.Any」を使用してください +( `oneof`ではなく)インターフェースタイプにより、パッケージの命名がコア部分になります +完全修飾としてエンコードされたメッセージの名前がエンコードに表示されるようになりました +情報。 -### 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: +これまでのところ、主に[Buf's](https://buf.build)[DEFAULT](https://buf.build/docs/lint-checkers#default)に従います。 +[`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout)の小さな偏差を無効にすることをお勧めします +コードを開発するのは便利ですが、警告があります +Bufから: -> you will have a very bad time with many Protobuf plugins across various languages if you do not do this +>そうしないと、さまざまな言語の多くのProtobufプラグインで非常に悪い時間を過ごすことになります -### Adoption of gRPC Queries +### gRPCを使用したクエリ -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. +[ADR 021](adr-021-protobuf-query-encoding.md)では、ProtobufはgRPCを使用します +ローカルクエリ。したがって、完全なgRPCサービスパスはABCIクエリの重要な部分になっています +トレイル。将来的には、gRPCクエリが永続的なスクリプトで許可される可能性があります +CosmWasmなどのテクノロジーを通じて、これらのクエリルートは次の場所に保存されます。 +スクリプトバイナリファイル。 -## Decision +## 決定 -The goal of this ADR is to provide thoughtful naming conventions that: +このADRの目標は、思慮深い命名規則を提供することです。 -* 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) +*ユーザーが直接操作するときに優れたユーザーエクスペリエンスを促進する +.protoファイルと完全修飾protobuf名 +*単純さと過度の最適化の可能性のバランスを取ります( +名前が短すぎて不思議です)または最適化が不十分です(肥大化した名前のみが受け入れられます +冗長な情報がたくさんあります) -These guidelines are meant to act as a style guide for both the Cosmos SDK and -third-party modules. +これらのガイドは、CosmosSDKおよび +サードパーティのモジュール。 -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: +開始点として、すべての[DEFAULT](https://buf.build/docs/lint-checkers#default)を使用する必要があります +[`PACKAGE_DIRECTORY_MATCH`](https://buf.build/docs/lint-checkers#file_layout)を含む[Buf's](https://buf.build)のチェッカー、 +の他に: * [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. +完全修飾名を使用したことを考えると +`google.protobuf.Any`とgRPCクエリルーティングでは、私たちの目標は +名前は簡潔に保ち、やりすぎないでください。一般的な経験則は +短い名前がより多くのまたは同じことを伝える場合は、短い名前を選択してください +名前。 -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. +たとえば、 `cosmos.bank.MsgSend`(19バイト)はほぼ同じ情報を伝達します +`cosmos_sdk.x.bank.v1.MsgSend`(28バイト)などですが、より簡潔です。 -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. +また、名前を付けて過度に最適化する誘惑に抵抗する必要があります +略語付きのミステリアスなショート。たとえば、試してはいけません +`cosmos.bank.MsgSend`を` csm.bk.MSnd`に減らすことは、ほんの数バイトを節約することです。 -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. +パッケージとタイプの名前は、ユーザーの利益のために選択する必要があります。 +これは、goコードベースに関連するレガシーの問題が原因である必要があります。 -#### 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. +一般的に、モードの進化は、protobufモードを更新する方法です。これは新しい分野を意味し、 +メッセージとRPCメソッドが既存のスキーマに追加され、古いフィールド、メッセージ、およびRPCメソッドが追加されます +できるだけ長く保管してください。 -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. +物事を破壊するのではなく、単に破壊するのではなく、モデルを開発するためにできる限りのことをする必要があります。 +[Buf](https://buf.build)すべての安定した(非アルファまたはベータ)パッケージには、重大な変更の検出を使用する必要があります +そのような損傷を防ぐため。 -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: +これを念頭に置いて、パッケージのさまざまな安定したバージョン(つまり、 `v1`または` v2`)を多かれ少なかれ検討する必要があります +さまざまなパッケージで、これがprotobufモードをアップグレードする最後の手段になるはずです。作成したシーン +`v2`が意味をなすのは次のとおりです。 -* 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. +*既存のモジュールと同様の機能を持つ新しいモジュールを作成したいので、 `v2`を追加するのが最も自然です +これを行う方法。この場合、実際には、APIが異なる2つの異なるが類似したモジュールしかありません。 +*既存のモジュールに新しく改善されたAPIを追加したいのですが、既存のパッケージに追加するのは面倒です。 +したがって、 `v2`に入れる方がユーザーにとってよりクリーンです。この場合、の使用を放棄しないように注意する必要があります +不変のスマートコントラクトで積極的に使用されている場合は `v1`。 -#### 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`または` beta`としてマークすることは最後の手段であり、一部のコンテンツを +安定したパッケージ(つまり、 `v1`または` v2`)を優先する必要があります +*削除するアクティブなディスカッションがある場合にのみ、パッケージを「アルファ」としてマークする必要があります。 +または、近い将来、パッケージを大幅に変更します +*活発な議論がある場合に限り、パッケージは「ベータ」としてマークされるべきです。 +近い将来、大幅にリファクタリング/再設計された機能ですが、削除されることはありません +*モジュールは、安定した(つまり、 `v1`または` v2`)および不安定な( `alpha`または` beta`)パッケージタイプを持つことができます。 -*`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. +*互換性を維持する責任を回避するために、 `alpha`と` beta`を使用しないでください。 * +特にブロックチェーン上でコードが公開されるときはいつでも、物事を変更するコストは高くなります。いくつかの +たとえば、不変のスマートコントラクトの場合、主要な変更は修復できない場合があります。 -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? +*他の人にコードを変更するように依頼するコストと、コードを変更するオプションを維持することの利点は何ですか？ +*それを `v1`に移動する計画は何ですか？これはユーザーにどのように影響しますか？ -`alpha` or `beta` should really be used to communicate "changes are planned". +`alpha`または` beta`は、実際には「計画された変更」を伝えるために使用する必要があります。 -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. +ケーススタディとして、gRPCリフレクションは `grpc.reflection.v1alpha`パッケージにあります。それ以来変わっていません +2017年には、gRPCurlなどの他の広く使用されているソフトウェアで使用されるようになりました。一部の人々はそれを生産サービスで使用するかもしれません +したがって、パッケージを `grpc.reflection.v1`に変更すると、一部のソフトウェアがクラッシュし、 +彼らはそれをしたくないかもしれません...それで今 `v1alpha`パッケージは多かれ少なかれ実際の` v1`です。そんなことはしないでください。 -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 +* [Buf推奨バージョンのサフィックス](https://buf.build/docs/lint-checkers#package_version_suffix) +(例: `v1alpha1`)は不安定なパッケージに使用する必要があります +*不安定なパッケージは通常、破壊的な変更の検出から除外する必要があります +*不変のスマートコントラクトモジュール(つまり、CosmWasm)_should_blockスマートコントラクト/永続的 +`alpha`.` beta`パッケージと相互作用するスクリプト -#### Omit v1 suffix +#### v1サフィックスを省略 -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`. +[Buf推奨バージョンサフィックス](https://buf.build/docs/lint-checkers#package_version_suffix)を使用する代わりに、 +実際に2番目のバージョンがないパッケージの場合、 `v1`を省略できます。この +`cosmos.bank.Send`などの一般的なユースケースのより簡潔な名前を許可します。 +2番目または3番目のバージョンのパッケージは `.v2`で表すことができます +または `.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. +トップレベルのパッケージでは、競合しないことがわかっている短い名前を使用する必要があります +コスモスエコシステムで一般的に使用される他の名前。近い将来、 +使用される最上位のパッケージ名を保持および索引付けするために、レジストリを作成する必要があります +コスモスエコシステム。 CosmosSDKが提供することを目的としているため +Cosmosプロジェクトのトップレベルタイプ。トップレベルパッケージ名は `cosmos`です。 +長い `cosmos_sdk`の代わりに、CosmosSDKで使用することをお勧めします。 +[ICS](https://github.com/cosmos/ics)仕様は1つを考慮することができます +`ics23`などの標準番号に基づく短いトップレベルパッケージ。 -#### 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. +下請けの深さを増すように注意する必要があります。一般的にシングル +モジュールまたはライブラリにはサブパッケージが必要です。 `x`または` modules`であっても +ソースコードでモジュールを表すために使用されます。これは通常、.protoには不要です。 +モジュールとしてのファイルは、サブパッケージの主な目的です。それだけ +使用頻度が低いことがわかっているものは、サブパッケージの深さを深くする必要があります。 -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`. +Cosmos SDKの場合、単に `cosmos.bank`と書くことをお勧めします。 +`cosmos.x.bank`の代わりに` cosmos.gov`など。実際には、ほとんどの非モジュール +タイプは `cosmos`パッケージに直接配置することも、導入することもできます +必要に応じて、 `cosmos.base`をパッケージ化します。この命名は変更されないことに注意してください +goパッケージ名、つまり `cosmos.bank`protobufパッケージはまだ存在します +`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. +メッセージタイプの名前は、わかりやすくするためにできるだけ簡潔にする必要があります。 `sdk.Msg` +トランザクションで使用されるタイプは、「Msg」プレフィックスを保持します。 +便利なコンテキスト。 -### Service and RPC Naming +### サービスとRPCの命名 -[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. +[ADR 021](adr-021-protobuf-query-encoding.md)は、モジュールが +gRPCクエリサービスを実現します。単純性の原則を考慮する必要があります +永続的なスクリプトから呼び出すことができるため、サービス名とRPC名のクエリに使用されます +CosmWasmおよびその他のモジュール。さらに、ユーザーは次のようなツールからこれらのクエリパスを使用できます。 +[gRPCurl](https://github.com/fullstorydev/grpcurl)。たとえば、短縮できます +`.cosmos_sdk.x.bank.v1.QueryService .QueryBalance`から +`.cosmos.bank.Query .Balance`は多くの有用な情報を失うことはありません。 -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`. +RPC要求および応答type_should_は `ServiceNameMethodNameRequest`.に従います +`ServiceNameMethodNameResponse`の命名規則。つまり、「Balance」という名前のRPCメソッドの場合 +`Query`サービスでは、リクエストとレスポンスのタイプは` QueryBalanceRequest`になります +そして `QueryBalanceResponse`。これは、BalanceRequestよりも自明です。 +そして「バランスの取れた反応」。 -#### Use just `Query` for the query service +#### クエリサービスとしてのみ `Query`を使用する -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. +[Bufのデフォルトのサービスサフィックスの推奨事項](https://github.com/cosmos/cosmos-sdk/pull/6033)の代わりに、 +クエリサービスを提供するには、単に短い `Query`を使用する必要があります。 -For other types of gRPC services, we should consider sticking with Buf's -default recommendation. +他のタイプのgRPCサービスについては、Bufに固執することを検討する必要があります +デフォルトで推奨されます。 -#### Omit `Get` and `Query` from query service RPC names +#### クエリサービスのRPC名から `Get`と` Query`を省略します -`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. +`Get`と` Query`は `Query`サービス名から省略されるべきです。 +完全修飾名では冗長です。たとえば、 `.cosmos.bank.Query .QueryBalance` +新しい情報なしで、「クエリ」を2回言うだけです。 -## 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. +ネーミングを調整するために、トップレベルのパッケージ名のレジストリを作成する必要があります +クロスエコロジカルで、競合を防ぎ、開発者が発見するのを助けます +便利なパターン。簡単な出発点はgitリポジトリです +コミュニティベースのガバナンス。 +## 結果 -## Consequences +### ポジティブ -### Positive +*名前はより簡潔で読みやすく入力しやすくなります +* `Any`を使用するすべてのトランザクションが短縮されます(` _sdk.x`と `.v1`は削除されます) +* `.proto`ファイルのインポートはより標準的になります(` "third_party .proto" `はありません +道) +* .protoファイルが +単一の `proto.`ディレクトリでは、散在する代わりにコピーできます +CosmosSDK全体 -* 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 Cosmos SDK +### ネガティブ -### Negative +### ニュートラル -### Neutral +* `.proto`ファイルを再編成して再構築する必要があります +*一部のモジュールはアルファまたはベータとしてマークする必要がある場合があります -* `.proto` files will need to be reorganized and refactored -* some modules may need to be marked as alpha or beta - -## References +## 参照 \ No newline at end of file diff --git a/docs/ja/architecture/adr-024-coin-metadata.md b/docs/ja/architecture/adr-024-coin-metadata.md index 5195a9c40008..92f2c358362b 100644 --- a/docs/ja/architecture/adr-024-coin-metadata.md +++ b/docs/ja/architecture/adr-024-coin-metadata.md @@ -1,50 +1,50 @@ -# ADR 024: Coin Metadata +# ADR 024:コインメタデータ -## Changelog +## 変更ログ -- 05/19/2020: Initial draft +2020年5月19日:最初のドラフト -## 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. +Cosmos SDKのアセットは、「amount」と「denom」で構成される「Coins」タイプで表されます。 +「金額」は、任意の大きい値または小さい値にすることができます。さらに、CosmosSDKは +アカウントベースのモデルには、基本アカウントとモジュールアカウントの2種類のメインアカウントがあります。 +すべてのアカウントタイプには、「コイン」で構成される一連の残高があります。 `x .bank`モジュールの保持 +すべてのアカウントのすべての残高を追跡し、1つのアカウントの残高の合計供給を追跡します +応用。 -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. +残高の「金額」に関して、Cosmos SDKは、静的および固定の額面単位を想定しています。 +金種自体に関係なく。つまり、クライアントとアプリケーションはCosmos-SDKベースで構築されています +チェーンは、より豊かなユーザーエクスペリエンスを提供するために、任意の金種単位を定義して使用することを選択できますが、 +txまたは操作がCosmosSDKステートマシンに到達すると、 `amount`は単一として扱われます +ユニット。たとえば、Cosmos Hub(Gaia)の場合、クライアントは1 ATOM = 10 ^ 6 uatomと想定しているため、すべてのtxと +Cosmos SDKの操作は、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. +これは明らかに、特にネットワークの相互運用性が向上し、 +その結果、資産タイプの総数が増加しました。 `x .bank`を保持することをお勧めします +各「デノム」のメタデータを追跡して、顧客、ウォレットプロバイダー、およびエクスプローラーが +UXを実行し、金種単位に関する仮定を行うための要件を削除します。 -## 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. +`x .bank`モジュールは、` denom`、特に "base"または +最小単位-CosmosSDKステートマシンで使用される単位。 -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`). +メタデータには、ゼロ以外の長さの宗派リストを含めることもできます。各エントリに含まれる名前 +宗派 `denom`、ベースインデックスおよびエイリアスのリスト。エントリは +「1denom = 10 ^ exponent base_denom」として解釈されます(たとえば、「1 ETH = 10 ^ 18wei」および「1uatom = 10 ^ 0uatom」)。 -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. +顧客にとって非常に重要な2つの宗派があります:最小の「ベース」 +人間のコミュニケーションで通常言及される単位である可能な単位と「ディスプレイ」 +そして通信します。これらのフィールドの値は、金種リストのエントリにリンクされています。 -The list in `denom_units` and the `display` entry may be changed via governance. +`denom_units`および` display`エントリのリストは、管理によって変更できます。 -As a result, we can define the type as follows: +したがって、タイプは次のように定義できます。 ```protobuf message DenomUnit { @@ -61,7 +61,7 @@ message Metadata { } ``` -As an example, the ATOM's metadata can be defined as follows: +たとえば、ATOMのメタデータは次のように定義できます。 ```json { @@ -91,20 +91,20 @@ As an example, the ATOM's metadata can be defined as follows: } ``` -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. +-4.3atom = 4.3 *(10 ^ 6)= 4,300,000uatom +-タグリストの表示名は文字列「atom」が使用できます。 +-バランス4300000は、4,300,000uatomまたは4,300matomまたは4.3atomとして表示できます。 + クライアントの作成者が作成しなかった場合は、4.3atomの `display`単位が適切なデフォルト値です。 + 別の表現を選択するという明確な決定。 -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. +クライアントは、CLIおよびRESTインターフェースを介して名前でメタデータを照会できる必要があります。 存在 +さらに、これらのインターフェイスにハンドラーを追加して、任意のユニットを別の特定のユニットに変換します。 +この基本的なフレームワークはすでにCosmosSDKに存在しているためです。 -Finally, we need to ensure metadata exists in the `GenesisState` of the `x/bank` module which is also -indexed by the base `denom`. +最後に、メタデータが `x .bank`モジュールの` GenesisState`に存在することを確認する必要があります。これも +ベース `denom`によってインデックス付けされます。 ```go type GenesisState struct { @@ -115,25 +115,24 @@ type GenesisState struct { } ``` -## 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 +-`x .bank`モジュールに必要な少量の追加ストレージスペース。 量 + 総資産の量はすべきではないため、追加のストレージの量は最小限にする必要があります + 大きい。 -- 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 +## 参照 \ No newline at end of file diff --git a/docs/ja/architecture/adr-027-deterministic-protobuf-serialization.md b/docs/ja/architecture/adr-027-deterministic-protobuf-serialization.md index 41c8d2fc10f6..019774e1de17 100644 --- a/docs/ja/architecture/adr-027-deterministic-protobuf-serialization.md +++ b/docs/ja/architecture/adr-027-deterministic-protobuf-serialization.md @@ -1,188 +1,188 @@ -# ADR 027: Deterministic Protobuf Serialization +# ADR 027:確定的Protobufシリアル化 -## Changelog +## 変更ログ -- 2020-08-07: Initial Draft -- 2020-09-01: Further clarify rules +-2020-08-07:最初のドラフト +-2020-09-01:ルールをさらに明確にする -## 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): +シリアル化は全単射ではありません(つまり、実際には無限の数があります +指定されたprotobufドキュメントの有効なバイナリ表現) 1 <.sup>。 + +このドキュメントでは、決定論的なシリアル化スキームについて説明します +このユースケースをカバーするprotobufドキュメントのサブセットですが、 +他の状況でも同じことが言えます。 + +### 環境 + +Cosmos SDKでの署名検証では、署名者と検証者が合意に達する必要があります +`SignDoc`で定義されているのと同じシリアル化 +[ADR-020](..adr-020-protobuf-transaction-encoding.md)は送信しません +シリアル化。 + +現在、ブロック署名には回避策を使用しています。新しい[TxRaw]を作成します(https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1proto#L30x) +例([adr-020-protobuf-transaction-encoding](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-020-protobuf-transaction-encoding.md#で定義)トレード)) +すべての[Tx]を変換する(https://github.com/cosmos/cosmos-sdk/blob/9e85e81e0e8140067dd893421290c191529c148c/proto/cosmos/tx/v1beta1/tx.proto#L13) +フィールドからクライアントまでのバイト数。これにより、追加のマニュアルが追加されます +トランザクションを送信および署名する際の手順。 + +### 決定 + +次のコーディングスキームは、他のADRで使用されます。 +特に `SignDoc`シリアル化の場合。 + +## 仕様 + +### スコープ + +このADRは、protobuf3シリアライザーを定義します。出力は有効なprotobufです +すべてのprotobufパーサーが解析できるようにシリアル化します。 + +定義が複雑なため、バージョン1ではマッピングはサポートされていません。 +決定論的シリアル化。これは将来変更される可能性があります。実装する必要があります +マップを含むドキュメントは、無効な入力として拒否されます。 + +### 背景-Protobuf3エンコーディング + +protobuf3のほとんどの数値タイプは、次のようにエンコードされます。 +[varints](https://developers.google.com/protocol-buffers/docs/encoding#varints)。 +各varintバイトには7ビットのデータがあるため、varintは最大10バイトになる可能性があります。 +varintsは、 `uint70`(70ビットの符号なし整数)の表現です。いつ +エンコードすると、値は基本タイプから `uint70`に変換され、 +デコード時に、解析されたuint70は適切な数値型に変換されます。 + +protobuf3に準拠するvarintの最大有効値 +`FF FF FF FF FF FF FF FF FF 7F`(つまり` 2 ** 70 -1`)。フィールドタイプが +`{、u、s} int64`、70ビットの上位6ビットは、デコードプロセス中に破棄されます。 +6ビットの延性を導入します。フィールドタイプが `{、u、s} int32`の場合、 +70の最上位38ビットはデコードプロセス中に破棄され、38ビットが導入されます +可鍛性。 + +他の不確実性の原因の中でも、このADRは次の可能性を排除します +可鍛性のコーディング。 + +### シリアル化ルール + +シリアル化はに基づいています +[protobuf3エンコーディング](https://developers.google.com/protocol-buffers/docs/encoding) +次のコンテンツが追加されました。 + +1.フィールドは昇順で1回だけシリアル化できます +2.追加のフィールドまたは追加のデータを追加することはできません +3. [デフォルト値](https://developers.google.com/protocol-buffers/docs/proto3#default) + 省略しなければならない +4.スカラー数値型の `repeated`フィールドを使用する必要があります + [パッキングエンコーディング](https://developers.google.com/protocol-buffers/docs/encoding#packed) +5.Varintエンコーディングは必要性を超えることはできません。 + *末尾のゼロバイトはありません(つまり、小さい方の端には、大きい方の先頭のゼロはありません) + エンディアン)。上記のルール3によると、デフォルト値の「0」は省略しなければならないため、 + この規則は、そのような状況には適用されません。 + ※varintの最大値は `FF FF FF FF FF FF FF FFFF01`である必要があります。 + 言い換えると、デコードするとき、70ビットの符号なしの上位6ビット + 整数は「0」でなければなりません。 (10バイトのvarintは、7ビットの10グループです。 + 70ビット。そのうち最下位の70-6 = 64のみが有用です。 )。 + * varintエンコーディングの32ビット値の最大値は、 `FF FF FF FF0F`である必要があります + 1つの例外を除いて(以下)。言い換えれば、デコードするとき、最高の38 + 70ビットの符号なし整数のビットは「0」である必要があります。 + *上記の1つの例外は、_negative_`int32`です。 + 完全な10バイトエンコーディングを使用して、拡張機能 2 <.sup>に署名します。 + * varintエンコーディングのブール値の最大値は「01」である必要があります(つまり、 + 「0」または「1」である必要があります)。上記のルール3によると、デフォルト値の「0」は + 省略されているため、ブール値が含まれている場合、その値は「1」である必要があります。 + +ルール1と2は非常に単純で、説明する必要がありますが +作成者に知られているすべてのprotobufエンコーダーのデフォルトの動作、3番目のルール +もっと楽しく。 protobuf3の逆シリアル化後は、区別できません +未設定フィールドとデフォルト値として設定されたフィールドの間の 3 <.sup>。存在 +ただし、シリアル化レベルでは、フィールドを空に設定できます +それらに注意を払うか、それらを完全に省略してください。これは、JSONなどの重要な違いです +属性は空( `" "`、 `0`)、` null`、または未定義にすることができ、結果として3になります。 +別のファイル。 + +パーサーが割り当てる必要があるため、デフォルト値として設定されたフィールドを省略することは有効です。 +シリアル化で欠落しているフィールドのデフォルト値は 4 <.sup>です。スカラーの場合 +タイプ、仕様では、デフォルト値 5 <.sup>を省略する必要があります。 「リピート」の場合 +空のリストを表現する唯一の方法は、フィールドをシリアル化する代わりに使用することです。列挙型は +値が0の最初の要素があります。これはデフォルトの 6 <.sup>です。と +メッセージフィールドのデフォルトはunset 7 <.sup>です。 + +デフォルト値を省略すると、ある程度の上位互換性が得られます。 +新しいバージョンのprotobufモードでは、ユーザーと同じシリアル化が生成されます +新しく追加されたフィールドが使用されていない限り(つまり、 +デフォルト)。 + +### 埋め込む + +低から高にソートされた3つの主要な実装戦略があります +ほとんどのカスタム開発: + +-**上記のルールに従うprotobufシリアライザーがデフォルトで使用されます。 ** 例えば + [gogoproto](https://pkg.go.dev/github.com/gogo/protobuf/gogoproto)既知 + ほとんどの場合に会いますが、いくつかのメモ(例: + `nullable = false`を使用します。それはまたオプションかもしれません + これに対応して、既存のシリアル化プログラム。 +-**エンコードする前にデフォルト値を標準化します。 **シリアル化プログラムが次の場合 + ルール1.および2.で、フィールドのシリアル化を明示的に解除できます。 + デフォルト値を正規化して設定しないようにすることができます。これは、使用中に行うことができます + [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 + 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: +-**必要なタイプの手書きのシリアル化プログラムを使用します。 **上記のいずれでもない場合 + この方法は便利です。独自のシリアル化プログラムを作成できます。 SignDocの場合これ + Goでは、既存のprotobufユーティリティに基づいて次のように表示されます。 ```go if !signDoc.body_bytes.empty() { - buf.WriteUVarInt64(0xA) // wire type and field number for body_bytes + 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(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(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.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.WriteUVarInt64(0x28)..wire type and field number for account_sequence buf.WriteUVarInt(signDoc.account_sequence) } ``` ### Test vectors -Given the protobuf definition `Article.proto` +protobufが `Article.proto`を定義しているとすると ```protobuf package blog; @@ -248,67 +248,67 @@ $ echo 0a1b54686520776f726c64206e65656473206368616e676520f09f8cb318e8bebec8bc2e2 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. +このようなエンコーディングを使用すると、決定論的なシリアル化を取得できます +CosmosSDK署名コンテキストで必要なすべてのprotobufドキュメント。 -### 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. +-参照とは無関係に検証できる明確に定義されたルール + 埋め込む +-トランザクション署名を実装するための障壁を下げるのに十分シンプル +-SignDocで0およびその他のnull値を引き続き使用して回避することができます + 0シーケンスを解く必要があります。これはからという意味ではありません + https://github.com/cosmos/cosmos-sdk/pull/6949はマージしないでくださいが、マージしないでください + 重要すぎる。 -### 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. +-トランザクション署名を実装する場合は、上記のコーディングルールに準拠する必要があります + 理解して実行します。 +-ルール番号3が必要なため、実装が複雑になります。 +-特定のデータ構造では、シリアル化のためにカスタムコードが必要になる場合があります。したがって + コードはあまり移植性がありません-それぞれに追加の作業が必要です + クライアントは、カスタムデータ構造を正しく処理するためにシリアル化を実装します。 -### Neutral +### ニュートラル -### Usage in Cosmos SDK +### CosmosSDKでの使用法 -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). +上記の理由(「ネガティブ」な部分)のため、回避策を維持することをお勧めします +データ構造を共有するために使用されます。例:前述の `TxRaw`は生のバイトを使用します +解決策として。これにより、有効なProtobufライブラリを使用せずに使用できます。 +この標準(および関連するエラーリスク)を満たすカスタムシリアル化プログラムを実装する必要があります。 -## 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 +- 1 <.sup> _メッセージがシリアル化される場合、順序は保証されません + 既知または未知のフィールドをどのように書き込む必要がありますか。シリアル化の順序は + 実装の詳細および特定の実装の詳細は、 + 将来の変更。したがって、プロトコルバッファパーサーは解析できる必要があります + 任意の順序のフィールド。 _から 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 +- 2 <.sup> https://developers.google.com/protocol-buffers/docs/encoding#signed_integers +- 3 <.sup> _スカラーメッセージフィールドの場合、メッセージが解析されると + フィールドが明示的にデフォルト値に設定されているかどうかを判断する方法はありません + 値(ブール値がfalseに設定されているかどうかなど)またはまったく設定されていない場合: + メッセージタイプを定義するときは、このことに注意する必要があります。例えば、 + falseに設定すると、ブール値のいずれも特定の動作を有効にしません。 + この動作がデフォルトで発生することは望ましくありません。 _から 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 +- 4 <.sup> _メッセージが解析されるとき、エンコードされたメッセージが解析されない場合 + 特定の特異要素、分析の対応するフィールドが含まれています + オブジェクトはフィールドのデフォルト値に設定されます。 _から 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 +- 5 <.sup> _スカラーメッセージフィールドがデフォルト値に設定されている場合は、 + 値はオンラインでシリアル化されません。 _から 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 +- 6 <.sup> _列挙の場合、デフォルト値は最初に定義された列挙値です。 + 0である必要があります。 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 +- 7 <.sup> _メッセージフィールドの場合、このフィールドは設定されていません。その正確な値は + 言語関連。 _から 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) +-コーディングルールと推論の一部は、 + [canonical-proto3 Aaron Craelius](https://github.com/regen-network/canonical-proto3) \ No newline at end of file diff --git a/docs/ja/architecture/adr-028-public-key-addresses.md b/docs/ja/architecture/adr-028-public-key-addresses.md index 51ccc4390d75..f8649cbba7c1 100644 --- a/docs/ja/architecture/adr-028-public-key-addresses.md +++ b/docs/ja/architecture/adr-028-public-key-addresses.md @@ -1,103 +1,103 @@ -# ADR 028: Public Key Addresses +# ADR 028:公開鍵アドレス -## Changelog +## 変更ログ -- 2020/08/18: Initial version -- 2021/01/15: Analysis and algorithm update +-2020/08/18:初期バージョン +-2021 .01/15:分析とアルゴリズムの更新 -## Status +## 状態 -Proposed +提案 -## Abstract +## 概要 -This ADR defines an address format for all addressable Cosmos SDK accounts. That includes: new public key algorithms, multisig public keys, and module accounts. +このADRは、アドレス可能なすべてのCosmosSDKアカウントのアドレス形式を定義します。これには、新しい公開鍵アルゴリズム、マルチ署名公開鍵、およびモジュールアカウントが含まれます。 -## Context +## 環境 -Issue [\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685) identified that public key -address spaces are currently overlapping. We confirmed that it significantly decreases security of Cosmos SDK. +問題[\#3685](https://github.com/cosmos/cosmos-sdk/issues/3685)で公開鍵が確認されました +アドレス空間は現在重複しています。 CosmosSDKのセキュリティが大幅に低下することを確認しました。 -### Problem +### 問題 -An attacker can control an input for an address generation function. This leads to a birthday attack, which significantly decreases the security space. -To overcome this, we need to separate the inputs for different kind of account types: -a security break of one account type shouldn't impact the security of other account types. +攻撃者はアドレス生成機能の入力を制御できます。これは誕生日攻撃につながる可能性があり、セキュリティスペースが大幅に減少します。 +この問題を克服するには、さまざまな種類の口座の入力を分離する必要があります。 +1つのアカウントタイプのセキュリティの中断は、他のアカウントタイプのセキュリティに影響を与えるべきではありません。 -### Initial proposals +### 予備的な提案 -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: +@ethanfreyは、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 +>ウィーブを構築するときに、これについて考えることに多くの時間を費やしました...別のユニバースSDK。 +>基本的に、条件をタイプとフォーマット、人間が読める文字列として定義し、いくつかのバイナリデータを追加します。この条件は、アドレス(これも20バイト)にハッシュされます。このプレフィックスを使用すると、条件が異なる特定のアドレスのプレイメージを見つけることができなくなります(たとえば、ed25519とsecp256k1)。 +>ここに詳細な説明がありますhttps://weave.readthedocs.io/en/latest/design/permissions.html +>そして、コードはここにあり、主に処理条件の最上位にあります。 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. +>はい、AFAIK、元の画像が一意で拡張不可能な場合、20バイトは衝突耐性が必要です。 2 ^ 160スペースでは、2 ^ 80要素の近くで衝突が発生すると予想されます(誕生日のパラドックス)。データベース内の既存の要素の競合を見つけたい場合でも、2 ^ 160です。 2 ^ 80これらすべての要素が状態で書き込まれる場合のみ。 +>あなたの良い例は例えばです。公開鍵バイトは、コーデックでサポートされている2つのアルゴリズムの有効な公開鍵です。これは、それらのいずれかが侵害された場合、それらがより安全な亜種によって保護されていても、アカウントを侵害することを意味します。これは、元の画像に識別可能なタイプ情報がない場合にのみ問題になります(アドレスにハッシュする前)。 +> 20バイトのスペースが実際のセキュリティの問題である場合、編み物中にアドレスサイズを増やして喜んでいるので、議論を聞きたいと思います。コスモス、イーサリアム、ビットコインはすべて20バイトを使用していると思いますが、これで十分です。そして、上記の議論は私にそれが安全であると感じさせます。しかし、私はこれ以上詳細な分析はしませんでした。 -This led to the first proposal (which we proved to be not good enough): -we concatenate a key type with a public key, hash it and take the first 20 bytes of that hash, summarized as `sha256(keyTypePrefix || keybytes)[:20]`. +これが最初の提案につながりました(私たちはそれが十分ではないことを証明しました): +キータイプを公開キーと連結し、ハッシュしてハッシュの最初の20バイトを取得し、合計して `sha256(keyTypePrefix || keybytes)[:20]`とします。 -### Review and Discussions +### レビューとディスカッション -In [\#5694](https://github.com/cosmos/cosmos-sdk/issues/5694) we discussed various solutions. -We agreed that 20 bytes it's not future proof, and extending the address length is the only way to allow addresses of different types, various signature types, etc. -This disqualifies the initial proposal. +[\#5694](https://github.com/cosmos/cosmos-sdk/issues/5694)では、さまざまなソリューションについて説明しました。 +20バイトは将来の証拠ではなく、アドレス長を延長することが、さまざまなタイプ、さまざまな署名タイプなどのアドレスを許可する唯一の方法であることに同意します。 +これにより、元の提案は失格となりました。 -In the issue we discussed various modifications: +この質問では、さまざまな変更について説明しました。 -+ Choice of the hash function. -+ Move the prefix out of the hash function: `keyTypePrefix + sha256(keybytes)[:20]` [post-hash-prefix-proposal]. -+ Use double hashing: `sha256(keyTypePrefix + sha256(keybytes)[:20])`. -+ Increase to keybytes hash slice from 20 byte to 32 or 40 bytes. We concluded that 32 bytes, produced by a good hash functions is future secure. ++ハッシュ関数の選択。 ++プレフィックスをハッシュ関数から移動します: `keyTypePrefix + sha256(keybytes)[:20]` [post-hash-prefix-proposal]。 ++ダブルハッシュを使用します: `sha256(keyTypePrefix + sha256(keybytes)[:20])`。 ++キーバイトのハッシュスライスを20バイトから32バイトまたは40バイトに増やします。優れたハッシュ関数によって生成された32バイトは、将来的に安全であると結論付けました。 -### Requirements +### 要件 -+ Support currently used tools - we don't want to break an ecosystem, or add a long adaptation period. Ref: https://github.com/cosmos/cosmos-sdk/issues/8041 -+ Try to keep the address length small - addresses are widely used in state, both as part of a key and object value. ++現在使用されているツールをサポートする-エコシステムに損害を与えたり、適応期間を長くしたりしたくありません。参照:https://github.com/cosmos/cosmos-sdk/issues/8041 ++アドレスの長さをできるだけ短くするようにしてください。アドレスは、キーとオブジェクトの値の一部として状態で広く使用されています。 -### Scope +### スコープ -This ADR only defines a process for the generation of address bytes. For end-user interactions with addresses (through the API, or CLI, etc.), we still use bech32 to format these addresses as strings. This ADR doesn't change that. -Using Bech32 for string encoding gives us support for checksum error codes and handling of user typos. +ADRは、アドレスバイトを生成するためのプロセスのみを定義します。エンドユーザーとアドレス間の対話(APIやCLIなどを介した)では、引き続きbech32を使用してこれらのアドレスを文字列にフォーマットします。 ADRはこれを変更しません。 +文字列エンコーディングにBech32を使用すると、チェックサムエラーコードとユーザースペルエラーの処理がサポートされます。 -## Decision +## 決定 -We define the following account types, for which we define the address function: +次のアカウントタイプを定義し、それらのアドレス関数を定義しました。 -1. simple accounts: represented by a regular public key (ie: secp256k1, sr25519) -2. naive multisig: accounts composed by other addressable objects (ie: naive multisig) -3. composed accounts with a native address key (ie: bls, group module accounts) -4. module accounts: basically any accounts which cannot sign transactions and which are managed internally by modules +1.単純なアカウント:共通の公開鍵で表されます(例:secp256k1、sr25519) +2. naive multisig:他のアドレス可能なオブジェクトで構成されるアカウント(例:naive multisig) +3.ローカルアドレスキーの組み合わせアカウント(例:bls、グループモジュールアカウント)を使用します +4.モジュールアカウント:基本的に、トランザクションに署名できず、モジュールによって内部的に管理されるすべてのアカウント -### Legacy Public Key Addresses Don't Change +###レガシー公開鍵アドレスは変更されません -Currently (Jan 2021), the only officially supported Cosmos SDK user accounts are `secp256k1` basic accounts and legacy amino multisig. -They are used in existing Cosmos SDK zones. They use the following address formats: +現在(2021年1月)、公式にサポートされているCosmos SDKユーザーアカウントは、「secp256k1」基本アカウントと従来のアミ​​ノマルチシグニチャのみです。 +これらは、既存のCosmosSDKエリアで使用されます。次のアドレス形式を使用します。 -- secp256k1: `ripemd160(sha256(pk_bytes))[:20]` -- legacy amino multisig: `sha256(aminoCdc.Marshal(pk))[:20]` +-secp256k1: `ripemd160(sha256(pk_bytes))[:20]` +-従来のアミ​​ノマルチ署名: `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. +既存の住所を変更したくありません。したがって、これら2つのキータイプのアドレスは変更されません。 -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. +現在のマルチ署名公開鍵は、アミノシリアル化を使用してアドレスを生成します。維持します +それらの公開鍵とそのアドレス形式、およびそれらを「従来のアミ​​ノ」マルチ署名公開鍵と呼びます +protobufで。また、以下に説明するように、アミノアドレスのないマルチ署名公開鍵を作成します。 -### Hash Function Choice +###ハッシュ関数の選択 -As in other parts of the Cosmos SDK, we will use `sha256`. +Cosmos SDKの他の部分と同様に、sha256を使用します。 -### Basic Address +### ベースアドレス -We start with defining a base hash algorithm for generating addresses. Notably, it's used for accounts represented by a single key pair. For each public key schema we have to have an associated `typ` string, which we discuss in a section below. `hash` is the cryptographic hash function defined in the previous section. +まず、アドレスの生成に使用される基本的なハッシュアルゴリズムを定義します。単一のキーペアで表されるアカウントに使用されることは注目に値します。公開鍵モードごとに、関連付けられた `typ`文字列が必要です。これについては、次のセクションで説明します。 `hash`は、前のセクションで定義した暗号化ハッシュ関数です。 ```go const A_LEN = 32 @@ -107,26 +107,26 @@ func Hash(typ string, key []byte) []byte { } ``` -The `+` is bytes concatenation, which doesn't use any separator. +`+`は、区切り文字のないバイト連結です。 -This algorithm is the outcome of a consultation session with a professional cryptographer. -Motivation: this algorithm keeps the address relatively small (length of the `typ` doesn't impact the length of the final address) -and it's more secure than [post-hash-prefix-proposal] (which uses the first 20 bytes of a pubkey hash, significantly reducing the address space). -Moreover the cryptographer motivated the choice of adding `typ` in the hash to protect against a switch table attack. +アルゴリズムは、プロの暗号学者との協議の結果です。 +動機:アルゴリズムはアドレスを比較的小さく保ちます( `typ`の長さは最終的なアドレスの長さに影響しません) +また、[post-hash-prefix-proposal]よりも安全です(公開鍵ハッシュの最初の20バイトを使用して、アドレス空間を大幅に削減します)。 +さらに、暗号技術者は、スイッチテーブル攻撃を防ぐためにハッシュに「typ」を追加することを選択するよう促しました。 -We use the `address.Hash` function for generating addresses for all accounts represented by a single key: +`address.Hash`関数を使用して、単一のキーで表されるすべてのアカウントのアドレスを生成します。 -* simple public keys: `address.Hash(keyType, pubkey)` +*単純な公開鍵: `address.Hash(keyType、pubkey)` -+ aggregated keys (eg: BLS): `address.Hash(keyType, aggregatedPubKey)` -+ modules: `address.Hash("module", moduleName)` ++集約キー(例:BLS): `address.Hash(keyType、aggregatedPubKey)` ++モジュール: `address.Hash(" module "、moduleName)` -### Composed Addresses +### 結合されたアドレス -For simple composed accounts (like new naive multisig), we generalize the `address.Hash`. The address is constructed by recursively creating addresses for the sub accounts, sorting the addresses and composing them into a single address. It ensures that the ordering of keys doesn't impact the resulting address. +単純な組み合わせアカウント(新しい単純なマルチ署名など)の場合、「address.Hash」を一般化します。 アドレスは、サブアカウントのアドレスを再帰的に作成し、アドレスを並べ替えて、それらを1つのアドレスに結合することによって作成されます。 キーの順序が結果のアドレスに影響を与えないようにします。 ```go -// We don't need a PubKey interface - we need anything which is addressable. +/.We don't need a PubKey interface - we need anything which is addressable. type Addressable interface { Address() []byte } @@ -138,17 +138,17 @@ func Composed(typ string, subaccounts []Addressable) []byte { } ``` -The `typ` parameter should be a schema descriptor, containing all significant attributes with deterministic serialization (eg: utf8 string). -`LengthPrefix` is a function which prepends 1 byte to the address. The value of that byte is the length of the address bits before prepending. The address must be at most 255 bits long. -We are using `LengthPrefix` to eliminate conflicts - it assures, that for 2 lists of addresses: `as = {a1, a2, ..., an}` and `bs = {b1, b2, ..., bm}` such that every `bi` and `ai` is at most 255 long, `concatenate(map(as, \a -> LengthPrefix(a))) = map(bs, \b -> LengthPrefix(b))` iff `as = bs`. +`typ`パラメータは、決定論的なシリアル化を伴うすべての重要な属性を含むパターン記述子である必要があります(例:utf8文字列)。 +`LengthPrefix`は、アドレスの1バイト前に追加する関数です。 このバイトの値は、フロントの前のアドレスビットの長さです。 アドレスの長さは最大255ビットです。 +競合を排除するために `LengthPrefix`を使用します-2つのアドレスリストに対して` as =(a1、a2、...、an} `と` bs =(b1、b2、...、bm) `すべての `bi`と` ai`の長さは最大255です。`concatenate(map(as、\ a-> LengthPrefix(a)))= map(bs、\ b-> LengthPrefix(b)) `iff` as = bs`。 -Implementation Tip: account implementations should cache addresses. +実装のヒント:アカウントの実装では、アドレスをキャッシュする必要があります。 -#### Multisig Addresses +#### マルチシグニチャアドレス -For new multisig public keys, we define the `typ` parameter not based on any encoding scheme (amino or protobuf). This avoids issues with non-determinism in the encoding scheme. +新しいマルチ署名公開鍵では、エンコードスキーム(aminoまたはprotobuf)に基づかない `typ`パラメーターを定義します。 これにより、コーディングスキームの不確実性の問題が回避されます。 -Example: +例: ```proto package cosmos.crypto.multisig; @@ -161,32 +161,32 @@ message PubKey { ```go func (multisig PubKey) Address() { - // first gather all nested pub keys - var keys []address.Addressable // cryptotypes.PubKey implements Addressable + ..first gather all nested pub keys + var keys []address.Addressable ..cryptotypes.PubKey implements Addressable for _, _key := range multisig.Pubkeys { keys = append(keys, key.GetCachedValue().(cryptotypes.PubKey)) } - // form the type from the message name (cosmos.crypto.multisig.PubKey) and the threshold joined together + ..form the type 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 Composed function defined above + ..use the Composed function defined above return address.Composed(prefix, keys) } ``` -#### Module Account Addresses +#### モジュールアカウントアドレス -NOTE: this section is not finalize and it's in active discussion. +注:このセクションはまだ完了しておらず、活発に議論されています。 -In Basic Address section we defined a module account address as: +基本アドレスの部分では、モジュールアカウントアドレスを次のように定義します。 ```go address.Hash("module", moduleName) ``` -We use `"module"` as a schema type for all module derived addresses. Module accounts can have sub accounts. The derivation process has a defined order: module name, submodule key, subsubmodule key. -Module account addresses are heavily used in the Cosmos SDK so it makes sense to optimize the derivation process: instead of using of using `LengthPrefix` for the module name, we use a null byte (`'\x00'`) as a separator. This works, because null byte is not a part of a valid module name. +すべてのモジュール派生アドレスのパターンタイプとして「モジュール」を使用します。 モジュールアカウントはサブアカウントを持つことができます。 派生プロセスには、モジュール名、サブモジュールキー、サブサブモジュールキーの定義されたシーケンスがあります。 +モジュールアカウントアドレスはCosmosSDKで広く使用されているため、派生プロセスを最適化することは理にかなっています。モジュール名として `LengthPrefix`ではなく、区切り文字としてnullバイト(` '\ x00'`)を使用します。 nullバイトは有効なモジュール名の一部ではないため、これは有効です。 ```go func Module(moduleName string, key []byte) []byte{ @@ -200,15 +200,15 @@ func Module(moduleName string, key []byte) []byte{ btcPool := address.Module("lending", btc.Addrress()}) ``` -If we want to create an address for a module account depending on more than one key, we can concatenate them: +複数のキーに基づいてモジュールアカウントのアドレスを作成する場合は、それらを接続できます。 ``` btcAtomAMM := address.Module("amm", btc.Addrress() + atom.Address()}) ``` -#### Derived Addresses +#### 派生アドレス -We must be able to cryptographically derive one address from another one. The derivation process must guarantee hash properties, hence we use the already defined `Hash` function: +パスワードを使用して、別のアドレスからアドレスを取得できる必要があります。 派生プロセスはハッシュ属性を保証する必要があるため、すでに定義されている `Hash`関数を使用します。 ```go func Derive(address []byte, derivationKey []byte) []byte { @@ -216,20 +216,20 @@ func Derive(address []byte, derivationKey []byte) []byte { } ``` -Note: `Module` is a special case of the more general _derived_ address, where we set the `"module"` string for the _from address_. +注: `モジュール`は、より普通家族_derivative_稼の特別なケースであり、_fromaddress_に文字列 `"モジュール "`を設定します。 -**Example** For a cosmwasm smart-contract address we could use the following construction: +**例** cosmwasmの場合、時間の構造であるスマートコントラクトを使用します。 ``` smartContractAddr := Derived(Module("cosmwasm", smartContractsNamespace), []{smartContractKey}) ``` -### Schema Types +### スキーマタイプ -A `typ` parameter used in `Hash` function SHOULD be unique for each account type. -Since all Cosmos SDK account types are serialized in the state, we propose to use the protobuf message name string. +`Hash`関数で使用される` typ`パラメータは、アカウントタイプごとに一意である必要があります。 +すべてのCosmosSDKアカウントタイプは状態でシリアル化されるため、protobufメッセージ名文字列を使用することをお勧めします。 -Example: all public key types have a unique protobuf message type similar to: +例:すべての公開鍵タイプには、次のような一意のprotobufメッセージタイプがあります。 ```proto package cosmos.crypto.sr25519; @@ -239,91 +239,91 @@ message PubKey { } ``` -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. We can easily obtain the name using -`proto.MessageName(msg)`. +すべてのprotobufメッセージには、一意の完全修飾名があります。この例では、「cosmos.crypto.sr25519.PubKey」です。 +これらの名前は、標準化された方法で.protoファイルから直接派生して使用されます +`Any`sのタイプURLなどの他の場所。次の方法で簡単に名前を取得できます +`proto.MessageName(msg)`。 -## Consequences +## 結果 -### Backwards Compatibility +###下位互換性 -This ADR is compatible with what was committed and directly supported in the Cosmos SDK repository. +このADRは、Cosmos SDKリポジトリで送信され、直接サポートされているコンテンツと互換性があります。 -### Positive +### ポジティブ -- a simple algorithm for generating addresses for new public keys, complex accounts and modules -- the algorithm generalizes _native composed keys_ -- increased security and collision resistance of addresses -- the approach is extensible for future use-cases - one can use other address types, as long as they don't conflict with the address length specified here (20 or 32 bytes). -- support new account types. +-新しい公開鍵、複雑なアカウント、モジュールのアドレスを生成するためのシンプルなアルゴリズム +-アルゴリズムは_ネイティブキーの組み合わせ_を要約します +-アドレスのセキュリティと衝突防止を改善します +-この方法は、将来のユースケースに拡張できます。-ここで指定されたアドレス長(20または32バイト)と競合しない限り、他のアドレスタイプを使用できます。 +-新しいアカウントタイプをサポートします。 -### Negative +### ネガティブ -- addresses do not communicate key type, a prefixed approach would have done this -- addresses are 60% longer and will consume more storage space -- requires a refactor of KVStore store keys to handle variable length addresses +-アドレスはキータイプを伝達しません。プレフィックスメソッドはこれを実行できます +-アドレスが60％長くなり、より多くのストレージスペースを消費します +-可変長アドレスを処理するためにKVStoreストレージキーを再構築する必要があります -### Neutral +### ニュートラル -- protobuf message names are used as key type prefixes +-protobufメッセージ名はキータイププレフィックスとして使用されます -## Further Discussions +##さらなる議論 -Some accounts can have a fixed name or may be constructed in other way (eg: modules). We were discussing an idea of an account with a predefined name (eg: `me.regen`), which could be used by institutions. -Without going into details, these kinds of addresses are compatible with the hash based addresses described here as long as they don't have the same length. -More specifically, any special account address must not have a length equal to 20 or 32 bytes. +一部のアカウントには固定名を付けることも、他の方法で作成することもできます(例:モジュール)。組織で使用できる事前定義された名前(例: `me.regen`)を持つアカウントのアイデアについて話し合っています。 +言うまでもなく、これらのタイプのアドレスは、長さが異なる限り、ここで説明するハッシュベースのアドレスと互換性があります。 +より具体的には、特別なアカウントアドレスの長さは20バイトまたは32バイトに等しくてはなりません。 -## Appendix: Consulting session +##付録:コンサルティングセッション -End of Dec 2020 we had a session with [Alan Szepieniec](https://scholar.google.be/citations?user=4LyZn8oAAAAJ&hl=en) to consult the approach presented above. +2020年12月末に、[Alan Szepieniec](https://scholar.google.be/citations?user=4LyZn8oAAAAJ&hl=en)とミーティングを行い、上記の方法について相談しました。 -Alan general observations: +アランの一般的なコメント: -+ we don’t need 2-preimage resistance -+ we need 32bytes address space for collision resistance -+ when an attacker can control an input for object with an address then we have a problem with birthday attack -+ there is an issue with smart-contracts for hashing -+ sha2 mining can be use to breaking address pre-image ++2つのプリイメージ抵抗は必要ありません ++衝突に抵抗するために32バイトのアドレス空間が必要です ++攻撃者がアドレスを介してオブジェクトの入力を制御できる場合、誕生日攻撃の問題が発生します ++ハッシュに使用されるスマートコントラクトに問題があります ++ sha2マイニングを使用して、元のアドレスを解読できます -Hashing algorithm +ハッシュアルゴリズム -+ any attack breaking blake3 will break blake2 -+ Alan is pretty confident about the current security analysis of the blake hash algorithm. It was a finalist, and the author is well known in security analysis. ++ blake3を破壊する攻撃は、blake2を破壊します ++ Alanは、ブレイクハッシュアルゴリズムの現在のセキュリティ分析に非常に自信を持っています。決勝戦の最終候補に挙げられた著者は、証券分析でよく知られています。 -Algorithm: +アルゴリズム: -+ Alan recommends to hash the prefix: `address(pub_key) = hash(hash(key_type) + pub_key)[:32]`, main benefits: - + we are free to user arbitrary long prefix names - + we still don’t risk collisions - + switch tables -+ discussion about penalization -> about adding prefix post hash -+ Aaron asked about post hash prefixes (`address(pub_key) = key_type + hash(pub_key)`) and differences. Alan noted that this approach has longer address space and it’s stronger. ++ Alanは、プレフィックスをハッシュすることを提案しています: `address(pub_key)= hash(hash(key_type)+ pub_key)[:32]`、主な利点: + +任意の長いプレフィックス名を自由に使用できます + +私たちはまだ衝突の危険を冒しません + +スイッチテーブル ++罰についての議論->プレフィックスを追加した後のハッシュについて ++ Aaronは、ハッシュ後のプレフィックス( `address(pub_key)= key_type + hash(pub_key)`)とその違いについて質問しました。 Alanは、この方法はアドレススペースが長く、より強力であると指摘しました。 -Algorithm for complex / composed keys: +複雑な/結合されたキーのアルゴリズム: -+ merging tree like addresses with same algorithm are fine ++同じアルゴリズムを使用して類似したアドレスを持つツリーをマージするのは良いことです -Module addresses: Should module addresses have different size to differentiate it? +モジュールアドレス:モジュールアドレスは、それらを区別するために異なるサイズにする必要がありますか？ -+ we will need to set a pre-image prefix for module addresse to keept them in 32-byte space: `hash(hash('module') + module_key)` -+ Aaron observation: we already need to deal with variable length (to not break secp256k1 keys). ++モジュールアドレスのプレイメージプレフィックスを設定して、32バイトのスペースに保持する必要があります: `hash(hash( 'module')+ module_key)` ++アーロンの観察:(secp256k1キーを破壊しないために)可変長を処理する必要があります。 -Discssion about arithmetic hash function for ZKP +ZKP算術ハッシュ関数に関する議論 -+ Posseidon / Rescue -+ Problem: much bigger risk because we don’t know much techniques and history of crypto-analysis of arithmetic constructions. It’s still a new ground and area of active research. ++ポセイドン/レスキュー ++問題:暗号解読技術と算術構造の歴史についてほとんど知らないため、リスクははるかに大きくなります。これはまだ新しい分野であり、活発な研究の分野です。 -Post quantum signature size +ポスト量子署名のサイズ -+ Alan suggestion: Falcon: speed / size ration - very good. -+ Aaron - should we think about it? - Alan: based on early extrapolation this thing will get able to break EC cryptography in 2050 . But that’s a lot of uncertainty. But there is magic happening with recurions / linking / simulation and that can speedup the progress. ++アランの提案:ファルコン:速度/体のサイズの比率-とても良い。 ++アーロン-私たちはそれについて考えるべきですか？ + アラン:初期の推論によると、これは2050年にEC暗号を解読できるようになるでしょう。しかし、多くの不確実性があります。しかし、魔法のようなことが再帰/リンク/シミュレーションで起こり、進行をスピードアップすることができます。 -Other ideas +その他のアイデア -+ Let’s say we use same key and two different address algorithms for 2 different use cases. Is it still safe to use it? Alan: if we want to hide the public key (which is not our use case), then it’s less secure but there are fixes. ++2つの異なるユースケースに同じキーと2つの異なるアドレスアルゴリズムを使用するとします。それでも安全に使用できますか？アラン:公開鍵を非表示にしたい場合(これは私たちのユースケースではありません)、そのセキュリティは低下しますが、それを修正する方法があります。 -### References +### 参照 -+ [Notes](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw) ++ [メモ](https://hackmd.io/_NGWI4xZSbKzj1BkCqyZMw) \ No newline at end of file diff --git a/docs/ja/architecture/adr-029-fee-grant-module.md b/docs/ja/architecture/adr-029-fee-grant-module.md index f6e9a4883c3d..f27448ef178d 100644 --- a/docs/ja/architecture/adr-029-fee-grant-module.md +++ b/docs/ja/architecture/adr-029-fee-grant-module.md @@ -1,58 +1,58 @@ -# ADR 029: Fee Grant Module +# ADR 029:経費補助モジュール -## Changelog +## 変更ログ -- 2020/08/18: Initial Draft -- 2021/05/05: Removed height based expiration support and simplified naming. +-2020/08/18:最初のドラフト +-2021 .05/05:高さベースの有効期限のサポートを削除し、名前を簡略化しました。 -## 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. +1つの解決策は、適切な料金でこれらのアカウントを自動的に埋めるサービスを提供することですが、より優れたユーザーエクスペリエンス +これは、これらのアカウントが適切な支出制限のある公費プールアカウントから引き出されることを許可することによって提供されます。 +単一のプールは、多数の小さな「フィルイン」トランザクションの解約を減らし、レバレッジをより効果的に利用します +プールを設定した組織のリソース。 -## 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. +解決策として、1つのアカウント、つまり「grant」が別のアカウント、つまり「grant」を付与できるようにするモジュール `x .feegrant`を提案しました。 +明確に定義された特定の制限内の費用引当金については、付与者のアカウント残高を使用します。 -Fee allowances are defined by the extensible `FeeAllowanceI` interface: +料金制限は、拡張可能な `FeeAllowanceI`インターフェースによって定義されます。 ```go type FeeAllowanceI { - // Accept can use fee payment requested as well as timestamp 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 can use fee payment requested as well as timestamp 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(ctx sdk.Context, fee sdk.Coins, msgs []sdk.Msg) (remove bool, err error) - // ValidateBasic should evaluate this FeeAllowance for internal consistency. - // Don't allow negative amounts, or negative periods for example. + ..ValidateBasic should evaluate this FeeAllowance for internal consistency. + ..Don't allow negative amounts, or negative periods for example. ValidateBasic() error } ``` @@ -60,37 +60,37 @@ type FeeAllowanceI { Two basic fee allowance types, `BasicAllowance` and `PeriodicAllowance` are defined to support known use cases: ```proto -// BasicAllowance implements FeeAllowanceI with a one-time grant of tokens -// that optionally expires. The delegatee can use up to SpendLimit to cover fees. +/.BasicAllowance implements FeeAllowanceI with a one-time grant of tokens +/.that optionally expires. The delegatee can use up to SpendLimit to cover fees. message BasicAllowance { - // 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. + ..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; - // expiration specifies an optional time when this allowance expires + ..expiration specifies an optional time when this allowance expires google.protobuf.Timestamp expiration = 2; } -// PeriodicAllowance extends FeeAllowanceI to allow for both a maximum cap, -// as well as a limit per time period. +/.PeriodicAllowance extends FeeAllowanceI to allow for both a maximum cap, +/.as well as a limit per time period. message PeriodicAllowance { BasicAllowance basic = 1; - // period specifies the time duration in which period_spend_limit coins can - // be spent before that allowance is reset + ..period specifies the time duration in which period_spend_limit coins can + ..be spent before that allowance is reset google.protobuf.Duration period = 2; - // period_spend_limit specifies the maximum number of coins that can be spent - // in the period + ..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 + ..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 + ..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 google.protobuf.Timestamp period_reset = 5; } @@ -99,15 +99,15 @@ message PeriodicAllowance { Allowances can be granted and revoked using `MsgGrantAllowance` and `MsgRevokeAllowance`: ```proto -// MsgGrantAllowance adds permission for Grantee to spend up to Allowance -// of fees from the account of Granter. +/.MsgGrantAllowance adds permission for Grantee to spend up to Allowance +/.of fees from the account of Granter. message MsgGrantAllowance { string granter = 1; string grantee = 2; google.protobuf.Any allowance = 3; } - // MsgRevokeAllowance removes any existing FeeAllowance from Granter to Grantee. +..MsgRevokeAllowance removes any existing FeeAllowance from Granter to Grantee. message MsgRevokeAllowance { string granter = 1; string grantee = 2; @@ -127,27 +127,26 @@ message Fee { } ``` -`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). +`granter`は節必要か、、だけ +経费経人の経费手当(最初は署名者なし→「経人」経のこと)。 -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. +「Fee_payer」との取引をする理する可能に、「DeductGrantedFeeDecorator」を表示名の「AnteDecorator」がありますます。 +経费積金方法経费を設定し、ます控除します。 -## 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 +-元の職務記述書と提出:https://medium.com/regen-network/hacking-the-cosmos-cosmwasm-and-key-management-a08b9f561d1b +-新しい規制とスタイルがオープン:https://gist.github.com/aaronc/b60628017352df5983791cad30babe56 +-B-harvestから元のテレビの設定は、この設定计に傒和えます:https://github.com/cosmos/cosmos-sdk/issues/4480 \ No newline at end of file diff --git a/docs/ja/architecture/adr-030-authz-module.md b/docs/ja/architecture/adr-030-authz-module.md index ff6286c2d888..33d2eaa679d0 100644 --- a/docs/ja/architecture/adr-030-authz-module.md +++ b/docs/ja/architecture/adr-030-authz-module.md @@ -1,82 +1,82 @@ -# ADR 030: Authorization Module +# ADR 030:認証モジュール -## Changelog +## 変更ログ -- 2019-11-06: Initial Draft -- 2020-10-12: Updated Draft -- 2020-11-13: Accepted -- 2020-05-06: proto API updates, use `sdk.Msg` instead of `sdk.ServiceMsg` (the latter concept was removed from Cosmos SDK) +-2019-11-06:最初のドラフト +-2020-10-12:ドラフトを更新します +-2020-11-13:承認済み +-2020-05-06:プロトAPIの更新、 `sdk.ServiceMsg`の代わりに` sdk.Msg`を使用します(後者の概念はCosmos SDKから削除されました) -## Status +## 状態 -Accepted +受け入れられました -## Abstract +## 概要 -This ADR defines the `x/authz` module which allows accounts to grant authorizations to perform actions -on behalf of that account to other accounts. +このADRは `x .authz`モジュールを定義します。これにより、アカウントに操作を実行する権限を付与できます。 +アカウントを他のアカウントに表します。 -## Context +## 環境 -The concrete use cases which motivated this module include: +このモジュールに影響を与えた特定のユースケースは次のとおりです。 -- the desire to delegate the ability to vote on proposals to other accounts besides the account which one has -delegated stake -- "sub-keys" functionality, as originally proposed in [\#4480](https://github.com/cosmos/cosmos-sdk/issues/4480) which -is a term used to describe the functionality provided by this module together with -the `fee_grant` module from [ADR 029](./adr-029-fee-grant-module.md) and the [group module](https://github.com/regen-network/cosmos-modules/tree/master/incubator/group). +-議決権を自分の口座以外の口座に委任したい +委託エクイティ +-[\#4480](https://github.com/cosmos/cosmos-sdk/issues/4480)で最初に提案された「サブキー」機能 +このモジュールによって提供される機能を説明するために使用される用語であり、 +`fee_grant`モジュールの[ADR029](..adr-029-fee-grant-module.md)および[グループモジュール](https://github.com/regen-network/cosmos-modules/tree/)マスター/インキュベーター/グループ)。 -The "sub-keys" functionality roughly refers to the ability for one account to grant some subset of its capabilities to -other accounts with possibly less robust, but easier to use security measures. For instance, a master account representing -an organization could grant the ability to spend small amounts of the organization's funds to individual employee accounts. -Or an individual (or group) with a multisig wallet could grant the ability to vote on proposals to any one of the member -keys. +「サブキー」機能とは、アカウントがその機能のサブセットを付与する機能を大まかに指します。 +他のアカウントはそれほど強力ではないかもしれませんが、セキュリティ対策を使用する方が簡単です。たとえば、マスターアカウント担当者 +組織は、組織の資金の一部を個々の従業員のアカウントに使用する機能を付与できます。 +または、マルチシグニチャウォレットを使用する個人(またはグループ)は、任意のメンバーに提案に投票する機能を付与できます。 +鍵。 -The current -implementation is based on work done by the [Gaian's team at Hackatom Berlin 2019](https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation). +現在 +実装は、[Hackatom Berlin 2019のGaianチーム](https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation)によって行われた作業に基づいています。 -## Decision +## 決定 -We will create a module named `authz` which provides functionality for -granting arbitrary privileges from one account (the _granter_) to another account (the _grantee_). Authorizations -must be granted for a particular `Msg` service methods one by one using an implementation -of `Authorization` interface. +`authz`というモジュールを作成します。 +あるアカウント(_granter_)から別のアカウント(_grantee_)に任意の権限を付与します。承認 +実装されている特定の `Msg`サービスメソッドを使用して1つずつ付与する必要があります +「承認」インターフェース。 -### Types +### タイプ -Authorizations determine exactly what privileges are granted. They are extensible -and can be defined for any `Msg` service method even outside of the module where -the `Msg` method is defined. `Authorization`s reference `Msg`s using their TypeURL. +承認によって、付与される特権が決まります。それらは拡張可能です +また、モジュールの外部であっても、任意の `Msg`サービスメソッドに対して定義できます。 +`Msg`メソッドが定義されています。 `Authorization`はTypeURLを使用して` Msg`を参照します。 -#### Authorization +#### 承認 ```go type Authorization interface { proto.Message - // MsgTypeURL returns the fully-qualified Msg TypeURL (as described in ADR 020), - // which will process and accept or reject a request. + /.MsgTypeURL returns the fully-qualified Msg TypeURL (as described in ADR 020), + /.which will process and accept or reject a request. MsgTypeURL() string - // Accept determines whether this grant permits the provided sdk.Msg to be performed, and if - // so provides an upgraded authorization instance. + /.Accept determines whether this grant permits the provided sdk.Msg to be performed, and if + /.so provides an upgraded authorization instance. Accept(ctx sdk.Context, msg sdk.Msg) (AcceptResponse, error) - // ValidateBasic does a simple validation check that - // doesn't require access to any other information. + /.ValidateBasic does a simple validation check that + /.doesn't require access to any other information. ValidateBasic() error } -// AcceptResponse instruments the controller of an authz message if the request is accepted -// and if it should be updated or deleted. +/.AcceptResponse instruments the controller of an authz message if the request is accepted +/.and if it should be updated or deleted. type AcceptResponse struct { - // If Accept=true, the controller can accept and authorization and handle the update. + /.If Accept=true, the controller can accept and authorization and handle the update. Accept bool - // If Delete=true, the controller must delete the authorization object and release - // storage resources. + /.If Delete=true, the controller must delete the authorization object and release + /.storage resources. Delete bool - // Controller, who is calling Authorization.Accept must check if `Updated != nil`. If yes, - // it must use the updated version and handle the update on the storage level. + /.Controller, who is calling Authorization.Accept must check if `Updated != nil`. If yes, + /.it must use the updated version and handle the update on the storage level. Updated Authorization } ``` @@ -86,9 +86,9 @@ a `SpendLimit` and updates it down to zero: ```go type SendAuthorization struct { - // SpendLimit specifies the maximum amount of tokens that can be spent - // by this authorization 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. + /.SpendLimit specifies the maximum amount of tokens that can be spent + /.by this authorization 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. SpendLimit sdk.Coins } @@ -113,30 +113,29 @@ func (a SendAuthorization) Accept(ctx sdk.Context, msg sdk.Msg) (authz.AcceptRes } ``` -A different type of capability for `MsgSend` could be implemented -using the `Authorization` interface with no need to change the underlying -`bank` module. - -### `Msg` Service +`MsgSend`の別のタイプの機能を実装できます +基になるものを変更する必要なしに `Authorization`インターフェースを使用する +`bank`モジュール。 +### `メッセージ`サービス ```proto service Msg { - // Grant grants the provided authorization to the grantee on the granter's - // account with the provided expiration time. + ..Grant grants the provided authorization to the grantee on the granter's + ..account with the provided expiration time. rpc Grant(MsgGrant) returns (MsgGrantResponse); - // Exec attempts to execute the provided messages using - // authorizations granted to the grantee. Each message should have only - // one signer corresponding to the granter of the authorization. + ..Exec attempts to execute the provided messages using + ..authorizations granted to the grantee. Each message should have only + ..one signer corresponding to the granter of the authorization. rpc Exec(MsgExec) returns (MsgExecResponse); - // Revoke revokes any authorization corresponding to the provided method name on the - // granter's account that has been granted to the grantee. + ..Revoke revokes any authorization corresponding to the provided method name on the + ..granter's account that has been granted to the grantee. rpc Revoke(MsgRevoke) returns (MsgRevokeResponse); } -// Grant gives permissions to execute -// the provided method with expiration time. +/.Grant gives permissions to execute +/.the provided method with expiration time. message Grant { google.protobuf.Any authorization = 1 [(cosmos_proto.accepts_interface) = "Authorization"]; google.protobuf.Timestamp expiration = 2 [(gogoproto.stdtime) = true, (gogoproto.nullable) = false]; @@ -155,31 +154,31 @@ message MsgExecResponse { message MsgExec { string grantee = 1; - // Authorization Msg requests to execute. Each msg must implement Authorization interface + ..Authorization Msg requests to execute. Each msg must implement Authorization interface repeated google.protobuf.Any msgs = 2 [(cosmos_proto.accepts_interface) = "sdk.Msg"];; } ``` -### Router Middleware +### ルーターミドルウェア -The `authz` `Keeper` will expose a `DispatchActions` method which allows other modules to send `Msg`s -to the router based on `Authorization` grants: +`authz``Keeper`は` DispatchActions`メソッドを公開します。これにより、他のモジュールが `Msg`を送信できるようになります。 +「許可」許可に基づくルーターへ: ```go type Keeper interface { - // DispatchActions routes the provided msgs to their respective handlers if the grantee was granted an authorization - // to send those messages by the first (and only) signer of each msg. + /.DispatchActions routes the provided msgs to their respective handlers if the grantee was granted an authorization + /.to send those messages by the first (and only) signer of each msg. DispatchActions(ctx sdk.Context, grantee sdk.AccAddress, msgs []sdk.Msg) sdk.Result` } ``` ### CLI -#### `tx exec` Method +#### `txexec`メソッド -When a CLI user wants to run a transaction on behalf of another account using `MsgExec`, they -can use the `exec` method. For instance `gaiacli tx gov vote 1 yes --from --generate-only | gaiacli tx authz exec --send-as --from ` -would send a transaction like this: +CLIユーザーが `MsgExec`を使用して別のアカウントに代わってトランザクションを実行したい場合、 +`exec`メソッドを使用できます。 たとえば、 `gaiacli tx govvote 1 yes --from --generate-only | gaiacli tx authz exec --send-as --from ` +次のようなトランザクションを送信します: ```go MsgExec { @@ -196,20 +195,19 @@ MsgExec { #### `tx grant --from ` -This CLI command will send a `MsgGrant` transaction. `authorization` should be encoded as -JSON on the CLI. - +このCLIコマンドは、 `MsgGrant`トランザクションを送信します。 `authorization`は次のようにエンコードする必要があります +CLIでのJSON。 #### `tx revoke --from ` -This CLI command will send a `MsgRevoke` transaction. +このCLIコマンドは、 `MsgRevoke`トランザクションを送信します。 ### Built-in Authorizations #### `SendAuthorization` ```proto -// SendAuthorization allows the grantee to spend up to spend_limit coins from -// the granter's account. +/.SendAuthorization allows the grantee to spend up to spend_limit coins from +/.the granter's account. message SendAuthorization { repeated cosmos.base.v1beta1.Coin spend_limit = 1; } @@ -218,32 +216,32 @@ message SendAuthorization { #### `GenericAuthorization` ```proto -// GenericAuthorization gives the grantee unrestricted permissions to execute -// the provided method on behalf of the granter's account. +/.GenericAuthorization gives the grantee unrestricted permissions to execute +/.the provided method on behalf of the granter's account. message GenericAuthorization { option (cosmos_proto.implements_interface) = "Authorization"; - // Msg, identified by it's type URL, to grant unrestricted permissions to execute + ..Msg, identified by it's type URL, to grant unrestricted permissions to execute string msg = 1; } ``` -## Consequences +## 結果 -### Positive +### ポジティブ -- Users will be able to authorize arbitrary actions on behalf of their accounts to other -users, improving key management for many use cases -- The solution is more generic than previously considered approaches and the -`Authorization` interface approach can be extended to cover other use cases by -SDK users +-ユーザーは、自分のアカウントに代わって他のユーザーに任意のアクションを許可できるようになります +ユーザー、多くのユースケースの改善されたキー管理 +-ソリューションは、以前に検討された方法よりも用途が広く、 +`Authorization`インターフェースメソッドは、他のユースケースをカバーするために次の方法で拡張できます +SDKユーザー -### Negative +### ネガティブ -### Neutral +### ニュートラル -## References +## 参照 -- Initial Hackatom implementation: https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation -- Post-Hackatom spec: https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module -- B-Harvest subkeys spec: https://github.com/cosmos/cosmos-sdk/issues/4480 +-最初のHackatomの実装:https://github.com/cosmos-gaians/cosmos-sdk/tree/hackatom/x/delegation +-ポストハッカトム仕様:https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#delegation-module +-B-Harvestサブキーの仕様:https://github.com/cosmos/cosmos-sdk/issues/4480 \ No newline at end of file diff --git a/docs/ja/architecture/adr-031-msg-service.md b/docs/ja/architecture/adr-031-msg-service.md index ff92c617bb5a..d2ee1bda5c6d 100644 --- a/docs/ja/architecture/adr-031-msg-service.md +++ b/docs/ja/architecture/adr-031-msg-service.md @@ -1,27 +1,26 @@ -# ADR 031: Protobuf Msg Services +# ADR 031:Protobufメッセージサービス -## Changelog +## 変更ログ -- 2020-10-05: Initial Draft -- 2021-04-21: Remove `ServiceMsg`s to follow Protobuf `Any`'s spec, see [#9063](https://github.com/cosmos/cosmos-sdk/issues/9063). +-2020-10-05:最初のドラフト +-2021-04-21:Protobufの `Any`仕様に従うように` ServiceMsg`を削除します。[#9063](https://github.com/cosmos/cosmos-sdk/issues/9063)を参照してください。 -## 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. +protobufの `service`定義を使用して` Msg`を定義し、重要な開発者UXを提供したいと考えています。 +生成されたコードの改善と、戻り型が明確に定義されるようになりました。 -## 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: +現在、CosmosSDKの `Msg`ハンドラーには、応答の` data`フィールドに配置された戻り値があります。 +ただし、これらの戻り値は、golangハンドラーコード以外の場所では指定されていません。 +初期の会話で[誰かが提案しました](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc/edit) +protobuf拡張フィールドを使用して、 `Msg`リターンタイプをキャプチャします。例: ```protobuf package cosmos.gov; @@ -33,29 +32,29 @@ message MsgSubmitProposal } ``` -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 Cosmos SDK to parse that value and return it to users. +`Msg`に明確な戻り値を指定すると、クライアントのユーザーエクスペリエンスが向上します。例えば、 +`x .gov`では、` MsgSubmitProposal`はプロポーザルIDをビッグエンディアンの `uint64`として返します。 +これは実際にはどこにも記録されていません。クライアントは内部構造を理解する必要があります +Cosmos SDKは値を解析し、ユーザーに返します。 -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. +さらに、場合によっては、これらの戻り値をプログラムで使用したいことがあります。 +たとえば、https://github.com/cosmos/cosmos-sdk/issues/7093はメソッドを提案します +モジュール間Ocapsには `Msg`ルーターを使用します。明確に定義されたリターンタイプは +このメソッドの開発者ユーザーエクスペリエンスを向上させます。 -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. +さらに、タイプ `Msg`のハンドラーの登録が増える傾向があります +ホルダー上部のテンプレートは、通常、手動タイプのスイッチで完成します。 +これは必ずしも悪いことではありませんが、モジュールの作成コストが増加します。 -## 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. +protobufの `service`定義を使用して` Msg`と +それらが生成するコードは、 `Msg`ハンドラーの代わりとして機能します。 -Below we define how this will look for the `SubmitProposal` message from `x/gov` module. -We start with a `Msg` `service` definition: +以下では、これが `x .gov`モジュールから` SubmitProposal`メッセージを見つける方法を定義します。 +`Msg``service`の定義から始めます。 ```proto package cosmos.gov; @@ -64,8 +63,8 @@ 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 +/.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; @@ -76,15 +75,14 @@ message MsgSubmitProposalResponse { } ``` -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)): +これはgRPCで最も一般的に使用されますが、このようにprotobufの「サービス」定義をオーバーロードしても違反しません。 +[protobuf仕様](https://developers.google.com/protocol-buffers/docs/proto3#services)の目的は次のとおりです。 +> gRPCを使用したくない場合は、独自のRPC実装でプロトコルバッファを使用することもできます。 +このメソッドを使用すると、自動的に生成された `MsgServer`インターフェイスが得られます。 +リターンタイプを明示的に指定することに加えて、これはクライアントおよびサーバーコードの生成も容易にします。 サーバー上 +一方では、これはほとんど自動生成されたゴールキーパーメソッドのようなものであり、最終的にはゴールキーパーの代わりに使用される可能性があります +([\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)を参照): ```go package gov @@ -93,40 +91,40 @@ type MsgServer interface { } ``` -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. +クライアント側では、開発者はトランザクションをカプセル化するRPC実装を作成することでこれを利用できます +論理。 [protobuf.js](https://github.com/protobufjs/protobuf.js#using-services)などの非同期コールバックを使用するProtobufライブラリ +複数の `Msg`を含むトランザクションの場合でも、特定のメッセージのコールバックを登録するために使用できます。 -Each `Msg` service method should have exactly one request parameter: its corresponding `Msg` type. For example, the `Msg` service method `/cosmos.gov.v1beta1.Msg/SubmitProposal` above has exactly one request parameter, namely the `Msg` type `/cosmos.gov.v1beta1.MsgSubmitProposal`. It is important the reader understands clearly the nomenclature difference between a `Msg` service (a Protobuf service) and a `Msg` type (a Protobuf message), and the differences in their fully-qualified name. +各 `Msg`サービスメソッドには、対応する` Msg`タイプのリクエストパラメータが必要です。たとえば、上記の `Msg`サービスメソッド` .cosmos.gov.v1beta1.Msg .SubmitProposal`には、リクエストパラメータが1つだけあります。つまり、 `Msg`タイプ` .cosmos.gov.v1beta1.MsgSubmitProposal`です。読者は、 `Msg`サービス(Protobufサービス)と` Msg`タイプ(Protobufメッセージ)の名前の違い、および完全修飾名の違いを明確に理解することが重要です。 -This convention has been decided over the more canonical `Msg...Request` names mainly for backwards compatibility, but also for better readability in `TxBody.messages` (see [Encoding section](#encoding) below): transactions containing `/cosmos.gov.MsgSubmitProposal` read better than those containing `/cosmos.gov.v1beta1.MsgSubmitProposalRequest`. +この規則は、主に下位互換性のためだけでなく、 `TxBody.messages`の読みやすさのために、より標準化された` Msg ... Request`名で決定されました([コーディングセクション](以下の#encoding)を参照)): `.cosmos.gov.MsgSubmitProposal`を含むものは、` .cosmos.gov.v1beta1.MsgSubmitProposalRequest`を含むものよりも読みやすくなります。 -One consequence of this convention is that each `Msg` type can be the request parameter of only one `Msg` service method. However, we consider this limitation a good practice in explicitness. +この合意の結果の1つは、各 `Msg`タイプが` Msg`サービスメソッドのリクエストパラメータにしかなれなくなることです。ただし、この制限は明確であり、良い習慣であると私たちは信じています。 -### Encoding +### エンコーディング -Encoding of transactions generated with `Msg` services do not differ from current Protobuf transaction encoding as defined in [ADR-020](./adr-020-protobuf-transaction-encoding.md). We are encoding `Msg` types (which are exactly `Msg` service methods' request parameters) as `Any` in `Tx`s which involves packing the -binary-encoded `Msg` with its type URL. +`Msg`サービスを使用して生成されたトランザクションエンコーディングは、[ADR-020](..adr-020-protobuf-transaction-encoding.md)で定義されている現在のProtobufトランザクションエンコーディングと同じです。 `Msg`タイプ(` Msg`サービスメソッドのリクエストパラメータ)を `Tx`の` Any`としてエンコードします。これにはパッケージングが含まれます +バイナリコード化された `Msg`とそのタイプのURL。 -### Decoding +### デコード -Since `Msg` types are packed into `Any`, decoding transactions messages are done by unpacking `Any`s into `Msg` types. For more information, please refer to [ADR-020](./adr-020-protobuf-transaction-encoding.md#transactions). +`Msg`タイプは` Any`にパックされているため、トランザクションメッセージは `Any`sを` Msg`タイプにアンパックすることでデコードされます。詳細については、[ADR-020](..adr-020-protobuf-transaction-encoding.md#transactions)を参照してください。 -### Routing +### ルーティング -We propose to add a `msg_service_router` in BaseApp. This router is a key/value map which maps `Msg` types' `type_url`s to their corresponding `Msg` service method handler. Since there is a 1-to-1 mapping between `Msg` types and `Msg` service method, the `msg_service_router` has exactly one entry per `Msg` service method. +BaseAppに `msg_service_router`を追加することをお勧めします。このルーターはキー/値マッピングであり、 `Msg`タイプの` type_url`を対応する `Msg`サービスメソッドハンドラーにマッピングします。 `Msg`タイプと` Msg`サービスメソッドの間には1対1のマッピングがあるため、 `msg_service_router`には` Msg`サービスメソッドごとに1つのエントリしかありません。 -When a transaction is processed by BaseApp (in CheckTx or in DeliverTx), its `TxBody.messages` are decoded as `Msg`s. Each `Msg`'s `type_url` is matched against an entry in the `msg_service_router`, and the respective `Msg` service method handler is called. +BaseAppが(CheckTxまたはDeliverTxで)トランザクションを処理するとき、その「TxBody.messages」は「Msg」としてデコードされます。各 `Msg`の` type_url`は `msg_service_router`のエントリと一致し、対応する` Msg`サービスメソッドハンドラが呼び出されます。 -For backward compatability, the old handlers are not removed yet. If BaseApp receives a legacy `Msg` with no correspoding entry in the `msg_service_router`, it will be routed via its legacy `Route()` method into the legacy handler. +下位互換性のために、古いハンドラーは削除されていません。 BaseAppが `msg_service_router`に対応するエントリがない古いバージョンの` Msg`を受信した場合、古いバージョンの `Route()`メソッドを介して古いバージョンのハンドラーにルーティングされます。 -### 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. +[ADR 021](..adr-021-protobuf-query-encoding.md)で、メソッド `RegisterQueryService`を導入しました +「AppModule」に移動します。これにより、モジュールはgRPCクエリアを登録できます。 -To register `Msg` services, we attempt a more extensible approach by converting `RegisterQueryService` -to a more generic `RegisterServices` method: +`Msg`サービスを登録するために、` RegisterQueryService`を変換することでより拡張可能なメソッドを試してみます +より一般的な `RegisterServices`メソッドへ: ```go type AppModule interface { @@ -139,26 +137,26 @@ type Configurator interface { MsgServer() grpc.Server } -// example module: +/.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). +`RegisterServices`メソッドと` Configurator`インターフェースは次のように設計されています +[\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)で説明されているユースケースに合わせて進化する +そして[\#7122](https://github.com/cosmos/cosmos-sdk/issues/7421)。 -When `Msg` services are registered, the framework _should_ verify that all `Msg` types -implement the `sdk.Msg` interface and throw an error during initialization rather -than later when transactions are processed. +`Msg`サービスを登録するとき、フレームワークはすべての` Msg`タイプを検証する必要があります +`sdk.Msg`インターフェースを実装し、初期化中にエラーをスローする代わりに +トランザクションが処理された後。 -### `Msg` Service Implementation +### `Msg`サービスの実装 -Just like query services, `Msg` service methods can retrieve the `sdk.Context` -from the `context.Context` parameter method using the `sdk.UnwrapSDKContext` -method: +サービスをクエリするのと同じように、 `Msg`サービスメソッドは` sdk.Context`を取得できます +`sdk.UnwrapSDKContext`の` context.Context`パラメータメソッドの使用から +方法: ```go package gov @@ -169,34 +167,34 @@ func (k Keeper) SubmitProposal(goCtx context.Context, params *types.MsgSubmitPro } ``` -The `sdk.Context` should have an `EventManager` already attached by BaseApp's `msg_service_router`. +`sdk.Context` 应该有一个已经由 BaseApp 的 `msg_service_router` 附加的 `EventManager`。 -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. +この設計により、モジュール機能の開示およびアクセス方法が変更されます。既存の `Handler`インターフェースと` AppModule.Route`を放棄し、代わりに上記の[Protocol Buffer Services](https://developers.google.com/protocol-buffers/docs/proto3#services)とサービスをサポートしますルーティング。これにより、コードが大幅に簡素化されます。ハンドラーとデーモンを作成する必要がなくなりました。プロトコルバッファを使用して自動生成されたクライアントは、モジュールとモジュールのユーザー間の通信インターフェイスを明確に分離します。制御ロジック(別名ハンドラーとデーモン)は公開されなくなりました。モジュールインターフェイスは、クライアントAPIを介してアクセスされるブラックボックスと見なすことができます。クライアントインターフェイスもプロトコルバッファによって生成されることに注意してください。 -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. +これにより、機能テストの実行方法を変更することもできます。 AppModuleとルーターをシミュレートする代わりに、クライアントをシミュレートします(サーバーは非表示のままになります)。具体的には、 `moduleB`で` moduleA.MsgServer`をシミュレートすることはなく、代わりに `moduleA.MsgClient`をシミュレートします。外部サービス(データベースやオンラインサーバーなど)を使用していると考えてください。クライアントとサーバー間の送信は、生成されたプロトコルバッファによって正しく処理されると想定しています。 -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. +最後に、クライアントAPIモジュールをオフにすると、ADR-033で説明されている理想的なOCAPモードがオンになります。サーバーの実装とインターフェースは隠されているため、誰も「管理者」/サーバーを保持できず、クライアントインターフェースで中継することを余儀なくされます。これにより、開発者にとって正しいパッケージングとソフトウェアエンジニアリングモデルが促進されます。 -### 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 +-返品タイプを明確に伝える +-プログラム登録とリターンタイプマーシャリングを手動で処理する必要がなくなり、インターフェイスを実装して登録するだけです。 +-通信インターフェースが自動的に生成され、開発者は状態遷移方法にのみ集中できるようになりました-これにより、[\#7093](https://github.com/cosmos/cosmos-sdk/issues/7093)のUXが向上します。 )方法(1)採用することを選択した場合 +-生成されたクライアントコードは、クライアントとテストに役立つ場合があります +-コードを大幅に削減および簡素化 -### Cons +### 欠点 -- using `service` definitions outside the context of gRPC could be confusing (but doesn’t violate the proto3 spec) +-gRPCコンテキストの外部で `service`定義を使用すると、混乱が生じる可能性があります(ただし、proto3仕様に違反しません)。 -## 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) +-[Initial Github Issue \#7122](https://github.com/cosmos/cosmos-sdk/issues/7122) +-[proto 3言語ガイド:サービスの定義](https://developers.google.com/protocol-buffers/docs/proto3#services) +-[`Any``Msg`の初期事前設計](https://docs.google.com/document/d/1eEgYgvgZqLE45vETjhwIw4VOqK-5hwQtZtjVbiXnIGc) +-[ADR 020](..adr-020-protobuf-transaction-encoding.md) +-[ADR 021](..adr-021-protobuf-query-encoding.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-032-typed-events.md b/docs/ja/architecture/adr-032-typed-events.md index 0d96054f51c6..62df08c090e5 100644 --- a/docs/ja/architecture/adr-032-typed-events.md +++ b/docs/ja/architecture/adr-032-typed-events.md @@ -1,45 +1,45 @@ -# ADR 032: Typed Events +# ADR 032:入力されたイベント -## Changelog +## 変更ログ -- 28-Sept-2020: Initial Draft +-2020年9月28日:最初のドラフト -## Authors +## 著者 -- Anil Kumar (@anilcse) -- Jack Zampolin (@jackzampolin) -- Adam Bozanich (@boz) +-アニルクマール(@anilcse) +-ジャックザンポリン(@jackzampolin) +-アダムボザンシ(@boz) -## Status +## 状態 -Proposed +提案 -## Abstract +## 概要 -Currently in the Cosmos 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. +現在、Cosmos SDKでは、イベントは各メッセージのハンドラーと「BeginBlock」および「EndBlock」で定義されています。各モジュールは各イベントのタイプを定義せず、 `map [string] string`として実装されます。最も重要なことは、これにより、多くの生の文字列の照合と解析が必要になるため、これらのイベントの使用が困難になることです。提案の焦点は、各モジュールで定義された**型付きイベント**を使用するようにイベントを更新し、イベントの発行とサブスクライブを容易にすることです。このワークフローは、Akashネットワークチームの経験に基づいています。 -## Context +## 環境 -Currently in the Cosmos 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. +現在、Cosmos SDKでは、イベントは各メッセージのハンドラーで定義されています。つまり、各モジュールには、各イベントの正規タイプのセットがありません。最も重要なことは、これにより、多くの生の文字列の照合と解析が必要になるため、これらのイベントの使用が困難になることです。提案の焦点は、各モジュールで定義された**型付きイベント**を使用するようにイベントを更新し、イベントの発行とサブスクライブを容易にすることです。このワークフローは、Akashネットワークチームの経験に基づいています。 -[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 Cosmos SDK modules. We have found that it is extremely useful in building this type of event driven application. +[私たちのプラットフォーム](http://github.com/ovrclk/akash)は、プロバイダー(データセンター-新しい注文に入札し、作成されたリースを監視する)とユーザー(アプリケーション開発者-アプリケーションリストをプロバイダー)終了。さらに、Akashチームは現在IBC [`relayer`](https://github.com/ovrclk/relayer)を維持しています。これは、もう1つの非常にイベント駆動型のプロセスです。これらのインフラストラクチャのコア部分を処理し、Kubernetes開発から学んだ教訓を統合する際に、私たちのチームはCosmosSDKモジュールで型付きイベントを定義して使用するための標準的な方法を開発しました。このタイプのイベント駆動型アプリケーションを構築するときに非常に便利です。 -As the Cosmos 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 Cosmos SDK to enable all Cosmos 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. +Cosmos SDKは、「ペギー」、他のフック領域、IBC、DeFiなどのアプリケーションでより広く使用されるため、ユーザーが必要とする新機能をサポートするために、イベント駆動型アプリケーションの需要が爆発的に増加します。すべてのCosmosSDKアプリケーションがイベント駆動型アプリケーションを迅速かつ簡単に構築してコアアプリケーションを支援できるように、調査結果をCosmosSDKにアップロードすることをお勧めします。ウォレット、エクスチェンジ、ブラウザ、defiプロトコルはすべてこの作業の恩恵を受けます。 -If this proposal is accepted, users will be able to build event driven Cosmos SDK apps in go by just writing `EventHandler`s for their specific event types and passing them to `EventEmitters` that are defined in the Cosmos SDK. +この提案が受け入れられると、ユーザーはgoでイベント駆動型のCosmos SDKアプリケーションを構築し、特定のイベントタイプのEventHandlerを記述して、CosmosSDKで定義されたEventEmittersに渡すことができます。 -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 +__Step-1__: `types`パッケージに追加の関数を実装します:` EmitTypedEvent`および `ParseTypedEvent`関数 ```go -// types/events.go +/.types/events.go -// EmitTypedEvent takes typed event and emits converting it into sdk.Event +/.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) @@ -69,7 +69,7 @@ func (em *EventManager) EmitTypedEvent(event proto.Message) error { return nil } -// ParseTypedEvent converts abci.Event back to typed event +/.ParseTypedEvent converts abci.Event back to typed event func ParseTypedEvent(event abci.Event) (proto.Message, error) { concreteGoType := proto.MessageType(event.Type) if concreteGoType == nil { @@ -107,17 +107,17 @@ func ParseTypedEvent(event abci.Event) (proto.Message, error) { } ``` -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. +ここで、 `EmitTypedEvent`は、型付きイベントを入力として受け取り、それにjsonシリアル化を適用する` EventManager`のメソッドです。 次に、JSONキーと値のペアを `event.Attributes`にマップし、` sdk.Event`の形式で出力します。 `Event.Type`は、プロトメッセージのタイプURLになります。 -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. +テンダーミントWebSocketで発行されるイベントをサブスクライブすると、それらは `abci.Event`の形式で発行されます。 `ParseTypedEvent`は、イベントを解析して元のプロトメッセージに戻します。 -__Step-2__: Add proto definitions for typed events for msgs in each module: +__Step-2__:各モジュールのmsgsの型付きイベントのプロトタイプ定義を追加します。 -For example, let's take `MsgSubmitProposal` of `gov` module and implement this event's type. +たとえば、 `gov`モジュールの` MsgSubmitProposal`を使用して、このイベントタイプを実装しましょう。 ```protobuf -// proto/cosmos/gov/v1beta1/gov.proto -// Add typed event definition +/.proto/cosmos/gov/v1beta1/gov.proto +/.Add typed event definition package cosmos.gov.v1beta1; @@ -128,10 +128,10 @@ message EventSubmitProposal { } ``` -__Step-3__: Refactor event emission to use the typed event created and emit using `sdk.EmitTypedEvent`: +__Step-3__: `sdk.EmitTypedEvent`を使用して作成および発行された型付きイベントを使用するように、イベント発行をリファクタリングします。 ```go -// x/gov/handler.go +/.x/gov/handler.go func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.MsgSubmitProposalI) (*sdk.Result, error) { ... types.Context.EventManager().EmitTypedEvent( @@ -145,41 +145,41 @@ func handleMsgSubmitProposal(ctx sdk.Context, keeper keeper.Keeper, msg types.Ms } ``` -#### 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. +ユーザーは `client.Context.Client.Subscribe`を使用して、` EventHandler`を使用して発行されたイベントをサブスクライブおよび使用できるようになります。 -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. +Akash Networkは、単純な[`pubsub`](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/pubsub/bus.go#L20)を構築しました。これを使用して、タイプイベントとして `abci.Events`および[publish](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L21)をサブスクライブできます。 -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 Cosmos 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 +*現在のCosmosSDKでのイベント実装の一貫性が向上しました +*イベントを処理し、イベント駆動型アプリケーションの作成を容易にする、より人間工学的な方法を提供します +*この実装は、 `EventHandler`のミドルウェアエコシステムをサポートします -### 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. +ADRは、これらのイベントを発行して使用するための可用性を追加することも推奨しています。したがって、開発者は書くだけで済みます +`EventHandler`は、実行するアクションを定義します。 ```go -// EventEmitter is a type that describes event emitter functions -// This should be defined in `types/events.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` +/.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 +/.Sample use of the functions below func main() { ctx, cancel := context.WithCancel(context.Background()) @@ -191,13 +191,13 @@ func main() { return } -// SubmitProposalEventHandler is an example of an event handler that prints proposal details -// when any EventSubmitProposal is emitted. +/.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 + ..Handle governance proposal events creation events case govtypes.EventSubmitProposal: - // Users define business logic here e.g. + ..Users define business logic here e.g. fmt.Println(ev.FromAddress, ev.ProposalId, ev.Proposal) return nil default: @@ -205,11 +205,11 @@ func SubmitProposalEventHandler(ev proto.Message) (err error) { } } -// TxEmitter is an example of an event emitter that emits just transaction events. This can and -// should be implemented somewhere in the Cosmos SDK. The Cosmos SDK can include an EventEmitters for tm.event='Tx' -// and/or tm.event='NewBlock' (the new block events may contain typed events) +/.TxEmitter is an example of an event emitter that emits just transaction events. This can and +/.should be implemented somewhere in the Cosmos SDK. The Cosmos 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 + ..Instantiate and start tendermint RPC client client, err := cliCtx.GetNode() if err != nil { return err @@ -219,25 +219,25 @@ func TxEmitter(ctx context.Context, cliCtx client.Context, ehs ...EventHandler) return err } - // Start the pubsub bus + ..Start the pubsub bus bus := pubsub.NewBus() defer bus.Close() - // Initialize a new error group + ..Initialize a new error group eg, ctx := errgroup.WithContext(ctx) - // Publish chain events to the pubsub bus + ..Publish chain events to the pubsub bus eg.Go(func() error { return PublishChainTxEvents(ctx, client, bus, simapp.ModuleBasics) }) - // Subscribe to the bus events + ..Subscribe to the bus events subscriber, err := bus.Subscribe() if err != nil { return err } - // Handle all the events coming out of the bus + /.Handle all the events coming out of the bus eg.Go(func() error { var err error for { @@ -260,23 +260,23 @@ func TxEmitter(ctx context.Context, cliCtx client.Context, ehs ...EventHandler) return group.Wait() } -// PublishChainTxEvents events using tmclient. Waits on context shutdown signals to exit. +/.PublishChainTxEvents events using tmclient. Waits on context shutdown signals to exit. func PublishChainTxEvents(ctx context.Context, client tmclient.EventsClient, bus pubsub.Bus, mb module.BasicManager) (err error) { - // Subscribe to transaction events + ..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 + ..Unsubscribe from transaction events on function exit defer func() { err = client.UnsubscribeAll(ctx, "txevents") }() - // Use errgroup to manage concurrency + ..Use errgroup to manage concurrency g, ctx := errgroup.WithContext(ctx) - // Publish transaction events in a goroutine + ..Publish transaction events in a goroutine g.Go(func() error { var err error for { @@ -289,8 +289,8 @@ func PublishChainTxEvents(ctx context.Context, client tmclient.EventsClient, bus if !evt.Result.IsOK() { continue } - // range over events, parse them using the basic manager and - // send them to the pubsub bus + ..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 { @@ -308,12 +308,12 @@ func PublishChainTxEvents(ctx context.Context, client tmclient.EventsClient, bus return err }) - // Exit on error or context cancelation + ..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) +-[バス経由でカスタムイベントを公開する](https://github.com/ovrclk/akash/blob/90d258caeb933b611d575355b8df281208a214f8/events/publish.go#L19-L58) +-[`クライアント`でイベントを使用](https://github.com/ovrclk/deploy/blob/bf6c633ab6c68f3026df59efd9982d6ca1bf0561/cmd/event-handlers.go#L57) \ No newline at end of file diff --git a/docs/ja/architecture/adr-033-protobuf-inter-module-comm.md b/docs/ja/architecture/adr-033-protobuf-inter-module-comm.md index e647e1eebb10..5668b29774b3 100644 --- a/docs/ja/architecture/adr-033-protobuf-inter-module-comm.md +++ b/docs/ja/architecture/adr-033-protobuf-inter-module-comm.md @@ -1,69 +1,69 @@ -# ADR 033: Protobuf-based Inter-Module Communication +# ADR 033:Protobufに基づくモジュール間の通信 -## Changelog +## 変更ログ -- 2020-10-05: Initial Draft +-2020-10-05:最初のドラフト -## Status +## 状態 -Proposed +提案 -## Abstract +## 概要 -This ADR introduces a system for permissioned inter-module communication leveraging the protobuf `Query` and `Msg` -service definitions defined in [ADR 021](./adr-021-protobuf-query-encoding.md) and -[ADR 031](./adr-031-msg-service.md) which provides: +ADRは、protobuf`Query`と `Msg`を使用して許可されたモジュール間で通信するためのシステムを導入します +[ADR 021](..adr-021-protobuf-query-encoding.md)サービス定義と +[ADR 031](..adr-031-msg-service.md)は以下を提供します: -- stable protobuf based module interfaces to potentially later replace the keeper paradigm -- stronger inter-module object capabilities (OCAPs) guarantees -- module accounts and sub-account authorization +-安定したprotobufベースのモジュールインターフェイスは、将来的にキーパーパラダイムに取って代わる可能性があります +-モジュール間オブジェクト機能(OCAP)のより強力な保証 +-モジュールアカウントとサブアカウントの承認 -## Context +## 環境 -In the current Cosmos SDK documentation on the [Object-Capability Model](../core/ocap.md), it is stated that: +現在のCosmosSDKドキュメントの[Object-CapabilityModel](...core .ocap.md)については、次のように述べられています。 -> 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. +>繁栄しているCosmosSDKモジュールエコシステムは、ブロックチェーンアプリケーションに簡単に組み合わせることができ、欠陥のあるモジュールや悪意のあるモジュールが含まれていると想定しています。 -There is currently not a thriving ecosystem of Cosmos SDK modules. We hypothesize that this is in part due to: +現在、繁栄しているCosmosSDKモジュールエコシステムはありません。これは部分的に次の理由によるものと想定しています。 -1. lack of a stable v1.0 Cosmos SDK to build modules off of. Module interfaces are changing, sometimes dramatically, from -point release to point release, often for good reasons, but this does not create a stable foundation to build on. -2. lack of a properly implemented object capability or even object-oriented encapsulation system which makes refactors -of module keeper interfaces inevitable because the current interfaces are poorly constrained. +1.モジュールを構築するための安定したv1.0CosmosSDKの欠如。モジュールインターフェイスは、から、時には劇的に変化しています +通常、ポイントリリースからポイントリリースへの正当な理由がありますが、これは安定した基盤を確立しません。 +2.正しく実装されたオブジェクト機能またはオブジェクト指向のパッケージングシステムの欠如、リファクタリングにつながる +現在のインターフェースの制約は非常に貧弱であるため、モジュールホルダーインターフェースの数は避けられません。 -### `x/bank` Case Study +### `x .bank`のケーススタディ -Currently the `x/bank` keeper gives pretty much unrestricted access to any module which references it. For instance, the -`SetBalance` method allows the caller to set the balance of any account to anything, bypassing even proper tracking of supply. +現在、 `x .bank`キーパーは、それを参照するすべてのモジュールにほぼ無制限にアクセスできます。例えば、 +`SetBalance`メソッドを使用すると、呼び出し元は、適切な供給追跡をバイパスする場合でも、任意のアカウントの残高を任意に設定できます。 -There appears to have been some later attempts to implement some semblance of OCAPs using module-level minting, staking -and burning permissions. These permissions allow a module to mint, burn or delegate tokens with reference to the module’s -own account. These permissions are actually stored as a `[]string` array on the `ModuleAccount` type in state. +その後、いくつかのOCAPの外観を実現するために、モジュールレベルのキャスティングと住宅ローンを使用する試みがいくつかあったようです。 +そして、許可を焼きます。これらの権限により、モジュールはモジュールの +自分のアカウント。これらの権限は、実際には、状態の「ModuleAccount」タイプの「[] string」配列に格納されます。 -However, these permissions don’t really do much. They control what modules can be referenced in the `MintCoins`, -`BurnCoins` and `DelegateCoins***` methods, but for one there is no unique object capability token that controls access — -just a simple string. So the `x/upgrade` module could mint tokens for the `x/staking` module simple by calling -`MintCoins(“staking”)`. Furthermore, all modules which have access to these keeper methods, also have access to -`SetBalance` negating any other attempt at OCAPs and breaking even basic object-oriented encapsulation. +ただし、これらの権限は実際にはあまり効果がありません。これらは、「MintCoins」で参照できるモジュールを制御します。 +`BurnCoins`メソッドと` DelegateCoins *** `メソッドがありますが、そのうちの1つには、アクセスを制御するための一意のオブジェクト機能トークンがありません- +単純な文字列。したがって、 `x .upgrade`モジュールは、を呼び出すことで、` x .stakeing`モジュールのトークンを単純に作成できます。 +`MintCoins("ステーキング ")`。さらに、これらのキーパーメソッドにアクセスできるすべてのモジュールもアクセスできます +`SetBalance`は、OCAPによる他の試みを無効にし、基本的なオブジェクト指向のカプセル化さえも破壊します。 -## Decision +## 決定 -Based on [ADR-021](./adr-021-protobuf-query-encoding.md) and [ADR-031](./adr-031-msg-service.md), we introduce the -Inter-Module Communication framework for secure module authorization and OCAPs. -When implemented, this could also serve as an alternative to the existing paradigm of passing keepers between -modules. The approach outlined here-in is intended to form the basis of a Cosmos SDK v1.0 that provides the necessary -stability and encapsulation guarantees that allow a thriving module ecosystem to emerge. +[ADR-021](..adr-021-protobuf-query-encoding.md)と[ADR-031](..adr-031-msg-service.md)に基づいて、 +セキュリティモジュールの承認とOCAPのためのモジュール間通信フレームワーク。 +実装後、これは既存のパラダイムの代替として使用することもできます。 +モジュール。ここで概説する方法は、Cosmos SDK v1.0の基礎を形成し、必要なものを提供することを目的としています。 +安定性とパッケージングの保証により、繁栄するモジュールエコシステムが出現しました。 -Of particular note — the decision is to _enable_ this functionality for modules to adopt at their own discretion. -Proposals to migrate existing modules to this new paradigm will have to be a separate conversation, potentially -addressed as amendments to this ADR. +特に注目に値するのは、モジュールがそれを単独で採用することを決定できるように、この関数を_enable_決定することです。 +既存のモジュールをこの新しいパラダイムに移行するという提案は、別の会話である必要があります。 +このADRの修正として。 -### New "Keeper" Paradigm +### 新しい「ガーディアン」パラダイム -In [ADR 021](./adr-021-protobuf-query-encoding.md), a mechanism for using protobuf service definitions to define queriers -was introduced and in [ADR 31](./adr-031-msg-service.md), a mechanism for using protobuf service to define `Msg`s was added. -Protobuf service definitions generate two golang interfaces representing the client and server sides of a service plus -some helper code. Here is a minimal example for the bank `cosmos.bank.Msg/Send` message type: +[ADR 021](..adr-021-protobuf-query-encoding.md)では、protobufサービス定義を使用してクエリを定義するためのメカニズム +[ADR 31](..adr-031-msg-service.md)で導入され、protobufサービスを使用して `Msg`を定義するメカニズムが追加されました。 +Protobufサービス定義は、サービスのクライアント側とサーバー側を表す2つのgolangインターフェースに加えて +いくつかのヘルプコード。以下は、銀行 `cosmos.bank.Msg .Send`のメッセージタイプの最小限の例です。 ```go package bank @@ -77,66 +77,66 @@ type MsgServer interface { } ``` -[ADR 021](./adr-021-protobuf-query-encoding.md) and [ADR 31](./adr-031-msg-service.md) specifies how modules can implement the generated `QueryServer` -and `MsgServer` interfaces as replacements for the legacy queriers and `Msg` handlers respectively. +[ADR 021](..adr-021-protobuf-query-encoding.md)および[ADR 31](..adr-031-msg-service.md)は、モジュールが生成された `QueryServer`を実装する方法を指定します +と `MsgServer`インターフェースは、それぞれ古いクエリャーと` Msg`ハンドラーの代わりに使用されます。 -In this ADR we explain how modules can make queries and send `Msg`s to other modules using the generated `QueryClient` -and `MsgClient` interfaces and propose this mechanism as a replacement for the existing `Keeper` paradigm. To be clear, -this ADR does not necessitate the creation of new protobuf definitions or services. Rather, it leverages the same proto -based service interfaces already used by clients for inter-module communication. +このADRでは、モジュールが生成された `QueryClient`を使用して、` Msg`をクエリして他のモジュールに送信する方法について説明しました。 +`MsgClient`とインターフェイスし、既存の` Keeper`パラダイムを置き換えるこのメカニズムを提案します。明確にするために、 +このADRでは、新しいprotobuf定義またはサービスを作成する必要はありません。代わりに、同じプロトタイプを使用します +クライアントがモジュール間の通信に使用したサービスインターフェイスに基づきます。 -Using this `QueryClient`/`MsgClient` approach has the following key benefits over exposing keepers to external modules: +この `QueryClient`.` MsgClient`メソッドを使用すると、Keepersを外部モジュールに公開するよりも次の主な利点があります。 -1. Protobuf types are checked for breaking changes using [buf](https://buf.build/docs/breaking-overview) and because of -the way protobuf is designed this will give us strong backwards compatibility guarantees while allowing for forward -evolution. -2. The separation between the client and server interfaces will allow us to insert permission checking code in between -the two which checks if one module is authorized to send the specified `Msg` to the other module providing a proper -object capability system (see below). -3. The router for inter-module communication gives us a convenient place to handle rollback of transactions, -enabling atomicy of operations ([currently a problem](https://github.com/cosmos/cosmos-sdk/issues/8030)). Any failure within a module-to-module call would result in a failure of the entire -transaction +1. [buf](https://buf.build/docs/break-overview)を使用して、Protobufタイプの重大な変更を確認します。 +protobufの設計により、前方互換性を確保しながら、強力な下位互換性が保証されます。 +進化。 +2.クライアントインターフェイスとサーバーインターフェイスを分離することで、2つの間に権限チェックコードを挿入できるようになります +これらの2つは、モジュールが指定された `Msg`を別のモジュールに送信して適切なものを提供することを許可されているかどうかを確認します +オブジェクト能力システム(以下を参照)。 +3.モジュール間の通信に使用されるルーターは、トランザクションのロールバックを処理するための便利な場所を提供します。 +操作のアトミック性を有効にします([現在の問題](https://github.com/cosmos/cosmos-sdk/issues/8030))。モジュール間呼び出しで障害が発生すると、モジュール全体で障害が発生します +トレード -This mechanism has the added benefits of: +このメカニズムには、次の追加の利点があります。 -- reducing boilerplate through code generation, and -- allowing for modules in other languages either via a VM like CosmWasm or sub-processes using gRPC +-コード生成を通じてボイラープレートを削減し、 +-CosmWasmなどのVMまたはgRPCを使用する子プロセスを介して他の言語のモジュールを使用できるようにする -### Inter-module Communication +### モジュール間通信 -To use the `Client` generated by the protobuf compiler we need a `grpc.ClientConn` [interface](https://github.com/regen-network/protobuf/blob/cosmos/grpc/types.go#L12) -implementation. For this we introduce -a new type, `ModuleKey`, which implements the `grpc.ClientConn` interface. `ModuleKey` can be thought of as the "private -key" corresponding to a module account, where authentication is provided through use of a special `Invoker()` function, -described in more detail below. +protobufコンパイラによって生成された `Client`を使用するには、` grpc.ClientConn` [interface](https://github.com/regen-network/protobuf/blob/cosmos/grpc/types.go#L12)が必要です。 +埋め込む。このために私たちは紹介します +`grpc.ClientConn`インターフェースを実装する新しいタイプ` ModuleKey`。 `ModuleKey`は「プライベート」と見なすことができます +「キー」はモジュールアカウントに対応し、特別な `Invoker()`関数を使用して認証を提供します。 +これについては、以下で詳しく説明します。 -Blockchain users (external clients) use their account's private key to sign transactions containing `Msg`s where they are listed as signers (each -message specifies required signers with `Msg.GetSigner`). The authentication checks is performed by `AnteHandler`. +ブロックチェーンユーザー(外部クライアント)は、アカウントの秘密鍵を使用して、署名者としてリストされている「メッセージ」を含むトランザクションに署名します(それぞれ +メッセージは `Msg.GetSigner`を使用して必要な署名者を指定します)。認証チェックは `AnteHandler`によって実行されます。 -Here, we extend this process, by allowing modules to be identified in `Msg.GetSigners`. When a module wants to trigger the execution a `Msg` in another module, -its `ModuleKey` acts as the sender (through the `ClientConn` interface we describe below) and is set as a sole "signer". It's worth to note -that we don't use any cryptographic signature in this case. -For example, module `A` could use its `A.ModuleKey` to create `MsgSend` object for `/cosmos.bank.Msg/Send` transaction. `MsgSend` validation -will assure that the `from` account (`A.ModuleKey` in this case) is the signer. +ここでは、モジュールを `Msg.GetSigners`で識別できるようにすることで、このプロセスを拡張します。モジュールが別のモジュールで `Msg`の実行をトリガーしたい場合、 +その `ModuleKey`は送信者として機能し(以下で説明する` ClientConn`インターフェースを介して)、唯一の「署名者」として設定されます。注目に値する +この場合、暗号化署名は使用しません。 +たとえば、モジュール `A`は、その` A.ModuleKey`を使用して、 `.cosmos.bank.Msg .Send`トランザクション用の` MsgSend`オブジェクトを作成できます。 `MsgSend`検証 +これにより、 `from`アカウント(この場合は` A.ModuleKey`)が署名者になります。 -Here's an example of a hypothetical module `foo` interacting with `x/bank`: +以下は、モジュール `foo`が` x .bank`と相互作用すると仮定した例です。 ```go package foo type FooMsgServer { - // ... + ..... bankQuery bank.QueryClient bankMsg bank.MsgClient } func NewFooMsgServer(moduleKey RootModuleKey, ...) FooMsgServer { - // ... + ..... return FooMsgServer { - // ... + ..... modouleKey: moduleKey, bankQuery: bank.NewQueryClient(moduleKey), bankMsg: bank.NewMsgClient(moduleKey), @@ -154,18 +154,18 @@ func (foo *FooMsgServer) Bar(ctx context.Context, req *MsgBarRequest) (*MsgBarRe } ``` -This design is also intended to be extensible to cover use cases of more fine grained permissioning like minting by -denom prefix being restricted to certain modules (as discussed in -[#7459](https://github.com/cosmos/cosmos-sdk/pull/7459#discussion_r529545528)). +この設計は、たとえばキャストによって、よりきめ細かいライセンスのユースケースをカバーするように拡張できることも目的としています。 +denomプレフィックスは、特定のモジュールに制限されています(例: +[#7459](https://github.com/cosmos/cosmos-sdk/pull/7459#discussion_r529545528))。 -### `ModuleKey`s and `ModuleID`s +### `ModuleKey`sと` ModuleID`s -A `ModuleKey` can be thought of as a "private key" for a module account and a `ModuleID` can be thought of as the -corresponding "public key". From the [ADR 028](./adr-028-public-key-addresses.md), modules can have both a root module account and any number of sub-accounts -or derived accounts that can be used for different pools (ex. staking pools) or managed accounts (ex. group -accounts). We can also think of module sub-accounts as similar to derived keys - there is a root key and then some -derivation path. `ModuleID` is a simple struct which contains the module name and optional "derivation" path, -and forms its address based on the `AddressHash` method from [the ADR-028](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses.md): +`ModuleKey`はモジュールアカウントの「秘密鍵」と見なすことができ、` ModuleID`は次のように見なすことができます +対応する「公開鍵」。 [ADR 028](..adr-028-public-key-addresses.md)から、モジュールはルートモジュールアカウントと任意の数のサブアカウントを持つことができます +または、さまざまなプール(例:誓約プール)または管理アカウント(例:グループ)で使用できます +アカウント)。 モジュールサブアカウントは派生キーに似ていると考えることもできます。ルートキーがあり、次にいくつかあります。 +パスを導き出します。 `ModuleID`は、モジュール名とオプションの「派生」パスを含む単純な構造です。 +そして、[ADR-028](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses)の `AddressHash`メソッドに従ってアドレスを形成します。md): ```go type ModuleID struct { @@ -178,15 +178,18 @@ func (key ModuleID) Address() []byte { } ``` -In addition to being able to generate a `ModuleID` and address, a `ModuleKey` contains a special function called -`Invoker` which is the key to safe inter-module access. The `Invoker` creates an `InvokeFn` closure which is used as an `Invoke` method in -the `grpc.ClientConn` interface and under the hood is able to route messages to the appropriate `Msg` and `Query` handlers -performing appropriate security checks on `Msg`s. This allows for even safer inter-module access than keeper's whose -private member variables could be manipulated through reflection. Golang does not support reflection on a function -closure's captured variables and direct manipulation of memory would be needed for a truly malicious module to bypass -the `ModuleKey` security. +この設計は、たとえばキャストによって、よりきめ細かいライセンスのユースケースをカバーするように拡張できることも目的としています。 +denomプレフィックスは、特定のモジュールに制限されています(例: +[#7459](https://github.com/cosmos/cosmos-sdk/pull/7459#discussion_r529545528))。 -The two `ModuleKey` types are `RootModuleKey` and `DerivedModuleKey`: +### `ModuleKey`sと` ModuleID`s + +`ModuleKey`はモジュールアカウントの「秘密鍵」と見なすことができ、` ModuleID`は次のように見なすことができます +対応する「公開鍵」。 [ADR 028](..adr-028-public-key-addresses.md)から、モジュールはルートモジュールアカウントと任意の数のサブアカウントを持つことができます +または、さまざまなプール(例:誓約プール)または管理アカウント(例:グループ)で使用できます +アカウント)。 モジュールサブアカウントは派生キーに似ていると考えることもできます。ルートキーがあり、次にいくつかあります。 +パスを導き出します。 `ModuleID`は、モジュール名とオプションの「派生」パスを含む単純な構造です。 +そして、[ADR-028](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses)の `AddressHash`メソッドに従ってアドレスを形成します。md): ```go type Invoker func(callInfo CallInfo) func(ctx context.Context, request, response interface{}, opts ...interface{}) error @@ -201,7 +204,7 @@ type RootModuleKey struct { invoker Invoker } -func (rm RootModuleKey) Derive(path []byte) DerivedModuleKey { /* ... */} +func (rm RootModuleKey) Derive(path []byte) DerivedModuleKey {.* ... */} type DerivedModuleKey struct { moduleName string @@ -210,8 +213,8 @@ type DerivedModuleKey struct { } ``` -A module can get access to a `DerivedModuleKey`, using the `Derive(path []byte)` method on `RootModuleKey` and then -would use this key to authenticate `Msg`s from a sub-account. Ex: +モジュールは、 `RootModuleKey`で` Derive(path [] byte) `メソッドを使用して、` DerivedModuleKey`にアクセスできます。 +このキーは、サブアカウントからの「メッセージ」を確認するために使用されます。 元: ```go package foo @@ -224,20 +227,20 @@ func (fooMsgServer *MsgServer) Bar(ctx context.Context, req *MsgBar) (*MsgBarRes } ``` -In this way, a module can gain permissioned access to a root account and any number of sub-accounts and send -authenticated `Msg`s from these accounts. The `Invoker` `callInfo.Caller` parameter is used under the hood to -distinguish between different module accounts, but either way the function returned by `Invoker` only allows `Msg`s -from either the root or a derived module account to pass through. +このようにして、モジュールはルートアカウントと任意の数のサブアカウントにアクセスして送信するためのアクセス許可を取得できます +これらのアカウントからの認証された「メッセージ」。 `Invoker``callInfo.Caller`パラメータがバックグラウンドで使用されます +異なるモジュールアカウントを区別しますが、どちらの方法でも、 `Invoker`によって返される関数は` Msg`のみを許可します +ルートまたは派生モジュールアカウントから渡します。 -Note that `Invoker` itself returns a function closure based on the `CallInfo` passed in. This will allow client implementations -in the future that cache the invoke function for each method type avoiding the overhead of hash table lookup. -This would reduce the performance overhead of this inter-module communication method to the bare minimum required for -checking permissions. +`Invoker`自体は、渡された` CallInfo`に基づいて関数クロージャを返すことに注意してください。 これにより、クライアントは実装できるようになります +将来的には、ハッシュテーブルルックアップのオーバーヘッドを回避するために、各メソッドタイプの呼び出し関数がキャッシュされます。 +これにより、このモジュール間通信方式のパフォーマンスオーバーヘッドが最小限に抑えられます。 +権限を確認してください。 -To re-iterate, the closure only allows access to authorized calls. There is no access to anything else regardless of any -name impersonation. +繰り返しになりますが、クロージャはアクセス許可呼び出しのみを許可します。 他のものにアクセスする方法はありません +名前になりすます。 -Below is a rough sketch of the implementation of `grpc.ClientConn.Invoke` for `RootModuleKey`: +以下は、「RootModuleKey」の「grpc.ClientConn.Invoke」実装の大まかなスケッチです。 ```go func (key RootModuleKey) Invoke(ctx context.Context, method string, args, reply interface{}, opts ...grpc.CallOption) error { @@ -246,11 +249,11 @@ func (key RootModuleKey) Invoke(ctx context.Context, method string, args, reply } ``` -### `AppModule` Wiring and Requirements +### `AppModule`の配線と要件 -In [ADR 031](./adr-031-msg-service.md), the `AppModule.RegisterService(Configurator)` method was introduced. To support -inter-module communication, we extend the `Configurator` interface to pass in the `ModuleKey` and to allow modules to -specify their dependencies on other modules using `RequireServer()`: +[ADR 031](..adr-031-msg-service.md)では、 `AppModule.RegisterService(Configurator)`メソッドが導入されました。 サポート +モジュール間の通信のために、 `Configurator`インターフェースを拡張して` ModuleKey`を渡し、モジュールを許可します +`RequireServer()`を使用して、他のモジュールへの依存関係を指定します。 ```go type Configurator interface { @@ -262,15 +265,15 @@ type Configurator interface { } ``` -The `ModuleKey` is passed to modules in the `RegisterService` method itself so that `RegisterServices` serves as a single -entry point for configuring module services. This is intended to also have the side-effect of greatly reducing boilerplate in -`app.go`. For now, `ModuleKey`s will be created based on `AppModuleBasic.Name()`, but a more flexible system may be -introduced in the future. The `ModuleManager` will handle creation of module accounts behind the scenes. +`ModuleKey`は` RegisterService`メソッド自体でモジュールに渡されるため、 `RegisterServices`は単一のものとして +モジュールサービスのエントリポイントを構成します。 これは、ボイラープレートを大幅に削減するという副作用もあります。 +`app.go`。 現在、 `ModuleKey`は` AppModuleBasic.Name() `に基づいて作成されますが、より柔軟なシステムは +将来。 `ModuleManager`は、バックグラウンドでモジュールアカウントの作成を処理します。 -Because modules do not get direct access to each other anymore, modules may have unfulfilled dependencies. To make sure -that module dependencies are resolved at startup, the `Configurator.RequireServer` method should be added. The `ModuleManager` -will make sure that all dependencies declared with `RequireServer` can be resolved before the app starts. An example -module `foo` could declare it's dependency on `x/bank` like this: +モジュールは相互に直接アクセスできなくなったため、モジュールの依存関係が満たされていない可能性があります。 確実に +起動時にモジュールの依存関係が解決された場合は、 `Configurator.RequireServer`メソッドを追加する必要があります。 `モジュールマネージャー` +これにより、アプリケーションが起動する前に、RequireServerで宣言されたすべての依存関係を解決できるようになります。 一例 +モジュール `foo`は、次のように` x .bank`への依存関係を宣言できます。 ```go package foo @@ -281,31 +284,31 @@ func (am AppModule) RegisterServices(cfg Configurator) { } ``` -### Security Considerations +### 安全上のご注意 -In addition to checking for `ModuleKey` permissions, a few additional security precautions will need to be taken by -the underlying router infrastructure. +「ModuleKey」権限の確認に加えて、いくつかの追加のセキュリティ対策を講じる必要があります +基盤となるルーターインフラストラクチャ。 -#### Recursion and Re-entry +#### 再帰と再入可能 -Recursive or re-entrant method invocations pose a potential security threat. This can be a problem if Module A -calls Module B and Module B calls module A again in the same call. +再帰的または再入可能なメソッド呼び出しは、潜在的なセキュリティの脅威を構成します。モジュールAの場合、これは問題である可能性があります +モジュールBとモジュールBを同じ呼び出しで呼び出します。モジュールAが再度呼び出されます。 -One basic way for the router system to deal with this is to maintain a call stack which prevents a module from -being referenced more than once in the call stack so that there is no re-entry. A `map[string]interface{}` table -in the router could be used to perform this security check. +ルータシステムがこの問題に対処するための基本的な方法は、モジュールを防ぐためにコールスタックを維持することです。 +コールスタックで複数回参照されるため、再入力されません。 `map [string] interface {}`テーブル +このセキュリティチェックを実行するためにルータで使用できます。 -#### Queries +#### お問い合わせ -Queries in Cosmos SDK are generally un-permissioned so allowing one module to query another module should not pose -any major security threats assuming basic precautions are taken. The basic precaution that the router system will -need to take is making sure that the `sdk.Context` passed to query methods does not allow writing to the store. This -can be done for now with a `CacheMultiStore` as is currently done for `BaseApp` queries. +Cosmos SDKのクエリは通常ライセンスがないため、あるモジュールが別のモジュールにクエリを実行できるようにすることは、構成されるべきではありません。 +基本的な予防策を講じる場合、主要なセキュリティ上の脅威。ルーターシステムの基本的な注意事項 +queryメソッドに渡された `sdk.Context`がストレージへの書き込みを許可されていないことを確認する必要があります。この +これは、「BaseApp」クエリに対して現在実行されているのと同じように、「CacheMultiStore」を使用して実行できるようになりました。 -### Internal Methods +### 内部メソッド -In many cases, we may wish for modules to call methods on other modules which are not exposed to clients at all. For this -purpose, we add the `InternalServer` method to `Configurator`: +多くの場合、モジュールが他のモジュールのメソッドを呼び出す必要があり、これらのモジュールはクライアントにまったく公開されません。このため +目標を達成するために、 `InternalServer`メソッドを` Configurator`に追加します。 ```go type Configurator interface { @@ -315,86 +318,85 @@ type Configurator interface { } ``` -As an example, x/slashing's Slash must call x/staking's Slash, but we don't want to expose x/staking's Slash to end users -and clients. - -Internal protobuf services will be defined in a corresponding `internal.proto` file in the given module's -proto package. +たとえば、Slash of x .stakeingはSlashof x .stakingを呼び出す必要がありますが、Slash of x .stakeingをエンドユーザーに公開したくありません。 +顧客と。 -Services registered against `InternalServer` will be callable from other modules but not by external clients. +内部protobufサービスは、指定されたモジュールの対応する「internal.proto」ファイルで定義されます。 +プロトタイプパッケージ。 -An alternative solution to internal-only methods could involve hooks / plugins as discussed [here](https://github.com/cosmos/cosmos-sdk/pull/7459#issuecomment-733807753). -A more detailed evaluation of a hooks / plugin system will be addressed later in follow-ups to this ADR or as a separate -ADR. +「InternalServer」に登録されているサービスは、他のモジュールから呼び出すことはできますが、外部クライアントから呼び出すことはできません。 -### Authorization +内部アプローチの別の解決策には、[ここ](https://github.com/cosmos/cosmos-sdk/pull/7459#issuecomment-733807753)で説明されているフック/プラグインが含まれる場合があります。 +フック/プラグインシステムのより詳細な評価は、このADRのフォローアップで、または個別に行われます。 +ADR。 -By default, the inter-module router requires that messages are sent by the first signer returned by `GetSigners`. The -inter-module router should also accept authorization middleware such as that provided by [ADR 030](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-030-authz-module.md). -This middleware will allow accounts to otherwise specific module accounts to perform actions on their behalf. -Authorization middleware should take into account the need to grant certain modules effectively "admin" privileges to -other modules. This will be addressed in separate ADRs or updates to this ADR. +### 承認 -### Future Work +デフォルトでは、モジュール間ルーターでは、GetSignersから返された最初の署名者がメッセージを送信する必要があります。この +モジュール間ルーターは、[ADR 030](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-030-authz-module.md)などの承認されたミドルウェアも受け入れる必要があります。 。 +ミドルウェアは、アカウントが他の方法で特定のモジュールアカウントに代わって操作を実行できるようにします。 +承認ミドルウェアは、特定のモジュールに「管理者」権限を効果的に付与する必要性を考慮する必要があります +その他のモジュール。これは、別のADRまたはこのADRの更新で解決されます。 -Other future improvements may include: +### 将来の仕事 -* custom code generation that: - * simplifies interfaces (ex. generates code with `sdk.Context` instead of `context.Context`) - * optimizes inter-module calls - for instance caching resolved methods after first invocation -* combining `StoreKey`s and `ModuleKey`s into a single interface so that modules have a single OCAPs handle -* code generation which makes inter-module communication more performant -* decoupling `ModuleKey` creation from `AppModuleBasic.Name()` so that app's can override root module account names -* inter-module hooks and plugins +その他の将来の改善には、次のものが含まれる可能性があります。 -## Alternatives +*カスタムコード生成: + *インターフェイスを簡素化します(たとえば、コードを生成するには、 `context.Context`の代わりに` sdk.Context`を使用します) + *モジュール間の呼び出しを最適化する-たとえば、最初の呼び出し後に解決をキャッシュする方法 +* `StoreKey`と` ModuleKey`を1つのインターフェースに結合して、モジュールが個別のOCAPハンドルを持つようにします。 +*モジュール間の通信をより効率的にするためのコード生成 +*アプリケーションがルートモジュールアカウント名を上書きできるように、 `ModuleKey`の作成を` AppModuleBasic.Name() `から切り離します +*モジュール間フックとプラグイン -### MsgServices vs `x/capability` +##代替プラン -The `x/capability` module does provide a proper object-capability implementation that can be used by any module in the -Cosmos SDK and could even be used for inter-module OCAPs as described in [\#5931](https://github.com/cosmos/cosmos-sdk/issues/5931). +### MsgServicesと `x .capability` -The advantages of the approach described in this ADR are mostly around how it integrates with other parts of the Cosmos SDK, -specifically: +`x .capability`モジュールは、適切なオブジェクト機能の実装を提供します。 +[\#5931](https://github.com/cosmos/cosmos-sdk/issues/5931)で説明されているように、CosmosSDKはモジュール間OCAPにも使用できます。 -* protobuf so that: - * code generation of interfaces can be leveraged for a better dev UX - * module interfaces are versioned and checked for breakage using [buf](https://docs.buf.build/breaking-overview) -* sub-module accounts as per ADR 028 -* the general `Msg` passing paradigm and the way signers are specified by `GetSigners` +このADRで説明されている方法の主な利点は、CosmosSDKの他の部分と統合する方法にあります。 +具体的には: -Also, this is a complete replacement for keepers and could be applied to _all_ inter-module communication whereas the -`x/capability` approach in #5931 would need to be applied method by method. +*次の目的でprotobuf: + *インターフェイスのコード生成を使用して、開発ユーザーエクスペリエンスを向上させることができます + * [buf](https://docs.buf.build/break-overview)を使用して、モジュールインターフェイスをバージョン管理し、損傷をチェックします +* ADR028のサブモジュールアカウントによると +*パラダイムと署名者を渡す一般的な `Msg`メソッドは` GetSigners`によって指定されます -## Consequences +さらに、これはキーパーの完全な代替品であり、モジュール間通信のすべてに適用できます。 +#5931の `x .capability`メソッドは1つずつ適用する必要があります。 -### Backwards Compatibility +## 結果 -This ADR is intended to provide a pathway to a scenario where there is greater long term compatibility between modules. -In the short-term, this will likely result in breaking certain `Keeper` interfaces which are too permissive and/or -replacing `Keeper` interfaces altogether. +### 下位互換性 -### Positive +このADRは、モジュール間の長期的な互換性が高いシナリオの方法を提供することを目的としています。 +短期的には、これは過度に寛大なおよび/または +`Keeper`インターフェースを完全に置き換えます。 +### ポジティブ -- an alternative to keepers which can more easily lead to stable inter-module interfaces -- proper inter-module OCAPs -- improved module developer DevX, as commented on by several particpants on - [Architecture Review Call, Dec 3](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q) -- lays the groundwork for what can be a greatly simplified `app.go` -- router can be setup to enforce atomic transactions for module-to-module calls +-安定したモジュール間インターフェースをより簡単に実装できるKeepersの代替 +-適切なモジュール間OCAP +-一部の参加者がコメントしたように、モジュール開発者DevXを改善しました + [アーキテクチャレビュー電話会議、12月3日](https://hackmd.io/E0wxxOvRQ5qVmTf6N_k84Q) +-大幅に簡素化された「app.go」の基盤を築く +-ルーターは、モジュールからモジュールへの呼び出しへのアトミックトランザクションを実施するように設定できます -### Negative +### ネガティブ -- modules which adopt this will need significant refactoring +-この方法のモジュールには、多くのリファクタリングが必要になります -### Neutral +### ニュートラル -## Test Cases [optional] +## テストケース[オプション] -## References +## 参照 -- [ADR 021](./adr-021-protobuf-query-encoding.md) -- [ADR 031](./adr-031-msg-service.md) -- [ADR 028](./adr-028-public-key-addresses.md) -- [ADR 030 draft](https://github.com/cosmos/cosmos-sdk/pull/7105) -- [Object-Capability Model](../docs/core/ocap.md) +-[ADR 021](..adr-021-protobuf-query-encoding.md) +-[ADR 031](..adr-031-msg-service.md) +-[ADR 028](..adr-028-public-key-addresses.md) +-[ADR 030ドラフト](https://github.com/cosmos/cosmos-sdk/pull/7105) +-[オブジェクト機能モデル](...docs .core .ocap.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-034-account-rekeying.md b/docs/ja/architecture/adr-034-account-rekeying.md index d3b54d17f17e..20e1ab203c12 100644 --- a/docs/ja/architecture/adr-034-account-rekeying.md +++ b/docs/ja/architecture/adr-034-account-rekeying.md @@ -1,30 +1,30 @@ -# ADR 034: Account Rekeying +# ADR 034:アカウントのキーの再生成 -## Changelog +## 変更ログ -- 30-09-2020: Initial Draft +2020年9月30日:最初のドラフト -## 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. +現在、Cosmos SDKでは、auth`BaseAccount`のアドレスは公開鍵のハッシュ値に基づいています。アカウントが作成された後、アカウントの公開鍵は不変であり、変更することはできません。キーローテーションは便利なセキュリティプラクティスであるため、これはユーザーにとって問題になる可能性がありますが、現在は不可能です。また、マルチ署名は一種の公開鍵であるため、アカウントのマルチ署名を設定すると更新できなくなります。組織や企業はマルチシグニチャを使用することが多く、内部的な理由により、マルチシグニチャセットを変更する必要がある場合があるため、これは問題があります。 -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. +アカウントの一部の「参加」は簡単に転送できないため、更新された公開鍵を使用してアカウントのすべての資産を新しいアカウントに転送するだけでは不十分です。たとえば、ステーキングでは、バインドされたAtomを転送するために、アカウントはすべての委任を解放し、3週間のバインド解除期間を待つ必要があります。さらに重要なことに、検証者のオペレーターの場合、検証者の所有権は基本的に譲渡できません。つまり、検証者のオペレーターキーを更新できないため、検証者の運用上のセキュリティが低下します。 -## 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. +`x .auth`に新機能を追加することをお勧めします。これにより、アカウントは、アドレスを変更せずに、アカウントに関連付けられた公開鍵を更新できます。 -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. +これが可能なのは、Cosmos SDKの `BaseAccount`が、他のブロックチェーン(ビットコインなど)のように公開鍵がトランザクション(明示的または暗黙的)に含まれていると想定するのではなく、アカウントの公開鍵を状態で保存するためです。 )およびEthereum。公開鍵はチェーンに格納されているため、アドレスは署名チェックプロセスとは関係がないため、公開鍵がアカウントアドレスにハッシュされていない可能性があります。 -To build this system, we design a new Msg type as follows: +このシステムを構築するために、次のように新しいMsgタイプを設計しました。 ```protobuf service Msg { @@ -39,38 +39,37 @@ message MsgChangePubKey { message MsgChangePubKeyResponse {} ``` -The MsgChangePubKey transaction needs to be signed by the existing pubkey in state. +MsgChangePubKeyトランザクションは、州内の既存の公開鍵によって署名される必要があります。 -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. +承認されると、このメッセージタイプのハンドラー(AccountKeeperを受け入れる)は、アカウントの状態公開鍵を更新し、メッセージ内の公開鍵に置き換えます。 -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. +公開鍵が変更されたアカウントは、状態から自動的に削除することはできません。 これは、プルーニングされた場合、アカウントの元の公開鍵で同じアドレスを再作成する必要がありますが、アドレスの所有者が元の公開鍵を所有していない可能性があるためです。 現在、アカウントを自動的にトリミングすることはありませんが、このオプションを妨げないようにします(これがアカウントの目的です)。 この問題を解決するために、この外部性を補うために、この操作に追加のガス料金を請求します(バインドされたガス量はパラメーター `PubKeyChangeCost`として構成されます)。 `ConsumeGas`関数を使用して、ハンドラー内の余分なガスを充電します。 さらに、将来的には、新しいMsgタイプ(「MsgDeleteAccount」など)を使用するアカウントが、セルフプルーニング用のキーを手動で再生成できるようにすることができます。 アカウントの手動プルーニングは、操作を実行するためのインセンティブとしてガスの払い戻しを提供できます。 ```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. +アドレスのキーが変更されるたびに、この変更のログがチェーンの状態に保存され、アドレスの以前のすべてのキーとそれらがアクティブである時間間隔のスタックが作成されます。これにより、dappsとクライアントは、アカウントの過去のキーを簡単に照会できます。これは、タイムスタンプ付きのオフチェーン署名付きメッセージの検証などの機能に役立つ場合があります。 -## 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. +H(pubkey)= addressであるため、アドレスと公開鍵の間で現在想定されている関係を解除します。これにはいくつかの結果があります。 -* 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. +*これにより、この機能をサポートするウォレットがより複雑になります。たとえば、チェーン上のアドレスが更新された場合、CLIウォレットの対応するキーも更新する必要があります。 +*変更された公開鍵の残高が0のアカウントは、自動的にプルーニングできません。 +### ニュートラル -### 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 ++ https://www.algorand.com/resources/blog/announcing-rekeying \ No newline at end of file diff --git a/docs/ja/architecture/adr-035-rosetta-api-support.md b/docs/ja/architecture/adr-035-rosetta-api-support.md index 7a10a59b0d42..b184160695ac 100644 --- a/docs/ja/architecture/adr-035-rosetta-api-support.md +++ b/docs/ja/architecture/adr-035-rosetta-api-support.md @@ -1,176 +1,176 @@ -# ADR 035: Rosetta API Support +# ADR 035:RosettaAPIのサポート -## Authors +## 著者 -- Jonathan Gimeno (@jgimeno) -- David Grierson (@senormonito) -- Alessio Treglia (@alessio) -- Frojdy Dymylja (@fdymylja) +-ジョナサン・ギメノ(@jgimeno) +-デビッドグリーソン(@senormonito) +-Alessio Treglia(@alessio) +-Frojdy Dymylja(@fdymylja) -## Changelog +## 変更ログ -- 2021-05-12: the external library [cosmos-rosetta-gateway](https://github.com/tendermint/cosmos-rosetta-gateway) has been moved within the Cosmos SDK. +-2021-05-12:外部ライブラリ[cosmos-rosetta-gateway](https://github.com/tendermint/cosmos-rosetta-gateway)がCosmosSDKに移動されました。 -## Context +## 環境 -[Rosetta API](https://www.rosetta-api.org/) is an open-source specification and set of tools developed by Coinbase to -standardise blockchain interactions. +[Rosetta API](https://www.rosetta-api.org/)は、Coinbaseによって開発されたオープンソース仕様およびツールセットです。 +ブロックチェーンの相互作用を標準化します。 -Through the use of a standard API for integrating blockchain applications it will +標準のAPIを使用してブロックチェーンアプリケーションを統合することにより、 -* 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. +*ユーザーが特定のブロックチェーンを簡単に操作できるようにする +*取引所が新しいブロックチェーンを迅速かつ簡単に統合できるようにする +*アプリケーション開発者が、ブロックエクスプローラー、ウォレット、dAppなどの次の場所でクロスブロックチェーンアプリケーションを構築できるようにします + コストと作業負荷を大幅に削減します。 -## 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. +明らかに、CosmosSDKにRosettaAPIサポートを追加すると、すべての開発者と +エコシステム内のCosmosSDKに基づくチェーン。実装方法が鍵となります。 -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. +1. **スケーラビリティ:**ネットワークをセットアップするアプリケーション開発者は、可能な限りリスクがなく、痛みがない必要があります + RosettaAPI互換サービスの構成を公開するために使用されます。 +2. **長期サポート:**この提案は、サポートされているすべてのCosmosSDKバージョンシリーズのサポートを提供することを目的としています。 +3. **コスト効率:** RosettaAPI仕様の後方移植が `master`からさまざまな安定したバージョンに変更されました + Cosmos SDKのブランチは、コストを削減する必要があります。 -We will achieve these delivering on these principles by the following: +これらの原則は、次の方法で実装します。 -1. There will be a package `rosetta/lib` - for the implementation of the core Rosetta API features, particularly: - a. The types and interfaces (`Client`, `OfflineClient`...), this separates design from implementation detail. - b. The `Server` functionality as this is independent of the Cosmos SDK version. - c. The `Online/OfflineNetwork`, which is not exported, and implements the rosetta API using the `Client` interface to query the node, build tx and so on. - d. The `errors` package to extend rosetta errors. -2. Due to differences between the Cosmos release series, each series will have its own specific implementation of `Client` interface. -3. There will be two options for starting an API service in applications: - a. API shares the application process - b. API-specific process. +1.パッケージ `rosetta .lib`があります + 特に次のようなコアRosettaAPI関数を実装するために使用されます。 + 一。設計と実装の詳細を分離するタイプとインターフェース( `Client`、` OfflineClient` ...)。 + `Server`関数は、CosmosSDKのバージョンに依存しません。 + C。 `Online .OnlineNetwork`、エクスポートしないでください。`Client`インターフェースを使用して、ロゼッタAPIの実装、ノードのクエリ、txのビルドなどを行ってください。 + d。ロゼッタエラーを拡張するために使用される `errors`パッケージ。 +2. Cosmosリリースシリーズの違いにより、各シリーズには、「クライアント」インターフェイスの独自の実装があります。 +3.アプリケーションでAPIサービスを開始するには、次の2つのオプションがあります。 + 一。 API共有申請プロセス + API固有のプロセス。 -## Architecture +## 建築 -### The External Repo +### 外部購入 -As section will describe the proposed external library, including the service implementation, plus the defined types and interfaces. +一部として、提案された外部ライブラリについて、サービスの実装、定義されたタイプおよびインターフェイスを含めて説明します。 -#### Server +#### サーバー -`Server` is a simple `struct` that is started and listens to the port specified in the settings. This is meant to be used across all the Cosmos SDK versions that are actively supported. +`Server`は、設定で指定されたポートで起動およびリッスンする単純な` struct`です。これは、アクティブにサポートされているすべてのバージョンのCosmosSDKで使用することを目的としています。 -The constructor follows: +コンストラクターは次のとおりです。 -`func NewServer(settings Settings) (Server, error)` +`func NewServer(設定)(サーバー、エラー)` -`Settings`, which are used to construct a new server, are the following: +新しいサーバーを構築するために使用される「設定」は次のとおりです。 ```go -// Settings define the rosetta server settings +/.Settings define the rosetta server settings type Settings struct { - // Network contains the information regarding the network + /.Network contains the information regarding the network Network *types.NetworkIdentifier - // Client is the online API handler + /.Client is the online API handler Client crgtypes.Client - // Listen is the address the handler will listen at + /.Listen is the address the handler will listen at Listen string - // Offline defines if the rosetta service should be exposed in offline mode + /.Offline defines if the rosetta service should be exposed in offline mode Offline bool - // Retries is the number of readiness checks that will be attempted when instantiating the handler - // valid only for online API + /.Retries is the number of readiness checks that will be attempted when instantiating the handler + /.valid only for online API Retries int - // RetryWait is the time that will be waited between retries + /.RetryWait is the time that will be waited between retries RetryWait time.Duration } ``` -#### Types +#### タイプ -Package types uses a mixture of rosetta types and custom defined type wrappers, that the client must parse and return while executing operations. +パッケージタイプはロゼッタタイプとカスタム定義タイプラッパーを混合し、クライアントは操作を実行するときにそれを解析して返す必要があります。 -##### Interfaces +##### インターフェース -Every SDK version uses a different format to connect (rpc, gRPC, etc), query and build transactions, we have abstracted this in what is the `Client` interface. -The client uses rosetta types, whilst the `Online/OfflineNetwork` takes care of returning correctly parsed rosetta responses and errors. +SDKの各バージョンは、接続(rpc、gRPCなど)、クエリ、トランザクションの構築に異なる形式を使用します。これを「クライアント」インターフェイスとは何かで抽象化します。 +クライアントはロゼッタタイプを使用し、 `Online .OfflineNetwork`は正しく解析されたロゼッタ応答とエラーを返す責任があります。 -Each Cosmos SDK release series will have their own `Client` implementations. -Developers can implement their own custom `Client`s as required. +Cosmos SDKの各バージョンシリーズには、独自の「クライアント」実装があります。 +開発者は、必要に応じて独自のカスタム `Client`を実装できます。 ```go -// Client defines the API the client implementation should provide. +/.Client defines the API the client implementation should provide. type Client interface { - // Needed if the client needs to perform some action before connecting. + /.Needed if the client needs to perform some action before connecting. Bootstrap() error - // Ready checks if the servicer constraints for queries are satisfied - // for example the node might still not be ready, it's useful in process - // when the rosetta instance might come up before the node itself - // the servicer must return nil if the node is ready + /.Ready checks if the servicer constraints for queries are satisfied + /.for example the node might still not be ready, it's useful in process + /.when the rosetta instance might come up before the node itself + /.the servicer must return nil if the node is ready Ready() error - // Data API + /.Data API - // Balances fetches the balance of the given address - // if height is not nil, then the balance will be displayed - // at the provided height, otherwise last block balance will be returned + /.Balances fetches the balance of the given address + /.if height is not nil, then the balance will be displayed + /.at the provided height, otherwise last block balance will be returned Balances(ctx context.Context, addr string, height *int64) ([]*types.Amount, error) - // BlockByHashAlt gets a block and its transaction at the provided height + /.BlockByHashAlt gets a block and its transaction at the provided height BlockByHash(ctx context.Context, hash string) (BlockResponse, error) - // BlockByHeightAlt gets a block given its height, if height is nil then last block is returned + /.BlockByHeightAlt gets a block given its height, if height is nil then last block is returned BlockByHeight(ctx context.Context, height *int64) (BlockResponse, error) - // BlockTransactionsByHash gets the block, parent block and transactions - // given the block hash. + /.BlockTransactionsByHash gets the block, parent block and transactions + /.given the block hash. BlockTransactionsByHash(ctx context.Context, hash string) (BlockTransactionsResponse, error) - // BlockTransactionsByHash gets the block, parent block and transactions - // given the block hash. + /.BlockTransactionsByHash gets the block, parent block and transactions + /.given the block hash. BlockTransactionsByHeight(ctx context.Context, height *int64) (BlockTransactionsResponse, error) - // GetTx gets a transaction given its hash + /.GetTx gets a transaction given its hash GetTx(ctx context.Context, hash string) (*types.Transaction, error) - // GetUnconfirmedTx gets an unconfirmed Tx given its hash - // NOTE(fdymylja): NOT IMPLEMENTED YET! + /.GetUnconfirmedTx gets an unconfirmed Tx given its hash + /.NOTE(fdymylja): NOT IMPLEMENTED YET! GetUnconfirmedTx(ctx context.Context, hash string) (*types.Transaction, error) - // Mempool returns the list of the current non confirmed transactions + /.Mempool returns the list of the current non confirmed transactions Mempool(ctx context.Context) ([]*types.TransactionIdentifier, error) - // Peers gets the peers currently connected to the node + /.Peers gets the peers currently connected to the node Peers(ctx context.Context) ([]*types.Peer, error) - // Status returns the node status, such as sync data, version etc + /.Status returns the node status, such as sync data, version etc Status(ctx context.Context) (*types.SyncStatus, error) - // Construction API + /.Construction API - // PostTx posts txBytes to the node and returns the transaction identifier plus metadata related - // to the transaction itself. + /.PostTx posts txBytes to the node and returns the transaction identifier plus metadata related + /.to the transaction itself. PostTx(txBytes []byte) (res *types.TransactionIdentifier, meta map[string]interface{}, err error) - // ConstructionMetadataFromOptions + /.ConstructionMetadataFromOptions ConstructionMetadataFromOptions(ctx context.Context, options map[string]interface{}) (meta map[string]interface{}, err error) OfflineClient } -// OfflineClient defines the functionalities supported without having access to the node +/.OfflineClient defines the functionalities supported without having access to the node type OfflineClient interface { NetworkInformationProvider - // SignedTx returns the signed transaction given the tx bytes (msgs) plus the signatures + /.SignedTx returns the signed transaction given the tx bytes (msgs) plus the signatures SignedTx(ctx context.Context, txBytes []byte, sigs []*types.Signature) (signedTxBytes []byte, err error) - // TxOperationsAndSignersAccountIdentifiers returns the operations related to a transaction and the account - // identifiers if the transaction is signed + /.TxOperationsAndSignersAccountIdentifiers returns the operations related to a transaction and the account + /.identifiers if the transaction is signed TxOperationsAndSignersAccountIdentifiers(signed bool, hexBytes []byte) (ops []*types.Operation, signers []*types.AccountIdentifier, err error) - // ConstructionPayload returns the construction payload given the request + /.ConstructionPayload returns the construction payload given the request ConstructionPayload(ctx context.Context, req *types.ConstructionPayloadsRequest) (resp *types.ConstructionPayloadsResponse, err error) - // PreprocessOperationsToOptions returns the options given the preprocess operations + /.PreprocessOperationsToOptions returns the options given the preprocess operations PreprocessOperationsToOptions(ctx context.Context, req *types.ConstructionPreprocessRequest) (options map[string]interface{}, err error) - // AccountIdentifierFromPublicKey returns the account identifier given the public key + /.AccountIdentifierFromPublicKey returns the account identifier given the public key AccountIdentifierFromPublicKey(pubKey *types.PublicKey) (*types.AccountIdentifier, error) } ``` -### 2. Cosmos SDK Implementation +### 2. CosmosSDKの実装 -The Cosmos SDK implementation, based on version, takes care of satisfying the `Client` interface. -In Stargate, Launchpad and 0.37, we have introduced the concept of rosetta.Msg, this message is not in the shared repository as the sdk.Msg type differs between Cosmos SDK versions. +バージョンベースのCosmosSDK実装は、 `Client`インターフェースを満たす役割を果たします。 +Stargate、Launchpad、0.37では、rosetta.Msgの概念が導入されました。このメッセージは、Cosmos SDKのバージョンによってsdk.Msgタイプが異なるため、共有リポジトリにはありません。 -The rosetta.Msg interface follows: +rosetta.Msgインターフェースは次のとおりです。 ```go -// Msg represents a cosmos-sdk message that can be converted from and to a rosetta operation. +/.Msg represents a cosmos-sdk message that can be converted from and to a rosetta operation. type Msg interface { sdk.Msg ToOperations(withStatus, hasError bool) []*types.Operation @@ -178,34 +178,34 @@ type Msg interface { } ``` -Hence developers who want to extend the rosetta set of supported operations just need to extend their module's sdk.Msgs with the `ToOperations` and `FromOperations` methods. +したがって、ロゼッタでサポートされている一連の操作を拡張したい開発者は、 `ToOperations`メソッドと` FromOperations`メソッドを使用してモジュールのsdk.Msgsを拡張するだけで済みます。 -### 3. API service invocation +### 3.APIサービスの呼び出し -As stated at the start, application developers will have two methods for invocation of the Rosetta API service: +冒頭で述べたように、アプリケーション開発者は、RosettaAPIサービスを呼び出す2つの方法があります。 -1. Shared process for both application and API -2. Standalone API service +1.アプリケーションとAPIの共有プロセス +2.独立したAPIサービス -#### Shared Process (Only Stargate) +#### 共有プロセス(スターゲートのみ) -Rosetta API service could run within the same execution process as the application. This would be enabled via app.toml settings, and if gRPC is not enabled the rosetta instance would be spinned in offline mode (tx building capabilities only). +Rosetta APIサービスは、アプリケーションと同じ実行プロセスで実行できます。これはapp.toml設定で有効になります。gRPCが有効になっていない場合、ロゼッタインスタンスはオフラインモードでローテーションされます(txビルド機能のみ)。 -#### Separate API service +#### 単一のAPIサービス -Client application developers can write a new command to launch a Rosetta API server as a separate process too, using the rosetta command contained in the `/server/rosetta` package. Construction of the command depends on Cosmos SDK version. Examples can be found inside `simd` for stargate, and `contrib/rosetta/simapp` for other release series. +クライアントアプリケーションの開発者は、 `.server .rosetta`パッケージに含まれているrosettaコマンドを使用して、RosettaAPIサーバーを別のプロセスとして起動する新しいコマンドを作成することもできます。コマンドの構成は、CosmosSDKのバージョンによって異なります。例はStargateの「simd」にあり、他のバージョンシリーズは「contrib .rosetta .simapp」にあります。 -## Status +## 状態 -Proposed +提案 -## Consequences +## 結果 -### Positive +### ポジティブ -- Out-of-the-box Rosetta API support within Cosmos SDK. -- Blockchain interface standardisation +-CosmosSDKでのRosettaAPIサポートをすぐに使用できます。 +-ブロックリンクインターフェイスの標準化 -## References +## 参照 -- https://www.rosetta-api.org/ +-https://www.rosetta-api.org. \ No newline at end of file diff --git a/docs/ja/architecture/adr-036-arbitrary-signature.md b/docs/ja/architecture/adr-036-arbitrary-signature.md index c175d25ec42f..25087e86ae18 100644 --- a/docs/ja/architecture/adr-036-arbitrary-signature.md +++ b/docs/ja/architecture/adr-036-arbitrary-signature.md @@ -1,73 +1,73 @@ -# ADR 036: Arbitrary Message Signature Specification +# ADR 036:任意のメッセージ署名仕様 -## Changelog +## 変更ログ -- 28/10/2020 - Initial draft +-2020年10月28日-ドラフト -## Authors +## 著者 -- Antoine Herzog (@antoineherzog) -- Zaki Manian (@zmanian) -- Aleksandr Bezobchuk (alexanderbez) [1] -- Frojdi Dymylja (@fdymylja) +-Antoine Herzog(@antoineherzog) +-ザキマニアン(@zmanian) +-Alexander Bezobchuk(alexanderbez)[1] +-Frojdi Dymylja(@fdymylja) -## Status +## 状態 -Draft +下書き -## Abstract +## 概要 -Currently, in the Cosmos SDK, there is no convention to sign arbitrary message like on Ethereum. We propose with this specification, for Cosmos SDK ecosystem, a way to sign and validate off-chain arbitrary messages. +現在、Cosmos SDKでは、Ethereumのように任意のメッセージに署名することに合意していません。この仕様では、CosmosSDKエコシステムのメッセージをオフチェーンで署名および検証する方法を提案します。 -This specification serves the purpose of covering every use case, this means that cosmos-sdk applications developers decide how to serialize and represent `Data` to users. +この仕様は、すべてのユースケースをカバーすることを目的としています。つまり、cosmos-sdkアプリケーション開発者は、ユーザーに「データ」をシリアル化して表現する方法を決定します。 -## Context +## 環境 -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. +オフチェーンでメッセージに署名できることは、ほとんどすべてのブロックチェーンの基本的な側面であることが証明されています。メッセージにオフチェーンで署名するという概念には、計算コストの節約、トランザクションのスループットとオーバーヘッドの削減など、多くの追加の利点があります。 Cosmosのコンテキストでは、このようなデータに署名するための主なアプリケーションには、検証者の身元を証明するための暗号的に安全で検証可能な方法の提供、および場合によっては他のフレームワークや組織へのリンクが含まれますが、これらに限定されません。さらに、元帳または同様のHSMデバイスを使用してCosmosメッセージに署名できます。 -Further context and use cases can be found in the references links. +その他のコンテキストとユースケースは、リファレンスリンクにあります。 -## Decision +## 決定 -The aim is being able to sign arbitrary messages, even using Ledger or similar HSM devices. +目標は、元帳または同様のHSMデバイスを使用している場合でも、任意のメッセージに署名できるようにすることです。 -As a result signed messages should look roughly like Cosmos SDK messages but **must not** be a valid on-chain transaction. `chain-id`, `account_number` and `sequence` can all be assigned invalid values. +したがって、署名されたメッセージはCosmos SDKメッセージとほぼ同じである必要がありますが、有効なオンチェーントランザクションになることは**できません**。 `chain-id`、` account_number`、 `sequence`にはすべて無効な値を割り当てることができます。 -Cosmos SDK 0.40 also introduces a concept of “auth_info” this can specify SIGN_MODES. +Cosmos SDK 0.40では、「auth_info」の概念も導入されました。SIGN_MODESを指定できます。 -A spec should include an `auth_info` that supports SIGN_MODE_DIRECT and SIGN_MODE_LEGACY_AMINO. +仕様には、SIGN_MODE_DIRECTおよびSIGN_MODE_LEGACY_AMINOをサポートする `auth_info`を含める必要があります。 -Create the `offchain` proto definitions, we extend the auth module with `offchain` package to offer functionalities to verify and sign offline messages. +`offchain`プロト定義を作成するには、` offchain`パッケージを使用して認証モジュールを拡張し、オフラインメッセージを検証して署名する機能を提供します。 -An offchain transaction follows these rules: +オフチェーントランザクションは、次のルールに従います。 -- the memo must be empty -- nonce, sequence number must be equal to 0 -- chain-id must be equal to “” -- fee gas must be equal to 0 -- fee amount must be an empty array +-メモは空である必要があります +-nonce、シリアル番号は0に等しくなければなりません +-チェーンIDは「」と同じである必要があります +-コストガスは0に等しくなければなりません +-料金の金額は空の配列である必要があります -Verification of an offchain transaction follows the same rules as an onchain one, except for the spec differences highlighted above. +上で強調した仕様の違いに加えて、オフチェーントランザクションの検証は、オンチェーントランザクションと同じルールに従います。 -The first message added to the `offchain` package is `MsgSignData`. +`offchain`パッケージに追加された最初のメッセージは` MsgSignData`です。 -`MsgSignData` allows developers to sign arbitrary bytes valid offchain only. Where `Signer` is the account address of the signer. `Data` is arbitrary bytes which can represent `text`, `files`, `object`s. It's applications developers decision how `Data` should be deserialized, serialized and the object it can represent in their context. +`MsgSignData`を使用すると、開発者は有効なオフチェーンバイトのみに署名できます。ここで、「署名者」は署名者のアカウントアドレスです。 `Data`は、` text`、 `files`、および` object`を表すことができる任意のバイトです。アプリケーション開発者は、「データ」をどのように逆シリアル化、シリアル化するか、およびそのコンテキストでどのオブジェクトを表すことができるかを決定します。 -It's applications developers decision how `Data` should be treated, by treated we mean the serialization and deserialization process and the Object `Data` should represent. +アプリケーション開発者は、「データ」の処理方法を決定します。処理するのは、シリアル化と逆シリアル化のプロセス、および「データ」が何を表すかです。 -Proto definition: +プロトタイプの定義: ```proto -// MsgSignData defines an arbitrary, general-purpose, off-chain message +/.MsgSignData defines an arbitrary, general-purpose, off-chain message message MsgSignData { - // Signer is the sdk.AccAddress of the message signer + ..Signer is the sdk.AccAddress of the message signer bytes Signer = 1 [(gogoproto.jsontag) = "signer", (gogoproto.casttype) = "github.com/cosmos/cosmos-sdk/types.AccAddress"]; - // Data represents the raw bytes of the content that is signed (text, json, etc) + ..Data represents the raw bytes of the content that is signed (text, json, etc) bytes Data = 2 [(gogoproto.jsontag) = "data"]; } ``` -Signed MsgSignData json example: +MsgSignData jsonの例に署名します: ```json { @@ -100,33 +100,32 @@ Signed MsgSignData json example: } ``` -## Consequences +## 結果 -There is a specification on how messages, that are not meant to be broadcast to a live chain, should be formed. +リアルタイムチェーンにブロードキャストすることを目的としていないメッセージを作成する方法に関する仕様があります。 -### Backwards Compatibility +### 下位互換性 -Backwards compatibility is maintained as this is a new message spec definition. +これは新しいメッセージ仕様定義であるため、下位互換性が維持されます。 -### Positive +### ポジティブ -- A common format that can be used by multiple applications to sign and verify off-chain messages. -- The specification is primitive which means it can cover every use case without limiting what is possible to fit inside it. -- It gives room for other off-chain messages specifications that aim to target more specific and common use cases such as off-chain-based authN/authZ layers [2]. +-オフチェーンメッセージに署名および検証するために複数のアプリケーションで使用できる一般的な形式。 +-仕様は原始的です。つまり、仕様に適合するものを制限することなく、すべてのユースケースをカバーできます。 +-オフチェーンauthN .authZレイヤー[2]など、より具体的で一般的なユースケースを対象とした他のオフチェーンメッセージ仕様のためのスペースを提供します。 +### ネガティブ -### Negative +-現在の提案では、アカウントアドレスと公開鍵の間に固定の関係が必要です。 +-マルチシグニチャアカウントには適用されません。 -- Current proposal requires a fixed relationship between an account address and a public key. -- Doesn't work with multisig accounts. +## さらなる議論 -## Further discussion +-`MsgSignData`のセキュリティに関して、 `MsgSignData`を使用する開発者は、` Data`に配置されたコンテンツを必要なときに再生できないようにする責任があります。 +-オフチェーンパッケージは、アプリケーション、支払いチャネル、一般的なL2ソリューションでの本人確認など、特定のユースケース向けの追加メッセージでさらに拡張されます。 -- Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content laying in `Data` non-replayable when, and if, needed. -- the offchain package will be further extended with extra messages that target specific use cases such as, but not limited to, authentication in applications, payment channels, L2 solutions in general. - -## References +## 参照 1. https://github.com/cosmos/ics/pull/33 2. https://github.com/cosmos/cosmos-sdk/pull/7727#discussion_r515668204 3. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-722478477 -4. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923 +4. https://github.com/cosmos/cosmos-sdk/pull/7727#issuecomment-721062923 \ No newline at end of file diff --git a/docs/ja/architecture/adr-037-gov-split-vote.md b/docs/ja/architecture/adr-037-gov-split-vote.md index 742fdd10841e..1a138a172a48 100644 --- a/docs/ja/architecture/adr-037-gov-split-vote.md +++ b/docs/ja/architecture/adr-037-gov-split-vote.md @@ -1,26 +1,26 @@ -# ADR 037: Governance split votes +# ADR 037:ガバナンス分割投票 -## Changelog +## 変更ログ -- 2020/10/28: Intial draft +-2020/10/28:最初のドラフト -## Status +## 状態 -Accepted +受け入れられました -## 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. +ADRは、ガバナンスモジュールの変更を定義し、利害関係者が投票をいくつかの投票オプションに分割できるようにします。たとえば、議決権の70％を使用して賛成票を投じ、議決権の30％を反対票を投じることができます。 -## 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. +現在、アドレスは1つのオプション(yes .no .abstention .veto)でのみ投票でき、すべての投票権はオプションの背後で使用されます。 -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 { @@ -35,7 +35,7 @@ type Vote struct { } ``` -And for backwards compatibility, we introduce `MsgVoteWeighted` while keeping `MsgVote`. +下位互換性のために、 `MsgVote`を保持しながら、` MsgVoteWeighted`を導入しました。 ``` type MsgVote struct { @@ -51,12 +51,12 @@ type MsgVoteWeighted struct { } ``` -The `ValidateBasic` of a `MsgVoteWeighted` struct would require that +`MsgVoteWeighted`構造の` ValidateBasic`には -1. The sum of all the Rates is equal to 1.0 -2. No Option is repeated +1.すべての金利の合計は1.0に等しい +2.重複するオプションはありません -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() { @@ -70,7 +70,7 @@ tally() { } ``` -The CLI command for creating a multi-option vote would be as such: +複数選択投票を作成するために使用されるCLIコマンドは次のとおりです。 ```sh simd tx gov vote 1 "yes=0.6,no=0.3,abstain=0.05,no_with_veto=0.05" --from mykey @@ -90,22 +90,22 @@ 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. +-以前のVoteMsgタイプは変更されないため、WeightedVoteMsg関数をサポートする必要がない限り、顧客はプログラムを更新する必要はありません。 +-州から投票構造を照会する場合、その構造は異なるため、すべての投票者とそれぞれの投票を表示したい顧客は、新しい形式と1人の投票者が分割投票を持つことができるという事実に対処する必要があります。 +-tally関数をクエリした結果は、クライアントと同じAPIを持つ必要があります。 -### 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. +-ガバナンス集計機能の変化は比較的小さい。 \ No newline at end of file diff --git a/docs/ja/architecture/adr-038-state-listening.md b/docs/ja/architecture/adr-038-state-listening.md index 7e5e49d4f255..eb0e8c6a87e6 100644 --- a/docs/ja/architecture/adr-038-state-listening.md +++ b/docs/ja/architecture/adr-038-state-listening.md @@ -1,69 +1,69 @@ -# ADR 038: KVStore state listening +# ADR 038:KVStoreステータスの監視 -## Changelog +## 変更ログ -- 11/23/2020: Initial draft +-2020年11月23日:最初のドラフト -## Status +## 状態 -Proposed +提案 -## Abstract +## 概要 -This ADR defines a set of changes to enable listening to state changes of individual KVStores and exposing these data to consumers. +このADRは、各KVStoreの状態の変化をリッスンし、これらのデータをコンシューマーに公開できるようにする一連の変更を定義します。 -## Context +## 環境 -Currently, KVStore data can be remotely accessed through [Queries](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/messages-and-queries.md#queries) -which proceed either through Tendermint and the ABCI, or through the gRPC server. -In addition to these request/response queries, it would be beneficial to have a means of listening to state changes as they occur in real time. +現在、KVStoreデータには[クエリ](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/messages-and-queries.md#queries)を介してリモートでアクセスできます。 +TendermintとABCIを介して、またはgRPCサーバーを介して。 +これらの要求/応答クエリに加えて、リアルタイムで発生する状態変化を監視する方法があります。 -## Decision +## 決定 -We will modify the `MultiStore` interface and its concrete (`rootmulti` and `cachemulti`) implementations and introduce a new `listenkv.Store` to allow listening to state changes in underlying KVStores. -We will introduce a plugin system for configuring and running streaming services that write these state changes and their surrounding ABCI message context to different destinations. +`MultiStore`インターフェースとその特定の(` rootmulti`および `cachemulti`)実装を変更し、新しい` listenkv.Store`を導入して、基盤となるKVStoreの状態変化を監視できるようにします。 +これらの状態変化と周囲のABCIメッセージコンテキストをさまざまな宛先に書き込むストリーミングサービスを構成および実行するためのプラグインシステムを紹介します。 -### Listening interface +### リスニングインターフェース -In a new file, `store/types/listening.go`, we will create a `WriteListener` interface for streaming out state changes from a KVStore. +新しいファイル `store .types .listener.go`に、KVStoreから状態の変化をストリーミングするための` WriteListener`インターフェースを作成します。 ```go -// WriteListener interface for streaming data out from a listenkv.Store +/.WriteListener interface for streaming data out from a listenkv.Store type WriteListener interface { - // if value is nil then it was deleted - // storeKey indicates the source KVStore, to facilitate using the same WriteListener across separate KVStores - // delete bool indicates if it was a delete; true: delete, false: set + /.if value is nil then it was deleted + /.storeKey indicates the source KVStore, to facilitate using the same WriteListener across separate KVStores + /.delete bool indicates if it was a delete; true: delete, false: set OnWrite(storeKey StoreKey, key []byte, value []byte, delete bool) error } ``` -### Listener type +### リスナータイプ -We will create a concrete implementation of the `WriteListener` interface in `store/types/listening.go`, that writes out protobuf -encoded KV pairs to an underlying `io.Writer`. +`store .types .listening.go`に` WriteListener`インターフェースの具体的な実装を作成します。これはprotobufを書き出します。 +エンコードされたKVペアと基礎となる `io.Writer`。 -This will include defining a simple protobuf type for the KV pairs. In addition to the key and value fields this message -will include the StoreKey for the originating KVStore so that we can write out from separate KVStores to the same stream/file -and determine the source of each KV pair. +これには、KVペアの単純なprotobufタイプの定義が含まれます。 キーフィールドと値フィールドに加えて、このメッセージ +別のKVStoreから同じストリーム/ファイルに書き込めるように、元のKVStoreのStoreKeyが含まれます +そして、各KVペアのソースを決定します。 ```protobuf message StoreKVPair { - optional string store_key = 1; // the store key for the KVStore this pair originates from - required bool set = 2; // true indicates a set operation, false indicates a delete operation + optional string store_key = 1;..the store key for the KVStore this pair originates from + required bool set = 2;..true indicates a set operation, false indicates a delete operation required bytes key = 3; required bytes value = 4; } ``` ```go -// StoreKVPairWriteListener is used to configure listening to a KVStore by writing out length-prefixed -// protobuf encoded StoreKVPairs to an underlying io.Writer +/.StoreKVPairWriteListener is used to configure listening to a KVStore by writing out length-prefixed +/.protobuf encoded StoreKVPairs to an underlying io.Writer type StoreKVPairWriteListener struct { writer io.Writer marshaller codec.BinaryCodec } -// NewStoreKVPairWriteListener wraps creates a StoreKVPairWriteListener with a provdied io.Writer and codec.BinaryCodec +/.NewStoreKVPairWriteListener wraps creates a StoreKVPairWriteListener with a provdied io.Writer and codec.BinaryCodec func NewStoreKVPairWriteListener(w io.Writer, m codec.BinaryCodec) *StoreKVPairWriteListener { return &StoreKVPairWriteListener{ writer: w, @@ -71,7 +71,7 @@ func NewStoreKVPairWriteListener(w io.Writer, m codec.BinaryCodec) *StoreKVPairW } } -// OnWrite satisfies the WriteListener interface by writing length-prefixed protobuf encoded StoreKVPairs +/.OnWrite satisfies the WriteListener interface by writing length-prefixed protobuf encoded StoreKVPairs func (wl *StoreKVPairWriteListener) OnWrite(storeKey types.StoreKey, key []byte, value []byte, delete bool) error error { kvPair := new(types.StoreKVPair) kvPair.StoreKey = storeKey.Name() @@ -91,45 +91,45 @@ func (wl *StoreKVPairWriteListener) OnWrite(storeKey types.StoreKey, key []byte, ### ListenKVStore -We will create a new `Store` type `listenkv.Store` that the `MultiStore` wraps around a `KVStore` to enable state listening. -We can configure the `Store` with a set of `WriteListener`s which stream the output to specific destinations. +新しい `Store`タイプ` listenkv.Store`を作成し、 `MultiStore`が` KVStore`を囲んでステータス監視を有効にします。 +出力を特定の宛先にストリーミングするように、一連のWriteListenerを使用してストアを構成できます。 ```go -// Store implements the KVStore interface with listening enabled. -// Operations are traced on each core KVStore call and written to any of the -// underlying listeners with the proper key and operation permissions +/.Store implements the KVStore interface with listening enabled. +/.Operations are traced on each core KVStore call and written to any of the +/.underlying listeners with the proper key and operation permissions type Store struct { parent types.KVStore listeners []types.WriteListener parentStoreKey types.StoreKey } -// NewStore returns a reference to a new traceKVStore given a parent -// KVStore implementation and a buffered writer. +/.NewStore returns a reference to a new traceKVStore given a parent +/.KVStore implementation and a buffered writer. func NewStore(parent types.KVStore, psk types.StoreKey, listeners []types.WriteListener) *Store { return &Store{parent: parent, listeners: listeners, parentStoreKey: psk} } -// Set implements the KVStore interface. It traces a write operation and -// delegates the Set call to the parent KVStore. +/.Set implements the KVStore interface. It traces a write operation and +/.delegates the Set call to the parent KVStore. func (s *Store) Set(key []byte, value []byte) { types.AssertValidKey(key) s.parent.Set(key, value) s.onWrite(false, key, value) } -// Delete implements the KVStore interface. It traces a write operation and -// delegates the Delete call to the parent KVStore. +/.Delete implements the KVStore interface. It traces a write operation and +/.delegates the Delete call to the parent KVStore. func (s *Store) Delete(key []byte) { s.parent.Delete(key) s.onWrite(true, key, nil) } -// onWrite writes a KVStore operation to all the WriteListeners +/.onWrite writes a KVStore operation to all the WriteListeners func (s *Store) onWrite(delete bool, key, value []byte) { for _, l := range s.listeners { if err := l.OnWrite(s.parentStoreKey, key, value, delete); err != nil { - // log error + ..log error } } } @@ -137,18 +137,18 @@ func (s *Store) onWrite(delete bool, key, value []byte) { ### MultiStore interface updates -We will update the `MultiStore` interface to allow us to wrap a set of listeners around a specific `KVStore`. -Additionally, we will update the `CacheWrap` and `CacheWrapper` interfaces to enable listening in the caching layer. +`MultiStore`インターフェースを更新して、リスナーのセットを特定の` KVStore`にラップできるようにします。 +さらに、 `CacheWrap`および` CacheWrapper`インターフェースを更新して、キャッシュレイヤーでのリスニングを有効にします。 ```go type MultiStore interface { ... - // ListeningEnabled returns if listening is enabled for the KVStore belonging the provided StoreKey + /.ListeningEnabled returns if listening is enabled for the KVStore belonging the provided StoreKey ListeningEnabled(key StoreKey) bool - // AddListeners adds WriteListeners for the KVStore belonging to the provided StoreKey - // It appends the listeners to a current set, if one already exists + /.AddListeners adds WriteListeners for the KVStore belonging to the provided StoreKey + /.It appends the listeners to a current set, if one already exists AddListeners(key StoreKey, listeners []WriteListener) } ``` @@ -157,22 +157,22 @@ type MultiStore interface { type CacheWrap interface { ... - // CacheWrapWithListeners recursively wraps again with listening enabled + /.CacheWrapWithListeners recursively wraps again with listening enabled CacheWrapWithListeners(storeKey types.StoreKey, listeners []WriteListener) CacheWrap } type CacheWrapper interface { ... - // CacheWrapWithListeners recursively wraps again with listening enabled + /.CacheWrapWithListeners recursively wraps again with listening enabled CacheWrapWithListeners(storeKey types.StoreKey, listeners []WriteListener) CacheWrap } ``` ### MultiStore implementation updates -We will modify all of the `Store` and `MultiStore` implementations to satisfy these new interfaces, and adjust the `rootmulti` `GetKVStore` method -to wrap the returned `KVStore` with a `listenkv.Store` if listening is turned on for that `Store`. +これらの新しいインターフェースを満たすようにすべての `Store`と` MultiStore`の実装を変更し、 `rootmulti``GetKVStore`メソッドを調整します +「Store」のリスニングがオンになっている場合、返される「KVStore」は「listenkv.Store」でラップされます。 ```go func (rs *Store) GetKVStore(key types.StoreKey) types.KVStore { @@ -189,8 +189,8 @@ func (rs *Store) GetKVStore(key types.StoreKey) types.KVStore { } ``` -We will also adjust the `cachemulti` constructor methods and the `rootmulti` `CacheMultiStore` method to forward the listeners -to and enable listening in the cache layer. +また、 `cachemulti`構築メソッドと` rootmulti``CacheMultiStore`メソッドを調整してリスナーを転送します +そして、キャッシュレイヤーでリスニングを有効にします。 ```go func (rs *Store) CacheMultiStore() types.CacheMultiStore { @@ -206,59 +206,59 @@ func (rs *Store) CacheMultiStore() types.CacheMultiStore { #### Streaming service -We will introduce a new `StreamingService` interface for exposing `WriteListener` data streams to external consumers. -In addition to streaming state changes as `StoreKVPair`s, the interface satisfies an `ABCIListener` interface that plugs -into the BaseApp and relays ABCI requests and responses so that the service can group the state changes with the ABCI -requests that affected them and the ABCI responses they affected. The `ABCIListener` interface also exposes a -`ListenSuccess` method which is (optionally) used by the `BaseApp` to await positive acknowledgement of message -receipt from the `StreamingService`. +`WriteListener`データストリームを外部コンシューマーに公開するための新しい` StreamingService`インターフェースを導入します。 +ストリームの状態が `StoreKVPair`に変わることを除いて、インターフェースは` ABCIListener`インターフェースを満たします。 +BaseAppを入力し、ABCIの要求と応答を中継して、サービスがABCIで状態の変化をグループ化できるようにします。 +それらに影響を与える要求とそれらが影響を与えるABCI応答。 `ABCIListener`インターフェースも公開します +`ListenSuccess`メソッド(オプション)は、メッセージの肯定的な確認を待つために` BaseApp`によって使用されます +「StreamingService」からの領収書。 ```go -// ABCIListener interface used to hook into the ABCI message processing of the BaseApp +/.ABCIListener interface used to hook into the ABCI message processing of the BaseApp type ABCIListener interface { - // ListenBeginBlock updates the streaming service with the latest BeginBlock messages + /.ListenBeginBlock updates the streaming service with the latest BeginBlock messages ListenBeginBlock(ctx types.Context, req abci.RequestBeginBlock, res abci.ResponseBeginBlock) error - // ListenEndBlock updates the steaming service with the latest EndBlock messages + /.ListenEndBlock updates the steaming service with the latest EndBlock messages ListenEndBlock(ctx types.Context, req abci.RequestEndBlock, res abci.ResponseEndBlock) error - // ListenDeliverTx updates the steaming service with the latest DeliverTx messages + /.ListenDeliverTx updates the steaming service with the latest DeliverTx messages ListenDeliverTx(ctx types.Context, req abci.RequestDeliverTx, res abci.ResponseDeliverTx) error - // ListenSuccess returns a chan that is used to acknowledge successful receipt of messages by the external service - // after some configurable delay, `false` is sent to this channel from the service to signify failure of receipt + /.ListenSuccess returns a chan that is used to acknowledge successful receipt of messages by the external service + /.after some configurable delay, `false` is sent to this channel from the service to signify failure of receipt ListenSuccess() <-chan bool } -// StreamingService interface for registering WriteListeners with the BaseApp and updating the service with the ABCI messages using the hooks +/.StreamingService interface for registering WriteListeners with the BaseApp and updating the service with the ABCI messages using the hooks type StreamingService interface { - // Stream is the streaming service loop, awaits kv pairs and writes them to a destination stream or file + /.Stream is the streaming service loop, awaits kv pairs and writes them to a destination stream or file Stream(wg *sync.WaitGroup) error - // Listeners returns the streaming service's listeners for the BaseApp to register + /.Listeners returns the streaming service's listeners for the BaseApp to register Listeners() map[types.StoreKey][]store.WriteListener - // ABCIListener interface for hooking into the ABCI messages from inside the BaseApp + /.ABCIListener interface for hooking into the ABCI messages from inside the BaseApp ABCIListener - // Closer interface + /.Closer interface io.Closer } ``` #### BaseApp registration -We will add a new method to the `BaseApp` to enable the registration of `StreamingService`s: +`BaseApp`に新しいメソッドを追加して、` StreamingService`の登録を有効にします。 ```go -// SetStreamingService is used to set a streaming service into the BaseApp hooks and load the listeners into the multistore +/.SetStreamingService is used to set a streaming service into the BaseApp hooks and load the listeners into the multistore func (app *BaseApp) SetStreamingService(s StreamingService) { - // add the listeners for each StoreKey + /.add the listeners for each StoreKey for key, lis := range s.Listeners() { app.cms.AddListeners(key, lis) } - // register the StreamingService within the BaseApp - // BaseApp will pass BeginBlock, DeliverTx, and EndBlock requests and responses to the streaming services to update their ABCI context + /.register the StreamingService within the BaseApp + /.BaseApp will pass BeginBlock, DeliverTx, and EndBlock requests and responses to the streaming services to update their ABCI context app.abciListeners = append(app.abciListeners, s) } ``` -We will add a new method to the `BaseApp` that is used to configure a global wait limit for receiving positive acknowledgement -of message receipt from the integrated `StreamingService`s. +「BaseApp」に新しいメソッドを追加して、肯定的な確認を受信するためのグローバル待機制限を構成します +統合された「StreamingService」からのメッセージ受信。 ```go func (app *BaseApp) SetGlobalWaitLimit(t time.Duration) { @@ -266,15 +266,15 @@ func (app *BaseApp) SetGlobalWaitLimit(t time.Duration) { } ``` -We will also modify the `BeginBlock`, `EndBlock`, and `DeliverTx` methods to pass ABCI requests and responses to any streaming service hooks registered -with the `BaseApp`. +また、「BeginBlock」、「EndBlock」、「DeliverTx」メソッドを変更して、登録されているストリーミングサービスフックにABCIリクエストとレスポンスを渡します。 +`BaseApp`を使用します。 ```go func (app *BaseApp) BeginBlock(req abci.RequestBeginBlock) (res abci.ResponseBeginBlock) { ... - // Call the streaming service hooks with the BeginBlock messages + /.Call the streaming service hooks with the BeginBlock messages for _, listener := range app.abciListeners { listener.ListenBeginBlock(app.deliverState.ctx, req, res) } @@ -288,7 +288,7 @@ func (app *BaseApp) EndBlock(req abci.RequestEndBlock) (res abci.ResponseEndBloc ... - // Call the streaming service hooks with the EndBlock messages + /.Call the streaming service hooks with the EndBlock messages for _, listener := range app.abciListeners { listener.ListenEndBlock(app.deliverState.ctx, req, res) } @@ -306,7 +306,7 @@ func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx if err != nil { resultStr = "failed" res := sdkerrors.ResponseDeliverTx(err, gInfo.GasWanted, gInfo.GasUsed, app.trace) - // If we throw an error, be sure to still call the streaming service's hook + /.If we throw an error, be sure to still call the streaming service's hook for _, listener := range app.abciListeners { listener.ListenDeliverTx(app.deliverState.ctx, req, res) } @@ -314,14 +314,14 @@ func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx } res := abci.ResponseDeliverTx{ - GasWanted: int64(gInfo.GasWanted), // TODO: Should type accept unsigned ints? - GasUsed: int64(gInfo.GasUsed), // TODO: Should type accept unsigned ints? + GasWanted: int64(gInfo.GasWanted),..TODO: Should type accept unsigned ints? + GasUsed: int64(gInfo.GasUsed), ..TODO: Should type accept unsigned ints? Log: result.Log, Data: result.Data, Events: sdk.MarkEventsToIndex(result.Events, app.indexEvents), } - // Call the streaming service hooks with the DeliverTx messages + /.Call the streaming service hooks with the DeliverTx messages for _, listener := range app.abciListeners { listener.ListenDeliverTx(app.deliverState.ctx, req, res) } @@ -330,12 +330,11 @@ func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx } ``` -We will also modify the `Commit` method to process `success/failure` signals from the integrated `StreamingService`s using -the `ABCIListener.ListenSuccess()` method. Each `StreamingService` has an internal wait threshold after which it sends -`false` to the `ListenSuccess()` channel, and the BaseApp also imposes a configurable global wait limit. -If the `StreamingService` is operating in a "fire-and-forget" mode, `ListenSuccess()` should immediately return `true` -off the channel despite the success status of the service. - +また、統合された `StreamingService`からの` success .failure`シグナルを処理するように `Commit`メソッドを変更します。 +`ABCIListener.ListenSuccess()`メソッド。 各「StreamingService」には内部待機しきい値があり、その後に送信されます +`ListenSuccess()`チャネルは `false`であり、BaseAppは構成可能なグローバル待機制限も課します。 +`StreamingService`が「fireandforget」モードで実行されている場合、` ListenSuccess() `はすぐに` true`を返す必要があります +サービスは正常な状態ですが、チャネルはまだ閉じています。 ```go func (app *BaseApp) Commit() (res abci.ResponseCommit) { @@ -351,8 +350,8 @@ func (app *BaseApp) Commit() (res abci.ResponseCommit) { halt = true } - // each listener has an internal wait threshold after which it sends `false` to the ListenSuccess() channel - // but the BaseApp also imposes a global wait limit + /.each listener has an internal wait threshold after which it sends `false` to the ListenSuccess() channel + /.but the BaseApp also imposes a global wait limit maxWait := time.NewTicker(app.globalWaitLimit) for _, lis := range app.abciListeners { select { @@ -368,10 +367,10 @@ func (app *BaseApp) Commit() (res abci.ResponseCommit) { } if halt { - // Halt the binary and allow Tendermint to receive the ResponseCommit - // response with the commit ID hash. This will allow the node to successfully - // restart and process blocks assuming the halt configuration has been - // reset or moved to a more distant value. + /.Halt the binary and allow Tendermint to receive the ResponseCommit + /.response with the commit ID hash. This will allow the node to successfully + /.restart and process blocks assuming the halt configuration has been + /.reset or moved to a more distant value. app.halt() } @@ -382,54 +381,54 @@ func (app *BaseApp) Commit() (res abci.ResponseCommit) { #### Plugin system -We propose a plugin architecture to load and run `StreamingService` implementations. We will introduce a plugin -loading/preloading system that is used to load, initialize, inject, run, and stop Cosmos-SDK plugins. Each plugin -must implement the following interface: +`StreamingService`実装をロードして実行するためのプラグインアーキテクチャを提案します。 プラグインを紹介します +ロード/プリロードシステムは、Cosmos-SDKプラグインのロード、初期化、注入、実行、および停止に使用されます。 プラグインごと +次のインターフェイスを実装する必要があります。 ```go -// Plugin is the base interface for all kinds of cosmos-sdk plugins -// It will be included in interfaces of different Plugins +/.Plugin is the base interface for all kinds of cosmos-sdk plugins +/.It will be included in interfaces of different Plugins type Plugin interface { - // Name should return unique name of the plugin + /.Name should return unique name of the plugin Name() string - // Version returns current version of the plugin + /.Version returns current version of the plugin Version() string - // Init is called once when the Plugin is being loaded - // The plugin is passed the AppOptions for configuration - // A plugin will not necessarily have a functional Init + /.Init is called once when the Plugin is being loaded + /.The plugin is passed the AppOptions for configuration + /.A plugin will not necessarily have a functional Init Init(env serverTypes.AppOptions) error - // Closer interface for shutting down the plugin process + /.Closer interface for shutting down the plugin process io.Closer } ``` -The `Name` method returns a plugin's name. -The `Version` method returns a plugin's version. -The `Init` method initializes a plugin with the provided `AppOptions`. -The io.Closer is used to shut down the plugin service. +`Name`メソッドは、プラグインの名前を返します。 +`Version`メソッドはプラグインのバージョンを返します。 +`Init`メソッドは、提供された` AppOptions`を使用してプラグインを初期化します。 +io.Closerは、プラグインサービスを閉じるために使用されます。 -For the purposes of this ADR we introduce a single kind of plugin- a state streaming plugin. -We will define a `StateStreamingPlugin` interface which extends the above `Plugin` interface to support a state streaming service. +このADRの目的で、プラグイン(ステートフロープラグイン)を導入しました。 +上記の `Plugin`インターフェースを拡張して状態ストリーミングサービスをサポートする` StateStreamingPlugin`インターフェースを定義します。 ```go -// StateStreamingPlugin interface for plugins that load a baseapp.StreamingService onto a baseapp.BaseApp +/.StateStreamingPlugin interface for plugins that load a baseapp.StreamingService onto a baseapp.BaseApp type StateStreamingPlugin interface { - // Register configures and registers the plugin streaming service with the BaseApp + /.Register configures and registers the plugin streaming service with the BaseApp Register(bApp *baseapp.BaseApp, marshaller codec.BinaryCodec, keys map[string]*types.KVStoreKey) error - // Start starts the background streaming process of the plugin streaming service + /.Start starts the background streaming process of the plugin streaming service Start(wg *sync.WaitGroup) - // Plugin is the base Plugin interface + /.Plugin is the base Plugin interface Plugin } ``` -The `Register` method is used during App construction to register the plugin's streaming service with an App's BaseApp using the BaseApp's `SetStreamingService` method. -The `Start` method is used during App construction to start the registered plugin streaming services and maintain synchronization with them. +`Register`メソッドは、アプリの構築中にBaseAppの` SetStreamingService`メソッドを使用して、プラグインのストリーミングサービスをアプリのBaseAppに登録するために使用されます。 +アプリ構築プロセスで `Start`メソッドを使用して、登録済みのプラグインストリーミングサービスを開始し、同期を維持します。 e.g. in `NewSimApp`: @@ -442,15 +441,15 @@ func NewSimApp( ... - // this loads the preloaded and any plugins found in `plugins.dir` + /.this loads the preloaded and any plugins found in `plugins.dir` pluginLoader, err := loader.NewPluginLoader(appOpts, logger) if err != nil { - // handle error + ..handle error } - // initialize the loaded plugins + /.initialize the loaded plugins if err := pluginLoader.Initialize(); err != nil { - // hanlde error + /.hanlde error } keys := sdk.NewKVStoreKeys( @@ -460,15 +459,15 @@ func NewSimApp( evidencetypes.StoreKey, ibctransfertypes.StoreKey, capabilitytypes.StoreKey, ) - // register the plugin(s) with the BaseApp + /.register the plugin(s) with the BaseApp if err := pluginLoader.Inject(bApp, appCodec, keys); err != nil { - // handle error + /.handle error } - // start the plugin services, optionally use wg to synchronize shutdown using io.Closer + /.start the plugin services, optionally use wg to synchronize shutdown using io.Closer wg := new(sync.WaitGroup) if err := pluginLoader.Start(wg); err != nil { - // handler error + /.handler error } ... @@ -480,7 +479,7 @@ func NewSimApp( #### Configuration -The plugin system will be configured within an app's app.toml file. +プラグインシステムは、アプリケーションのapp.tomlファイルで構成されます。 ```toml [plugins] @@ -489,21 +488,19 @@ The plugin system will be configured within an app's app.toml file. dir = "the directory to load non-preloaded plugins from; defaults to cosmos-sdk/plugin/plugins" ``` -There will be three parameters for configuring the plugin system: `plugins.on`, `plugins.disabled` and `plugins.dir`. -`plugins.on` is a bool that turns on or off the plugin system at large, `plugins.dir` directs the system to a directory -to load plugins from, and `plugins.disabled` is a list of names for the plugins we want to disable (useful for disabling preloaded plugins). - -Configuration of a given plugin is ultimately specific to the plugin, but we will introduce some standards here: +プラグインシステムを構成するための3つのパラメーターがあります: `plugins.on`、` plugins.disabled`、および `plugins.dir`。 +`plugins.on`はブール値であり、プラグインシステム全体を開いたり閉じたりするために使用されます。`plugins.dir`はシステムをディレクトリに転送します +そこからプラグインをロードします。`plugins.disabled`は、無効にするプラグインの名前のリストです(プリロードされたプラグインを無効にするために使用されます)。 -Plugin TOML configuration should be split into separate sub-tables for each kind of plugin (e.g. `plugins.streaming`). -Within these sub-tables, the parameters for a specific plugin of that kind are included in another sub-table (e.g. `plugins.streaming.file`). -It is generally expected, but not required, that a streaming service plugin can be configured with a set of store keys -(e.g. `plugins.streaming.file.keys`) for the stores it listens to and a mode (e.g. `plugins.streaming.file.mode`) -that signifies whether the service operates in a fire-and-forget capacity (`faf`) or the BaseApp should require positive -acknowledgement of message receipt by the service (`ack`). - -e.g. +特定のプラグインの構成は最終的にプラグイン固有ですが、ここではいくつかの基準について説明します。 +プラグインのTOML構成は、プラグインごとに個別のサブテーブルに分割する必要があります(例: `plugins.streaming`)。 +これらのサブテーブルでは、そのような特定のプラグインのパラメーターは別のサブテーブル(たとえば、 `plugins.streaming.file`)に含まれています。 +通常、必須ではありませんが、一連のストレージキーを使用して、ストリーミングメディアサービスプラグインを構成できます。 +(例: `plugins.streaming.file.keys`)それがリッスンするストレージとモード(例:` plugins.streaming.file.mode`) +これは、サービスがファイアアンドフォーゲット( `faf`)で実行されているか、BaseAppがポジティブを要求する必要があるかを示します +サービスによるメッセージ受信の確認( `ack`)。 +例えば ```toml [plugins] on = false # turn the plugin system, as a whole, on or off @@ -523,29 +520,28 @@ e.g. #### Encoding and decoding streams -ADR-038 introduces the interfaces and types for streaming state changes out from KVStores, associating this -data with their related ABCI requests and responses, and registering a service for consuming this data and streaming it to some destination in a final format. -Instead of prescribing a final data format in this ADR, it is left to a specific plugin implementation to define and document this format. -We take this approach because flexibility in the final format is necessary to support a wide range of streaming service plugins. For example, -the data format for a streaming service that writes the data out to a set of files will differ from the data format that is written to a Kafka topic. - -## Consequences +ADR-038は、KVStoreから状態変更をストリーミングするために使用されるインターフェースとタイプを導入し、これを関連付けます +データとそれに関連するABCIの要求と応答、およびデータを消費して最終的な形式で宛先にストリーミングするサービスを登録します。 +最終的なデータ形式はこのADRで指定されていませんが、特定のプラグイン実装がこの形式を定義および記録します。 +幅広いストリーミングメディアサービスプラグインをサポートするには、最終フォーマットの柔軟性が必要であるため、このアプローチを使用します。 例えば、 +一連のファイルにデータを書き込むストリーミングサービスのデータ形式は、Kafkaトピックのデータ形式とは異なります。 +## 結果 -These changes will provide a means of subscribing to KVStore state changes in real time. +これらの変更は、KVStoreの状態変更をリアルタイムでサブスクライブする手段を提供します。 -### Backwards Compatibility +### 下位互換性 -- This ADR changes the `MultiStore`, `CacheWrap`, and `CacheWrapper` interfaces, implementations supporting the previous version of these interfaces will not support the new ones +-このADRは、 `MultiStore`、` CacheWrap`、および `CacheWrapper`インターフェースを変更しました。これらのインターフェースをサポートする以前のバージョンの実装は、新しいインターフェースをサポートしません。 -### Positive +### ポジティブ -- Ability to listen to KVStore state changes in real time and expose these events to external consumers +-KVStoreステータスの変更をリアルタイムで監視し、これらのイベントを外部の消費者に公開する機能 -### Negative +### ネガティブ -- Changes `MultiStore`, `CacheWrap`, and `CacheWrapper` interfaces +-`MultiStore`、 `CacheWrap`、および` CacheWrapper`インターフェースを変更しました -### Neutral +### ニュートラル -- Introduces additional- but optional- complexity to configuring and running a cosmos application -- If an application developer opts to use these features to expose data, they need to be aware of the ramifications/risks of that data exposure as it pertains to the specifics of their application +-Cosmosアプリケーションを構成および実行するための追加のオプションの複雑さを導入しました +-アプリケーション開発者がこれらの機能を使用してデータを開示することを選択した場合、データ開示はアプリケーションの詳細に関連しているため、そのデータ開示の結果/リスクを理解する必要があります。 \ No newline at end of file diff --git a/docs/ja/architecture/adr-039-epoched-staking.md b/docs/ja/architecture/adr-039-epoched-staking.md index 44c1f14088b1..418c672d8f46 100644 --- a/docs/ja/architecture/adr-039-epoched-staking.md +++ b/docs/ja/architecture/adr-039-epoched-staking.md @@ -1,122 +1,121 @@ -# ADR 039: Epoched Staking +# ADR 039:画期的な賭け -## Changelog +## 変更ログ -- 10-Feb-2021: Initial Draft +-2021年2月10日:最初のドラフト -## Authors +## 著者 -- Dev Ojha (@valardragon) -- Sunny Aggarwal (@sunnya97) +-Dev Ojha(@valardragon) +-Sunny Aggarwal(@ sunya97) -## Status +## 状態 -Proposed +提案 -## Abstract +## 概要 -This ADR updates the proof of stake module to buffer the staking weight updates for a number of blocks before updating the consensus' staking weights. The length of the buffer is dubbed an epoch. The prior functionality of the staking module is then a special case of the abstracted module, with the epoch being set to 1 block. +ADRは、コンセンサスエクイティウェイトを更新する前に、エクイティプルーフモジュールを更新して、複数のブロックのエクイティプルーフウェイトの更新をバッファリングします。バッファの長さはエポックと呼ばれます。ステーキングモジュールのアプリオリ機能は抽象モジュールの特殊なケースであり、エポックは1ブロックに設定されます。 -## Context +## 環境 -The current proof of stake module takes the design decision to apply staking weight changes to the consensus engine immediately. This means that delegations and unbonds get applied immediately to the validator set. This decision was primarily done as it was implementationally simplest, and because we at the time believed that this would lead to better UX for clients. +現在のエクイティプルーフモジュールは、設計上の決定を採用し、エクイティウェイトの変更をコンセンサスエンジンに即座に適用します。これは、委任とバインド解除がバリデーターセットにすぐに適用されることを意味します。この決定は主に、実装が最も簡単であり、顧客により良いユーザーエクスペリエンスをもたらすと信じていたためです。 -An alternative design choice is to allow buffering staking updates (delegations, unbonds, validators joining) for a number of blocks. This 'epoch'd proof of stake consensus provides the guarantee that the consensus weights for validators will not change mid-epoch, except in the event of a slash condition. +別の設計オプションは、複数のブロック(委任、バインド解除、検証者の結合)の誓約更新のバッファリングを許可することです。この種の「エポック」エクイティコンセンサスプルーフは、スラッシュ条件がない限り、検証者のコンセンサスウェイトが中期的に変化しないことを保証します。 -Additionally, the UX hurdle may not be as significant as was previously thought. This is because it is possible to provide users immediate acknowledgement that their bond was recorded and will be executed. +さらに、ユーザーエクスペリエンスの障壁は、以前考えられていたほど重要ではない場合があります。これは、ユーザーが自分の預金が記録され、実行されることをすぐに確認できるためです。 -Furthermore, it has become clearer over time that immediate execution of staking events comes with limitations, such as: +さらに、時間の経過とともに、次のようなステーキングイベントの即時実行の制限がますます明白になっています。 -* Threshold based cryptography. One of the main limitations is that because the validator set can change so regularly, it makes the running of multiparty computation by a fixed validator set difficult. Many threshold-based cryptographic features for blockchains such as randomness beacons and threshold decryption require a computationally-expensive DKG process (will take much longer than 1 block to create). To productively use these, we need to guarantee that the result of the DKG will be used for a reasonably long time. It wouldn't be feasible to rerun the DKG every block. By epoching staking, it guarantees we'll only need to run a new DKG once every epoch. +*しきい値に基づく暗号化。主な制限の1つは、バリデーターセットを定期的に変更できるため、固定のバリデーターセットからマルチパーティ計算を実行することが困難になることです。ランダムビーコンやしきい値復号化など、ブロックチェーンの多くのしきい値ベースの暗号化機能には、計算コストの高いDKGプロセスが必要です(作成時間は1ブロックの作成よりもはるかに長くなります)。これらを有効に活用するためには、DKGの成果を長期にわたって活用していく必要があります。ブロックごとにDKGを再実行することはできません。エポックステーキングにより、エポックごとに1回だけ新しいDKGを実行する必要があることが保証されます。 -* Light client efficiency. This would lessen the overhead for IBC when there is high churn in the validator set. In the Tendermint light client bisection algorithm, the number of headers you need to verify is related to bounding the difference in validator sets between a trusted header and the latest header. If the difference is too great, you verify more header in between the two. By limiting the frequency of validator set changes, we can reduce the worst case size of IBC lite client proofs, which occurs when a validator set has high churn. +*軽いクライアント効率。これにより、バリデーターセットに大量のチャーンがある場合のIBCのオーバーヘッドが削減されます。 Tendermint lightクライアントの二分法アルゴリズムでは、検証する必要のあるヘッダーの数は、信頼できるヘッダーと最新のヘッダーの間のバリデーターセットの差の制限に関連しています。差が大きすぎる場合は、2つの間のヘッダーをさらに確認してください。バリデーターセットへの変更の頻度を制限することにより、バリデーターセットの解約率が高い場合に発生するIBCliteクライアントアテステーションのワーストケースサイズを減らすことができます。 -* Fairness of deterministic leader election. Currently we have no ways of reasoning of fairness of deterministic leader election in the presence of staking changes without epochs (tendermint/spec#217). Breaking fairness of leader election is profitable for validators, as they earn additional rewards from being the proposer. Adding epochs at least makes it easier for our deterministic leader election to match something we can prove secure. (Albeit, we still haven’t proven if our current algorithm is fair with > 2 validators in the presence of stake changes) +*リーダー選挙の公平性について決定論的。現在、エポックなしで決定論的リーダー選挙の公平性について推論する方法はありません(tendermint .spec#217)。リーダー選挙の公平性を破ることは、提案者になることで追加の報酬を得ることができるため、バリデーターにとって有益です。エポックを追加すると、少なくとも、決定論的なリーダー選挙が安全であると証明できるものと一致することが容易になります。 (それでも、現在のアルゴリズムが、エクイティの変更が存在する場合に2つを超えるバリデーターに対して公平であるかどうかはまだ証明されていません) -* Staking derivative design. Currently, reward distribution is done lazily using the F1 fee distribution. While saving computational complexity, lazy accounting requires a more stateful staking implementation. Right now, each delegation entry has to track the time of last withdrawal. Handling this can be a challenge for some staking derivatives designs that seek to provide fungibility for all tokens staked to a single validator. Force-withdrawing rewards to users can help solve this, however it is infeasible to force-withdraw rewards to users on a per block basis. With epochs, a chain could more easily alter the design to have rewards be forcefully withdrawn (iterating over delegator accounts only once per-epoch), and can thus remove delegation timing from state. This may be useful for certain staking derivative designs. +*ステーキングデリバティブデザイン。現在、F1料金の分配を使用して報酬の分配が遅れています。計算の複雑さを軽減する一方で、怠惰な簿記には、よりステートフルなステーキングの実装が必要です。ここで、各委任エントリは、最後の撤回の時刻を追跡する必要があります。この問題に対処することは、単一のバリデーターに誓約されたすべてのトークンに代替可能性を提供しようとする一部の誓約派生設計にとっては課題となる可能性があります。ユーザーに報酬の撤回を強制することはこの問題の解決に役立ちますが、ブロックごとにユーザーへの報酬を強制的に撤回することは現実的ではありません。エポックを使用すると、チェーンはより簡単にデザインを変更して報酬の撤回を強制でき(各エポックはプリンシパルアカウントを1回だけ繰り返す)、コミッション時間を州から削除できます。これは、特定の住宅ローンのデリバティブの設計に役立つ場合があります。 -## Design considerations +## 設計上の考慮事項 -### Slashing +### スラッシュ -There is a design consideration for whether to apply a slash immediately or at the end of an epoch. A slash event should apply to only members who are actually staked during the time of the infraction, namely during the epoch the slash event occured. +スラッシュをすぐに適用するか、エポックの最後に適用するかについては、設計上の考慮事項があります。スラッシュイベントは、違反期間中、つまりスラッシュイベントが発生した期間中に実際に賭けたメンバーにのみ適用する必要があります。 -Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned usecases. The benefits of immediate slashing for consensus layer security can be all be obtained by executing the validator jailing immediately (thus removing it from the validator set), and delaying the actual slash change to the validator's weight until the epoch boundary. For the use cases mentioned above, workarounds can be integrated to avoid problems, as follows: +すぐに適用すると、より高いコンセンサスレイヤーのセキュリティが提供されると見なすことができますが、上記のユースケースには潜在的なコストがかかります。コンセンサスレイヤーのセキュリティを即座に削減するメリットは、バリデーター刑務所をすぐに実行し(したがって、バリデーターセットから削除し)、検証権の変更の実際の削減をエポック境界まで遅らせることで得られます。上記のユースケースでは、以下に示すように、問題を回避するために回避策を統合できます。 -- For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that. -- For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala https://github.com/tendermint/spec/issues/199). -- For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to parameterize such that the cost of a slash within the epoch far outweights benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D) -- For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occured is fully queryable given the validator address. +-しきい値ベースの暗号化の場合、この設定により、しきい値暗号化で元の時代の重みを使用できるようになり、コンセンサスを更新して、追加のセキュリティをより迅速に活用できるようにする必要があります。しきい値ベースの暗号化によってチェーンの活性が妨げられる場合は、残りのバリデーターの活性しきい値を効果的に引き上げています。 (あるいは、投獄されたノードは引き続きシェアを提供できます)極端な場合、計画は失敗します。つまり、バリデーターの3分の1以上が単一のエポック内に投獄されます。この極端なケースでは、チェーンにはすでに独自のカスタムインシデント対応計画があり、しきい値パスワードの処理方法を定義することもその一部である必要があります。 +-ライトクライアントの効率を高めるために、ヘッダーには、ピリオド内のスラッシュを示すポイントを含めることができます(ala https://github.com/tendermint/spec/issues/199)。 +-リーダー選挙の公平性を判断するために、エポック内でスラッシュまたは投獄を適用すると、私たちが提供しようとしている保証が損なわれます。次に、これにより、公平性の保証を提供するための新しい(ただし明らかに単純な)問題が再導入されます。言い換えれば、検証者は、敵対的に提案者のセットから自分自身を削除することを選択できます。セキュリティの観点から、これは2つの異なるメカニズムを介して処理される可能性があります(または、達成するのが依然として困難であることが判明する可能性があります)。 1つは、セキュリティステートメントを作成し、攻撃者がユーザーに事前に固定しきい値を設定して、一定期間内に設定された提案者から撤退するように強制する能力があることを認めることです。 2番目の方法はパラメーター化です。これは提案者であるため、エポックでのスラッシュのコストはメリットをはるかに上回ります。ただし、後者の基準は非常に疑わしいものです。複雑なステートマシンを備えたチェーンでは、提案者になることで多くの有益な副作用が発生する可能性があるためです。 (つまり、Fomo3DなどのDeFiゲーム) +-問題を引き起こさないステーキングの派生設計。バリデーターアドレスが与えられると、スラッシュが発生するかどうかは完全に照会可能であるため、これによってステーキングレコードの状態サイズが大きくなることはありません。 +### トークンのロックアップ -### Token lockup +誰かが委託取引を行う場合、すぐに誓約されていなくても、トークンは誓約モジュールによって管理されるプールに転送され、期間の終わりに使用される必要があります。これにより、トークンがどこにステーキングされているかを心配し、それらがステーキングに割り当てられていることに気付かずにこれらのトークンを使用して、ステーキングトランザクションが失敗するのを防ぐことができます。 -When someone makes a transaction to delegate, even though they are not immediately staked, their tokens should be moved into a pool managed by the staking module which will then be used at the end of an epoch. This prevents concerns where they stake, and then spend those tokens not realizing they were already allocated for staking, and thus having their staking tx fail. +### エポックのパイプライン化 -### Pipelining the epochs +特にしきい値ベースの暗号化では、エポック変更のためのパイプラインが必要です。これは、エポックNにいるときに、バリデーターセットがそれに応じてDKGを実行できるように、エポックN +1の重みを固定する必要があるためです。したがって、現在N番目の期間にいる場合は、N + 1番目の期間のエクイティウェイトを固定し、新しいエクイティの変更をN +2番目の期間に適用する必要があります。 -For threshold based cryptography in particular, we need a pipeline for epoch changes. This is because when we are in epoch N, we want the epoch N+1 weights to be fixed so that the validator set can do the DKG accordingly. So if we are currently in epoch N, the stake weights for epoch N+1 should already be fixed, and new stake changes should be getting applied to epoch N + 2. +これは、エポックパイプの長さのパラメータを設定することで処理できます。ハードフォーク中を除いて、パイプラインの長さの切り替えの複雑さを軽減するために、このパラメーターを変更しないでください。 -This can be handled by making a parameter for the epoch pipeline length. This parameter should not be alterable except during hard forks, to mitigate implementation complexity of switching the pipeline length. +パイプの長さが1の場合、エポックNの間に再割り当てすると、エポックN +1の開始前に再割り当てが適用されます。 +パイプラインの長さが2の場合、N番目の期間に再割り当てすると、N +2番目の期間が開始する前に再委任が適用されます。 -With pipeline length 1, if I redelegate during epoch N, then my redelegation is applied prior to the beginning of epoch N+1. -With pipeline length 2, if I redelegate during epoch N, then my redelegation is applied prior to the beginning of epoch N+2. +### 賞 -### Rewards +すべてのステーキングの更新がエポック境界に適用された場合でも、報酬が請求されるとすぐに配布できます。これは、報酬の自動バインドを実現していないため、現在のエクイティウェイトに影響を与えないためです。このような関数を実装する場合は、報酬がエポック境界に自動的にバインドされるように設定する必要があります。 -Even though all staking updates are applied at epoch boundaries, rewards can still be distributed immediately when they are claimed. This is because they do not affect the current stake weights, as we do not implement auto-bonding of rewards. If such a feature were to be implemented, it would have to be setup so that rewards are auto-bonded at the epoch boundary. +### パラメータ化されたエポック長 -### Parameterizing the epoch length +エポックの長さを選択するときは、キューイングステータス/計算構造を比較検討し、前述の即時実行制限を相殺する必要があります(特定のチェーンに適用される場合)。 -When choosing the epoch length, there is a trade-off queued state/computation buildup, and countering the previously discussed limitations of immediate execution if they apply to a given chain. +可変ブロック時間ABCIメカニズムが導入される前は、計算の累積のために高い期間長を使用することは賢明ではありませんでした。これは、ブロックの実行時間がTendermintの予想ブロック時間よりも長い場合、ラウンドが増加する可能性があるためです。 -Until an ABCI mechanism for variable block times is introduced, it is ill-advised to be using high epoch lengths due to the computation buildup. This is because when a block's execution time is greater than the expected block time from Tendermint, rounds may increment. +## 決定 -## Decision +__Step-1__:すべての誓約とカットメッセージのバッファーを実現します。 -__Step-1__: Implement buffering of all staking and slashing messages. +まず、バインドされているトークンを格納するためのプールを作成しますが、これは「EpochDelegationPool」と呼ばれるエポック境界で適用する必要があります。次に、2つの別々のキューがあります。1つはステーキング用で、もう1つはスラッシュ用です。各メッセージが配信されたときに何が起こるかを以下に説明します。 -First we create a pool for storing tokens that are being bonded, but should be applied at the epoch boundary called the `EpochDelegationPool`. Then, we have two separate queues, one for staking, one for slashing. We describe what happens on each message being delivered below: +###誓約ニュース -### Staking messages +-** MsgCreateValidator **:ユーザーのセルフバインディングをすぐに `EpochDelegationPool`に移動します。 「EpochDelegationPool」から資金を取得して、自己拘束を処理するためのエポック境界のメッセージをキューに入れます。エポックの実行が失敗した場合、資金はエポックデレゲーションプールからユーザーのアカウントに返還されます。 +-** MsgEditValidator **:メッセージを検証します。有効な場合は、エポックの最後に実行するためにメッセージをキューに入れます。 +-** MsgDelegate **:ユーザーの資金をすぐに `EpochDelegationPool`に送金します。委任を処理するためのエポック境界のメッセージをキューに入れ、「EpochDelegationPool」から資金を取得します。エポックの実行が失敗した場合、資金はエポックデレゲーションプールからユーザーのアカウントに返還されます。 +-** MsgBeginRedelegate **:メッセージを確認します。有効な場合は、エポックの最後に実行するためにメッセージをキューに入れます。 +-** MsgUndelegate **:メッセージを確認します。有効な場合は、エポックの最後に実行するためにメッセージをキューに入れます。 -- **MsgCreateValidator**: Move user's self-bond to `EpochDelegationPool` immediately. Queue a message for the epoch boundary to handle the self-bond, taking the funds from the `EpochDelegationPool`. If Epoch execution fail, return back funds from `EpochDelegationPool` to user's account. -- **MsgEditValidator**: Validate message and if valid queue the message for execution at the end of the Epoch. -- **MsgDelegate**: Move user's funds to `EpochDelegationPool` immediately. Queue a message for the epoch boundary to handle the delegation, taking the funds from the `EpochDelegationPool`. If Epoch execution fail, return back funds from `EpochDelegationPool` to user's account. -- **MsgBeginRedelegate**: Validate message and if valid queue the message for execution at the end of the Epoch. -- **MsgUndelegate**: Validate message and if valid queue the message for execution at the end of the Epoch. +### メッセージをカット -### Slashing messages +-** MsgUnjail **:メッセージを確認します。有効な場合は、エポックの最後に実行するためにメッセージをキューに入れます。 +-**スラッシュイベント**:スラッシュイベントが作成されるたびに、エポックの最後に適用されるスラッシュモジュールのキューに入れられます。このスラッシュがすぐに適用されるように、キューを設定する必要があります。 -- **MsgUnjail**: Validate message and if valid queue the message for execution at the end of the Epoch. -- **Slash Event**: Whenever a slash event is created, it gets queued in the slashing module to apply at the end of the epoch. The queues should be setup such that this slash applies immediately. +### 証拠メッセージ -### Evidence Messages +-** MsgSubmitEvidence **:すぐに実行すると、バリデーターはすぐに投獄されます。ただし、スラッシュでは、実際のスラッシュイベントがキューに入れられます。 -- **MsgSubmitEvidence**: This gets executed immediately, and the validator gets jailed immediately. However in slashing, the actual slash event gets queued. +次に、エンドブロッカーにメソッドを追加して、キューがエポック境界でクリアされ、委任された更新が適用されるようにします。 -Then we add methods to the end blockers, to ensure that at the epoch boundary the queues are cleared and delegation updates are applied. +__Step-2__:キューに入れられた誓約トランザクションのクエリを実現します。 -__Step-2__: Implement querying of queued staking txs. +特定のアドレスの誓約アクティビティを照会する場合、ステータスは、誓約されたトークンの数を返すだけでなく、そのアドレスでキューに入れられた誓約イベントがあるかどうかも返す必要があります。これには、キューに入れられる今後のステーキングイベントを追跡するために、クエリロジックでより多くの作業が必要になります。 -When querying the staking activity of a given address, the status should return not only the amount of tokens staked, but also if there are any queued stake events for that address. This will require more work to be done in the querying logic, to trace the queued upcoming staking events. +最初の実装として、これは、キューに入れられたすべての住宅ローンイベントの線形検索として実装できます。ただし、長いエポックを必要とするチェーンの場合、一定時間で結果を生成できるように、最終的にはクエリをサポートするノードの追加サポートを構築する必要があります。 (これは、アドレスごとに今後のステーキングイベントにインデックスを付けるための補助ハッシュグラフを維持することで実現できます) -As an initial implementation, this can be implemented as a linear search over all queued staking events. However, for chains that need long epochs, they should eventually build additional support for nodes that support querying to be able to produce results in constant time. (This is do-able by maintaining an auxilliary hashmap for indexing upcoming staking events by address) +__ステップ-3__:ガスを調整します -__Step-3__: Adjust gas +現在、ガスは、トランザクションがすぐに完了したときにトランザクションを実行するためのコストを表します。 (p2pコスト、状態アクセスコスト、および計算コストのコストを組み合わせます)ただし、現在、トランザクションは、将来のブロック、つまりエポック境界で計算を引き起こす可能性があります。 -Currently gas represents the cost of executing a transaction when its done immediately. (Merging together costs of p2p overhead, state access overhead, and computational overhead) However, now a transaction can cause computation in a future block, namely at the epoch boundary. +この問題を解決するには、最初に将来の計算量(ガスでの価格設定)を見積もるためのパラメーターを含め、メッセージの固定料金として追加する必要があります。 +ガス価格の将来の計算と現在の計算の重み付け方法の範囲から除外し、現在の重みと等しくなるように設定します。 -To handle this, we should initially include parameters for estimating the amount of future computation (denominated in gas), and add that as a flat charge needed for the message. -We leave it as out of scope for how to weight future computation versus current computation in gas pricing, and have it set such that the are weighted equally for now. +## 結果 -## Consequences +### ポジティブ -### Positive +*既存の機能の保持を可能にするプルーフオブステークモジュールを抽象化しました +*バリデーターセットに基づくしきい値暗号化などの新機能を有効にする -* Abstracts the proof of stake module that allows retaining the existing functionality -* Enables new features such as validator-set based threshold cryptography +### ネガティブ -### Negative - -* Increases complexity of integrating more complex gas pricing mechanisms, as they now have to consider future execution costs as well. -* When epoch > 1, validators can no longer leave the network immediately, and must wait until an epoch boundary. +*将来の実行コストも考慮する必要があるため、より複雑なガス価格設定メカニズムの統合の複雑さが増しました。 +*エポック> 1の場合、ベリファイアはネットワークをすぐに離れることができなくなり、エポック境界まで待機する必要があります。 \ No newline at end of file diff --git a/docs/ja/architecture/adr-040-storage-and-smt-state-commitments.md b/docs/ja/architecture/adr-040-storage-and-smt-state-commitments.md index 75bf962a6ea9..61e31d188ffd 100644 --- a/docs/ja/architecture/adr-040-storage-and-smt-state-commitments.md +++ b/docs/ja/architecture/adr-040-storage-and-smt-state-commitments.md @@ -1,139 +1,139 @@ -# ADR 040: Storage and SMT State Commitments +# ADR 040:ストレージとSMT状態のコミットメント -## Changelog +## 変更ログ -- 2020-01-15: Draft +-2020-01-15:ドラフト -## Status +## 状態 -DRAFT Not Implemented +ドラフトは実装されていません -## Abstract +## 概要 -Sparse Merkle Tree ([SMT](https://osf.io/8mcnh/)) is a version of a Merkle Tree with various storage and performance optimizations. This ADR defines a separation of state commitments from data storage and the Cosmos SDK transition from IAVL to SMT. +スパースマーケルツリー([SMT](https://osf.io/8mcnh/))は、さまざまなストレージとパフォーマンスの最適化を備えたバージョンのマーケルツリーです。このADRは、州のコミットメントとデータストレージの分離、およびCosmosSDKのIAVLからSMTへの変換を定義します。 -## Context +## 環境 -Currently, Cosmos SDK uses IAVL for both state [commitments](https://cryptography.fandom.com/wiki/Commitment_scheme) and data storage. +現在、Cosmos SDKはステータス[コミットメント](https://cryptography.fandom.com/wiki/Commitment_scheme)とデータストレージにIAVLを使用しています。 -IAVL has effectively become an orphaned project within the Cosmos ecosystem and it's proven to be an inefficient state commitment data structure. -In the current design, IAVL is used for both data storage and as a Merkle Tree for state commitments. IAVL is meant to be a standalone Merkelized key/value database, however it's using a KV DB engine to store all tree nodes. So, each node is stored in a separate record in the KV DB. This causes many inefficiencies and problems: +IAVLは、事実上Cosmosエコシステムで孤立したプロジェクトになり、非効率的な州のコミットメントデータ構造であることが証明されています。 +現在の設計では、IAVLはデータストレージと状態コミットメントのMerkelツリーに使用されます。 IAVLは、独立したMerkelized Key .Valueデータベースを目指していますが、KVデータベースエンジンを使用してすべてのツリーノードを格納します。したがって、各ノードはKVDBの個別のレコードに格納されます。これは多くの非効率性と問題を引き起こします: -+ Each object query requires a tree traversal from the root. Subsequent queries for the same object are cached on the Cosmos SDK level. -+ Each edge traversal requires a DB query. -+ Creating snapshots is [expensive](https://github.com/cosmos/cosmos-sdk/issues/7215#issuecomment-684804950). It takes about 30 seconds to export less than 100 MB of state (as of March 2020). -+ Updates in IAVL may trigger tree reorganization and possible O(log(n)) hashes re-computation, which can become a CPU bottleneck. -+ The node structure is pretty expensive - it contains a standard tree node elements (key, value, left and right element) and additional metadata such as height, version (which is not required by the Cosmos SDK). The entire node is hashed, and that hash is used as the key in the underlying database, [ref](https://github.com/cosmos/iavl/blob/master/docs/node/node.md -). ++すべてのオブジェクトクエリは、ルートからツリーをトラバースする必要があります。同じオブジェクトに対する後続のクエリは、CosmosSDKレベルでキャッシュされます。 ++各エッジトラバーサルにはDBクエリが必要です。 ++スナップショットを作成します[高価](https://github.com/cosmos/cosmos-sdk/issues/7215#issuecomment-684804950)。 100 MB未満の状態をエクスポートするのに約30秒かかります(2020年3月現在)。 ++ IAVLの更新により、ツリーの再編成とO(log(n))ハッシュの再計算がトリガーされる可能性があり、これがCPUのボトルネックになる可能性があります。 ++ノード構造は非常に高価です。標準のツリーノード要素(キー、値、左および右の要素)と、高さやバージョン(Cosmos SDKでは不要)などの追加のメタデータが含まれています。ノード全体をハッシュし、基になるデータベースのキーとしてハッシュを使用します[ref](https://github.com/cosmos/iavl/blob/master/docs/node/node.md +)。 -Moreover, the IAVL project lacks support and a maintainer and we already see better and well-established alternatives. Instead of optimizing the IAVL, we are looking into other solutions for both storage and state commitments. +さらに、IAVLプロジェクトにはサポートとメンテナーが不足しており、より優れた完全な代替案が見られました。 IAVLは最適化されていませんが、ストレージと状態の約束を達成するための他のソリューションを検討しています。 -## Decision +## 決定 -We propose to separate the concerns of state commitment (**SC**), needed for consensus, and state storage (**SS**), needed for state machine. Finally we replace IAVL with [Celestia's SMT](https://github.com/lazyledger/smt). Celestia SMT is based on Diem (called jellyfish) design [*] - it uses a compute-optimised SMT by replacing subtrees with only default values with a single node (same approach is used by Ethereum2) and implements compact proofs. +コンセンサスに必要な状態コミットメント(** SC **)とステートマシンに必要な状態ストレージ(** SS **)のフォーカスを分離することをお勧めします。最後に、IAVLを[CelestiaのSMT](https://github.com/lazyledger/smt)に置き換えます。 Celestia SMTはDiem(クラゲと呼ばれる)設計に基づいています[*]-デフォルト値のみのサブツリーを単一ノードで置き換えることにより(Ethereum2は同じ方法を使用します)、計算上最適化されたSMTを使用し、コンパクトな証明を実現します。 -The storage model presented here doesn't deal with data structure nor serialization. It's a Key-Value database, where both key and value are binaries. The storage user is responsible for data serialization. +ここで説明するストレージモデルは、データ構造やシリアル化を扱いません。これはキーと値のデータベースであり、キーと値はバイナリファイルです。ストレージユーザーは、データのシリアル化を担当します。 -### Decouple state commitment from storage +### 状態の約束をストレージから分離する -Separation of storage and commitment (by the SMT) will allow the optimization of different components according to their usage and access patterns. +ストレージとコミットメントを(SMTを介して)分離することで、さまざまなコンポーネントをその使用法とアクセスパターンに基づいて最適化できます。 -`SC` (SMT) is used to commit to a data and compute Merkle proofs. `SS` is used to directly access data. To avoid collisions, both `SS` and `SC` will use a separate storage namespace (they could use the same database underneath). `SS` will store each record directly (mapping `(key, value)` as `key → value`). +`SC`(SMT)は、データを送信し、マークル証明を計算するために使用されます。 `SS`はデータに直接アクセスするために使用されます。競合を回避するために、 `SS`と` SC`の両方が別々のストレージ名前空間を使用します(以下で同じデータベースを使用できます)。 `SS`は各レコードを直接保存します(`(key、value) `を` key→value`にマップします)。 -SMT is a merkle tree structure: we don't store keys directly. For every `(key, value)` pair, `hash(key)` is used as leaf path (we hash a key to uniformly distribute leaves in the tree) and `hash(value)` as the leaf contents. The tree structure is specified in more depth [below](#smt-for-state-commitment). +SMTはMerkelツリー構造です。キーを直接保存しません。 `(key、value)`ペアごとに、 `hash(key)`がリーフパスとして使用され(キーをハッシュしてツリー内の葉を均等に分散します)、 `hash(value)`はリーフコンテンツです。 [以下](#smt-for-state-commitment)は、ツリー構造をより詳細に指定します。 -For data access we propose 2 additional KV buckets (implemented as namespaces for the key-value pairs, sometimes called [column family](https://github.com/facebook/rocksdb/wiki/Terminology)): +データアクセスには、2つの追加のKVバケットを使用することをお勧めします(キーと値のペアの名前空間として実装され、[列ファミリー](https://github.com/facebook/rocksdb/wiki/Terminology)と呼ばれることもあります): -1. B1: `key → value`: the principal object storage, used by a state machine, behind the Cosmos SDK `KVStore` interface: provides direct access by key and allows prefix iteration (KV DB backend must support it). -2. B2: `hash(key) → key`: a reverse index to get a key from an SMT path. Internally the SMT will store `(key, value)` as `prefix || hash(key) || hash(value)`. So, we can get an object value by composing `hash(key) → B2 → B1`. -3. We could use more buckets to optimize the app usage if needed. +1. B1: `key→value`:Cosmos SDK` KVStore`インターフェースの背後にあるステートマシンによって使用されるメインオブジェクトストレージ:直接キーアクセスを提供し、プレフィックスの反復を許可します(KV DBバックエンドがサポートする必要があります)。 +2. B2: `hash(key)→key`:SMTパスからキーの逆インデックスを取得します。内部的には、SMTは `(key、value)`を `prefix || hash(key)|| hash(value)`として保存します。したがって、 `hash(key)→B2→B1`を組み合わせることでオブジェクト値を取得できます。 +3.必要に応じて、より多くのバケットを使用してアプリケーションの使用を最適化できます。 -We propose to use a KV database for both `SS` and `SC`. The store interface will allow to use the same physical DB backend for both `SS` and `SC` as well two separate DBs. The latter option allows for the separation of `SS` and `SC` into different hardware units, providing support for more complex setup scenarios and improving overall performance: one can use different backends (eg RocksDB and Badger) as well as independently tuning the underlying DB configuration. +「SS」と「SC」にはKVデータベースの使用をお勧めします。ストレージインターフェイスでは、「SS」と「SC」に同じ物理データベースバックエンドと2つの別々のデータベースを使用できます。後者のオプションでは、 `SS`と` SC`を異なるハードウェアユニットに分離して、より複雑なセットアップシナリオをサポートし、全体的なパフォーマンスを向上させることができます。異なるバックエンド(RocksDBやBadgerなど)を使用でき、最下層を個別に調整できます。データベース構成。 -### Requirements +### 要件 -State Storage requirements: +州の保管要件: -+ range queries -+ quick (key, value) access -+ creating a snapshot -+ historical versioning -+ pruning (garbage collection) ++範囲クエリ ++高速(キー、値)アクセス ++スナップショットを作成する ++履歴バージョン ++剪定(ガベージコレクション) -State Commitment requirements: +国家のコミットメント要件: -+ fast updates -+ tree path should be short -+ query historical commitment proofs using ICS-23 standard -+ pruning (garbage collection) ++クイックアップデート ++ツリーパスは短くする必要があります ++ ICS-23標準を使用して、過去のコミットメント証明書を照会します ++剪定(ガベージコレクション) -### SMT for State Commitment +### National Commitment SMT -A Sparse Merkle tree is based on the idea of a complete Merkle tree of an intractable size. The assumption here is that as the size of the tree is intractable, there would only be a few leaf nodes with valid data blocks relative to the tree size, rendering a sparse tree. +スパースなマークルツリーは、扱いにくいサイズの完全なマークルツリーのアイデアに基づいています。ここでの前提は、ツリーのサイズを処理するのが難しいため、ツリーのサイズに比べて有効なデータブロックを持つリーフノードが数個しかないため、まばらなツリーが表示されることです。 -The full specification can be found at [Celestia](https://github.com/celestiaorg/celestia-specs/blob/ec98170398dfc6394423ee79b00b71038879e211/src/specs/data_structures.md#sparse-merkle-tree). In summary: +完全な仕様は[Celestia](https://github.com/celestiaorg/celestia-specs/blob/ec98170398dfc6394423ee79b00b71038879e211/src/specs/data_structures.md#sparse-merkle-tree)にあります。要するに: -* The SMT consists of a binary Merkle tree, constructed in the same fashion as described in [Certificate Transparency (RFC-6962)](https://tools.ietf.org/html/rfc6962), but using as the hashing function SHA-2-256 as defined in [FIPS 180-4](https://doi.org/10.6028/NIST.FIPS.180-4). -* Leaves and internal nodes are hashed differently: the one-byte `0x00` is prepended for leaf nodes while `0x01` is prepended for internal nodes. -* Default values are given to leaf nodes with empty leaves. -* While the above rule is sufficient to pre-compute the values of intermediate nodes that are roots of empty subtrees, a further simplification is to extend this default value to all nodes that are roots of empty subtrees. The 32-byte zero is used as the default value. This rule takes precedence over the above one. -* An internal node that is the root of a subtree that contains exactly one non-empty leaf is replaced by that leaf's leaf node. +* SMTは、[Certificate Transparency(RFC-6962)](https://tools.ietf.org/html/rfc6962)で説明されているのと同じ方法で構築された、バイナリMerkleツリーで構成されていますが、ハッシュ関数SHAとして使用されます。 -2-256、[FIPS 180-4](https://doi.org/10.6028/NIST.FIPS.180-4)で定義されています。 +※リーフノードと内部ノードのハッシュ方式が異なります。リーフノードの前面に1バイトの「0x00」が追加され、内部ノードの前面に「0x01」が追加されます。 +*空のリーフノードにデフォルト値を割り当てます。 +*上記のルールは、空のサブツリーのルートである中間ノードの値を事前に計算するのに十分ですが、さらに単純化すると、このデフォルト値を空のサブツリーのルートであるすべてのノードに拡張できます。デフォルト値として32バイトのゼロが使用されます。このルールは、上記のルールよりも優先されます。 +*空でないリーフを含むサブツリーのルートである内部ノードは、そのリーフのリーフノードに置き換えられます。 -### Snapshots for storage sync and state versioning +### ストレージ同期と状態バージョン管理のためのスナップショット -Below, with simple _snapshot_ we refer to a database snapshot mechanism, not to a _ABCI snapshot sync_. The latter will be referred as _snapshot sync_ (which will directly use DB snapshot as described below). +以下では、単に_snapshot_によって、_ABCIスナップショット同期_ではなく、データベーススナップショットメカニズムを参照しています。後者は_snapshotsync_と呼ばれます(以下で説明するように、データベーススナップショットが直接使用されます)。 -Database snapshot is a view of DB state at a certain time or transaction. It's not a full copy of a database (it would be too big). Usually a snapshot mechanism is based on a _copy on write_ and it allows DB state to be efficiently delivered at a certain stage. -Some DB engines support snapshotting. Hence, we propose to reuse that functionality for the state sync and versioning (described below). We limit the supported DB engines to ones which efficiently implement snapshots. In a final section we discuss the evaluated DBs. +データベーススナップショットは、特定の時間またはトランザクションにおけるデータベースの状態のビューです。データベースの完全なコピーではありません(大きすぎます)。通常、スナップショットメカニズムは_コピーオンライト_に基づいており、特定の段階でDBステータスを効果的に転送できます。 +一部のデータベースエンジンはスナップショットをサポートしています。したがって、状態の同期とバージョン管理(以下で説明)にこの機能を再利用することをお勧めします。サポートされているデータベースエンジンは、スナップショットを効果的に実装するものに限定しています。最後のセクションでは、評価されたDBについて説明します。 -One of the Stargate core features is a _snapshot sync_ delivered in the `/snapshot` package. It provides a way to trustlessly sync a blockchain without repeating all transactions from the genesis. This feature is implemented in Cosmos SDK and requires storage support. Currently IAVL is the only supported backend. It works by streaming to a client a snapshot of a `SS` at a certain version together with a header chain. +Stargateのコア機能の1つは、 `.snapshot`パッケージで提供される_snapshotsync_です。これは、信頼せずに、すべてのトランザクションを繰り返さずにブロックチェーンを同期する方法を提供します。この機能はCosmosSDKに実装されており、ストレージのサポートが必要です。現在、サポートされているバックエンドはIAVLのみです。これは、特定のバージョンの「SS」のスナップショットをヘッダーチェーンとともにクライアントにストリーミングすることで機能します。 -A new database snapshot will be created in every `EndBlocker` and identified by a block height. The `root` store keeps track of the available snapshots to offer `SS` at a certain version. The `root` store implements the `RootStore` interface described below. In essence, `RootStore` encapsulates a `Committer` interface. `Committer` has a `Commit`, `SetPruning`, `GetPruning` functions which will be used for creating and removing snapshots. The `rootStore.Commit` function creates a new snapshot and increments the version on each call, and checks if it needs to remove old versions. We will need to update the SMT interface to implement the `Committer` interface. -NOTE: `Commit` must be called exactly once per block. Otherwise we risk going out of sync for the version number and block height. -NOTE: For the Cosmos SDK storage, we may consider splitting that interface into `Committer` and `PruningCommitter` - only the multiroot should implement `PruningCommitter` (cache and prefix store don't need pruning). +新しいデータベーススナップショットが各「EndBlocker」に作成され、ブロックの高さで識別されます。 `root`は、利用可能なスナップショットを保存および追跡して、` SS`の特定のバージョンを提供します。 `root`ストアは、以下で説明する` RootStore`インターフェースを実装します。基本的に、 `RootStore`は` Committer`インターフェースをカプセル化します。 `Committer`には、スナップショットを作成および削除するための` Commit`、 `SetPruning`、および` GetPruning`関数があります。 `rootStore.Commit`関数は、新しいスナップショットを作成し、呼び出されるたびにバージョンをインクリメントし、古いバージョンを削除する必要があるかどうかを確認します。 `コミッター`インターフェースを実装するためにSMTインターフェースを更新する必要があります。 +注:各ブロックは、 `Commit`を1回だけ呼び出す必要があります。そうしないと、バージョン番号とブロックが高度に同期するリスクに直面する可能性があります。 +注:Cosmos SDKストレージの場合、インターフェイスを `Committer`と` PruningCommitter`に分割することを検討できます。マルチルートのみが `PruningCommitter`を実装する必要があります(キャッシュとプレフィックスストレージをトリミングする必要はありません)。 -Number of historical versions for `abci.RequestQuery` and state sync snapshots is part of a node configuration, not a chain configuration (configuration implied by the blockchain consensus). A configuration should allow to specify number of past blocks and number of past blocks modulo some number (eg: 100 past blocks and one snapshot every 100 blocks for past 2000 blocks). Archival nodes can keep all past versions. +`abci.RequestQuery`と状態同期スナップショットの履歴バージョン番号は、チェーン構成(ブロックチェーンコンセンサスによって暗示される構成)ではなく、ノード構成の一部です。構成では、過去のブロックの数と特定の数を法として過去のブロックの数を指定できる必要があります(たとえば、過去100ブロックと過去2000ブロックの100ブロックごとのスナップショット)。アーカイブノードは、過去のすべてのバージョンを保持できます。 -Pruning old snapshots is effectively done by a database. Whenever we update a record in `SC`, SMT won't update nodes - instead it creates new nodes on the update path, without removing the old one. Since we are snapshotting each block, we need to change that mechanism to immediately remove orphaned nodes from the database. This is a safe operation - snapshots will keep track of the records and make it available when accessing past versions. +古いスナップショットのプルーニングは、データベースによって効果的に実行されます。 `SC`のレコードを更新するときはいつでも、SMTはノードを更新しません-古いノードを削除する代わりに、更新パス上に新しいノードを作成します。各ブロックのスナップショットを取得しているため、データベースから孤立したノードをすぐに削除するようにメカニズムを変更する必要があります。これは安全な操作です。スナップショットはレコードを追跡し、過去のバージョンにアクセスするときに利用できるようにします。 -To manage the active snapshots we will either use a DB _max number of snapshots_ option (if available), or we will remove DB snapshots in the `EndBlocker`. The latter option can be done efficiently by identifying snapshots with block height and calling a store function to remove past versions. +アクティブなスナップショットを管理するために、DB _スナップショットの最大数_オプション(使用可能な場合)を使用するか、「EndBlocker」のDBスナップショットを削除します。ブロックの高さでスナップショットを識別し、ストレージ関数を呼び出して過去のバージョンを削除することにより、後者のオプションを効果的に完了することができます。 -#### Accessing old state versions +#### 古いステータスバージョンにアクセス -One of the functional requirements is to access old state. This is done through `abci.RequestQuery` structure. The version is specified by a block height (so we query for an object by a key `K` at block height `H`). The number of old versions supported for `abci.RequestQuery` is configurable. Accessing an old state is done by using available snapshots. -`abci.RequestQuery` doesn't need old state of `SC` unless the `prove=true` parameter is set. The SMT merkle proof must be included in the `abci.ResponseQuery` only if both `SC` and `SS` have a snapshot for requested version. +機能要件の1つは、古い状態にアクセスすることです。これは、「abci.RequestQuery」構造を介して行われます。バージョンはブロックの高さで指定されます(したがって、ブロックの高さ「H」でキー「K」を使用してオブジェクトを照会します)。 `abci.RequestQuery`でサポートされている古いバージョンの数は構成可能です。古い状態へのアクセスは、利用可能なスナップショットを使用して行われます。 +`prove = true`パラメータが設定されていない限り、` abci.RequestQuery`は `SC`の古い状態を必要としません。 `SC`と` SS`の両方に要求されたバージョンのスナップショットがある場合にのみ、SMTMerkel証明書を `abci.ResponseQuery`に含める必要があります。 -Moreover, Cosmos SDK could provide a way to directly access a historical state. However, a state machine shouldn't do that - since the number of snapshots is configurable, it would lead to nondeterministic execution. +さらに、Cosmos SDKは、履歴状態に直接アクセスする方法を提供できます。ただし、ステートマシンはこれを行うべきではありません。スナップショットの数は構成可能であるため、非決定論的な実行につながります。 -We positively [validated](https://github.com/cosmos/cosmos-sdk/discussions/8297) a versioning and snapshot mechanism for querying old state with regards to the database we evaluated. +評価したデータベースの古い状態をクエリするためのバージョン管理とスナップショットのメカニズムを積極的に[確認](https://github.com/cosmos/cosmos-sdk/discussions/8297)します。 -### State Proofs +### ステータスの証明 -For any object stored in State Store (SS), we have corresponding object in `SC`. A proof for object `V` identified by a key `K` is a branch of `SC`, where the path corresponds to the key `hash(K)`, and the leaf is `hash(K, V)`. +状態ストア(SS)に格納されているオブジェクトの場合、対応するオブジェクトが「SC」にあります。キー「K」で識別されるオブジェクト「V」の証明は「SC」のブランチであり、パスはキー「hash(K)」に対応し、リーフは「hash(K、V)」です。 -### Rollbacks +### ロールバック -We need to be able to process transactions and roll-back state updates if a transaction fails. This can be done in the following way: during transaction processing, we keep all state change requests (writes) in a `CacheWrapper` abstraction (as it's done today). Once we finish the block processing, in the `Endblocker`, we commit a root store - at that time, all changes are written to the SMT and to the `SS` and a snapshot is created. +トランザクションが失敗した場合は、トランザクションを処理してステータスの更新をロールバックできる必要があります。これは、次の方法で実行できます。トランザクション中に、すべての状態変更要求(書き込み)を「CacheWrapper」抽象化に保存します(今日と同じように)。ブロック処理が終了したら、「Endblocker」でルートストレージを送信します。その時点で、すべての変更がSMTと「SS」に書き込まれ、スナップショットが作成されます。 -### Committing to an object without saving it +### オブジェクトを保存せずに送信する -We identified use-cases, where modules will need to save an object commitment without storing an object itself. Sometimes clients are receiving complex objects, and they have no way to prove a correctness of that object without knowing the storage layout. For those use cases it would be easier to commit to the object without storing it directly. +モジュールがオブジェクト自体ではなくオブジェクトpromiseを保存する必要があるユースケースを特定しました。クライアントが複雑なオブジェクトを受け取ることがあり、ストレージレイアウトを知らないと、オブジェクトの正確さを証明できません。これらのユースケースでは、オブジェクトを直接保存せずに送信する方が簡単です。 -### Refactor MultiStore +### マルチストアのリファクタリング -The Stargate `/store` implementation (store/v1) adds an additional layer in the SDK store construction - the `MultiStore` structure. The multistore exists to support the modularity of the Cosmos SDK - each module is using its own instance of IAVL, but in the current implementation, all instances share the same database. The latter indicates, however, that the implementation doesn't provide true modularity. Instead it causes problems related to race condition and atomic DB commits (see: [\#6370](https://github.com/cosmos/cosmos-sdk/issues/6370) and [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297#discussioncomment-757043)). +Stargateの `.store`実装(store .v1)は、追加のレイヤー(` MultiStore`構造)をSDKストレージビルドに追加します。マルチストアは、Cosmos SDKのモジュール性をサポートするために存在します。各モジュールは独自のIAVLインスタンスを使用しますが、現在の実装では、すべてのインスタンスが同じデータベースを共有します。ただし、後者は、実装が真のモジュール性を提供しないことを示しています。代わりに、競合状態とアトミックデータベースの送信に関連する問題が発生します([\#6370](https://github.com/cosmos/cosmos-sdk/issues/6370)および[ディスカッション](https://を参照)。 github.com)。com.cosmos .cosmos-sdk .discussions .8297#discussioncomment-757043))。 -We propose to reduce the multistore concept from the SDK, and to use a single instance of `SC` and `SS` in a `RootStore` object. To avoid confusion, we should rename the `MultiStore` interface to `RootStore`. The `RootStore` will have the following interface; the methods for configuring tracing and listeners are omitted for brevity. +SDKで複数のストレージの概念を減らし、「RootStore」オブジェクトで「SC」と「SS」の単一インスタンスを使用することをお勧めします。混乱を避けるために、 `MultiStore`インターフェースの名前を` RootStore`に変更する必要があります。 `RootStore`には次のインターフェースがあります。簡潔にするために、トラッキングとリスナーを構成する方法は省略されています。 ```go -// Used where read-only access to versions is needed. +/.Used where read-only access to versions is needed. type BasicRootStore interface { Store GetKVStore(StoreKey) KVStore CacheRootStore() CacheRootStore } -// Used as the main app state, replacing CommitMultiStore. +/.Used as the main app state, replacing CommitMultiStore. type CommitRootStore interface { BasicRootStore Committer @@ -142,18 +142,18 @@ type CommitRootStore interface { GetVersion(uint64) (BasicRootStore, error) SetInitialVersion(uint64) error - ... // Trace and Listen methods + .....Trace and Listen methods } -// Replaces CacheMultiStore for branched state. +/.Replaces CacheMultiStore for branched state. type CacheRootStore interface { BasicRootStore Write() - ... // Trace and Listen methods + .....Trace and Listen methods } -// Example of constructor parameters for the concrete type. +/.Example of constructor parameters for the concrete type. type RootStoreConfig struct { Upgrades *StoreUpgrades InitialVersion uint64 @@ -162,104 +162,103 @@ type RootStoreConfig struct { } ``` - - + + -In contrast to `MultiStore`, `RootStore` doesn't allow to dynamically mount sub-stores or provide an arbitrary backing DB for individual sub-stores. +「MultiStore」とは異なり、「RootStore」では、サブストアを動的にマウントしたり、単一のサブストアにバックアップデータベースを提供したりすることはできません。 -NOTE: modules will be able to use a special commitment and their own DBs. For example: a module which will use ZK proofs for state can store and commit this proof in the `RootStore` (usually as a single record) and manage the specialized store privately or using the `SC` low level interface. +注:モジュールは、特別なPromiseと独自のデータベースを使用できるようになります。例:州にZK認定を使用するモジュールは、この認定を `RootStore`(通常は単一のレコードとして)に保存して送信し、専用ストレージをプライベートに管理するか、` SC`低レベルインターフェイスを使用して管理できます。 -#### Compatibility support +#### 互換性のサポート -To ease the transition to this new interface for users, we can create a shim which wraps a `CommitMultiStore` but provides a `CommitRootStore` interface, and expose functions to safely create and access the underlying `CommitMultiStore`. +ユーザーがこの新しいインターフェースに簡単に移行できるようにするために、「CommitMultiStore」をラップするが「CommitRootStore」インターフェースを提供し、基になる「CommitMultiStore」を安全に作成してアクセスするための関数を公開するシムを作成できます。 -The new `RootStore` and supporting types can be implemented in a `store/v2` package to avoid breaking existing code. +新しい `RootStore`とサポートタイプを` store .v2`パッケージに実装して、既存のコードを壊さないようにすることができます。 -#### Merkle Proofs and IBC +#### メルケルプルーフとIBC -Currently, an IBC (v1.0) Merkle proof path consists of two elements (`["", ""]`), with each key corresponding to a separate proof. These are each verified according to individual [ICS-23 specs](https://github.com/cosmos/ibc-go/blob/f7051429e1cf833a6f65d51e6c3df1609290a549/modules/core/23-commitment/types/merkle.go#L17), and the result hash of each step is used as the committed value of the next step, until a root commitment hash is obtained. -The root hash of the proof for `""` is hashed with the `""` to validate against the App Hash. +現在、IBC(v1.0)マークル証明パスは2つの要素( `[" "、" "]`)で構成されており、各キーは個別の証明に対応しています。これらはすべて、個人の[ICS-23仕様](https://github.com/cosmos/ibc-go/blob/f7051429e1cf833a6f65d51e6c3df1609290a549/modules/core/23-commitment/types/merkle.go#L17)に従って検証されています。ルートコミットハッシュが取得されるまで、ハッシュは次のステップでコミット値として使用されます。 +`" "`の証明書のルートハッシュは、アプリケーションハッシュを検証するために `" "`でハッシュされます。 -This is not compatible with the `RootStore`, which stores all records in a single Merkle tree structure, and won't produce separate proofs for the store- and record-key. Ideally, the store-key component of the proof could just be omitted, and updated to use a "no-op" spec, so only the record-key is used. However, because the IBC verification code hardcodes the `"ibc"` prefix and applies it to the SDK proof as a separate element of the proof path, this isn't possible without a breaking change. Breaking this behavior would severely impact the Cosmos ecosystem which already widely adopts the IBC module. Requesting an update of the IBC module across the chains is a time consuming effort and not easily feasible. +これは、すべてのレコードを単一のMerkleツリー構造に格納し、ストレージキーとレコードキーに対して個別の証明を生成しない「RootStore」とは互換性がありません。理想的には、プルーフのストレージキーコンポーネントを省略して、「操作なし」仕様を使用するように更新できるため、レコードキーのみが使用されます。ただし、IBC検証コードは `" ibc "`プレフィックスをハードコードし、それを認証パスの個別の要素としてSDK認証に適用するため、これは大きな変更なしでは不可能です。この動作を破ると、IBCモジュールを広く採用しているCosmosエコシステムに深刻な影響を及ぼします。 IBCモジュールを更新するためのクロスチェーン要求は、時間のかかる作業であり、実装するのは簡単ではありません。 -As a workaround, the `RootStore` will have to use two separate SMTs (they could use the same underlying DB): one for IBC state and one for everything else. A simple Merkle map that reference these SMTs will act as a Merkle Tree to create a final App hash. The Merkle map is not stored in a DBs - it's constructed in the runtime. The IBC substore key must be `"ibc"`. +回避策として、「RootStore」は2つの別々のSMTを使用する必要があります(1つは同じ基になるデータベースを使用できます)。1つはIBC状態用で、もう1つはその他すべて用です。これらのSMTを参照する単純なMerkleマップは、最終的なアプリハッシュを作成するためのMerkleツリーとして機能します。 MerkleマッピングはDBに保存されません-実行時に構築されます。 IBCサブストレージキーは「ibc」である必要があります。 -The workaround can still guarantee atomic syncs: the [proposed DB backends](#evaluated-kv-databases) support atomic transactions and efficient rollbacks, which will be used in the commit phase. +回避策は引き続きアトミック同期を保証できます。[提案されたデータベースバックエンド](#evaluated-kv-databases)は、コミットフェーズ中に使用されるアトミックトランザクションと効率的なロールバックをサポートします。 -The presented workaround can be used until the IBC module is fully upgraded to supports single-element commitment proofs. +提案されたソリューションは、IBCモジュールが完全にアップグレードされて単一要素のコミットメントの証明をサポートするまで使用できます。 -### Optimization: compress module key prefixes +### 最適化:モジュールキープレフィックスを圧縮 -We consider a compression of prefix keys by creating a mapping from module key to an integer, and serializing the integer using varint coding. Varint coding assures that different values don't have common byte prefix. For Merkle Proofs we can't use prefix compression - so it should only apply for the `SS` keys. Moreover, the prefix compression should be only applied for the module namespace. More precisely: +モジュールキーから整数へのマッピングを作成し、varintエンコーディングを使用して整数をシリアル化することにより、プレフィックスキーを圧縮することを検討します。バリントエンコーディングは、異なる値に共通のバイトプレフィックスがないことを保証します。マークル証明の場合、プレフィックス圧縮を使用できないため、 `SS`キーに対してのみ機能するはずです。さらに、プレフィックス圧縮はモジュール名前空間にのみ適用する必要があります。すなわち: -+ each module has it's own namespace; -+ when accessing a module namespace we create a KVStore with embedded prefix; -+ that prefix will be compressed only when accessing and managing `SS`. ++各モジュールには独自の名前空間があります。 ++モジュールの名前空間にアクセスするときに、プレフィックスが埋め込まれたKVStoreを作成します。 ++プレフィックスは、「SS」にアクセスして管理する場合にのみ圧縮されます。 -We need to assure that the codes won't change. We can fix the mapping in a static variable (provided by an app) or SS state under a special key. +コードが変更されないようにする必要があります。静的変数(アプリケーションによって提供される)またはSS状態のマッピングを特別なキーで修正できます。 -TODO: need to make decision about the key compression. +TODO:キーの圧縮を決定する必要があります。 +## 最適化:SSキー圧縮 -## Optimization: SS key compression +一部のオブジェクトは、Protobufメッセージタイプを含むキーで保存される場合があります。そのような鍵は非常に長いです。 Protobufメッセージタイプをvarintにマッピングできれば、多くのスペースを節約できます。 -Some objects may be saved with key, which contains a Protobuf message type. Such keys are long. We could save a lot of space if we can map Protobuf message types in varints. +TODO:この操作を完了するか、別のADRに移動します。 -TODO: finalize this or move to another ADR. +## 結果 -## Consequences +### 下位互換性 -### Backwards Compatibility +このADRでは、CosmosSDKレベルのAPIの変更は導入されません。 -This ADR doesn't introduce any Cosmos SDK level API changes. +ステートマシンのストレージレイアウトを変更し、これらの変更をマージするためにストレージハードフォークとネットワークのアップグレードが必要でした。 SMTはメルケル認証機能を提供しますが、ICS23とは互換性がありません。 ICS23互換性の証明を更新する必要があります。 -We change the storage layout of the state machine, a storage hard fork and network upgrade is required to incorporate these changes. SMT provides a merkle proof functionality, however it is not compatible with ICS23. Updating the proofs for ICS23 compatibility is required. +### ポジティブ -### Positive ++州と州のコミットメントを切り離すことで、さらなる最適化とより優れたストレージモデルのためのより優れたエンジニアリングの機会がもたらされます。 ++パフォーマンスの向上。 ++ IAVLよりも広く採用されていることが証明されているSMTベースのキャンプに参加してください。 SMTの採用を決定したサンプルプロジェクト:Ethereum2、Diem(Libra)、Trillan、Tezos、Celestia。 ++マルチストアの削除により、現在のマルチストア設計の長期的な問題が修正されます。 ++簡略化されたメルケル証明— IBCを除いて、すべてのモジュールには1つのメルケル証明しかありません。 -+ Decoupling state from state commitment introduce better engineering opportunities for further optimizations and better storage patterns. -+ Performance improvements. -+ Joining SMT based camp which has wider and proven adoption than IAVL. Example projects which decided on SMT: Ethereum2, Diem (Libra), Trillan, Tezos, Celestia. -+ Multistore removal fixes a longstanding issue with the current MultiStore design. -+ Simplifies merkle proofs - all modules, except IBC, have only one pass for merkle proof. +### ネガティブ -### Negative ++ストレージの移行 ++ LLSMTはプルーニングをサポートしていません-この機能を追加してテストする必要があります。 ++ `SS`キーにはキープレフィックスのオーバーヘッドがあります。 `SC`のすべてのキーは同じサイズ(ハッシュされている)であるため、これは` SC`には影響しません。 -+ Storage migration -+ LL SMT doesn't support pruning - we will need to add and test that functionality. -+ `SS` keys will have an overhead of a key prefix. This doesn't impact `SC` because all keys in `SC` have same size (they are hashed). +### ニュートラル -### Neutral ++ Cosmosホワイトペーパーの主要な提案の1つであるIAVLを廃止します。 -+ Deprecating IAVL, which is one of the core proposals of Cosmos Whitepaper. +## 代替デザイン -## Alternative designs +ほとんどの代替設計は、[State Commitments and Storage Report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)で評価されています。 -Most of the alternative designs were evaluated in [state commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h). +イーサリアムの調査が公開されました[VerkleTrie](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)-多項式のコミットメントをメルケルツリーと組み合わせて、ツリーのアイデアの高さを減らします。このコンセプトには大きな可能性がありますが、実装するには時期尚早だと思います。他の研究で必要なすべてのライブラリが実装されると、現在のSMTベースの設計をVerkleTrieに簡単に更新できます。このADRで説明されている設計の主な利点は、状態の約束をデータストレージから分離し、より強力なインターフェイスを設計することです。 -Ethereum research published [Verkle Trie](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) - an idea of combining polynomial commitments with merkle tree in order to reduce the tree height. This concept has a very good potential, but we think it's too early to implement it. The current, SMT based design could be easily updated to the Verkle Trie once other research implement all necessary libraries. The main advantage of the design described in this ADR is the separation of state commitments from the data storage and designing a more powerful interface. +## さらなる議論 -## Further Discussions +### 評価されたKVデータベース -### Evaluated KV Databases +スナップショットのサポートを評価するために使用される既存のデータベースKVデータベースを検証しました。次のデータベースは、効率的なスナップショットメカニズムを提供します:Badger、RocksDB、[Pebble](https://github.com/cockroachdb/pebble)。このようなサポートを提供していない、または本番環境の準備ができていないデータベース:boltdb、leveldb、goleveldb、membdb、lmdb。 -We verified existing databases KV databases for evaluating snapshot support. The following databases provide efficient snapshot mechanism: Badger, RocksDB, [Pebble](https://github.com/cockroachdb/pebble). Databases which don't provide such support or are not production ready: boltdb, leveldb, goleveldb, membdb, lmdb. +### リレーショナルデータベース -### RDBMS +状態を保存するには、単純なKVの代わりにRDBMSを使用します。 RDBMSを使用するには、Cosmos SDK API( `KVStore`インターフェース)に大きな変更を加える必要があり、より優れたデータ抽出およびインデックス作成ソリューションを提供します。オブジェクトを1バイトのブロックとして保存する代わりに、上記のSMTで「hash(key、protobuf(object))」として状態ストレージレイヤーのテーブルにレコードとして保存できます。 RDBMSに登録されているオブジェクトがSMTに送信されたオブジェクトと同じであることを確認するには、RDBMSからオブジェクトをロードし、protobufを使用してマーシャリング、ハッシュ、およびSMT検索を実行する必要があります。 -Use of RDBMS instead of simple KV store for state. Use of RDBMS will require a Cosmos SDK API breaking change (`KVStore` interface) and will allow better data extraction and indexing solutions. Instead of saving an object as a single blob of bytes, we could save it as record in a table in the state storage layer, and as a `hash(key, protobuf(object))` in the SMT as outlined above. To verify that an object registered in RDBMS is same as the one committed to SMT, one will need to load it from RDBMS, marshal using protobuf, hash and do SMT search. +### チェーン店 -### Off Chain Store +モジュールを使用してデータベースをサポートできるユースケースについて説明していますが、データベースは自動的に送信されません。このモジュールは、堅牢なストレージモデルを使用する役割を果たし、__オブジェクトを保存せずにオブジェクトにコミットする_セクションで説明されている機能を使用することを選択できます。 -We were discussing use case where modules can use a support database, which is not automatically committed. Module will responsible for having a sound storage model and can optionally use the feature discussed in __Committing to an object without saving it_ section. +## 参照する -## References - -+ [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100) -+ [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15 -+ [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h) -+ [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt) -+ Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf) -+ [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf), [Trillian Verifiable Data Structures](https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf). -+ Design and implementation [discussion](https://github.com/cosmos/cosmos-sdk/discussions/8297). -+ [How to Upgrade IBC Chains and their Clients](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md) -+ [ADR-40 Effect on IBC](https://github.com/cosmos/ibc-go/discussions/256) ++ [IAVL次は何ですか？ ](https://github.com/cosmos/cosmos-sdk/issues/7100) ++ [IAVLの概要](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv)v0.15 ++ [State Commitment and Storage Report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h) ++ [Celestia(LazyLedger)SMT](https://github.com/lazyledger/smt) ++ Facebook Diem(Libra)SMT [デザイン](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf) ++ [Trillian Revocation Transparency](https://github.com/google/trillian/blob/master/docs/papers/RevocationTransparency.pdf)、[Trillian Verizable Data Structure](https://github.com/google.trillian.blob/master/docs/papers/VerizableDataStructures.pdf)。 ++設計と実装[ディスカッション](https://github.com/cosmos/cosmos-sdk/discussions/8297)。 ++ [IBCチェーンとそのクライアントをアップグレードする方法](https://github.com/cosmos/ibc-go/blob/main/docs/ibc/upgrades/quick-guide.md) ++ [IBCに対するADR-40の影響](https://github.com/cosmos/ibc-go/discussions/256) \ No newline at end of file diff --git a/docs/ja/architecture/adr-041-in-place-store-migrations.md b/docs/ja/architecture/adr-041-in-place-store-migrations.md index 3eb8a078ccac..148cdafb3379 100644 --- a/docs/ja/architecture/adr-041-in-place-store-migrations.md +++ b/docs/ja/architecture/adr-041-in-place-store-migrations.md @@ -1,129 +1,129 @@ -# ADR 041: In-Place Store Migrations +# ADR 041:オンサイトストレージ移行 -## Changelog +## 変更ログ -- 17.02.2021: Initial Draft +-17.02.2021:最初のドラフト -## Status +## 状態 -Accepted +受け入れられました -## Abstract +## 概要 -This ADR introduces a mechanism to perform in-place state store migrations during chain software upgrades. +このADRは、チェーンソフトウェアのアップグレード中にインプレース状態のストレージ移行を実行するメカニズムを導入します。 -## Context +## 環境 -When a chain upgrade introduces state-breaking changes inside modules, the current procedure consists of exporting the whole state into a JSON file (via the `simd export` command), running migration scripts on the JSON file (`simd migrate` command), clearing the stores (`simd unsafe-reset-all` command), and starting a new chain with the migrated JSON file as new genesis (optionally with a custom initial block height). An example of such a procedure can be seen [in the Cosmos Hub 3->4 migration guide](https://github.com/cosmos/gaia/blob/v4.0.3/docs/migration/cosmoshub-3.md#upgrade-procedure). +チェーンのアップグレードによってモジュール内の状態に破壊的な変更が導入された場合、現在のプロセスには、状態全体をJSONファイルにエクスポートし( `simd export`コマンドを使用)、JSONで移行スクリプト(` simdmigrate`コマンド)を実行することが含まれますファイルを作成し、ストレージをクリアして( `simd unsafe-reset-all`コマンド)、移行したJSONファイルを新しい作成として使用して(カスタムの初期ブロック高さを使用することを選択できます)、新しいチェーンを開始します。 [Cosmos Hub 3-> 4移行ガイド](https://github.com/cosmos/gaia/blob/v4.0.3/docs/migration/cosmoshub-3.md#Upgradeプログラム)。 -This procedure is cumbersome for multiple reasons: +このプロセスは、さまざまな理由で面倒です。 -- The procedure takes time. It can take hours to run the `export` command, plus some additional hours to run `InitChain` on the fresh chain using the migrated JSON. -- The exported JSON file can be heavy (~100MB-1GB), making it difficult to view, edit and transfer, which in turn introduces additional work to solve these problems (such as [streaming genesis](https://github.com/cosmos/cosmos-sdk/issues/6936)). +-手続きには時間がかかります。 `export`コマンドの実行には数時間かかる場合があり、移行されたJSONを使用して新しいチェーンで` InitChain`を実行する場合はさらに時間がかかる場合があります。 +-エクスポートされたJSONファイルは重く(〜100MB-1GB)、表示、編集、転送が難しい場合があります。これにより、これらの問題を解決するための追加の作業が発生します(例:[ストリーミングジェネシス](https://github.com).cosmos .cosmos-sdk .issues .6936))。 -## Decision +## 決定 -We propose a migration procedure based on modifying the KV store in-place without involving the JSON export-process-import flow described above. +上記のJSONエクスポート-プロセス-インポートプロセスを使用せずに、KVストレージのその場での変更に基づく移行プロセスを提案します。 -### Module `ConsensusVersion` +### モジュール `ConsensusVersion` -We introduce a new method on the `AppModule` interface: +`AppModule`インターフェースに新しいメソッドを導入しました。 ```go type AppModule interface { - // --snip-- + ..--snip-- ConsensusVersion() uint64 } ``` -This methods returns an `uint64` which serves as state-breaking version of the module. It MUST be incremented on each consensus-breaking change introduced by the module. To avoid potential errors with default values, the initial version of a module MUST be set to 1. In the Cosmos SDK, version 1 corresponds to the modules in the v0.41 series. +このメソッドは、モジュールの状態破棄バージョンとしてuint64を返します。 モジュールによって導入されたコンセンサスを破る変更ごとにインクリメントする必要があります。 デフォルト値の潜在的なエラーを回避するには、モジュールの初期バージョンを1に設定する必要があります。 Cosmos SDKでは、バージョン1はv0.41シリーズのモジュールに対応しています。 -### Module-Specific Migration Functions +### モジュール固有の移行機能 -For each consensus-breaking change introduced by the module, a migration script from ConsensusVersion `N` to version `N+1` MUST be registered in the `Configurator` using its newly-added `RegisterMigration` method. All modules receive a reference to the configurator in their `RegisterServices` method on `AppModule`, and this is where the migration functions should be registered. The migration functions should be registered in increasing order. +モジュールによって導入されたコンセンサスを破る変更ごとに、新しく追加された `RegisterMigration`メソッドを使用して、ConsensusVersion`N`からバージョン` N + 1`への移行スクリプトを `Configurator`に登録する必要があります。 すべてのモジュールは、移行機能を登録する必要がある「AppModule」の「RegisterServices」メソッドでコンフィギュレーターへの参照を受け取ります。 移行機能は昇順で登録する必要があります。 ```go func (am AppModule) RegisterServices(cfg module.Configurator) { - // --snip-- + ..--snip-- cfg.RegisterMigration(types.ModuleName, 1, func(ctx sdk.Context) error { - // Perform in-place store migrations from ConsensusVersion 1 to 2. + ..Perform in-place store migrations from ConsensusVersion 1 to 2. }) cfg.RegisterMigration(types.ModuleName, 2, func(ctx sdk.Context) error { - // Perform in-place store migrations from ConsensusVersion 2 to 3. + ..Perform in-place store migrations from ConsensusVersion 2 to 3. }) - // etc. + ..etc. } ``` -For example, if the new ConsensusVersion of a module is `N` , then `N-1` migration functions MUST be registered in the configurator. +たとえば、モジュールの新しいConsensusVersionが `N`の場合、` N-1`移行機能をコンフィギュレータに登録する必要があります。 -In the Cosmos SDK, the migration functions are handled by each module's keeper, because the keeper holds the `sdk.StoreKey` used to perform in-place store migrations. To not overload the keeper, a `Migrator` wrapper is used by each module to handle the migration functions: +Cosmos SDKでは、キーパーがインプレースストレージ移行の実行に使用される `sdk.StoreKey`を保持しているため、移行機能は各モジュールのキーパーによって処理されます。 キーパーに過負荷をかけないように、各モジュールは `Migrator`ラッパーを使用して移行機能を処理します。 ```go -// Migrator is a struct for handling in-place store migrations. +/.Migrator is a struct for handling in-place store migrations. type Migrator struct { BaseKeeper } ``` -Migration functions should live inside the `migrations/` folder of each module, and be called by the Migrator's methods. We propose the format `Migrate{M}to{N}` for method names. +移行関数は、各モジュールの `migrations.`フォルダーに配置され、移行者のメソッドによって呼び出される必要があります。 メソッド名の形式は `Migrate {M} to {N}`にすることをお勧めします。 ```go -// Migrate1to2 migrates from version 1 to 2. +/.Migrate1to2 migrates from version 1 to 2. func (m Migrator) Migrate1to2(ctx sdk.Context) error { - return v043bank.MigrateStore(ctx, m.keeper.storeKey) // v043bank is package `x/bank/migrations/v043`. + return v043bank.MigrateStore(ctx, m.keeper.storeKey)..v043bank is package `x/bank/migrations/v043`. } ``` -Each module's migration functions are specific to the module's store evolutions, and are not described in this ADR. An example of x/bank store key migrations after the introduction of ADR-028 length-prefixed addresses can be seen in this [store.go code](https://github.com/cosmos/cosmos-sdk/blob/36f68eb9e041e20a5bb47e216ac5eb8b91f95471/x/bank/legacy/v043/store.go#L41-L62). +各モジュールの移行機能は、モジュールのストレージの進化に固有であり、このADRでは説明されていません。 ADR-028の長さのプレフィックスアドレスの導入後のx .bankストアキーの移行の例は、この[store.goコード](https://github.com/cosmos/cosmos-sdk/blob/36f68eb9e041e20a5bb47e216ac5eb8b91f95471.x .bank .legacy .v043 .store.go#L41-L62)。 -### Tracking Module Versions in `x/upgrade` +### `x .upgrade`でモジュールバージョンを追跡する -We introduce a new prefix store in `x/upgrade`'s store. This store will track each module's current version, it can be modelized as a `map[string]uint64` of module name to module ConsensusVersion, and will be used when running the migrations (see next section for details). The key prefix used is `0x1`, and the key/value format is: +`x .upgrade`のストレージに新しいプレフィックスストレージを導入しました。 ストレージは各モジュールの現在のバージョンを追跡し、モジュール名からモジュールConsensusVersionへの `map [string] uint64`としてモデル化でき、移行の実行時に使用されます(詳細については次のセクションを参照してください)。 使用されるキープレフィックスは `0x1`であり、キー/値の形式は次のとおりです。 ``` 0x2 | {bytes(module_name)} => BigEndian(module_consensus_version) ``` -The initial state of the store is set from `app.go`'s `InitChainer` method. +ストレージの初期状態は、 `app.go`の` InitChainer`メソッドによって設定されます。 -The UpgradeHandler signature needs to be updated to take a `VersionMap`, as well as return an upgraded `VersionMap` and an error: +UpgradeHandler署名を更新して、 `VersionMap`を取得し、アップグレードされた` VersionMap`とエラーを返す必要があります。 ```diff - type UpgradeHandler func(ctx sdk.Context, plan Plan) + type UpgradeHandler func(ctx sdk.Context, plan Plan, versionMap VersionMap) (VersionMap, error) ``` -To apply an upgrade, we query the `VersionMap` from the `x/upgrade` store and pass it into the handler. The handler runs the actual migration functions (see next section), and if successful, returns an updated `VersionMap` to be stored in state. +アップグレードを適用するには、 `x .upgrade`ストアから` VersionMap`を照会し、それをハンドラーに渡します。 ハンドラーは実際の移行関数を実行し(次のセクションを参照)、成功すると、状態に格納される更新された「VersionMap」を返します。 ```diff func (k UpgradeKeeper) ApplyUpgrade(ctx sdk.Context, plan types.Plan) { - // --snip-- + ..--snip-- - handler(ctx, plan) -+ updatedVM, err := handler(ctx, plan, k.GetModuleVersionMap(ctx)) // k.GetModuleVersionMap() fetches the VersionMap stored in state. ++ updatedVM, err := handler(ctx, plan, k.GetModuleVersionMap(ctx))..k.GetModuleVersionMap() fetches the VersionMap stored in state. + if err != nil { + return err + } + -+ // Set the updated consensus versions to state ++ ..Set the updated consensus versions to state + k.SetModuleVersionMap(ctx, updatedVM) } ``` -A gRPC query endpoint to query the `VersionMap` stored in `x/upgrade`'s state will also be added, so that app developers can double-check the `VersionMap` before the upgrade handler runs. +gRPCクエリエンドポイントも追加され、 `x .upgrade`状態で保存されている` VersionMap`をクエリします。これにより、アプリケーション開発者は、アップグレードハンドラーを実行する前に `VersionMap`を再確認できます。 -### Running Migrations +### 移行の実行 -Once all the migration handlers are registered inside the configurator (which happens at startup), running migrations can happen by calling the `RunMigrations` method on `module.Manager`. This function will loop through all modules, and for each module: +すべての移行ハンドラーがコンフィギュレーターに登録されると(起動時に発生します)、 `module.Manager`で` RunMigrations`メソッドを呼び出すことで移行を実行できます。この関数は、すべてのモジュールと各モジュールを繰り返し処理します。 -- Get the old ConsensusVersion of the module from its `VersionMap` argument (let's call it `M`). -- Fetch the new ConsensusVersion of the module from the `ConsensusVersion()` method on `AppModule` (call it `N`). -- If `N>M`, run all registered migrations for the module sequentially `M -> M+1 -> M+2...` until `N`. - - There is a special case where there is no ConsensusVersion for the module, as this means that the module has been newly added during the upgrade. In this case, no migration function is run, and the module's current ConsensusVersion is saved to `x/upgrade`'s store. +-モジュールの古いConsensusVersionを `VersionMap`パラメーターから取得します(これを` M`と呼びます)。 +-`AppModule`の `ConsensusVersion()`メソッドからモジュールの新しいConsensusVersion( `N`と呼びます)を取得します。 +-`N> M`の場合、モジュール `M-> M + 1-> M + 2 ...`の登録されたすべての移行を `N`まで実行します。 + -モジュールにConsensusVersionがない特殊なケースがあります。これは、モジュールがアップグレードプロセス中に新たに追加されたことを意味するためです。この場合、移行機能は実行されず、モジュールの現在のConsensusVersionが `x .upgrade`のストレージに保存されます。 -If a required migration is missing (e.g. if it has not been registered in the `Configurator`), then the `RunMigrations` function will error. +必要な移行が欠落している場合(たとえば、 `Configurator`に登録されていない場合)、` RunMigrations`関数はエラーを出します。 -In practice, the `RunMigrations` method should be called from inside an `UpgradeHandler`. +実際には、 `RunMigrations`メソッドは` UpgradeHandler`内から呼び出す必要があります。 ```go app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgradetypes.Plan, vm module.VersionMap) (module.VersionMap, error) { @@ -131,37 +131,36 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -Assuming a chain upgrades at block `n`, the procedure should run as follows: +チェーンがブロックnでアップグレードされたとすると、プログラムは次のように実行されます。 -- the old binary will halt in `BeginBlock` when starting block `N`. In its store, the ConsensusVersions of the old binary's modules are stored. -- the new binary will start at block `N`. The UpgradeHandler is set in the new binary, so will run at `BeginBlock` of the new binary. Inside `x/upgrade`'s `ApplyUpgrade`, the `VersionMap` will be retrieved from the (old binary's) store, and passed into the `RunMigrations` functon, migrating all module stores in-place before the modules' own `BeginBlock`s. +-ブロック「N」を開始すると、古いバイナリファイルは「BeginBlock」で停止します。そのストレージには、古いバイナリモジュールのコンセンサスバージョンが保存されます。 +-新しいバイナリファイルはブロック「N」から始まります。 UpgradeHandlerは新しいバイナリファイルに設定されているため、新しいバイナリファイルの「BeginBlock」で実行されます。 `x .upgrade`の` ApplyUpgrade`では、 `VersionMap`が(古いバイナリ)ストレージから取得され、` RunMigrations`関数に渡されて、モジュール自体の `BeginBlockの前にすべてのモジュールストレージ`が移行されます。 -## Consequences +## 結果 -### Backwards Compatibility +### 下位互換性 -This ADR introduces a new method `ConsensusVersion()` on `AppModule`, which all modules need to implement. It also alters the UpgradeHandler function signature. As such, it is not backwards-compatible. +このADRは、 `AppModule`に新しいメソッド` ConsensusVersion() `を導入し、すべてのモジュールがこのメソッドを実装する必要があります。また、UpgradeHandler関数のシグネチャも変更します。したがって、下位互換性はありません。 -While modules MUST register their migration functions when bumping ConsensusVersions, running those scripts using an upgrade handler is optional. An application may perfectly well decide to not call the `RunMigrations` inside its upgrade handler, and continue using the legacy JSON migration path. +モジュールはConsensusVersionsと衝突するときに移行関数を登録する必要がありますが、アップグレードハンドラーを使用してこれらのスクリプトを実行することはオプションです。アプリケーションは、アップグレードハンドラーで `RunMigrations`を呼び出さず、代わりに古いJSON移行パスを引き続き使用することを決定する可能性があります。 -### Positive +### ポジティブ -- Perform chain upgrades without manipulating JSON files. -- While no benchmark has been made yet, it is probable that in-place store migrations will take less time than JSON migrations. The main reason supporting this claim is that both the `simd export` command on the old binary and the `InitChain` function on the new binary will be skipped. +-JSONファイルを操作せずにチェーンのアップグレードを実行します。 +-ベースラインは確立されていませんが、インプレースストレージ移行はJSON移行よりも時間がかからない場合があります。このステートメントをサポートする主な理由は、古いバイナリファイルの `simdexport`コマンドと新しいバイナリファイルの` InitChain`関数がスキップされるためです。 -### Negative +### ネガティブ -- Module developers MUST correctly track consensus-breaking changes in their modules. If a consensus-breaking change is introduced in a module without its corresponding `ConsensusVersion()` bump, then the `RunMigrations` function won't detect the migration, and the chain upgrade might be unsuccessful. Documentation should clearly reflect this. +-モジュール開発者は、コンセンサスを破るモジュールの変更を正しく追跡する必要があります。対応する `ConsensusVersion()`バンプなしでコンセンサスを破る変更がモジュールに導入された場合、 `RunMigrations`関数は移行を検出せず、チェーンのアップグレードが失敗する可能性があります。ドキュメントはこれを明確に反映している必要があります。 -### Neutral +### ニュートラル -- The Cosmos SDK will continue to support JSON migrations via the existing `simd export` and `simd migrate` commands. -- The current ADR does not allow creating, renaming or deleting stores, only modifying existing store keys and values. The Cosmos SDK already has the `StoreLoader` for those operations. +-Cosmos SDKは、既存の `simdexport`および` simdmigrate`コマンドによるJSON移行を引き続きサポートします。 +-現在のADRでは、ストレージの作成、名前の変更、削除は許可されていません。変更できるのは、既存のストレージキーと値のみです。 Cosmos SDKは、これらの操作に `StoreLoader`を提供しています。 +## さらなる議論 -## Further Discussions +## 参照 -## References - -- Initial discussion: https://github.com/cosmos/cosmos-sdk/discussions/8429 -- Implementation of `ConsensusVersion` and `RunMigrations`: https://github.com/cosmos/cosmos-sdk/pull/8485 -- Issue discussing `x/upgrade` design: https://github.com/cosmos/cosmos-sdk/issues/8514 +-予備的なディスカッション:https://github.com/cosmos/cosmos-sdk/discussions/8429 +-`ConsensusVersion`と `RunMigrations`の実装:https://github.com/cosmos/cosmos-sdk/pull/8485 +-`x .upgrade`デザインの問題について話し合います:https://github.com/cosmos/cosmos-sdk/issues/8514 \ No newline at end of file diff --git a/docs/ja/architecture/adr-042-group-module.md b/docs/ja/architecture/adr-042-group-module.md index 2907c7305aa8..00a0fc94d3f2 100644 --- a/docs/ja/architecture/adr-042-group-module.md +++ b/docs/ja/architecture/adr-042-group-module.md @@ -1,64 +1,64 @@ -# ADR 042: Group Module +# ADR 042:グループモジュール -## Changelog +## 変更ログ -- 2020/04/09: Initial Draft +-2020/04/09:最初のドラフト -## Status +## 状態 -Draft +下書き -## Abstract +## 概要 -This ADR defines the `x/group` module which allows the creation and management of on-chain multi-signature accounts and enables voting for message execution based on configurable decision policies. +ADRは、「x .group」モジュールを定義します。これにより、チェーン上のマルチシグニチャアカウントの作成と管理が可能になり、構成可能な決定ポリシーに基づいてメッセージ実行に投票できるようになります。 -## Context +## 環境 -The legacy amino multi-signature mechanism of the Cosmos SDK has certain limitations: +Cosmos SDKによって残されたアミノマルチシグニチャメカニズムには、特定の制限があります。 -- Key rotation is not possible, although this can be solved with [account rekeying](adr-034-account-rekeying.md). -- Thresholds can't be changed. -- UX is cumbersome for non-technical users ([#5661](https://github.com/cosmos/cosmos-sdk/issues/5661)). -- It requires `legacy_amino` sign mode ([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141)). +-キーのローテーションはできませんが、[アカウントのキーの再生成](adr-034-account-rekeying.md)で解決できます。 +-しきい値は変更できません。 +-UXは、技術者以外のユーザーにとっては厄介です([#5661](https://github.com/cosmos/cosmos-sdk/issues/5661))。 +-`legacy_amino`シンボルパターン([#8141](https://github.com/cosmos/cosmos-sdk/issues/8141))が必要です。 -While the group module is not meant to be a total replacement for the current multi-signature accounts, it provides a solution to the limitations described above, with a more flexible key management system where keys can be added, updated or removed, as well as configurable thresholds. -It's meant to be used with other access control modules such as [`x/feegrant`](./adr-029-fee-grant-module.md) ans [`x/authz`](adr-030-authz-module.md) to simplify key management for individuals and organizations. +グループモジュールは、現在のマルチ署名アカウントを完全に置き換えることを意図したものではありませんが、上記の制限を解決する方法を提供し、キーを追加、更新、または削除できる、より柔軟なキー管理システムと、構成可能なしきい値を備えています。 +[`x .feegrant`](..adr-029-fee-grant-module.md)ans [` x .authz`](adr-030-authz)などの他のアクセス制御モジュールで使用することを目的としています。 -module .md)個人および組織のキー管理を簡素化します。 -The proof of concept of the group module can be found in https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1 and https://github.com/regen-network/regen-ledger/tree/master/x/group. +グループモジュールの概念実証は、https://github.com/regen-network/regen-ledger/tree/master/proto/regen/group/v1alpha1およびhttps://github.com/regen-にあります。 network .regen-ledger .tree .master .x .group。 -## Decision +## 決定 -We propose merging the `x/group` module with its supporting [ORM/Table Store package](https://github.com/regen-network/regen-ledger/tree/master/orm) ([#7098](https://github.com/cosmos/cosmos-sdk/issues/7098)) into the Cosmos SDK and continuing development here. There will be a dedicated ADR for the ORM package. +`x .group`モジュールをサポートされている[ORM .Table Storeパッケージ](https://github.com/regen-network/regen-ledger/tree/master/orm)([#7098](https ://github.com/cosmos/cosmos-sdk/issues/7098))Cosmos SDKに入り、ここで開発を続行します。 ORMパッケージには専用のADRがあります。 -### Group +### グループ -A group is a composition of accounts with associated weights. It is not -an account and doesn't have a balance. It doesn't in and of itself have any -sort of voting or decision weight. -Group members can create proposals and vote on them through group accounts using different decision policies. +グループは、関連する重みを持つアカウントの組み合わせです。そうではない +アカウントと残高なし。何もありません +特定の投票の重みまたは決定の重み。 +グループメンバーは、さまざまな意思決定戦略を使用して提案を作成し、グループアカウントを通じて投票することができます。 -It has an `admin` account which can manage members in the group, update the group -metadata and set a new admin. +グループメンバーを管理し、グループを更新できる「admin」アカウントがあります +メタデータを作成し、新しい管理者を設定します。 ```proto message GroupInfo { - // group_id is the unique ID of this group. + ..group_id is the unique ID of this group. uint64 group_id = 1; - // admin is the account address of the group's admin. + ..admin is the account address of the group's admin. string admin = 2; - // metadata is any arbitrary metadata to attached to the group. + ..metadata is any arbitrary metadata to attached to the group. bytes metadata = 3; - // version is used to track changes to a group's membership structure that - // would break existing proposals. Whenever a member weight has changed, - // or any member is added or removed, the version is incremented and will - // invalidate all proposals from older versions. + ..version is used to track changes to a group's membership structure that + ..would break existing proposals. Whenever a member weight has changed, + ..or any member is added or removed, the version is incremented and will + ..invalidate all proposals from older versions. uint64 version = 4; - // total_weight is the sum of the group members' weights. + ..total_weight is the sum of the group members' weights. string total_weight = 5; } ``` @@ -66,84 +66,84 @@ message GroupInfo { ```proto message GroupMember { - // group_id is the unique ID of the group. + ..group_id is the unique ID of the group. uint64 group_id = 1; - // member is the member data. + ..member is the member data. Member member = 2; } -// Member represents a group member with an account address, -// non-zero weight and metadata. +/.Member represents a group member with an account address, +/.non-zero weight and metadata. message Member { - // address is the member's account address. + ..address is the member's account address. string address = 1; - // weight is the member's voting weight that should be greater than 0. + ..weight is the member's voting weight that should be greater than 0. string weight = 2; - // metadata is any arbitrary metadata to attached to the member. + ..metadata is any arbitrary metadata to attached to the member. bytes metadata = 3; } ``` -### Group Account +### グループアカウント -A group account is an account associated with a group and a decision policy. -A group account does have a balance. +グループアカウントは、グループおよび意思決定戦略に関連付けられたアカウントです。 +グループアカウントには残高があります。 -Group accounts are abstracted from groups because a single group may have -multiple decision policies for different types of actions. Managing group -membership separately from decision policies results in the least overhead -and keeps membership consistent across different policies. The pattern that -is recommended is to have a single master group account for a given group, -and then to create separate group accounts with different decision policies -and delegate the desired permissions from the master account to -those "sub-accounts" using the [`x/authz` module](adr-030-authz-module.md). +単一のグループが持っている可能性があるため、グループアカウントはグループから抽象化されます +さまざまなタイプのアクションに対する複数の意思決定戦略。 経営陣 +意思決定戦略とは別のメンバーシップは、最小限のオーバーヘッドにつながります +また、さまざまなポリシーで一貫したメンバーシップを維持します。 そのパターン +特定のグループのプライマリグループアカウントを設定することをお勧めします。 +次に、異なる意思決定戦略で個別のグループアカウントを作成します +そして、必要な権限をマスターアカウントからに委任します +[`x .authz`モジュール](adr-030-authz-module.md)を使用する「サブアカウント」。 ```proto message GroupAccountInfo { - // address is the group account address. + ..address is the group account address. string address = 1; - // group_id is the ID of the Group the GroupAccount belongs to. + ..group_id is the ID of the Group the GroupAccount belongs to. uint64 group_id = 2; - // admin is the account address of the group admin. + ..admin is the account address of the group admin. string admin = 3; - // metadata is any arbitrary metadata of this group account. + ..metadata is any arbitrary metadata of this group account. bytes metadata = 4; - // version is used to track changes to a group's GroupAccountInfo structure that - // invalidates active proposal from old versions. + ..version is used to track changes to a group's GroupAccountInfo structure that + ..invalidates active proposal from old versions. uint64 version = 5; - // decision_policy specifies the group account's decision policy. + ..decision_policy specifies the group account's decision policy. google.protobuf.Any decision_policy = 6 [(cosmos_proto.accepts_interface) = "DecisionPolicy"]; } ``` -Similarly to a group admin, a group account admin can update its metadata, decision policy or set a new group account admin. +グループ管理者と同様に、グループアカウント管理者は、メタデータ、意思決定ポリシーを更新したり、新しいグループアカウント管理者を設定したりできます。 -A group account can also be an admin or a member of a group. -For instance, a group admin could be another group account which could "elects" the members or it could be the same group that elects itself. +グループアカウントは、管理者またはグループメンバーになることもできます。 +たとえば、グループ管理者は、メンバーを「選出」できる別のグループアカウントにすることも、自分自身を選出する同じグループにすることもできます。 -### Decision Policy +### 決定ポリシー -A decision policy is the mechanism by which members of a group can vote on -proposals. +意思決定戦略は、グループメンバーが投票できるメカニズムです。 +提案。 -All decision policies should have a minimum and maximum voting window. -The minimum voting window is the minimum duration that must pass in order -for a proposal to potentially pass, and it may be set to 0. The maximum voting -window is the maximum time that a proposal may be voted on and executed if -it reached enough support before it is closed. -Both of these values must be less than a chain-wide max voting window parameter. +すべての意思決定戦略には、最小および最大の投票ウィンドウが必要です。 +最小投票ウィンドウは、順番に通過する必要がある最短の期間です +提案の可能性があるため、0に設定できます。 最大投票数 +ウィンドウは、プロポーザルに投票して実行できる最大時間です。 +閉店前に十分なサポートを受けました。 +これらの値は両方とも、チェーン全体の最大投票ウィンドウパラメータよりも小さくする必要があります。 -We define the `DecisionPolicy` interface that all decision policies must implement: +すべての決定ポリシーが実装する必要がある `DecisionPolicy`インターフェースを定義します。 ```go type DecisionPolicy interface { @@ -161,119 +161,119 @@ type DecisionPolicyResult struct { } ``` -#### Threshold decision policy +#### しきい値決定戦略 -A threshold decision policy defines a minimum support votes (_yes_), based on a tally -of voter weights, for a proposal to pass. For -this decision policy, abstain and veto are treated as no support (_no_). +しきい値決定戦略は、カウントに基づいてサポート投票の最小数を定義します(_yes_) +有権者は提案に合格するように加重されます。 にとって +この決定ポリシー、棄権、拒否権はサポートされていないと見なされます(_no_)。 ```proto message ThresholdDecisionPolicy { - // threshold is the minimum weighted sum of support votes for a proposal to succeed. + ..threshold is the minimum weighted sum of support votes for a proposal to succeed. string threshold = 1; - // voting_period is the duration from submission of a proposal to the end of voting period - // Within this period, votes and exec messages can be submitted. + ..voting_period is the duration from submission of a proposal to the end of voting period + ..Within this period, votes and exec messages can be submitted. google.protobuf.Duration voting_period = 2 [(gogoproto.nullable) = false]; } ``` -### Proposal +### 提案 -Any member of a group can submit a proposal for a group account to decide upon. -A proposal consists of a set of `sdk.Msg`s that will be executed if the proposal -passes as well as any metadata associated with the proposal. These `sdk.Msg`s get validated as part of the `Msg/CreateProposal` request validation. They should also have their signer set as the group account. +グループのメンバーは誰でも、グループアカウントが決定するための提案を提出できます。 +提案の場合、提案は一連の `sdk.Msg`で構成されます +パスと提案に関連するメタデータ。 これらの `sdk.Msg`は、` Msg .CreateProposal`リクエスト検証の一部として検証されます。 また、署名者をグループアカウントとして設定する必要があります。 -Internally, a proposal also tracks: +内部的には、提案は以下も追跡します。 -- its current `Status`: submitted, closed or aborted -- its `Result`: unfinalized, accepted or rejected -- its `VoteState` in the form of a `Tally`, which is calculated on new votes and when executing the proposal. +-現在の「ステータス」:送信済み、クローズ済み、または中止済み +-その「結果」:不完全、承認、または拒否 +-その「VoteState」は「Tally」の形式であり、新しい投票と提案の実行に基づいて計算されます。 ```proto -// Tally represents the sum of weighted votes. +/.Tally represents the sum of weighted votes. message Tally { option (gogoproto.goproto_getters) = false; - // yes_count is the weighted sum of yes votes. + ..yes_count is the weighted sum of yes votes. string yes_count = 1; - // no_count is the weighted sum of no votes. + ..no_count is the weighted sum of no votes. string no_count = 2; - // abstain_count is the weighted sum of abstainers. + ..abstain_count is the weighted sum of abstainers. string abstain_count = 3; - // veto_count is the weighted sum of vetoes. + ..veto_count is the weighted sum of vetoes. string veto_count = 4; } ``` -### Voting +### 投票 -Members of a group can vote on proposals. There are four choices to choose while voting - yes, no, abstain and veto. Not -all decision policies will support them. Votes can contain some optional metadata. -In the current implementation, the voting window begins as soon as a proposal -is submitted. +グループメンバーは提案に投票できます。投票するときは、「はい」、「いいえ」、「棄権」、「拒否」の4つの選択肢があります。いいえ +すべての意思決定ポリシーがそれらをサポートします。投票には、オプションのメタデータを含めることができます。 +現在の実装では、投票ウィンドウは提案の直後に開始されます +提出されました。 -Voting internally updates the proposal `VoteState` as well as `Status` and `Result` if needed. +必要に応じて、投票により提案「VoteState」と「Status」および「Result」が内部で更新されます。 -### Executing Proposals +### 提案を実行する -Proposals will not be automatically executed by the chain in this current design, -but rather a user must submit a `Msg/Exec` transaction to attempt to execute the -proposal based on the current votes and decision policy. A future upgrade could -automate this and have the group account (or a fee granter) pay. +現在の設計では、チェーンは提案を自動的に実行しません。 +代わりに、ユーザーは実行を試みるために `Msg .Exec`トランザクションを送信する必要があります +現在の投票および意思決定方針に基づく提案。将来のアップグレードの可能性 +これを自動的に行い、グループアカウント(または手数料の付与者)に支払いを依頼します。 -#### Changing Group Membership +#### グループメンバーシップを変更する -In the current implementation, updating a group or a group account after submitting a proposal will make it invalid. It will simply fail if someone calls `Msg/Exec` and will eventually be garbage collected. +現在の実装では、提案を送信した後にグループまたはグループアカウントを更新すると、それが無効になります。誰かが `Msg .Exec`を呼び出すと、失敗するだけで、最終的にはガベージコレクションされます。 -### Notes on current implementation +### 現在の実装に関する注意 -This section outlines the current implementation used in the proof of concept of the group module but this could be subject to changes and iterated on. +このセクションでは、グループモジュールの概念実証で使用されている現在の実装の概要を説明しますが、これは変更および反復される可能性があります。 #### ORM -The [ORM package](https://github.com/cosmos/cosmos-sdk/discussions/9156) defines tables, sequences and secondary indexes which are used in the group module. +[ORMパッケージ](https://github.com/cosmos/cosmos-sdk/discussions/9156)は、グループモジュールで使用されるテーブル、シーケンス、およびセカンダリインデックスを定義します。 -Groups are stored in state as part of a `groupTable`, the `group_id` being an auto-increment integer. Group members are stored in a `groupMemberTable`. +グループは「groupTable」の一部として状態に格納され、「group_id」は自動インクリメント整数です。グループメンバーは「groupMemberTable」に保存されます。 -Group accounts are stored in a `groupAccountTable`. The group account address is generated based on an auto-increment integer which is used to derive the group module `RootModuleKey` into a `DerivedModuleKey`, as stated in [ADR-033](adr-033-protobuf-inter-module-comm.md#modulekeys-and-moduleids). The group account is added as a new `ModuleAccount` through `x/auth`. +グループアカウントは「groupAccountTable」に保存されます。グループアカウントアドレスは、自動インクリメント整数に基づいて生成されます。この整数は、グループモジュール `RootModuleKey`を[ADR-033](adr-033-protobuf-inter-module-commなどの` DerivedModuleKey`に派生させるために使用されます。 md#modulekeys-および-moduleids)。グループアカウントは、 `x .auth`を介して新しい` ModuleAccount`として追加されます。 -Proposals are stored as part of the `proposalTable` using the `Proposal` type. The `proposal_id` is an auto-increment integer. +プロポーザルは、「proposalTable」の一部として保存される「Proposal」タイプを使用します。 `proposal_id`は自動インクリメント整数です。 -Votes are stored in the `voteTable`. The primary key is based on the vote's `proposal_id` and `voter` account address. +投票は「voteTable」に保存されます。主キーは、投票された `proposal_id`と` voter`アカウントアドレスに基づいています。 -#### ADR-033 to route proposal messages +#### ADR-033プロポーザルニュースによるルート -Inter-module communication introduced by [ADR-033](adr-033-protobuf-inter-module-comm.md) can be used to route a proposal's messages using the `DerivedModuleKey` corresponding to the proposal's group account. +[ADR-033](adr-033-protobuf-inter-module-comm.md)導入されたモジュール間通信は、プロポーザルのグループアカウントに対応する「DerivedModuleKey」を使用してプロポーザルのメッセージをルーティングするために使用できます。 -## Consequences +## 結果 -### Positive +### ポジティブ -- Improved UX for multi-signature accounts allowing key rotation and custom decision policies. +-マルチ署名アカウントのUXを改善し、キーローテーションとカスタム意思決定戦略を可能にしました。 -### Negative +### ネガティブ -### Neutral +### ニュートラル -- It uses ADR 033 so it will need to be implemented within the Cosmos SDK, but this doesn't imply necessarily any large refactoring of existing Cosmos SDK modules. -- The current implementation of the group module uses the ORM package. +-ADR 033を使用しているため、Cosmos SDKに実装する必要がありますが、これは既存のCosmosSDKモジュールの大規模なリファクタリングを意味するものではありません。 +-グループモジュールの現在の実装では、ORMパッケージを使用しています。 -## Further Discussions +## さらなる議論 -- Convergence of `/group` and `x/gov` as both support proposals and voting: https://github.com/cosmos/cosmos-sdk/discussions/9066 -- `x/group` possible future improvements: - - Execute proposals on submission (https://github.com/regen-network/regen-ledger/issues/288) - - Withdraw a proposal (https://github.com/regen-network/cosmos-modules/issues/41) - - Make `Tally` more flexible and support non-binary choices +-` .group`と `x .gov`は、提案と投票の収束をサポートするために使用されます:https://github.com/cosmos/cosmos-sdk/discussions/9066 +-`x .group`の将来の改善の可能性: + -提出時に提案を実行します(https://github.com/regen-network/regen-ledger/issues/288) + -提案を撤回します(https://github.com/regen-network/cosmos-modules/issues/41) + -「タリー」をより柔軟にし、非バイナリオプションをサポートします -## References +## 参照する -- Initial specification: - - https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#group-module - - [#5236](https://github.com/cosmos/cosmos-sdk/pull/5236) -- Proposal to add `x/group` into the Cosmos SDK: [#7633](https://github.com/cosmos/cosmos-sdk/issues/7633) +-初期仕様: + -https://gist.github.com/aaronc/b60628017352df5983791cad30babe56#group-module + -[#5236](https://github.com/cosmos/cosmos-sdk/pull/5236) +-CosmosSDKに `x .group`を追加する提案:[#7633](https://github.com/cosmos/cosmos-sdk/issues/7633) \ No newline at end of file diff --git a/docs/ja/architecture/adr-043-nft-module.md b/docs/ja/architecture/adr-043-nft-module.md index cf07070c3fee..8559f1f9bdf2 100644 --- a/docs/ja/architecture/adr-043-nft-module.md +++ b/docs/ja/architecture/adr-043-nft-module.md @@ -1,65 +1,65 @@ -# ADR 43: NFT Module +# ADR 43:NFTモジュール -## Changelog +## 変更ログ -- 2021-05-01: Initial Draft -- 2021-07-02: Review updates +-2021-05-01:最初のドラフト +-2021-07-02:レビューの更新 -## Status +## 状態 -PROPOSED +提案 -## Abstract +## 概要 -This ADR defines the `x/nft` module which is a generic implementation of NFTs, roughly "compatible" with ERC721. **Applications using the `x/nft` module must implement the following functions**: +ADRは `x .nft`モジュールを定義します。これは、NFTの一般的な実装であり、ERC721とほぼ「互換性があります」。 ** `x .nft`モジュールを使用するアプリは、次の機能を実装する必要があります**: -- `MsgNewClass` - Receive the user's request to create a class, and call the `NewClass` of the `x/nft` module. -- `MsgUpdateClass` - Receive the user's request to update a class, and call the `UpdateClass` of the `x/nft` module. -- `MsgMintNFT` - Receive the user's request to mint a nft, and call the `MintNFT` of the `x/nft` module. -- `BurnNFT` - Receive the user's request to burn a nft, and call the `BurnNFT` of the `x/nft` module. -- `UpdateNFT` - Receive the user's request to update a nft, and call the `UpdateNFT` of the `x/nft` module. +-`MsgNewClass`-クラスを作成するというユーザーのリクエストを受け取り、 `x .nft`モジュールの` NewClass`を呼び出します。 +-`MsgUpdateClass`-ユーザーの更新クラス要求を受け取り、 `x .nft`モジュールの` UpdateClass`を呼び出します。 +-`MsgMintNFT`-nftを作成するユーザーの要求を受け取り、 `x .nft`モジュールの` MintNFT`を呼び出します。 +-`BurnNFT`-ユーザーの書き込みnftリクエストを受信し、 `x .nft`モジュールの` BurnNFT`を呼び出します。 +-`UpdateNFT`-nftを更新するユーザーの要求を受け取り、 `x .nft`モジュールの` UpdateNFT`を呼び出します。 -## Context +## 環境 -NFTs are more than just crypto art, which is very helpful for accruing value to the Cosmos ecosystem. As a result, Cosmos Hub should implement NFT functions and enable a unified mechanism for storing and sending the ownership representative of NFTs as discussed in https://github.com/cosmos/cosmos-sdk/discussions/9065. +NFTは単なる暗号技術ではなく、Cosmosエコシステムの価値を蓄積するのに非常に役立ちます。したがって、https://github.com/cosmos/cosmos-sdk/discussions/9065で説明されているように、Cosmos HubはNFT機能を実装し、統合メカニズムがNFTの所有権を保存して送信できるようにする必要があります。 -As discussed in [#9065](https://github.com/cosmos/cosmos-sdk/discussions/9065), several potential solutions can be considered: +[#9065](https://github.com/cosmos/cosmos-sdk/discussions/9065)で説明されているように、いくつかの考えられる解決策を検討できます。 -- irismod/nft and modules/incubator/nft -- CW721 -- DID NFTs -- interNFT +-irismod .nftおよびmodule .incubator .nft +-CW721 +-NFTを行う +-クロスNFT -Since functions/use cases of NFTs are tightly connected with their logic, it is almost impossible to support all the NFTs' use cases in one Cosmos SDK module by defining and implementing different transaction types. +NFTの機能/ユースケースはロジックと密接に関連しているため、さまざまなトランザクションタイプを定義して実装することにより、1つのCosmosSDKモジュールでNFTのすべてのユースケースをサポートすることはほとんど不可能です。 -Considering generic usage and compatibility of interchain protocols including IBC and Gravity Bridge, it is preferred to have a generic NFT module design which handles the generic NFTs logic. -This design idea can enable composability that application-specific functions should be managed by other modules on Cosmos Hub or on other Zones by importing the NFT module. +IBCやGravityBridgeを含むチェーン間プロトコルの一般的な使用法と互換性を考慮すると、一般的なNFTロジックを処理するために一般的なNFTモジュール設計を採用するのが最善です。 +この設計アイデアは、構成可能性を実現できます。つまり、NFTモジュールをインポートすることにより、特定のアプリケーションの機能をCosmosハブまたは他のゾーンの他のモジュールで管理する必要があります。 -The current design is based on the work done by [IRISnet team](https://github.com/irisnet/irismod/tree/master/modules/nft) and an older implementation in the [Cosmos repository](https://github.com/cosmos/modules/tree/master/incubator/nft). +現在の設計は、[IRISnetチーム](https://github.com/irisnet/irismod/tree/master/modules/nft)と[Cosmosリポジトリ](https://github.com/cosmos/modules/tree)に基づいています。 .master .incubator .nft)。 -## Decision +## 決定 -We create a `x/nft` module, which contains the following functionality: +次の関数を含む `x .nft`モジュールを作成しました。 -- Store NFTs and track their ownership. -- Expose `Keeper` interface for composing modules to transfer, mint and burn NFTs. -- Expose external `Message` interface for users to transfer ownership of their NFTs. -- Query NFTs and their supply information. +-NFTを保存し、その所有権を追跡します。 +-パブリック `Keeper`インターフェース。モジュールを組み合わせて、NFTを送信、キャスト、および書き込むために使用されます。 +-ユーザーがNFTの所有権を譲渡するための外部「メッセージ」インターフェースを開きます。 +-NFTとその供給情報についてお問い合わせください。 -The proposed module is a base module for NFT app logic. It's goal it to provide a common layer for storage, basic transfer functionality and IBC. The module should not be used as a standalone. -Instead an app should create a specialized module to handle app specific logic (eg: NFT ID construction, royalty), user level minting and burning. Moreover an app specialized module should handle auxiliary data to support the app logic (eg indexes, ORM, business data). +提案されたモジュールは、NFTアプリケーションロジックの基本モジュールです。その目標は、ストレージ、基本的な伝送機能、およびIBCに共通のレイヤーを提供することです。このモジュールは単独で使用しないでください。 +代わりに、アプリケーションは、アプリケーション固有のロジック(NFT IDの構築、使用料など)、ユーザーレベルのキャスト、および書き込みを処理するための専用モジュールを作成する必要があります。さらに、アプリケーション固有のモジュールは、アプリケーションロジック(インデックス、ORM、ビジネスデータなど)をサポートするために補助データを処理する必要があります。 -All data carried over IBC must be part of the `NFT` or `Class` type described below. The app specific NFT data should be encoded in `NFT.data` for cross-chain integrity. Other objects related to NFT, which are not important for integrity can be part of the app specific module. +IBCで伝送されるすべてのデータは、以下で説明する「NFT」または「クラス」タイプの一部である必要があります。クロスチェーンの整合性を実現するには、アプリケーション固有のNFTデータを「NFT.data」にエンコードする必要があります。完全性にとって重要ではないNFTに関連する他のオブジェクトは、アプリケーションの特定のモジュールの一部である可能性があります。 -### Types +### タイプ -We propose two main types: -+ `Class` -- describes NFT class. We can think about it as a smart contract address. -+ `NFT` -- object representing unique, non fungible asset. Each NFT is associated with a Class. +主に2つのタイプをお勧めします。 ++ `Class`-NFTクラスについて説明します。スマートコントラクトアドレスと考えることができます。 ++ `NFT`-ユニークでかけがえのない資産を表すオブジェクト。各NFTはクラスに関連付けられています。 -#### Class +#### クラス -NFT **Class** is comparable to an ERC-721 smart contract (provides description of a smart contract), under which a collection of NFTs can be created and managed. +NFT **クラス**はERC-721スマートコントラクト(スマートコントラクトの説明を提供します)に似ており、その下でNFTのコレクションを作成および管理できます。 ```protobuf message Class { @@ -73,17 +73,17 @@ message Class { } ``` -- `id` is an alphanumeric identifier of the NFT class; it is used as the primary index for storing the class; _required_ -- `name` is a descriptive name of the NFT class; _optional_ -- `symbol` is the symbol usually shown on exchanges for the NFT class; _optional_ -- `description` is a detailed description of the NFT class; _optional_ -- `uri` is a URI for the class metadata stored off chain. It should be a JSON file that contains metadata about the NFT class and NFT data schema ([OpenSea example](https://docs.opensea.io/docs/contract-level-metadata)); _optional_ -- `uri_hash` is a hash of the document pointed by uri; _optional_ -- `data` is app specific metadata of the class; _optional_ +-`id`はNFTクラスの英数字の識別子であり、ストレージクラスのメインインデックスとして使用されます; _Required_ +-`name`はNFTクラスの説明的な名前です; _optional_ +-`symbol`は通常NFT取引所に表示されるシンボルです; _optional_ +-`description`はNFTクラスの詳細な説明です; _optional_ +-`uri`は、チェーンの下に格納されているクラスメタデータのURIです。 NFTクラスとNFTデータモデルに関するメタデータを含むJSONファイルである必要があります([OpenSeaの例](https://docs.opensea.io/docs/contract-level-metadata)); _optional_ +-`uri_hash`は、uriが指すドキュメントのハッシュ値です; _optional_ +-`data`は、クラスのアプリケーション固有のメタデータです。_optional_ #### NFT -We define a general model for `NFT` as follows. +以下に示すように、「NFT」の一般的なモデルを定義しました。 ```protobuf message NFT { @@ -95,28 +95,28 @@ message NFT { } ``` -- `class_id` is the identifier of the NFT class where the NFT belongs; _required_ -- `id` is an alphanumeric identifier of the NFT, unique within the scope of its class. It is specified by the creator of the NFT and may be expanded to use DID in the future. `class_id` combined with `id` uniquely identifies an NFT and is used as the primary index for storing the NFT; _required_ +-`class_id`は、NFTが属するNFTクラスの識別子です。_Required_ +-`id`は、NFTの英数字の識別子であり、そのクラス範囲内で一意です。 これはNFTの作成者によって指定され、将来DIDを使用するように拡張される可能性があります。 `class_id`を` id`と組み合わせて、NFTを格納するためのメインインデックスとしてNFTを一意に識別します; _Required_ ``` {class_id}/{id} --> NFT (bytes) ``` -- `uri` is a URI for the NFT metadata stored off chain. Should point to a JSON file that contains metadata about this NFT (Ref: [ERC721 standard and OpenSea extension](https://docs.opensea.io/docs/metadata-standards)); _required_ -- `uri_hash` is a hash of the document pointed by uri; _optional_ -- `data` is an app specific data of the NFT. CAN be used by composing modules to specify additional properties of the NFT; _optional_ +-`uri`は、チェーンの下に保存されているNFTメタデータのURIです。 このNFTに関するメタデータを含むJSONファイルを指す必要があります(参照:[ERC721標準およびOpenSea拡張機能](https://docs.opensea.io/docs/metadata-standards)); _Required_ +-`uri_hash`は、uriが指すドキュメントのハッシュ値です; _optional_ +-`data`はNFTのアプリケーション固有のデータです。 組み合わせたモジュールを使用して、NFTの追加属性を指定できます; _optional_ -This ADR doesn't specify values that `data` can take; however, best practices recommend upper-level NFT modules clearly specify their contents. Although the value of this field doesn't provide the additional context required to manage NFT records, which means that the field can technically be removed from the specification, the field's existence allows basic informational/UI functionality. +このADRは、 `data`が取ることができる値を指定しませんが、ベストプラクティスでは、上位レベルのNFTモジュールがその内容を明示的に指定することをお勧めします。 このフィールドの値は、NFTレコードを管理するために必要な追加のコンテキストを提供しません。つまり、このフィールドは仕様から技術的に削除できますが、このフィールドの存在により、基本的な情報.UI機能が可能になります。 -### `Keeper` Interface +### `Keeper`インターフェース ```go type Keeper interface { NewClass(class Class) UpdateClass(class Class) - Mint(nft NFT，receiver sdk.AccAddress) // updates totalSupply - Burn(classId string, nftId string) // updates totalSupply + Mint(nft NFT，receiver sdk.AccAddress) ..updates totalSupply + Burn(classId string, nftId string) ..updates totalSupply Update(nft NFT) Transfer(classId string, nftId string, receiver sdk.AccAddress) @@ -133,7 +133,7 @@ type Keeper interface { } ``` -Other business logic implementations should be defined in composing modules that import `x/nft` and use its `Keeper`. +他のビジネスロジックの実装は、 `x .nft`をインポートし、その` Keeper`を使用する複合モジュールで定義する必要があります。 ### `Msg` Service @@ -151,9 +151,9 @@ message MsgSend { message MsgSendResponse {} ``` -`MsgSend` can be used to transfer the ownership of an NFT to another address. +`MsgSend`を使用して、NFTの所有権を別のアドレスに譲渡できます。 -The implementation outline of the server is as follows: +サーバーの実装概要は次のとおりです。 ```go type msgServer struct{ @@ -161,191 +161,189 @@ type msgServer struct{ } func (m msgServer) Send(ctx context.Context, msg *types.MsgSend) (*types.MsgSendResponse, error) { - // check current ownership + ..check current ownership assertEqual(msg.Sender, m.k.GetOwner(msg.ClassId, msg.Id)) - // transfer ownership + ..transfer ownership m.k.Transfer(msg.ClassId, msg.Id, msg.Receiver) return &types.MsgSendResponse{}, nil } ``` -The query service methods for the `x/nft` module are: +`x .nft`モジュールのクエリサービスメソッドは次のとおりです。 ```proto service Query { - // Balance queries the number of NFTs of a given class owned by the owner, same as balanceOf in ERC721 + ..Balance queries the number of NFTs of a given class owned by the owner, same as balanceOf in ERC721 rpc Balance(QueryBalanceRequest) returns (QueryBalanceResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/balance/{class_id}/{owner}"; } - // Owner queries the owner of the NFT based on its class and id, same as ownerOf in ERC721 + ..Owner queries the owner of the NFT based on its class and id, same as ownerOf in ERC721 rpc Owner(QueryOwnerRequest) returns (QueryOwnerResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/owner/{class_id}/{id}"; } - // Supply queries the number of NFTs of a given class, same as totalSupply in ERC721Enumerable + ..Supply queries the number of NFTs of a given class, same as totalSupply in ERC721Enumerable rpc Supply(QuerySupplyRequest) returns (QuerySupplyResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/supply/{class_id}"; } - // NFTsOfClassByOwner queries the NFTs of a given class owned by the owner, similar to tokenOfOwnerByIndex in ERC721Enumerable + ..NFTsOfClassByOwner queries the NFTs of a given class owned by the owner, similar to tokenOfOwnerByIndex in ERC721Enumerable rpc NFTsOfClassByOwner(QueryNFTsOfClassByOwnerRequest) returns (QueryNFTsResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/owned_nfts/{class_id}/{owner}"; } - // NFTsOfClass queries all NFTs of a given class, similar to tokenByIndex in ERC721Enumerable + ..NFTsOfClass queries all NFTs of a given class, similar to tokenByIndex in ERC721Enumerable rpc NFTsOfClass(QueryNFTsOfClassRequest) returns (QueryNFTsResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/nfts/{class_id}"; } - // NFT queries an NFT based on its class and id. + ..NFT queries an NFT based on its class and id. rpc NFT(QueryNFTRequest) returns (QueryNFTResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/nfts/{class_id}/{id}"; } - // Class queries an NFT class based on its id + ..Class queries an NFT class based on its id rpc Class(QueryClassRequest) returns (QueryClassResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/classes/{class_id}"; } - // Classes queries all NFT classes + ..Classes queries all NFT classes rpc Classes(QueryClassesRequest) returns (QueryClassesResponse) { option (google.api.http).get = "/cosmos/nft/v1beta1/classes"; } } -// QueryBalanceRequest is the request type for the Query/Balance RPC method +/.QueryBalanceRequest is the request type for the Query/Balance RPC method message QueryBalanceRequest { string class_id = 1; string owner = 2; } -// QueryBalanceResponse is the response type for the Query/Balance RPC method +/.QueryBalanceResponse is the response type for the Query/Balance RPC method message QueryBalanceResponse{ uint64 amount = 1; } -// QueryOwnerRequest is the request type for the Query/Owner RPC method +/.QueryOwnerRequest is the request type for the Query/Owner RPC method message QueryOwnerRequest { string class_id = 1; string id = 2; } -// QueryOwnerResponse is the response type for the Query/Owner RPC method +/.QueryOwnerResponse is the response type for the Query/Owner RPC method message QueryOwnerResponse{ string owner = 1; } -// QuerySupplyRequest is the request type for the Query/Supply RPC method +/.QuerySupplyRequest is the request type for the Query/Supply RPC method message QuerySupplyRequest { string class_id = 1; } -// QuerySupplyResponse is the response type for the Query/Supply RPC method +/.QuerySupplyResponse is the response type for the Query/Supply RPC method message QuerySupplyResponse { uint64 amount = 1; } -// QueryNFTsOfClassByOwnerRequest is the request type for the Query/NFTsOfClassByOwner RPC method +/.QueryNFTsOfClassByOwnerRequest is the request type for the Query/NFTsOfClassByOwner RPC method message QueryNFTsOfClassByOwnerRequest { string class_id = 1; string owner = 2; cosmos.base.query.v1beta1.PageResponse pagination = 3; } -// QueryNFTsOfClassRequest is the request type for the Query/NFTsOfClass RPC method +/.QueryNFTsOfClassRequest is the request type for the Query/NFTsOfClass RPC method message QueryNFTsOfClassRequest { string class_id = 1; cosmos.base.query.v1beta1.PageResponse pagination = 2; } -// QueryNFTsResponse is the response type for the Query/NFTsOfClass and Query/NFTsOfClassByOwner RPC methods +/.QueryNFTsResponse is the response type for the Query/NFTsOfClass and Query/NFTsOfClassByOwner RPC methods message QueryNFTsResponse { repeated cosmos.nft.v1beta1.NFT nfts = 1; cosmos.base.query.v1beta1.PageResponse pagination = 2; } -// QueryNFTRequest is the request type for the Query/NFT RPC method +/.QueryNFTRequest is the request type for the Query/NFT RPC method message QueryNFTRequest { string class_id = 1; string id = 2; } -// QueryNFTResponse is the response type for the Query/NFT RPC method +/.QueryNFTResponse is the response type for the Query/NFT RPC method message QueryNFTResponse { cosmos.nft.v1beta1.NFT nft = 1; } -// QueryClassRequest is the request type for the Query/Class RPC method +/.QueryClassRequest is the request type for the Query/Class RPC method message QueryClassRequest { string class_id = 1; } -// QueryClassResponse is the response type for the Query/Class RPC method +/.QueryClassResponse is the response type for the Query/Class RPC method message QueryClassResponse { cosmos.nft.v1beta1.Class class = 1; } -// QueryClassesRequest is the request type for the Query/Classes RPC method +/.QueryClassesRequest is the request type for the Query/Classes RPC method message QueryClassesRequest { - // pagination defines an optional pagination for the request. + ..pagination defines an optional pagination for the request. cosmos.base.query.v1beta1.PageRequest pagination = 1; } -// QueryClassesResponse is the response type for the Query/Classes RPC method +/.QueryClassesResponse is the response type for the Query/Classes RPC method message QueryClassesResponse { repeated cosmos.nft.v1beta1.Class classes = 1; cosmos.base.query.v1beta1.PageResponse pagination = 2; } ``` -### Interoperability +### 相互運用性 -Interoperability is all about reusing assets between modules and chains. The former one is achieved by ADR-33: Protobuf client - server communication. At the time of writing ADR-33 is not finalized. The latter is achieved by IBC. Here we will focus on the IBC side. -IBC is implemented per module. Here, we aligned that NFTs will be recorded and managed in the x/nft. This requires creation of a new IBC standard and implementation of it. +相互運用性とは、モジュールとチェーンの間でアセットを再利用することです。前者は、ADR-33:Protobufクライアント/サーバー通信によって実現されます。執筆時点では、ADR-33はまだ完成していません。後者はIBCによって実装されています。ここでは、IBCの側面に焦点を当てます。 +IBCはモジュールに実装されています。ここでは、NFTがx .nftで記録および管理されることに同意します。これには、新しいIBC標準を作成して実装する必要があります。 -For IBC interoperability, NFT custom modules MUST use the NFT object type understood by the IBC client. So, for x/nft interoperability, custom NFT implementations (example: x/cryptokitty) should use the canonical x/nft module and proxy all NFT balance keeping functionality to x/nft or else re-implement all functionality using the NFT object type understood by the IBC client. In other words: x/nft becomes the standard NFT registry for all Cosmos NFTs (example: x/cryptokitty will register a kitty NFT in x/nft and use x/nft for book keeping). This was [discussed](https://github.com/cosmos/cosmos-sdk/discussions/9065#discussioncomment-873206) in the context of using x/bank as a general asset balance book. Not using x/nft will require implementing another module for IBC. +IBCの相互運用性のために、NFTカスタムモジュールは、IBCクライアントが理解できるNFTオブジェクトタイプを使用する必要があります。したがって、x .nftの相互運用性のために、カスタムNFT実装(例:x .cryptokitty)は、標準化されたx .nftモジュールを使用し、すべてのNFTバランス維持機能をx .nftにプロキシする必要があります。それ以外の場合は、理解されているNFTオブジェクトタイプを使用してすべての機能を再実行します。 IBCのお客様から提供されています。言い換えると、x .nftはすべてのCosmosNFTの標準NFTレジストリになります(たとえば、x .cryptokittyはキティNFTをx .nftに登録し、簿記にx .nftを使用します)。これは、x .bankを一般的な貸借対照表として使用する場合に使用されます[ディスカッション](https://github.com/cosmos/cosmos-sdk/discussions/9065#discussioncomment-873206)。 x .nftを使用しない場合は、IBC用に別のモジュールを実装する必要があります。 -## Consequences +## 結果 -### Backward Compatibility +### 下位互換性 -No backward incompatibilities. +後方互換性はありません。 -### Forward Compatibility +### 上位互換性 -This specification conforms to the ERC-721 smart contract specification for NFT identifiers. Note that ERC-721 defines uniqueness based on (contract address, uint256 tokenId), and we conform to this implicitly because a single module is currently aimed to track NFT identifiers. Note: use of the (mutable) data field to determine uniqueness is not safe.s +この仕様は、NFT識別子のERC-721スマートコントラクト仕様に準拠しています。 ERC-721は(契約アドレス、uint256 tokenId)に基づいて一意性を定義し、現在単一のモジュールがNFT識別子を追跡するように設計されているため、これに暗黙的に準拠していることに注意してください。注:(変数)データフィールドを使用して一意性を判断することは安全ではありません。 -### Positive +### ポジティブ -- NFT identifiers available on Cosmos Hub. -- Ability to build different NFT modules for the Cosmos Hub, e.g., ERC-721. -- NFT module which supports interoperability with IBC and other cross-chain infrastructures like Gravity Bridge +-Cosmosハブで利用可能なNFT識別子。 +-ERC-721などのCosmosHub用のさまざまなNFTモジュールを構築する機能。 +-NFTモジュール、IBCやGravityBridgeなどの他のクロスチェーンインフラストラクチャとの相互運用性をサポート -### Negative +### ネガティブ -+ New IBC app is required for x/nft -+ CW721 adapter is required ++ x .nftには新しいIBCアプリケーションが必要です ++ CW721アダプターが必要 +### ニュートラル -### Neutral +-他の機能には、より多くのモジュールが必要です。たとえば、NFTトランザクション機能には管理モジュールが必要であり、NFTプロパティの定義には収集モジュールが必要です。 +## さらなる議論 -- Other functions need more modules. For example, a custody module is needed for NFT trading function, a collectible module is needed for defining NFT properties. +ハブ上の他のタイプのアプリケーションについては、将来、より多くのアプリケーション固有のモジュールを開発できます。 -## Further Discussions +-`x .nft .custody`:トランザクション機能をサポートするためのホストNFT。 +-`x .nft .marketplace`:sdk.Coinsを使用してNFTを売買します。 +-`x .fractional`:複数の利害関係者の資産(NFTまたはその他の資産)の所有権を分割するためのモジュール。 `x .group`はほとんどの状況に適しているはずです。 -For other kinds of applications on the Hub, more app-specific modules can be developed in the future: +Cosmosエコシステムの他のネットワークは、特定のNFTアプリケーションおよびユースケース向けに独自のNFTモジュールを設計および実装できます。 -- `x/nft/custody`: custody of NFTs to support trading functionality. -- `x/nft/marketplace`: selling and buying NFTs using sdk.Coins. -- `x/fractional`: a module to split an ownership of an asset (NFT or other assets) for multiple stakeholder. `x/group` should work for most of the cases. +## 参照する -Other networks in the Cosmos ecosystem could design and implement their own NFT modules for specific NFT applications and use cases. - -## References - -- Initial discussion: https://github.com/cosmos/cosmos-sdk/discussions/9065 -- x/nft: initialize module: https://github.com/cosmos/cosmos-sdk/pull/9174 -- [ADR 033](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-033-protobuf-inter-module-comm.md) +-予備的なディスカッション:https://github.com/cosmos/cosmos-sdk/discussions/9065 +-x .nft:初期化モジュール:https://github.com/cosmos/cosmos-sdk/pull/9174 +-[ADR 033](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-033-protobuf-inter-module-comm.md) \ No newline at end of file diff --git a/docs/ja/architecture/adr-044-protobuf-updates-guidelines.md b/docs/ja/architecture/adr-044-protobuf-updates-guidelines.md index dc650424d349..449142a790a6 100644 --- a/docs/ja/architecture/adr-044-protobuf-updates-guidelines.md +++ b/docs/ja/architecture/adr-044-protobuf-updates-guidelines.md @@ -1,138 +1,138 @@ -# ADR 044: Guidelines for Updating Protobuf Definitions +# ADR 044:Protobuf定義更新ガイド -## Changelog +## 変更ログ -- 28.06.2021: Initial Draft -- 02.12.2021: Add `Since:` comment for new fields +-28.06.2021:最初のドラフト +-02.12.2021:新しいフィールドに `Since:`コメントを追加 -## Status +## 状態 -Draft +下書き -## Abstract +## 概要 -This ADR provides guidelines and recommended practices when updating Protobuf definitions. These guidelines are targeting module developers. +このADRは、Protobufの定義を更新する際のガイドラインと推奨プラクティスを提供します。これらのガイドラインは、モジュール開発者を対象としています。 -## Context +## 環境 -The Cosmos SDK maintains a set of [Protobuf definitions](https://github.com/cosmos/cosmos-sdk/tree/master/proto/cosmos). It is important to correctly design Protobuf definitions to avoid any breaking changes within the same version. The reasons are to not break tooling (including indexers and explorers), wallets and other third-party integrations. +Cosmos SDKは、一連の[Protobuf定義](https://github.com/cosmos/cosmos-sdk/tree/master/proto/cosmos)を維持しています。同じバージョンでの破壊的な変更を避けるために、Protobuf定義を正しく設計することが重要です。その理由は、ツール(インデクサーやリソースマネージャーを含む)、ウォレット、その他のサードパーティの統合を壊さないためです。 -When making changes to these Protobuf definitions, the Cosmos SDK currently only follows [Buf's](https://docs.buf.build/) recommendations. We noticed however that Buf's recommendations might still result in breaking changes in the SDK in some cases. For example: +これらのProtobuf定義を変更する場合、Cosmos SDKは現在、[Buf](https://docs.buf.build/)の推奨事項のみに従います。ただし、場合によっては、Bufの提案によってSDKに大きな変更が加えられる可能性があることに気づきました。例えば: -- Adding fields to `Msg`s. Adding fields is a not a Protobuf spec-breaking operation. However, when adding new fields to `Msg`s, the unknown field rejection will throw an error when sending the new `Msg` to an older node. -- Marking fields as `reserved`. Protobuf proposes the `reserved` keyword for removing fields without the need to bump the package version. However, by doing so, client backwards compatibility is broken as Protobuf doesn't generate anything for `reserved` fields. See [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) for more details on this issue. +-`Msg`にフィールドを追加します。フィールドの追加は、Protobuf仕様によって破られる操作ではありません。ただし、 `Msg`に新しいフィールドを追加すると、不明なフィールドの拒否により、新しい` Msg`が古いノードに送信されるときにエラーがスローされます。 +-フィールドを「予約済み」としてマークします。 Protobufは、パッケージのバージョンを変更せずにフィールドを削除するには、 `reserved`キーワードを使用することをお勧めします。ただし、Protobufは「予約済み」フィールドに対して何も生成しないため、これを行うと、クライアントの下位互換性が失われます。この問題の詳細については、[#9446](https://github.com/cosmos/cosmos-sdk/issues/9446)を参照してください。 -Moreover, module developers often face other questions around Protobuf definitions such as "Can I rename a field?" or "Can I deprecate a field?" This ADR aims to answer all these questions by providing clear guidelines about allowed updates for Protobuf definitions. +さらに、モジュール開発者は、「フィールドの名前を変更できますか？」や「フィールドを破棄できますか？」など、Protobufの定義に関する他の質問に直面することがよくあります。これらすべての質問に答えてください。 -## Decision +## 決定 -We decide to keep [Buf's](https://docs.buf.build/) recommendations with the following exceptions: +次の場合を除いて、[Buf](https://docs.buf.build/)の提案を保持することにしました。 -- `UNARY_RPC`: the Cosmos SDK currently does not support streaming RPCs. -- `COMMENT_FIELD`: the Cosmos SDK allows fields with no comments. -- `SERVICE_SUFFIX`: we use the `Query` and `Msg` service naming convention, which doesn't use the `-Service` suffix. -- `PACKAGE_VERSION_SUFFIX`: some packages, such as `cosmos.crypto.ed25519`, don't use a version suffix. -- `RPC_REQUEST_STANDARD_NAME`: Requests for the `Msg` service don't have the `-Request` suffix to keep backwards compatibility. +-`UNARY_RPC`:Cosmos SDKは現在、ストリーミングRPCをサポートしていません。 +-`COMMENT_FIELD`:Cosmos SDKでは、コメントなしのフィールドを使用できます。 +-`SERVICE_SUFFIX`: `Query`および` Msg`サービスの命名規則を使用し、 `-Service`サフィックスは使用しません。 +-`PACKAGE_VERSION_SUFFIX`: `cosmos.crypto.ed25519`などの一部のパッケージは、バージョンサフィックスを使用しません。 +-`RPC_REQUEST_STANDARD_NAME`: `Msg`サービスへのリクエストには、下位互換性を維持するための` -Request`サフィックスがありません。 -On top of Buf's recommendations we add the following guidelines that are specific to the Cosmos SDK. +Bufの提案に加えて、次のCosmosSDK固有のガイドを追加しました。 -### Updating Protobuf Definition Without Bumping Version +### 衝突バージョンなしでProtobuf定義を更新 -#### 1. `Msg`s MUST NOT have new fields +#### 1.`Msg`sは新しいフィールドを持つことができません -When processing `Msg`s, the Cosmos SDK's antehandlers are strict and don't allow unknown fields in `Msg`s. This is checked by the unknown field rejection in the [`codec/unknownproto` package](https://github.com/cosmos/cosmos-sdk/blob/master/codec/unknownproto). +`Msg`を処理する場合、Cosmos SDKの前処理手順は厳密であり、` Msg`で不明なフィールドを使用することはできません。これは、[`codec .unknownproto`パッケージ](https://github.com/cosmos/cosmos-sdk/blob/master/codec/unknownproto)の不明なフィールドを拒否することでチェックされます。 -Now imagine a v0.43 node accepting a `MsgExample` transaction, and in v0.44 the chain developer decides to add a field to `MsgExample`. A client developer, which only manipulates Protobuf definitions, would see that `MsgExample` has a new field, and will populate it. However, sending the new `MsgExample` to an old v0.43 node would cause the v0.43 node to reject the `MsgExample` because of the unknown field. The expectation that the same Protobuf version can be used across multiple node versions MUST be guaranteed. +ここで、v0.43ノードが `MsgExample`トランザクションを受け入れ、v0.44で、チェーン開発者が` MsgExample`にフィールドを追加することを決定したと想像してください。 Protobuf定義のみを操作するクライアント開発者は、 `MsgExample`に新しいフィールドがあることを確認し、それを入力します。ただし、新しい「MsgExample」を古いv0.43ノードに送信すると、フィールドが不明であるため、v0.43ノードは「MsgExample」を拒否します。同じProtobufバージョンが複数のノードバージョンで使用できるという期待を保証する必要があります。 -For this reason, module developers MUST NOT add new fields to existing `Msg`s. +このため、モジュール開発者は既存の `Msg`に新しいフィールドを追加してはなりません。 -It is worth mentioning that this does not limit adding fields to a `Msg`, but also to all nested structs and `Any`s inside a `Msg`. +これは、 `Msg`へのフィールドの追加を制限するのではなく、すべてのネストされた構造と` Msg`の `Any`へのフィールドの追加も制限することに注意してください。 -#### 2. Non-`Msg`-related Protobuf definitions MAY have new fields, but MUST add a `Since:` comment +#### 2. `Msg`に関係のないProtobuf定義には新しいフィールドがあるかもしれませんが、` since: `コメントを追加する必要があります -On the other hand, module developers MAY add new fields to Protobuf definitions related to the `Query` service or to objects which are saved in the store. This recommendation follows the Protobuf specification, but is added in this document for clarity. +一方、モジュール開発者は、ストレージに格納されている「クエリ」サービスまたはオブジェクトに関連するProtobuf定義に新しいフィールドを追加できます。 この推奨事項はProtobuf仕様に従いますが、わかりやすくするためにこのドキュメントに追加されています。 -The SDK requires the Protobuf comment of the new field to contain one line with the following format: +SDKでは、新しいフィールドのProtobufコメントに次の形式の1行が含まれている必要があります。 ```protobuf -// Since: cosmos-sdk {, ...} +/.Since: cosmos-sdk {, ...} ``` -Where each `version` denotes a minor ("0.45") or patch ("0.44.5") version from which the field is available. This will greatly help client libraries, who can optionally use reflection or custom code generation to show/hide these fields depending on the targetted node version. +各 `version`は、フィールドで使用可能なマイナー(" 0.45 ")またはパッチ(" 0.44.5 ")バージョンを表します。 これはクライアントライブラリに大いに役立ちます。クライアントライブラリは、リフレクションまたはカスタムコード生成を使用して、ターゲットノードのバージョンに基づいてこれらのフィールドを表示/非表示にすることを選択できます。 -As examples, the following comments are valid: +たとえば、次のコメントが有効です。 ```protobuf -// Since: cosmos-sdk 0.44 +/.Since: cosmos-sdk 0.44 -// Since: cosmos-sdk 0.42.11, 0.44.5 +/.Since: cosmos-sdk 0.42.11, 0.44.5 ``` and the following ones are NOT valid: ```protobuf -// Since cosmos-sdk v0.44 +/.Since cosmos-sdk v0.44 -// since: cosmos-sdk 0.44 +/.since: cosmos-sdk 0.44 -// Since: cosmos-sdk 0.42.11 0.44.5 +/.Since: cosmos-sdk 0.42.11 0.44.5 -// Since: Cosmos SDK 0.42.11, 0.44.5 +/.Since: Cosmos SDK 0.42.11, 0.44.5 ``` -#### 3. Fields MAY be marked as `deprecated`, and nodes MAY implement a protocol-breaking change for handling these fields +#### 3.フィールドは「非推奨」としてマークでき、ノードはこれらのフィールドを処理するためにプロトコルに破壊的な変更を実装できます -Protobuf supports the [`deprecated` field option](https://developers.google.com/protocol-buffers/docs/proto#options), and this option MAY be used on any field, including `Msg` fields. If a node handles a Protobuf message with a non-empty deprecated field, the node MAY change its behavior upon processing it, even in a protocol-breaking way. When possible, the node MUST handle backwards compatibility without breaking the consensus (unless we increment the proto version). +Protobufは[`deprecated`フィールドオプション](https://developers.google.com/protocol-buffers/docs/proto#options)をサポートしており、このオプションは` Msg`フィールドを含むすべてのフィールドに使用できます。ノードが空でない非推奨フィールドを使用してProtobufメッセージを処理する場合、プロトコルに違反する方法であっても、ノードはメッセージの処理中に動作を変更する可能性があります。可能であれば、ノードはコンセンサスを壊すことなく下位互換性を処理する必要があります(プロトタイプバージョンを増やす場合を除く)。 -As an example, the Cosmos SDK v0.42 to v0.43 update contained two Protobuf-breaking changes, listed below. Instead of bumping the package versions from `v1beta1` to `v1`, the SDK team decided to follow this guideline, by reverting the breaking changes, marking those changes as deprecated, and modifying the node implementation when processing messages with deprecated fields. More specifically: +たとえば、Cosmos SDK v0.42からv0.43へのアップデートには、以下に示すProtobufに対する2つの重大な変更が含まれています。 SDKチームはパッケージバージョンを `v1beta1`から` v1`にアップグレードしませんでしたが、重大な変更を元に戻し、これらの変更を非推奨としてマークし、非推奨フィールドを処理することにより、このガイドラインに従うことにしました。メッセージ中にノードの実装を変更します。さらに: -- The Cosmos SDK recently removed support for [time-based software upgrades](https://github.com/cosmos/cosmos-sdk/pull/8849). As such, the `time` field has been marked as deprecated in `cosmos.upgrade.v1beta1.Plan`. Moreover, the node will reject any proposal containing an upgrade Plan whose `time` field is non-empty. -- The Cosmos SDK now supports [governance split votes](./adr-037-gov-split-vote.md). When querying for votes, the returned `cosmos.gov.v1beta1.Vote` message has its `option` field (used for 1 vote option) deprecated in favor of its `options` field (allowing multiple vote options). Whenever possible, the SDK still populates the deprecated `option` field, that is, if and only if the `len(options) == 1` and `options[0].Weight == 1.0`. +-Cosmos SDKは最近、[Time-Based Software Upgrade](https://github.com/cosmos/cosmos-sdk/pull/8849)のサポートをキャンセルしました。したがって、「time」フィールドは「cosmos.upgrade.v1beta1.Plan」で非推奨としてマークされています。さらに、ノードは、空でない「時間」フィールドを含むアップグレード計画の提案を拒否します。 +-Cosmos SDKは、[Governance Split Voting](..adr-037-gov-split-vote.md)をサポートするようになりました。投票をクエリする場合、返された `cosmos.gov.v1beta1.Vote`メッセージの` option`フィールド(1投票オプションの場合)は非推奨になり、その `options`フィールド(複数の投票オプションを許可)に置き換えられます。可能な場合は常に、SDKは非推奨の `option`フィールドに入力します。つまり、` len(options)== 1`および `options [0] .Weight == 1.0`の場合に限ります。 -#### 4. Fields MUST NOT be renamed +#### 4。フィールドの名前を変更することはできません -Whereas the official Protobuf recommendations do not prohibit renaming fields, as it does not break the Protobuf binary representation, the SDK explicitly forbids renaming fields in Protobuf structs. The main reason for this choice is to avoid introducing breaking changes for clients, which often rely on hard-coded fields from generated types. Moreover, renaming fields will lead to client-breaking JSON representations of Protobuf definitions, used in REST endpoints and in the CLI. +公式のProtobufは、Protobufバイナリ表現を破壊しないため、フィールドの名前変更を禁止しないことを推奨していますが、SDKはProtobuf構造内のフィールドの名前変更を明示的に禁止しています。この選択の主な理由は、クライアントに破壊的な変更を導入しないようにすることです。これは通常、生成タイプのハードコードされたフィールドに依存します。さらに、フィールドの名前を変更すると、Protobufによって定義されたクライアントがRESTエンドポイントとCLIのJSON表現を壊します。 -### Incrementing Protobuf Package Version +### Protobufパッケージバージョンをインクリメント -TODO, needs architecture review. Some topics: +TODO、アーキテクチャのレビューが必要です。いくつかのトピック: -- Bumping versions frequency -- When bumping versions, should the Cosmos SDK support both versions? - - i.e. v1beta1 -> v1, should we have two folders in the Cosmos SDK, and handlers for both versions? -- mention ADR-023 Protobuf naming +-衝突バージョンの頻度 +-バージョンを衝突させる場合、Cosmos SDKは2つのバージョンをサポートする必要がありますか？ + -つまり、v1beta1-> v1であり、Cosmos SDKに2つのフォルダーと、2つのバージョンのハンドラーが必要ですか？ +-メンションADR-023Protobufの命名 -## 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. +>後方非互換性を導入するすべてのADRには、非互換性とその重大度を説明するセクションを含める必要があります。 ADRは、作成者がこれらの非互換性にどのように対処するつもりかを説明する必要があります。十分な下位互換性に関する書類がないADRの提出は、完全に拒否される可能性があります。 -### Positive +### ポジティブ -- less pain to tool developers -- more compatibility in the ecosystem -- ... +-ツール開発者の苦痛を軽減します +-エコシステムの互換性の向上 +-..。 -### Negative +### ネガティブ -{negative consequences} +{否定的な結果} -### Neutral +### ニュートラル -- more rigor in Protobuf review +-Protobufレビューの厳密性 -## Further Discussions +## さらなる議論 -This ADR is still in the DRAFT stage, and the "Incrementing Protobuf Package Version" will be filled in once we make a decision on how to correctly do it. +このADRはまだドラフト段階にあります。正しく行う方法を決定したら、「インクリメンタルProtobufパッケージバージョン」に入力します。 -## 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. +コンセンサスの変更に影響を与えるADRの場合、実装されたテストケースは必須です。該当する場合、他のADRがテストケースへのリンクを含めることを選択する場合があります。 -## References +## 参照する -- [#9445](https://github.com/cosmos/cosmos-sdk/issues/9445) Release proto definitions v1 -- [#9446](https://github.com/cosmos/cosmos-sdk/issues/9446) Address v1beta1 proto breaking changes +-[#9445](https://github.com/cosmos/cosmos-sdk/issues/9445)プロト定義v1をリリース +-[#9446](https://github.com/cosmos/cosmos-sdk/issues/9446)v1beta1プロトの主要な変更を解決します \ No newline at end of file diff --git a/docs/ja/architecture/adr-045-check-delivertx-middlewares.md b/docs/ja/architecture/adr-045-check-delivertx-middlewares.md index 7c5f84109ad0..9e5c06551638 100644 --- a/docs/ja/architecture/adr-045-check-delivertx-middlewares.md +++ b/docs/ja/architecture/adr-045-check-delivertx-middlewares.md @@ -1,29 +1,27 @@ -# ADR 045: BaseApp `{Check,Deliver}Tx` as Middlewares +# ADR 045:ミドルウェアとしてのBaseApp `{Check、Deliver} Tx` -## Changelog +## 変更ログ -- 20.08.2021: Initial draft. -- 07.12.2021: Update `tx.Handler` interface ([\#10693](https://github.com/cosmos/cosmos-sdk/pull/10693)). +-20.08.2021:最初のドラフト。 +-07.12.2021: `tx.Handler`インターフェースを更新します([\#10693](https://github.com/cosmos/cosmos-sdk/pull/10693))。 -## Status +## 状態 -ACCEPTED +受け入れられました -## Abstract +## 概要 -This ADR replaces the current BaseApp `runTx` and antehandlers design with a middleware-based design. +このADRは、現在のBaseApp`runTx`およびアンティハンドラーの設計をミドルウェアベースの設計に置き換えます。 -## Context +## 環境 -BaseApp's implementation of ABCI `{Check,Deliver}Tx()` and its own `Simulate()` method call the `runTx` method under the hood, which first runs antehandlers, then executes `Msg`s. However, the [transaction Tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [refunding unused gas](https://github.com/cosmos/cosmos-sdk/issues/2150) use cases require custom logic to be run after the `Msg`s execution. There is currently no way to achieve this. +BaseAppのABCI` {Check、Deliver} Tx() `と独自の` Simulate() `メソッドの実装は、基礎となる` runTx`メソッドを呼び出します。このメソッドは、最初にアンティハンドラーを実行し、次に `Msg`を実行します。ただし、[トランザクションのヒント](https://github.com/cosmos/cosmos-sdk/issues/9406)および[未使用のガスの払い戻し](https://github.com/cosmos/cosmos-sdk/issues.2150 )ユースケースでは、 `Msg`の実行後にカスタムロジックを実行する必要があります。現在、これを達成する方法はありません。 -An naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular. +簡単な解決策は、ポスト `Msg`フックをBaseAppに追加することです。ただし、Cosmos SDKチームは、アプリケーションの配線を容易にする全体像も検討しています([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182))。これには、BaseAppの軽量化とモジュール性。 -## Decision +## 決定 -We decide to transform Baseapp's implementation of ABCI `{Check,Deliver}Tx` and its own `Simulate` methods to use a middleware-based design. - -The two following interfaces are the base of the middleware design, and are defined in `types/tx`: +BaseappのABCI` {Check、Deliver} Tx`実装と独自の `Simulate`メソッドを変換して、ミドルウェアベースの設計を使用することにしました。 ```go type Handler interface { @@ -35,7 +33,7 @@ type Handler interface { type Middleware func(Handler) Handler ``` -where we define the following arguments and return types: +ここでは、次のパラメーターと戻り値のタイプを定義しました。 ```go type Request struct { @@ -46,9 +44,9 @@ type Request struct { type Response struct { GasWanted uint64 GasUsed uint64 - // MsgResponses is an array containing each Msg service handler's response - // type, packed in an Any. This will get proto-serialized into the `Data` field - // in the ABCI Check/DeliverTx responses. + /.MsgResponses is an array containing each Msg service handler's response + /.type, packed in an Any. This will get proto-serialized into the `Data` field + /.in the ABCI Check/DeliverTx responses. MsgResponses []*codectypes.Any Log string Events []abci.Event @@ -63,18 +61,18 @@ type ResponseCheckTx struct { } ``` -Please note that because CheckTx handles separate logic related to mempool priotization, its signature is different than DeliverTx and SimulateTx. +CheckTxはメモリプールの優先順位付けに関連する個別のロジックを処理するため、そのシグネチャはDeliverTxおよびSimulateTxとは異なることに注意してください。 -BaseApp holds a reference to a `tx.Handler`: +BaseAppは `tx.Handler`への参照を保持します: ```go type BaseApp struct { - // other fields + ..other fields txHandler tx.Handler } ``` -Baseapp's ABCI `{Check,Deliver}Tx()` and `Simulate()` methods simply call `app.txHandler.{Check,Deliver,Simulate}Tx()` with the relevant arguments. For example, for `DeliverTx`: +BaseappのABCI` {Check、Deliver} Tx() `および` Simulate() `メソッドは、関連するパラメーターを使用して` app.txHandler。{Check、Deliver、Simulate} Tx() `を呼び出すだけです。 たとえば、 `DeliverTx`の場合: ```go func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx { @@ -94,7 +92,7 @@ func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) abci.ResponseDeliverTx return abciRes } -// convertTxResponseToDeliverTx converts a tx.Response into a abci.ResponseDeliverTx. +/.convertTxResponseToDeliverTx converts a tx.Response into a abci.ResponseDeliverTx. func convertTxResponseToDeliverTx(txRes tx.Response) (abci.ResponseDeliverTx, error) { data, err := makeABCIData(txRes) if err != nil { @@ -108,83 +106,83 @@ func convertTxResponseToDeliverTx(txRes tx.Response) (abci.ResponseDeliverTx, er }, nil } -// makeABCIData generates the Data field to be sent to ABCI Check/DeliverTx. +/.makeABCIData generates the Data field to be sent to ABCI Check/DeliverTx. func makeABCIData(txRes tx.Response) ([]byte, error) { return proto.Marshal(&sdk.TxMsgData{MsgResponses: txRes.MsgResponses}) } ``` -The implementations are similar for `BaseApp.CheckTx` and `BaseApp.Simulate`. +「BaseApp.CheckTx」と「BaseApp.Simulate」の実装は似ています。 -`baseapp.txHandler`'s three methods' implementations can obviously be monolithic functions, but for modularity we propose a middleware composition design, where a middleware is simply a function that takes a `tx.Handler`, and returns another `tx.Handler` wrapped around the previous one. +`baseapp.txHandler`の3つのメソッドの実装は明らかに単一の関数ですが、モジュール化のために、ミドルウェアが単なる関数であるミドルウェアの組み合わせ設計を提案します。ミドルウェアは` tx.Handler`を受け入れ、別の `txを返します。 .Handler``は前のものにラップされています。 -### Implementing a Middleware +### ミドルウェアを実装する -In practice, middlewares are created by Go function that takes as arguments some parameters needed for the middleware, and returns a `tx.Middleware`. +実際、ミドルウェアはGo関数によって作成されます。この関数は、ミドルウェアに必要ないくつかのパラメーターをパラメーターとして受け取り、 `tx.Middleware`を返します。 -For example, for creating an arbitrary `MyMiddleware`, we can implement: +たとえば、任意の `MyMiddleware`を作成するには、次のように実装できます。 ```go -// myTxHandler is the tx.Handler of this middleware. Note that it holds a -// reference to the next tx.Handler in the stack. +/.myTxHandler is the tx.Handler of this middleware. Note that it holds a +/.reference to the next tx.Handler in the stack. type myTxHandler struct { - // next is the next tx.Handler in the middleware stack. + ..next is the next tx.Handler in the middleware stack. next tx.Handler - // some other fields that are relevant to the middleware can be added here + ..some other fields that are relevant to the middleware can be added here } -// NewMyMiddleware returns a middleware that does this and that. +/.NewMyMiddleware returns a middleware that does this and that. func NewMyMiddleware(arg1, arg2) tx.Middleware { return func (txh tx.Handler) tx.Handler { return myTxHandler{ next: txh, - // optionally, set arg1, arg2... if they are needed in the middleware + ..optionally, set arg1, arg2... if they are needed in the middleware } } } -// Assert myTxHandler is a tx.Handler. +/.Assert myTxHandler is a tx.Handler. var _ tx.Handler = myTxHandler{} func (h myTxHandler) CheckTx(ctx context.Context, req Request, checkReq RequestcheckTx) (Response, ResponseCheckTx, error) { - // CheckTx specific pre-processing logic + ..CheckTx specific pre-processing logic - // run the next middleware + ..run the next middleware res, checkRes, err := txh.next.CheckTx(ctx, req, checkReq) - // CheckTx specific post-processing logic + ..CheckTx specific post-processing logic return res, checkRes, err } func (h myTxHandler) DeliverTx(ctx context.Context, req Request) (Response, error) { - // DeliverTx specific pre-processing logic + ..DeliverTx specific pre-processing logic - // run the next middleware + ..run the next middleware res, err := txh.next.DeliverTx(ctx, tx, req) - // DeliverTx specific post-processing logic + ..DeliverTx specific post-processing logic return res, err } func (h myTxHandler) SimulateTx(ctx context.Context, req Request) (Response, error) { - // SimulateTx specific pre-processing logic + ..SimulateTx specific pre-processing logic - // run the next middleware + ..run the next middleware res, err := txh.next.SimulateTx(ctx, tx, req) - // SimulateTx specific post-processing logic + ..SimulateTx specific post-processing logic return res, err } ``` -### Composing Middlewares +### 複合ミドルウェア -While BaseApp simply holds a reference to a `tx.Handler`, this `tx.Handler` itself is defined using a middleware stack. The Cosmos SDK exposes a base (i.e. innermost) `tx.Handler` called `RunMsgsTxHandler`, which executes messages. +BaseAppは `tx.Handler`への参照のみを保持しますが、この` tx.Handler`自体はミドルウェアスタックを使用して定義されます。 Cosmos SDKは、メッセージを実行する `RunMsgsTxHandler`と呼ばれる基本的な(つまり最も内側の)` tx.Handler`を公開します。 -Then, the app developer can compose multiple middlewares on top on the base `tx.Handler`. Each middleware can run pre-and-post-processing logic around its next middleware, as described in the section above. Conceptually, as an example, given the middlewares `A`, `B`, and `C` and the base `tx.Handler` `H` the stack looks like: +次に、アプリケーション開発者は、基本的な `tx.Handler`の上に複数のミドルウェアを組み合わせることができます。 前のセクションで説明したように、各ミドルウェアは、次のミドルウェアの周りで前処理ロジックと後処理ロジックを実行できます。 概念的には、例として、ミドルウェア `A`、` B`、および `C`とベース` tx.Handler` `H`を考えると、スタックは次のようになります。 ``` A.pre @@ -196,26 +194,26 @@ A.pre A.post ``` -We define a `ComposeMiddlewares` function for composing middlewares. It takes the base handler as first argument, and middlewares in the "outer to inner" order. For the above stack, the final `tx.Handler` is: +ミドルウェアをアセンブルするための `ComposeMiddlewares`関数を定義します。 基本的な処理プログラムを最初のパラメータとし、「外部から内部へ」の順にミドルウェアを使用します。 上記のスタックの場合、最終的な `tx.Handler`は次のとおりです。 ```go txHandler := middleware.ComposeMiddlewares(H, A, B, C) ``` -The middleware is set in BaseApp via its `SetTxHandler` setter: +ミドルウェアは、「SetTxHandler」セッターを介してBaseAppに設定されます。 ```go -// simapp/app.go +/.simapp/app.go txHandler := middleware.ComposeMiddlewares(...) app.SetTxHandler(txHandler) ``` -The app developer can define their own middlewares, or use the Cosmos SDK's pre-defined middlewares from `middleware.NewDefaultTxHandler()`. +アプリケーション開発者は、独自のミドルウェアを定義するか、CosmosSDKの `middleware.NewDefaultTxHandler()`から事前定義されたミドルウェアを使用できます。 -### Middlewares Maintained by the Cosmos SDK +### ミドルウェアはCosmosSDKによって維持されています -While the app developer can define and compose the middlewares of their choice, the Cosmos SDK provides a set of middlewares that caters for the ecosystem's most common use cases. These middlewares are: +アプリケーション開発者は選択したミドルウェアを定義して組み合わせることができますが、Cosmos SDKは、エコシステムの最も一般的なユースケースを満たすミドルウェアのセットを提供します。 これらのミドルウェアは次のとおりです。 | Middleware | Description | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -226,86 +224,85 @@ While the app developer can define and compose the middlewares of their choice, | RecoveryTxMiddleware | This index recovers from panics. It replaces baseapp.runTx's panic recovery described in [ADR-022](./adr-022-custom-panic-handling.md). | | GasTxMiddleware | This replaces the [`Setup`](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0/x/auth/ante/setup.go) Antehandler. It sets a GasMeter on sdk.Context. Note that before, GasMeter was set on sdk.Context inside the antehandlers, and there was some mess around the fact that antehandlers had their own panic recovery system so that the GasMeter could be read by baseapp's recovery system. Now, this mess is all removed: one middleware sets GasMeter, another one handles recovery. | -### Similarities and Differences between Antehandlers and Middlewares +### アンティハンドラーとミドルウェアの類似点と相違点 -The middleware-based design builds upon the existing antehandlers design described in [ADR-010](./adr-010-modular-antehandler.md). Even though the final decision of ADR-010 was to go with the "Simple Decorators" approach, the middleware design is actually very similar to the other [Decorator Pattern](./adr-010-modular-antehandler.md#decorator-pattern) proposal, also used in [weave](https://github.com/iov-one/weave). +ミドルウェアベースの設計は、[ADR-010](..adr-010-modular-antehandler.md)で説明されている既存のハンドラー設計に基づいています。 ADR-010の最終決定は「シンプルデコレータ」方式を採用することですが、ミドルウェアの設計は実際には他の[デコレータパターン](..adr-010-modular-antehandler.md#decorator-pattern)の提案と一致しています。 In [weave](https://github.com/iov-one/weave)も使用します。 -#### Similarities with Antehandlers +#### アンティハンドラーとの類似点 -- Designed as chaining/composing small modular pieces. -- Allow code reuse for `{Check,Deliver}Tx` and for `Simulate`. -- Set up in `app.go`, and easily customizable by app developers. -- Order is important. +-小さなモジュラーパーツをリンク/結合するように設計されています。 +-` {Check、Deliver} Tx`と `Simulate`のコードの再利用を許可します。 +-`app.go`で設定し、アプリ開発者が簡単にカスタマイズできます。 +-順序は重要です。 -#### Differences with Antehandlers +#### アンティハンドラーとの違い -- The Antehandlers are run before `Msg` execution, whereas middlewares can run before and after. -- The middleware approach uses separate methods for `{Check,Deliver,Simulate}Tx`, whereas the antehandlers pass a `simulate bool` flag and uses the `sdkCtx.Is{Check,Recheck}Tx()` flags to determine in which transaction mode we are. -- The middleware design lets each middleware hold a reference to the next middleware, whereas the antehandlers pass a `next` argument in the `AnteHandle` method. -- The middleware design use Go's standard `context.Context`, whereas the antehandlers use `sdk.Context`. +-アンチハンドラは `Msg`が実行される前に実行され、ミドルウェアは前後に実行できます。 +-ミドルウェアメソッドは `{Check、Deliver、Simulate} Tx`に別のメソッドを使用し、アンティハンドラーは` Simulate bool`フラグを渡し、 `sdkCtx.Is {Check、Recheck} Tx()`フラグを使用してトランザクションモードです。 +-ミドルウェアの設計により、各ミドルウェアは次のミドルウェアへの参照を保持でき、ハンドラーは `AnteHandle`メソッドで` next`パラメーターを渡します。 +-ミドルウェアの設計ではGoの標準の `context.Context`を使用しますが、アンティハンドラーでは` sdk.Context`を使用します。 -## Consequences +## 結果 -### Backwards Compatibility +### 下位互換性 -Since this refactor removes some logic away from BaseApp and into middlewares, it introduces API-breaking changes for app developers. Most notably, instead of creating an antehandler chain in `app.go`, app developers need to create a middleware stack: +このリファクタリングは一部のロジックをBaseAppからミドルウェアに移動するため、アプリケーション開発者向けのAPIに重大な変更が加えられます。特に、アプリケーション開発者は `app.go`にアンティハンドラチェーンを作成する必要はありませんが、ミドルウェアスタックを作成する必要があります。 -```diff -- anteHandler, err := ante.NewAnteHandler( -- ante.HandlerOptions{ -- AccountKeeper: app.AccountKeeper, -- BankKeeper: app.BankKeeper, -- SignModeHandler: encodingConfig.TxConfig.SignModeHandler(), -- FeegrantKeeper: app.FeeGrantKeeper, -- SigGasConsumer: ante.DefaultSigVerificationGasConsumer, -- }, +`` `diff +-anteHandler、err:= ante.NewAnteHandler( +-ante.HandlerOptions { +-AccountKeeper:app.AccountKeeper、 +-BankKeeper:app.BankKeeper、 +-SignModeHandler:encodingConfig.TxConfig.SignModeHandler()、 +-FeegrantKeeper:app.FeeGrantKeeper、 +-SigGasConsumer:ante.DefaultSigVerificationGasConsumer、 +-}、 -) -+txHandler, err := authmiddleware.NewDefaultTxHandler(authmiddleware.TxHandlerOptions{ -+ Debug: app.Trace(), -+ IndexEvents: indexEvents, -+ LegacyRouter: app.legacyRouter, -+ MsgServiceRouter: app.msgSvcRouter, -+ LegacyAnteHandler: anteHandler, -+ TxDecoder: encodingConfig.TxConfig.TxDecoder, ++ txHandler、err:= authmiddleware.NewDefaultTxHandler(authmiddleware.TxHandlerOptions { ++デバッグ:app.Trace()、 ++ IndexEvents:indexEvents、 ++ LegacyRouter:app.legacyRouter、 ++ MsgServiceRouter:app.msgSvcRouter、 ++ LegacyAnteHandler:anteHandler、 ++ TxDecoder:encodingConfig.TxConfig.TxDecoder、 +}) -if err != nil { - panic(err) +err！= nil {の場合 + パニック(エラー) } -- app.SetAnteHandler(anteHandler) +-app.SetAnteHandler(anteHandler) + app.SetTxHandler(txHandler) -``` - -Other more minor API breaking changes will also be provided in the CHANGELOG. As usual, the Cosmos SDK will provide a release migration document for app developers. +`` ` -This ADR does not introduce any state-machine-, client- or CLI-breaking changes. +CHANGELOGは、他の小さなAPIの重大な変更も提供します。いつものように、Cosmos SDKは、アプリケーション開発者向けのバージョン移行ドキュメントを提供します。 -### Positive +このADRは、ステートマシン、クライアント、またはCLIに破壊的な変更を導入しません。 -- Allow custom logic to be run before an after `Msg` execution. This enables the [tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [gas refund](https://github.com/cosmos/cosmos-sdk/issues/2150) uses cases, and possibly other ones. -- Make BaseApp more lightweight, and defer complex logic to small modular components. -- Separate paths for `{Check,Deliver,Simulate}Tx` with different returns types. This allows for improved readability (replace `if sdkCtx.IsRecheckTx() && !simulate {...}` with separate methods) and more flexibility (e.g. returning a `priority` in `ResponseCheckTx`). +### ポジティブ -### Negative +-「メッセージ」の実行後にカスタムロジックを実行できるようにします。これにより、[ヒント](https://github.com/cosmos/cosmos-sdk/issues/9406)と[ガスの払い戻し](https://github.com/cosmos/cosmos-sdk/issues/2150)のユースケースが作成されます、他の場合もあります。 +-BaseAppをより軽量にし、複雑なロジックを小さなモジュラーコンポーネントに渡します。 +-異なるリターンタイプの `{Check、Deliver、Simulate} Tx`の個別のパス。これにより、読みやすさが向上し( `if sdkCtx.IsRecheckTx()&&！simulate {...}`を別のメソッドに置き換えます)、柔軟性が向上します(たとえば、 `ResponseCheckTx`で` priority`を返します)。 +### ネガティブ -- It is hard to understand at first glance the state updates that would occur after a middleware runs given the `sdk.Context` and `tx`. A middleware can have an arbitrary number of nested middleware being called within its function body, each possibly doing some pre- and post-processing before calling the next middleware on the chain. Thus to understand what a middleware is doing, one must also understand what every other middleware further along the chain is also doing, and the order of middlewares matters. This can get quite complicated to understand. -- API-breaking changes for app developers. +-一見すると、 `sdk.Context`と` tx`を指定してミドルウェアを実行した後に発生する状態の更新を理解するのは困難です。ミドルウェアは、その関数本体でネストされたミドルウェアをいくつでも呼び出すことができ、各ミドルウェアは、チェーン内の次のミドルウェアを呼び出す前に、前処理と後処理を実行する場合があります。したがって、ミドルウェアが何をしているのかを理解するには、チェーン内の他のミドルウェアも何をしているのかを理解する必要があります。ミドルウェアの順序は非常に重要です。これは理解するのが非常に難しくなる可能性があります。 +-アプリケーション開発者向けのAPIへの画期的な変更。 -### Neutral +### ニュートラル -No neutral consequences. +中立的な結果はありません。 -## Further Discussions +## さらなる議論 -- [#9934](https://github.com/cosmos/cosmos-sdk/discussions/9934) Decomposing BaseApp's other ABCI methods into middlewares. -- Replace `sdk.Tx` interface with the concrete protobuf Tx type in the `tx.Handler` methods signature. +-[#9934](https://github.com/cosmos/cosmos-sdk/discussions/9934)BaseAppの他のABCIメソッドをミドルウェアに分解します。 +-`sdk.Tx`インターフェースを `tx.Handler`メソッドシグネチャの具象protobufTxタイプに置き換えます。 -## Test Cases +## テストケース -We update the existing baseapp and antehandlers tests to use the new middleware API, but keep the same test cases and logic, to avoid introducing regressions. Existing CLI tests will also be left untouched. +新しいミドルウェアAPIを使用するように既存のbaseappテストとantehandlersテストを更新しますが、リグレッションの発生を避けるために同じテストケースとロジックを維持します。既存のCLIテストも変更されません。 -For new middlewares, we introduce unit tests. Since middlewares are purposefully small, unit tests suit well. +新しいミドルウェアについては、単体テストを導入しました。ミドルウェアは小さいので、単体テストは非常に適しています。 -## References +## 参照する -- Initial discussion: https://github.com/cosmos/cosmos-sdk/issues/9585 -- Implementation: [#9920 BaseApp refactor](https://github.com/cosmos/cosmos-sdk/pull/9920) and [#10028 Antehandlers migration](https://github.com/cosmos/cosmos-sdk/pull/10028) +-予備的なディスカッション:https://github.com/cosmos/cosmos-sdk/issues/9585 +-実装:[#9920 BaseAppリファクタリング](https://github.com/cosmos/cosmos-sdk/pull/9920)および[#10028アンティハンドラーの移行](https://github.com/cosmos/cosmos-sdk.プル.10028) \ No newline at end of file diff --git a/docs/ja/architecture/adr-046-module-params.md b/docs/ja/architecture/adr-046-module-params.md index 520c79884e82..b90c79d6525d 100644 --- a/docs/ja/architecture/adr-046-module-params.md +++ b/docs/ja/architecture/adr-046-module-params.md @@ -1,56 +1,56 @@ -# ADR 046: Module Params +# ADR 046:モジュールパラメータ -## Changelog +## 変更ログ -- Sep 22, 2021: Initial Draft +-2021年9月22日:最初のドラフト -## Status +## 状態 -Proposed +提案 -## Abstract +## 概要 -This ADR describes an alternative approach to how Cosmos SDK modules use, interact, -and store their respective parameters. +このADRは、使用方法、相互作用方法、 +そして、それぞれのパラメータを保存します。 -## Context +## 環境 -Currently, in the Cosmos SDK, modules that require the use of parameters use the -`x/params` module. The `x/params` works by having modules define parameters, -typically via a simple `Params` structure, and registering that structure in -the `x/params` module via a unique `Subspace` that belongs to the respective -registering module. The registering module then has unique access to its respective -`Subspace`. Through this `Subspace`, the module can get and set its `Params` -structure. +現在、Cosmos SDKでは、パラメーターを使用する必要のあるモジュールが使用されています +`x .params`モジュール。 `x .params`は、モジュールにパラメータを定義させることで機能します。 +通常、単純な「Params」構造を介して、構造をに登録します +`x .params`モジュールは固有の` Subspace`を通過します +モジュールを登録します。次に、登録モジュールはそれぞれに一意にアクセスできます +`部分空間`。この `Subspace`を介して、モジュールはその` Params`を取得および設定できます。 +構造。 -In addition, the Cosmos SDK's `x/gov` module has direct support for changing -parameters on-chain via a `ParamChangeProposal` governance proposal type, where -stakeholders can vote on suggested parameter changes. +さらに、CosmosSDKの `x .gov`モジュールは変更を直接サポートします +「ParamChangeProposal」ガバナンス提案タイプを介してチェーンにパラメーターを設定します。ここで、 +利害関係者は、提案されたパラメーターの変更に投票できます。 -There are various tradeoffs to using the `x/params` module to manage individual -module parameters. Namely, managing parameters essentially comes for "free" in -that developers only need to define the `Params` struct, the `Subspace`, and the -various auxiliary functions, e.g. `ParamSetPairs`, on the `Params` type. However, -there are some notable drawbacks. These drawbacks include the fact that parameters -are serialized in state via JSON which is extremely slow. In addition, parameter -changes via `ParamChangeProposal` governance proposals have no way of reading from -or writing to state. In other words, it is currently not possible to have any -state transitions in the application during an attempt to change param(s). +`x .params`モジュールを使用して単一を管理します +モジュールパラメータ。言い換えれば、管理パラメータは本質的に「無料」です +開発者は、 `Params`構造、` Subspace`、および +`ParamSetPairs`などのさまざまな補助関数は` Params`タイプにあります。でも、 +明らかな欠点がいくつかあります。これらの欠点には、パラメータが含まれます +非常に遅いJSONを介して状態でシリアル化します。さらに、パラメータ +`ParamChangeProposal`ガバナンス提案を通じて行われた変更は読み取ることができません +または国に書いてください。言い換えれば、 +パラメータを変更しようとしたときのアプリケーションの状態遷移。 -## Decision +## 決定 -We will build off of the alignment of `x/gov` and `x/authz` work per -[#9810](https://github.com/cosmos/cosmos-sdk/pull/9810). Namely, module developers -will create one or more unique parameter data structures that must be serialized -to state. The Param data structures must implement `sdk.Msg` interface with respective -Protobuf Msg service method which will validate and update the parameters with all -necessary changes. The `x/gov` module via the work done in -[#9810](https://github.com/cosmos/cosmos-sdk/pull/9810), will dispatch Param -messages, which will be handled by Protobuf Msg services. +`x .gov`と` x .authz`の配置に基づいて構築します +[#9810](https://github.com/cosmos/cosmos-sdk/pull/9810)。モジュール開発者 +シリアル化する必要がある1つ以上の一意のパラメータデータ構造を作成します +声明。 Paramデータ構造は、 `sdk.Msg`インターフェースとそれぞれを実装する必要があります +Protobuf Msgサービスメソッド、すべてのパラメータを検証および更新します +必要な変更。 `x .gov`モジュールが渡されます +[#9810](https://github.com/cosmos/cosmos-sdk/pull/9810)、Paramがスケジュールされます +メッセージはProtobufMsgサービスによって処理されます。 -Note, it is up to developers to decide how to structure their parameters and -the respective `sdk.Msg` messages. Consider the parameters currently defined in -`x/auth` using the `x/params` module for parameter management: +パラメータを構造化する方法を決定するのは開発者次第であることに注意してください。 +対応する `sdk.Msg`メッセージ。現在定義されているパラメータを検討してください +`x .auth`はパラメータ管理に` x .params`モジュールを使用します。 ```protobuf message Params { @@ -62,22 +62,21 @@ message Params { } ``` -Developers can choose to either create a unique data structure for every field in -`Params` or they can create a single `Params` structure as outlined above in the -case of `x/auth`. +开发人员可以选择为每个字段创建唯一的数据结构 +`Params` 或者他们可以创建一个单一的 `Params` 结构，如上所述 +“x/auth”的情况。 -In the former, `x/params`, approach, a `sdk.Msg` would need to be created for every single -field along with a handler. This can become burdensome if there are a lot of -parameter fields. In the latter case, there is only a single data structure and -thus only a single message handler, however, the message handler might have to be -more sophisticated in that it might need to understand what parameters are being -changed vs what parameters are untouched. +在前者中，`x/params` 方法，需要为每个单独的创建一个 `sdk.Msg` +字段以及处理程序。 如果有很多，这可能会成为负担 +参数字段。 在后一种情况下，只有一个数据结构和 +因此只有一个消息处理程序，但是，消息处理程序可能必须是 +更复杂，因为它可能需要了解正在使用的参数 +更改与未更改的参数。 -Params change proposals are made using the `x/gov` module. Execution is done through -`x/authz` authorization to the root `x/gov` module's account. - -Continuing to use `x/auth`, we demonstrate a more complete example: +参数更改建议是使用 `x/gov` 模块提出的。 执行是通过 +`x/authz` 授权给根 `x/gov` 模块的帐户。 +继续使用`x/auth`，我们演示一个更完整的例子: ```go type Params struct { MaxMemoCharacters uint64 @@ -100,9 +99,9 @@ type MsgUpdateParamsResponse struct {} func (ms msgServer) UpdateParams(goCtx context.Context, msg *types.MsgUpdateParams) (*types.MsgUpdateParamsResponse, error) { ctx := sdk.UnwrapSDKContext(goCtx) - // verification logic... + ..verification logic... - // persist params + ..persist params params := ParamsFromMsg(msg) ms.SaveParams(ctx, params) @@ -110,15 +109,15 @@ func (ms msgServer) UpdateParams(goCtx context.Context, msg *types.MsgUpdatePara } func ParamsFromMsg(msg *types.MsgUpdateParams) Params { - // ... + ..... } ``` -A gRPC `Service` query should also be provided, for example: +gRPCの `Service`クエリも提供する必要があります。次に例を示します。 ```protobuf service Query { - // ... + ..... rpc Params(QueryParamsRequest) returns (QueryParamsResponse) { option (google.api.http).get = "/cosmos//v1beta1/params"; @@ -130,55 +129,53 @@ message QueryParamsResponse { } ``` -## Consequences - -As a result of implementing the module parameter methodology, we gain the ability -for module parameter changes to be stateful and extensible to fit nearly every -application's use case. We will be able to emit events (and trigger hooks registered -to that events using the work proposed in [even hooks](https://github.com/cosmos/cosmos-sdk/discussions/9656)), -call other Msg service methods or perform migration. -In addition, there will be significant gains in performance when it comes to reading -and writing parameters from and to state, especially if a specific set of parameters -are read on a consistent basis. - -However, this methodology will require developers to implement more types and -Msg service metohds which can become burdensome if many parameters exist. In addition, -developers are required to implement persistance logics of module parameters. -However, this should be trivial. +## 結果 -### Backwards Compatibility +モジュールパラメータメソッドを実装した結果、 +モジュールパラメータの変更をステートフルで拡張可能にして、ほぼすべてに適応できるようにします +アプリケーションのユースケース。イベントを発行する(そして登録されたフックをトリガーする)ことができるようになります +[偶数フック](https://github.com/cosmos/cosmos-sdk/discussions/9656))で提案された作業のイベントを使用します。 +他のメッセージサービスメソッドを呼び出すか、移行を実行します。 +さらに、読書のパフォーマンスが大幅に向上します +そして、特に特定のパラメータのセットの場合、状態との間でパラメータを書き込みます +一貫して読んでください。 -The new method for working with module parameters is naturally not backwards -compatible with the existing `x/params` module. However, the `x/params` will -remain in the Cosmos SDK and will be marked as deprecated with no additional -functionality being added apart from potential bug fixes. Note, the `x/params` -module may be removed entirely in a future release. +ただし、このアプローチでは、開発者はより多くのタイプを実装する必要があり、 +パラメータが多いと、メッセージサービスの方法が煩雑になる場合があります。また、 +開発者は、モジュールパラメータの永続ロジックを実装する必要があります。 +ただし、これは些細なことです。 -### Positive +### 下位互換性 -- Module parameters are serialized more efficiently -- Modules are able to react on parameters changes and perform additional actions. -- Special events can be emitted, allowing hooks to be triggered. +モジュールパラメータを処理する新しい方法は、当然、逆行しません。 +既存の `x .params`モジュールと互換性があります。ただし、 `x .params`は +Cosmos SDKに保持し、非推奨としてマークされ、追加されなくなります +潜在的なバグ修正に加えて、機能も追加されました。 `x .params`に注意してください +モジュールは、将来のバージョンで完全に削除される可能性があります。 +### ポジティブ -### Negative +-モジュールパラメータをより効率的にシリアル化する +-モジュールはパラメータの変更に反応し、他の操作を実行できます。 +-特別なイベントを発行して、フックをトリガーすることができます。 +### ネガティブ -- Module parameters becomes slightly more burdensome for module developers: - - Modules are now responsible for persisting and retrieving parameter state - - Modules are now required to have unique message handlers to handle parameter - changes per unique parameter data structure. +-モジュールパラメータは、モジュール開発者にとって少し負担になります。 + -モジュールは、パラメータ状態の永続化と取得を担当するようになりました + -モジュールには、パラメーターを処理するための一意のメッセージハンドラーが必要です。 + 各固有のパラメーターのデータ構造の変更。 -### Neutral +### ニュートラル -- Requires [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810) to be reviewed - and merged. +-[#9810](https://github.com/cosmos/cosmos-sdk/pull/9810)を確認する必要があります + とマージされました。 - +ADRがドラフトまたは提案段階にある間、このセクションには、将来の反復で解決される問題の要約が含まれている必要があります(通常はプルリクエストディスカッションからのコメントを参照します)。 +後で、このセクションでは、このADRの分析中に作成者またはレビュー担当者が見つけたアイデアや改善点をオプションで一覧表示できます。-> -## References +## 参照 -- https://github.com/cosmos/cosmos-sdk/pull/9810 -- https://github.com/cosmos/cosmos-sdk/issues/9438 -- https://github.com/cosmos/cosmos-sdk/discussions/9913 +-https://github.com/cosmos/cosmos-sdk/pull/9810 +-https://github.com/cosmos/cosmos-sdk/issues/9438 +-https://github.com/cosmos/cosmos-sdk/discussions/9913 \ No newline at end of file diff --git a/docs/ja/basics/README.md b/docs/ja/basics/README.md index 0446a72d08b3..d69f5ea83586 100644 --- a/docs/ja/basics/README.md +++ b/docs/ja/basics/README.md @@ -1,11 +1,11 @@ -# Basics +# 基本 -This repository contains reference documentation on the basic concepts of the Cosmos SDK. +此存储库包含有关 Cosmos SDK 基本概念的参考文档。 -1. [Anatomy of a Cosmos 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) +1. [Cosmos SDK 应用剖析](./app-anatomy.md) +2. [交易的生命周期](./tx-lifecycle.md) +3. [查询的生命周期](./query-lifecycle.md) +4. [账户](./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. +阅读基础知识后，请前往 [核心参考](../core/README.md) 获取更高级的材料。 \ No newline at end of file diff --git a/docs/ja/basics/accounts.md b/docs/ja/basics/accounts.md index 3727de86b06f..797f0ac054b4 100644 --- a/docs/ja/basics/accounts.md +++ b/docs/ja/basics/accounts.md @@ -1,17 +1,16 @@ -# Accounts +# 帐户 -This document describes the in-built account and public key system of the Cosmos SDK. {synopsis} +本文档介绍了 Cosmos SDK 的内置账号和公钥系统。 {概要} -### Pre-requisite Readings +### 先决条件阅读 -- [Anatomy of a Cosmos SDK Application](./app-anatomy.md) {prereq} +- [Cosmos SDK 应用剖析](./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`. - -For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). The BIP32 allows users to create an HD wallet (as specified in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) - a set of accounts derived from an initial secret seed. A seed is usually created from a 12- or 24-word mnemonic. A single seed can derive any number of `PrivKey`s using a 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. +在 Cosmos SDK 中，一个 _account_ 指定一对 _public key_ `PubKey` 和 _private key_ `PrivKey`。可以派生出“公钥”以生成各种“地址”，用于识别应用程序中的用户(以及其他方)。 `Addresses` 还与 [`message`s](../building-modules/messages-and-queries.md#messages) 相关联，以识别 `message` 的发送者。 `PrivKey` 用于生成[数字签名](#signatures) 以证明与给定的“消息”的“PrivKey”关联的“地址”。 +对于 HD 密钥派生，Cosmos SDK 使用称为 [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) 的标准。 BIP32 允许用户创建一个 HD 钱包(如 [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) 中指定的)——一组源自初始秘密的账户种子。种子通常由 12 或 24 字的助记符创建。单个种子可以使用单向加密函数派生任意数量的“PrivKey”。然后，可以从 `PrivKey` 派生出一个 `PubKey`。自然地，助记符是最敏感的信息，因为如果保留助记符，私钥总是可以重新生成的。 ``` Account 0 Account 1 Account 2 @@ -52,19 +51,19 @@ For HD key derivation the Cosmos SDK uses a standard called [BIP32](https://gith +-------------------+ ``` -In the Cosmos SDK, keys are stored and managed by using an object called a [`Keyring`](#keyring). +在 Cosmos SDK 中，密钥是通过一个名为 [`Keyring`](#keyring) 的对象来存储和管理的。 -## Keys, accounts, addresses, and signatures +## 密钥、帐户、地址和签名 -The principal way of authenticating a user is done using [digital signatures](https://en.wikipedia.org/wiki/Digital_signature). Users sign transactions using their own private key. Signature verification is done with the associated public key. For on-chain signature verification purposes, we store the public key in an `Account` object (alongside other data required for a proper transaction validation). +对用户进行身份验证的主要方式是使用 [数字签名](https://en.wikipedia.org/wiki/Digital_signature)。用户使用自己的私钥签署交易。签名验证是使用关联的公钥完成的。出于链上签名验证的目的，我们将公钥存储在“Account”对象中(以及正确交易验证所需的其他数据)。 -In the node, all data is stored using Protocol Buffers serialization. +在节点中，所有数据都使用 Protocol Buffers 序列化存储。 -The Cosmos SDK supports the following digital key schemes for creating digital signatures: +Cosmos SDK 支持以下用于创建数字签名的数字密钥方案: -- `secp256k1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256k1` package](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/crypto/keys/secp256k1/secp256k1.go). -- `secp256r1`, as implemented in the [Cosmos SDK's `crypto/keys/secp256r1` package](https://github.com/cosmos/cosmos-sdk/blob/master/crypto/keys/secp256r1/pubkey.go), -- `tm-ed25519`, as implemented in the [Cosmos SDK `crypto/keys/ed25519` package](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/crypto/keys/ed25519/ed25519.go). This scheme is supported only for the consensus validation. +- `secp256k1`，在 [Cosmos SDK 的 `crypto/keys/secp256k1` 包中实现](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/crypto/keys/secp256k1/secp256k1。去)。 +- `secp256r1`，在 [Cosmos SDK 的 `crypto/keys/secp256r1` 包中实现](https://github.com/cosmos/cosmos-sdk/blob/master/crypto/keys/secp256r1/pubkey.go) , +- `tm-ed25519`，在 [Cosmos SDK `crypto/keys/ed25519` 包中实现](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/crypto/keys/ed25519/ ed25519.go)。该方案仅支持共识验证。 | | Address length in bytes | Public key length in bytes | Used for transaction authentication | Used for consensus (tendermint) | |:------------:|:-----------------------:|:--------------------------:|:-----------------------------------:|:-------------------------------:| @@ -72,30 +71,30 @@ The Cosmos SDK supports the following digital key schemes for creating digital s | `secp256r1` | 32 | 33 | yes | no | | `tm-ed25519` | -- not used -- | 32 | no | yes | -## Addresses +## 地址 -`Addresses` and `PubKey`s are both public information that identifies actors in the application. `Account` is used to store authentication information. The basic account implementation is provided by a `BaseAccount` object. +`Addresses` 和 `PubKey`s 都是识别应用程序中参与者的公共信息。 `Account` 用于存储认证信息。基本帐户实现由“BaseAccount”对象提供。 -Each account is identified using `Address` which is a sequence of bytes derived from a public key. In the Cosmos SDK, we define 3 types of addresses that specify a context where an account is used: +每个帐户都使用“地址”标识，地址是从公钥派生的字节序列。在 Cosmos SDK 中，我们定义了 3 种地址类型，用于指定使用帐户的上下文: -- `AccAddress` identifies users (the sender of a `message`). -- `ValAddress` identifies validator operators. -- `ConsAddress` identifies validator nodes that are participating in consensus. Validator nodes are derived using the **`ed25519`** curve. +- `AccAddress` 标识用户(`message` 的发送者)。 +- `ValAddress` 标识验证器操作符。 +- `ConsAddress` 标识参与共识的验证器节点。验证器节点是使用 **`ed25519`** 曲线导出的。 -These types implement the `Address` interface: +这些类型实现了 `Address` 接口: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/types/address.go#L71-L90 -Address construction algorithm is defined in [ADR-28](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses.md). -Here is the standard way to obtain an account address from a `pub` public key: +地址构建算法在[ADR-28](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses.md)中定义。 +以下是从“pub”公钥获取帐户地址的标准方法: ```go sdk.AccAddress(pub.Address().Bytes()) ``` -Of note, the `Marshal()` and `Bytes()` method both return the same raw `[]byte` form of the address. `Marshal()` is required for Protobuf compatibility. +值得注意的是，`Marshal()` 和 `Bytes()` 方法都返回地址的相同原始 `[]byte` 形式。 `Marshal()` 是 Protobuf 兼容性所必需的。 -For user interaction, addresses are formatted using [Bech32](https://en.bitcoin.it/wiki/Bech32) and implemented by the `String` method. The Bech32 method is the only supported format to use when interacting with a blockchain. The Bech32 human-readable part (Bech32 prefix) is used to denote an address type. Example: +对于用户交互，地址使用 [Bech32](https://en.bitcoin.it/wiki/Bech32) 格式化并通过 `String` 方法实现。 Bech32 方法是与区块链交互时唯一支持使用的格式。 Bech32 人类可读部分(Bech32 前缀)用于表示地址类型。 例子: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/types/address.go#L230-L244 @@ -105,44 +104,44 @@ For user interaction, addresses are formatted using [Bech32](https://en.bitcoin. | Validator Operator | cosmosvaloper | | Consensus Nodes | cosmosvalcons | -### Public Keys +### 公钥 -Public keys in Cosmos SDK are defined by `cryptotypes.PubKey` interface. Since public keys are saved in a store, `cryptotypes.PubKey` extends the `proto.Message` interface: +Cosmos SDK 中的公钥由`cryptotypes.PubKey` 接口定义。由于公钥保存在存储中，`cryptotypes.PubKey` 扩展了 `proto.Message` 接口: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/crypto/types/types.go#L8-L17 -A compressed format is used for `secp256k1` and `secp256r1` serialization. +压缩格式用于“secp256k1”和“secp256r1”序列化。 -- 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`. +- 第一个字节是一个 0x02 字节，如果 `y` 坐标是与 `x` 坐标相关的两个字节中字典序最大的。 +- 否则第一个字节是“0x03”。 -This prefix is followed by the `x`-coordinate. +此前缀后跟“x”坐标。 -Public Keys are not used to reference accounts (or users) and in general are not used when composing transaction messages (with few exceptions: `MsgCreateValidator`, `Validator` and `Multisig` messages). -For user interactions, `PubKey` is formatted using Protobufs JSON ([ProtoMarshalJSON](https://github.com/cosmos/cosmos-sdk/blob/release/v0.42.x/codec/json.go#L12) function). Example: +公钥不用于引用帐户(或用户)，通常在编写交易消息时不使用(除了少数例外:`MsgCreateValidator`、`Validator` 和 `Multisig` 消息)。 +对于用户交互，`PubKey` 使用 Protobufs JSON ([ProtoMarshalJSON](https://github.com/cosmos/cosmos-sdk/blob/release/v0.42.x/codec/json.go#L12) 函数格式化)。例子: +++ https://github.com/cosmos/cosmos-sdk/blob/7568b66/crypto/keyring/output.go#L23-L39 -## Keyring +## 钥匙圈 -A `Keyring` is an object that stores and manages accounts. In the Cosmos SDK, a `Keyring` implementation follows the `Keyring` interface: +`Keyring` 是一个存储和管理帐户的对象。在 Cosmos SDK 中，Keyring 实现遵循 Keyring 接口: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/crypto/keyring/keyring.go#L51-L89 -The default implementation of `Keyring` comes from the third-party [`99designs/keyring`](https://github.com/99designs/keyring) library. +`Keyring` 的默认实现来自第三方 [`99designs/keyring`](https://github.com/99designs/keyring) 库。 -A few notes on the `Keyring` methods: +关于“Keyring”方法的一些注意事项: -- `Sign(uid string, payload []byte) ([]byte, sdkcrypto.PubKey, error)` strictly deals with the signature of the `payload` bytes. You must prepare and encode the transaction into a canonical `[]byte` form. Because protobuf is 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 Cosmos SDK by default, it is deferred to the [`anteHandler`](../core/baseapp.md#antehandler). +- `Sign(uid string, payload []byte) ([]byte, sdkcrypto.PubKey, error)`严格处理`payload`字节的签名。您必须准备交易并将其编码为规范的 `[]byte` 形式。因为 protobuf 不是确定性的，所以在 [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) 中已经确定要签名的规范 `payload` 是 `SignDoc` 结构，确定性使用 [ADR-027](adr-027-deterministic-protobuf-serialization.md) 编码。请注意，Cosmos SDK 中默认没有实现签名验证，它推迟到 [`anteHandler`](../core/baseapp.md#antehandler)。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/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. The `PrivKey` is **never stored unencrypted**, instead it is [encrypted with a passphrase](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/armor.go) before being persisted. In the context of this method, the key type and sequence number refer to the segment of the BIP44 derivation path (for example, `0`, `1`, `2`, ...) that is used to derive a private and a public key from the mnemonic. Using the same mnemonic and derivation path, the same `PrivKey`, `PubKey` and `Address` is generated. The following keys are supported by the keyring: +- `NewAccount(uid, mnemonic, bip39Passwd, hdPath string, algo SignatureAlgo) (Info, error)` 基于 [`bip44 path`](https://github.com/bitcoin/bips/blob/) 创建一个新账户master/bip-0044.mediawiki)并将其保存在磁盘上。 `PrivKey` **永远不会未加密存储**，而是 [使用密码加密](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/crypto/armor.go ) 之前被坚持。在此方法的上下文中，密钥类型和序列号指的是 BIP44 派生路径中用于派生私有和助记符中的公钥。使用相同的助记符和派生路径，生成相同的`PrivKey`、`PubKey`和`Address`。密钥环支持以下密钥: -- `secp256k1` -- `ed25519` +-`secp256k1` +-`ed25519` -- `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 the private key 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. +- `ExportPrivKeyArmor(uid, encryptPassphrase string) (armor string, err error)` 使用给定的密码以 ASCII 装甲加密格式导出私钥。然后，您可以使用 `ImportPrivKey(uid, Armor, passphrase string)` 函数将私钥再次导入密钥环，或者使用 `UnarmorDecryptPrivKey(armorStr string, passphrase string)` 函数将其解密为原始私钥。 -## Next {hide} +## 下一个 {hide} -Learn about [gas and fees](./gas-fees.md) {hide} +了解 [gas 和费用](./gas-fees.md) {hide} \ No newline at end of file diff --git a/docs/ja/basics/app-anatomy.md b/docs/ja/basics/app-anatomy.md index f3fdab68f5da..6882d210f779 100644 --- a/docs/ja/basics/app-anatomy.md +++ b/docs/ja/basics/app-anatomy.md @@ -1,10 +1,10 @@ -# Anatomy of a Cosmos SDK Application +# Cosmos SDK 应用剖析 -This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used. {synopsis} +本文档描述了 Cosmos SDK 应用程序的核心部分。 在整个文档中，将使用名为“app”的占位符应用程序。 {概要} -## Node Client +## 节点客户端 -The Daemon, or [Full-Node Client](../core/node.md), is the core process of a Cosmos 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. +Daemon 或 [Full-Node Client](../core/node.md) 是基于 Cosmos SDK 的区块链的核心进程。 网络中的参与者运行这个过程来初始化他们的状态机，与其他全节点连接并在新块进入时更新他们的状态机。 ``` ^ +-------------------------------+ ^ @@ -24,226 +24,226 @@ Blockchain Node | | Consensus | | 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). +区块链全节点将自己呈现为二进制文件，通常后缀“-d”表示“守护进程”(例如，“appd”表示“app”或“gaiad”表示“gaia”)。这个二进制文件是通过运行一个简单的 [`main.go`](../core/node.md#main-function) 函数来构建的，该函数放置在 `./cmd/appd/` 中。此操作通常通过 [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: +构建主二进制文件后，可以通过运行 [`start` 命令](../core/node.md#start-command) 来启动节点。这个命令函数主要做三件事: -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 `~/.app/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). +1.创建一个在[`app.go`](#core-application-file)中定义的状态机实例。 +2. 使用从存储在`~/.app/data` 文件夹中的`db` 中提取的最新已知状态初始化状态机。此时，状态机处于“appBlockHeight”高度。 +3. 创建并启动一个新的 Tendermint 实例。除其他事项外，该节点将与其对等方执行握手。它将从它们那里获取最新的 `blockHeight`，如果它大于本地 `appBlockHeight`，则重放块以同步到这个高度。如果`appBlockHeight`为`0`，则节点从创世开始，Tendermint通过ABCI向`app`发送`InitChain`消息，触发[`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**. +通常，状态机的核心定义在名为“app.go”的文件中。它主要包含**应用程序的类型定义**和**创建和初始化应用程序**的函数。 -### 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: +`app.go` 中定义的第一件事是应用程序的 `type`。它一般由以下几部分组成: -- **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 Cosmos 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). +- **对[`baseapp`](../core/baseapp.md)的引用。**`app.go`中定义的自定义应用程序是`baseapp`的扩展。当 Tendermint 将交易中继到应用程序时，`app` 使用 `baseapp` 的方法将它们路由到适当的模块。 `baseapp` 实现了应用程序的大部分核心逻辑，包括所有 [ABCI 方法](https://tendermint.com/docs/spec/abci/abci.html#overview) 和 [路由逻辑](../core/baseapp.md#routing)。 +- **存储键列表**。包含整个状态的 [store](../core/store.md) 在Cosmos SDK。每个模块使用 multistore 中的一个或多个 store 来持久化它们的状态部分。可以使用在“app”类型中声明的特定键来访问这些存储。这些键和 `keepers` 是 Cosmos SDK [对象功能模型](../core/ocap.md) 的核心。 +- **模块的`keeper`s 列表。** 每个模块都定义了一个名为[`keeper`](../building-modules/keeper.md) 的抽象，它处理这个模块存储的读写.一个模块的`keeper`的方法可以从其他模块(如果授权)调用，这就是为什么它们在应用程序的类型中声明并作为接口导出到其他模块，以便后者只能访问授权的功能。 +- **对 [`appCodec`](../core/encoding.md) 的引用。** 应用程序的 `appCodec` 用于序列化和反序列化数据结构以存储它们，因为存储只能持久化` []字节`。默认编解码器是 [Protocol Buffers](../core/encoding.md)。 +- **对 [`legacyAmino`](../core/encoding.md) 编解码器的引用。** Cosmos SDK 的某些部分尚未迁移到使用上面的 `appCodec`，并且仍然硬编码使用氨基。其他部分明确使用 Amino 以实现向后兼容性。由于这些原因，该应用程序仍然保留对旧版 Amino 编解码器的引用。请注意，Amino 编解码器将在即将发布的版本中从 SDK 中删除。 +- **对 [模块管理器](../building-modules/module-manager.md#manager)** 和 [基本模块管理器](../building-modules/module-manager.md# 的引用基本管理器)。模块管理器是一个包含应用程序模块列表的对象。它促进了与这些模块相关的操作，例如注册它们的 [`Msg` 服务](../core/baseapp.md#msg-services) 和 [gRPC `Query` 服务](../core/baseapp.md#grpc -query-services)，或为各种功能设置模块之间的执行顺序，如 [`InitChainer`](#initchainer)、[`BeginBlocker` 和 `EndBlocker`](#beginblocker-and-endblocker)。 -See an example of application type definition from `simapp`, the Cosmos SDK's own app used for demo and testing purposes: +请参阅“simapp”中的应用程序类型定义示例，Cosmos SDK 自己的应用程序用于演示和测试目的: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L145-L187 -### 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. +该函数构造了一个新的应用程序，该应用程序的类型在上一节中定义。它必须满足 `AppCreator` 签名才能在应用程序守护程序命令的 [`start` 命令](../core/node.md#start-command) 中使用。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/types/app.go#L48-L50 -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 Cosmos 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`, `BeginBlocker` and `EndBlocker` functions of each of the [application's modules](#application-module-interface). Note that not all modules implement these functions. -- Set the remainder 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. +- 实例化一个新的 [`codec`](../core/encoding.md) 并使用 [basic manager](../building-modules/module-manager.md) 初始化每个应用程序模块的 `codec` #basicmanager) +- 使用对“baseapp”实例、编解码器和所有适当存储键的引用来实例化新应用程序。 +- 使用每个应用程序模块的`NewKeeper` 函数实例化应用程序`type` 中定义的所有[`keeper`s](#keeper)。请注意，`keepers` 必须以正确的顺序实例化，因为一个模块的 `NewKeeper` 可能需要引用另一个模块的 `keeper`。 +- 使用每个应用程序模块的 [`AppModule`](#application-module-interface) 对象实例化应用程序的 [模块管理器](../building-modules/module-manager.md#manager)。 +- 使用模块管理器，初始化应用程序的 [`Msg` 服务](../core/baseapp.md#msg-services), [gRPC `Query` 服务](../core/baseapp.md#grpc-query -services)、[旧版`Msg` 路由](../core/baseapp.md#routing) 和[旧版查询路由](../core/baseapp.md#query-routing)。当 Tendermint 通过 ABCI 将交易中继到应用程序时，它会使用此处定义的路由路由到相应模块的 [`Msg` 服务](#msg-services)。同样，当应用程序接收到 gRPC 查询请求时，它会使用此处定义的 gRPC 路由路由到相应模块的 [`gRPC 查询服务`](#grpc-query-services)。 Cosmos SDK 仍然支持旧版 `Msg` 和旧版 Tendermint 查询，它们分别使用旧版 `Msg` 路由和旧版查询路由进行路由。 +- 使用模块管理器，注册[应用程序模块的不变量](../building-modules/invariants.md)。不变量是在每个块结束时评估的变量(例如令牌的总供应量)。检查不变量的过程是通过一个称为 [`InvariantsRegistry`](../building-modules/invariants.md#invariant-registry) 的特殊模块完成的。不变量的值应等于模块中定义的预测值。如果该值与预测值不同，则将触发不变注册表中定义的特殊逻辑(通常会停止链)。这有助于确保没有严重错误被忽视并产生难以修复的持久影响。 +- 使用模块管理器，设置每个[应用程序模块](#application-module-interface) 的`InitGenesis`、`BeginBlocker` 和`EndBlocker` 函数之间的执行顺序。请注意，并非所有模块都实现了这些功能。 +- 设置应用程序的其余参数: + - [`InitChainer`](#initchainer):用于在应用程序第一次启动时对其进行初始化。 + - [`BeginBlocker`, `EndBlocker`](#beginblocker-and-endlbocker):在每个块的开头和结尾调用)。 + - [`anteHandler`](../core/baseapp.md#antehandler):用于处理费用和签名验证。 +- 安装存储。 +- 退回申请。 -Note that this function only creates an instance of the app, while the actual state is either carried over from the `~/.app/data` folder if the node is restarted, or generated from the genesis file if the node is started for the first time. +请注意，此函数仅创建应用程序的一个实例，而实际状态要么在节点重新启动时从`~/.app/data` 文件夹中转移过来，要么在节点启动时从创世文件中生成。第一次。 -See an example of application constructor from `simapp`: +请参阅“simapp”中的应用程序构造函数示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L198-L441 ### 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. +`InitChainer` 是一个函数，它从创世文件(即创世账户的代币余额)初始化应用程序的状态。当应用程序从 Tendermint 引擎接收到 `InitChain` 消息时调用它，这发生在节点在 `appBlockHeight == 0` 处启动时(即在创世时)。应用程序必须通过 [`SetInitChainer`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetInitChainer) 在其 [构造函数](#constructor-function) 中设置 `InitChainer` ) 方法。 -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`. +一般来说，`InitChainer` 主要由应用程序各个模块的 [`InitGenesis`](../building-modules/genesis.md#initgenesis) 函数组成。这是通过调用模块管理器的 `InitGenesis` 函数来完成的，模块管理器又会调用它包含的每个模块的 `InitGenesis` 函数。请注意，必须使用 [模块管理器的](../building-modules/module-manager.md) `SetOrderInitGenesis` 方法在模块管理器中设置必须调用模块的 `InitGenesis` 函数的顺序。这是在[应用程序的构造函数](#application-constructor) 中完成的，并且必须在“SetInitChainer”之前调用“SetOrderInitGenesis”。 -See an example of an `InitChainer` from `simapp`: +请参阅“simapp”中的“InitChainer”示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L464-L471 ### BeginBlocker and EndBlocker -The Cosmos 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. +Cosmos SDK 为开发人员提供了将代码自动执行作为其应用程序的一部分的可能性。这是通过两个名为“BeginBlocker”和“EndBlocker”的函数实现的。当应用程序分别从 Tendermint 引擎接收到 `BeginBlock` 和 `EndBlock` 消息时调用它们，这发生在每个块的开头和结尾。应用程序必须通过 [`SetBeginBlocker`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp) 在其 [构造函数](#constructor-function) 中设置 `BeginBlocker` 和 `EndBlocker` #BaseApp.SetBeginBlocker) 和 [`SetEndBlocker`](https://godoc.org/github.com/cosmos/cosmos-sdk/baseapp#BaseApp.SetEndBlocker) 方法。 -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' `BeginBlock` 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. +一般来说，`BeginBlocker` 和`EndBlocker` 函数主要由每个应用程序模块的[`BeginBlock` 和`EndBlock`](../building-modules/beginblock-endblock.md) 函数组成。这是通过调用模块管理器的`BeginBlock` 和`EndBlock` 函数来完成的，模块管理器又会调用它包含的每个模块的`BeginBlock` 和`EndBlock` 函数。请注意，必须分别使用“SetOrderBeginBlock”和“SetOrderEndBlock”方法在模块管理器中设置必须调用模块“BeginBlock”和“EndBlock”函数的顺序。这是通过[应用程序的构造函数](#application-constructor)中的[模块管理器](../building-modules/module-manager.md)完成的，并且必须调用`SetOrderBeginBlock`和`SetOrderEndBlock`方法在`SetBeginBlocker` 和`SetEndBlocker` 函数之前。 -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. +作为旁注，重要的是要记住特定于应用程序的区块链是确定性的。开发人员必须注意不要在“BeginBlocker”或“EndBlocker”中引入不确定性，并且还必须注意不要使它们的计算成本过高，因为 [gas](./gas-fees.md) 不会限制成本`BeginBlocker` 和 `EndBlocker` 执行。 -See an example of `BeginBlocker` and `EndBlocker` functions from `simapp` +请参阅“simapp”中的“BeginBlocker”和“EndBlocker”函数示例 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/app.go#L454-L462 ### 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. +`EncodingConfig` 结构是 `app.go` 文件的最后一个重要部分。 此结构的目标是定义将在整个应用程序中使用的编解码器。 +++ 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 that 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 that contains a `type_url` (name of a concrete type implementing 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 that can be used to register the module's own interfaces and implementations. - - You can read more about Any in [ADR-19](../architecture/adr-019-protobuf-state-encoding.md#usage-of-any-to-encode-interfaces). - - To go more into details, the Cosmos 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 default codec used throughout the Cosmos SDK. It is composed of a `BinaryCodec` used to encode and decode state, and a `JSONCodec` 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 Cosmos 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. +- `InterfaceRegistry`:Protobuf 编解码器使用 `InterfaceRegistry` 来处理使用 [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto)。 `Any` 可以被认为是一个包含 `type_url`(实现接口的具体类型的名称)和一个 `value`(它的编码字节)的结构。 `InterfaceRegistry` 提供了一种注册接口和实现的机制，可以从 `Any` 安全地解包。应用程序的每个模块都实现了`RegisterInterfaces` 方法，该方法可用于注册模块自己的接口和实现。 + - 您可以在 [ADR-19](../architecture/adr-019-protobuf-state-encoding.md#usage-of-any-to-encode-interfaces) 中阅读有关 Any 的更多信息。 + - 为了更详细地了解，Cosmos SDK 使用了名为 [`gogoprotobuf`](https://github.com/gogo/protobuf) 的 Protobuf 规范的实现。默认情况下，[`Any` 的gogo protobuf 实现](https://godoc.org/github.com/gogo/protobuf/types) 使用[全局类型注册](https://github.com/gogo/protobuf/blob/master/proto/properties.go#L540) 将封装在 `Any` 中的值解码为具体的 Go 类型。这引入了一个漏洞，依赖树中的任何恶意模块都可以在全局 protobuf 注册表中注册一个类型，并导致它被在 `type_url` 字段中引用它的事务加载和解组。更多信息请参考[ADR-019](../architecture/adr-019-protobuf-state-encoding.md)。 +- `Marshaler`:整个 Cosmos SDK 中使用的默认编解码器。它由用于编码和解码状态的 `BinaryCodec` 和用于向用户输出数据的 `JSONCodec` 组成(例如在 [CLI](#cli) 中)。默认情况下，SDK 使用 Protobuf 作为`Marshaler`。 +- `TxConfig`:`TxConfig` 定义了一个接口，客户端可以利用它来生成应用程序定义的具体事务类型。目前，SDK 处理两种交易类型:“SIGN_MODE_DIRECT”(使用 Protobuf 二进制作为在线编码)和“SIGN_MODE_LEGACY_AMINO_JSON”(取决于 Amino)。阅读有关交易的更多信息 [此处](../core/transactions.md)。 +- `Amino`:Cosmos SDK 的一些遗留部分仍然使用 Amino 来实现向后兼容。每个模块都公开了一个 `RegisterLegacyAmino` 方法来在 Amino 中注册模块的特定类型。应用程序开发人员不应再使用此 `Amino` 编解码器，并将在未来版本中删除。 -The Cosmos SDK exposes a `MakeTestEncodingConfig` function used to create a `EncodingConfig` for the app constructor (`NewApp`). It uses Protobuf as a default `Marshaler`. -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. +Cosmos SDK 公开了一个 `MakeTestEncodingConfig` 函数，用于为应用程序构造函数(`NewApp`)创建一个 `EncodingConfig`。它使用 Protobuf 作为默认的“Marshaler”。 +注意:此功能已标记为已弃用，只能用于创建应用程序或在测试中使用。我们正在努力在星际之门发布后重构编解码器管理。 -See an example of a `MakeTestEncodingConfig` from `simapp`: +请参阅“simapp”中的“MakeTestEncodingConfig”示例: +++ https://github.com/cosmos/cosmos-sdk/blob/590358652cc1cbc13872ea1659187e073ea38e75/simapp/encoding.go#L8-L19 ## Modules -[Modules](../building-modules/intro.md) are the heart and soul of Cosmos SDK applications. They can be considered as state-machines nested 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 a Cosmos 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 Cosmos SDK's `x/` folder, which contains already-built modules). +[模块](../building-modules/intro.md) 是 Cosmos SDK 应用程序的核心和灵魂。它们可以被视为嵌套在状态机中的状态机。当交易通过 ABCI 从底层 Tendermint 引擎中继到应用程序时，它由 [`baseapp`](../core/baseapp.md) 路由到适当的模块以进行处理。这种范式使开发人员能够轻松构建复杂的状态机，因为他们需要的大多数模块通常已经存在。对于开发人员而言，构建 Cosmos SDK 应用程序所涉及的大部分工作都围绕构建其应用程序所需的尚不存在的自定义模块，并将它们与已经存在的模块集成到一个连贯的应用程序中。在应用程序目录中，标准做法是将模块存储在 `x/` 文件夹中(不要与 Cosmos SDK 的 `x/` 文件夹混淆，其中包含已构建的模块)。 -### 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-dependent 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`. +模块必须实现 Cosmos SDK 中定义的 [interfaces](../building-modules/module-manager.md#application-module-interfaces)，[`AppModuleBasic`](../building-modules/module-manager.md #appmodulebasic) 和 [`AppModule`](../building-modules/module-manager.md#appmodule)。前者实现模块的基本非依赖元素，例如`codec`，而后者处理模块的大部分方法(包括需要引用其他模块的`keeper`的方法)。 `AppModule` 和 `AppModuleBasic` 类型都在名为 `./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 called from the `module manager`(../building-modules/module-manager.md#manager), which manages the application's collection of modules. +`AppModule` 在模块上公开了一组有用的方法，这些方法有助于将模块组合成一个连贯的应用程序。这些方法从管理应用程序模块集合的`模块管理器`(../building-modules/module-manager.md#manager) 调用。 -### `Msg` Services +### `Msg` 服务 -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` service is a set of state transition RPC methods. -Each Protobuf `Msg` service method is 1:1 related to a Protobuf request type, which must implement `sdk.Msg` interface. -Note that `sdk.Msg`s are bundled in [transactions](../core/transactions.md), and each transaction contains one or multiple messages. +每个模块定义了两个 [Protobuf 服务](https://developers.google.com/protocol-buffers/docs/proto#services):一个用于处理消息的 `Msg` 服务，以及一个用于处理查询的 gRPC `Query` 服务。如果我们将模块视为状态机，那么“Msg”服务就是一组状态转换 RPC 方法。 +每个 Protobuf `Msg` 服务方法都与一个 Protobuf 请求类型 1:1 相关，它必须实现 `sdk.Msg` 接口。 +请注意，`sdk.Msg`s 捆绑在 [transactions](../core/transactions.md) 中，每个交易包含一条或多条消息。 -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: +当全节点收到一个有效的交易块时，Tendermint 通过 [`DeliverTx`](https://tendermint.com/docs/app-dev/abci-spec.html#delivertx) 将每个交易块中继到应用程序.然后，应用程序处理事务: -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. `sdk.Msg`s are encoded using Protobuf [`Any`s](#register-codec). By analyzing each `Any`'s `type_url`, baseapp's `msgServiceRouter` routes the `sdk.Msg` to the corresponding module's `Msg` service. -4. If the message is successfully processed, the state is updated. +1. 收到交易后，应用程序首先将其从 `[]bytes` 中解组。 +2. 然后，在提取交易中包含的 `Msg`(s) 之前，它会验证一些关于交易的事情，比如 [费用支付和签名](#gas-fees.md#antehandler)。 +3. `sdk.Msg`s 使用 Protobuf [`Any`s](#register-codec) 进行编码。通过分析每个 `Any` 的 `type_url`，baseapp 的 `msgServiceRouter` 将 `sdk.Msg` 路由到相应模块的 `Msg` 服务。 +4. 如果消息处理成功，则更新状态。 -For a more details look at a transaction [lifecycle](./tx-lifecycle.md). +有关更多详细信息，请查看事务 [lifecycle](./tx-lifecycle.md)。 -Module developers create custom `Msg` services when they build their own module. The general practice is to define the `Msg` Protobuf service in a `tx.proto` file. For example, the `x/bank` module defines a service with two methods to transfer tokens: +模块开发人员在构建自己的模块时会创建自定义的 `Msg` 服务。一般的做法是在 `tx.proto` 文件中定义 `Msg` Protobuf 服务。例如，`x/bank` 模块定义了一个服务，它具有两种传输令牌的方法: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/proto/cosmos/bank/v1beta1/tx.proto#L10-L17 -Service methods use `keeper` in order to update the module state. +服务方法使用 `keeper` 来更新模块状态。 -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. +每个模块还应该实现 `RegisterServices` 方法作为 [`AppModule` 接口](#application-module-interface) 的一部分。这个方法应该调用生成的 Protobuf 代码提供的 `RegisterMsgServer` 函数。 -### gRPC `Query` Services +### gRPC `Query` 服务 -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 configured under the `grpc.enable` and `grpc.address` fields inside [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml). +gRPC `Query` 服务是在 v0.40 Stargate 版本中引入的。它们允许用户使用 [gRPC](https://grpc.io) 查询状态。它们默认启用，可以在 [`app.toml`](../run-node/run-node.md#configuring-the- 内的 `grpc.enable` 和 `grpc.address` 字段下配置节点使用应用程序)。 -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. +gRPC `Query` 服务在模块的 Protobuf 定义文件中定义，特别是在 `query.proto` 中。 `query.proto` 定义文件公开了一个 `Query` [Protobuf 服务](https://developers.google.com/protocol-buffers/docs/proto#services)。每个 gRPC 查询端点对应一个服务方法，以 rpc 关键字开头，位于 Query 服务中。 -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. +Protobuf 为每个模块生成一个 `QueryServer` 接口，包含所有服务方法。一个模块的 [`keeper`](#keeper) 则需要通过提供每个服务方法的具体实现来实现这个 `QueryServer` 接口。这个具体的实现是对应的 gRPC 查询端点的处理程序。 -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. +最后，每个模块还应该实现 `RegisterServices` 方法作为 [`AppModule` 接口](#application-module-interface) 的一部分。这个方法应该调用生成的 Protobuf 代码提供的 `RegisterQueryServer` 函数。 -### 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`](../building-modules/keeper.md) 是其模块存储的看门人。要在模块的存储中读取或写入，必须通过其 `keeper` 方法之一。这是由 Cosmos SDK 的 [object-capabilities](../core/ocap.md) 模型确保的。只有持有存储密钥的对象才能访问它，并且只有模块的`keeper` 应该持有模块存储的密钥。 -`Keepers` are generally defined in a file called `keeper.go`. It contains the `keeper`'s type definition and methods. +`Keepers` 通常定义在一个名为 `keeper.go` 的文件中。它包含 `keeper` 的类型定义和方法。 -The `keeper` type definition generally consists of: +`keeper` 类型定义通常包括: -- **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. +- **Key(s)** 到 multistore 中模块的 store(s)。 +- 参考**其他模块的`keepers`**。仅当 `keeper` 需要访问其他模块的存储(读取或写入它们)时才需要。 +- 对应用程序的 **codec** 的引用。 `keeper` 需要它在存储它们之前编组结构，或者在检索它们时解组它们，因为存储只接受 `[]bytes` 作为值。 -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. +与类型定义一起，`keeper.go` 文件的下一个重要组件是 `keeper` 的构造函数，`NewKeeper`。这个函数实例化一个上面定义的类型的新的`keeper`，带有一个`codec`，存储`keys`和潜在的对其他模块`keeper`s的引用作为参数。 `NewKeeper` 函数是从 [应用程序的构造函数](#constructor-function) 调用的。文件的其余部分定义了 `keeper` 的方法，主要是 getter 和 setter。 -### Command-Line, gRPC Services and REST Interfaces +### 命令行、gRPC 服务和 REST 接口 -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. +每个模块都定义了命令行命令、gRPC 服务和 REST 路由，这些路由通过 [应用程序的接口](#application-interfaces) 暴露给最终用户。这使最终用户能够创建模块中定义的类型的消息，或查询模块管理的状态子集。 -#### 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): +通常，[与模块相关的命令](../building-modules/module-interfaces.md#cli) 定义在模块文件夹中名为`client/cli` 的文件夹中。 CLI 将命令分为两类，事务和查询，分别在 `client/cli/tx.go` 和 `client/cli/query.go` 中定义。这两个命令都建立在 [Cobra 库](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 Cosmos 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. +- 交易命令让用户生成新交易，以便它们可以包含在一个块中并最终更新状态。应该为模块中定义的每个 [消息类型](#message-types) 创建一个命令。该命令使用最终用户提供的参数调用消息的构造函数，并将其包装到事务中。 Cosmos SDK 处理签名和其他交易元数据的添加。 +- 查询让用户查询模块定义的状态的子集。查询命令将查询转发到 [application's query router](../core/baseapp.md#query-routing)，后者将它们路由到适当的 [querier](#querier) 提供的 `queryRoute` 参数。 #### 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. +[gRPC](https://grpc.io) 是一个现代开源的高性能 RPC 框架，支持多种语言。这是外部客户端(如钱包、浏览器和其他后端服务)与节点交互的推荐方式。 -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: +每个模块都可以公开 gRPC 端点，称为 [服务方法](https://grpc.io/docs/what-is-grpc/core-concepts/#service-definition) 并在 [模块的 Protobuf `query.proto 中定义`文件](#grpc-query-services)。服务方法由其名称、输入参数和输出响应定义。然后模块需要: -- 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. +- 在`AppModuleBasic` 上定义一个`RegisterGRPCGatewayRoutes` 方法，将客户端gRPC 请求连接到模块内的正确处理程序。 +- 对于每个服务方法，定义一个相应的处理程序。处理程序实现服务 gRPC 请求所需的核心逻辑，位于 `keeper/grpc_query.go` 文件中。 -#### gRPC-gateway REST Endpoints +#### gRPC 网关 REST 端点 -Some external clients may not wish to use gRPC. The Cosmos 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. +一些外部客户端可能不希望使用 gRPC。在这种情况下，Cosmos SDK 提供了一个 gRPC 网关服务，它将每个 gRPC 服务公开为一个对应的 REST 端点。请参阅 [grpc-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) 文档以了解更多信息。 -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. +REST 端点与 gRPC 服务一起在 Protobuf 文件中定义，使用 Protobuf 注释。想要公开 REST 查询的模块应该在它们的 `rpc` 方法中添加 `google.api.http` 注释。默认情况下，SDK 中定义的所有 REST 端点都有一个以 `/cosmos/` 前缀开头的 URL。 -The Cosmos 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. +Cosmos SDK 还提供了一个开发端点来为这些 REST 端点生成 [Swagger](https://swagger.io/) 定义文件。可以在 [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) 配置文件中的 `api.swagger` 键下启用此端点。 -## Application Interface +## 应用程序接口 -[Interfaces](#command-line-grpc-services-and-rest-interfaces) 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. +[接口](#command-line-grpc-services-and-rest-interfaces) 让终端用户与全节点客户端交互。这意味着从全节点查询数据或创建和发送由全节点中继并最终包含在一个块中的新交易。 -The main interface is the [Command-Line Interface](../core/cli.md). The CLI of a Cosmos 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: +主界面是[命令行界面](../core/cli.md)。 Cosmos SDK 应用程序的 CLI 是通过聚合应用程序使用的每个模块中定义的 [CLI 命令](#cli) 构建的。应用程序的 CLI 与守护进程(例如 `appd`)相同，并在名为 `appd/main.go` 的文件中定义。该文件包含: -- **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. +- **一个`main()`函数**，用于构建`appd`接口客户端。此函数准备每个命令，并在构建它们之前将它们添加到 `rootCmd`。在`appd` 的根目录下，该函数添加了诸如`status`、`keys` 和`config` 等通用命令、查询命令、tx 命令和`rest-server`。 +- **查询命令**是通过调用`queryCmd`函数添加的。此函数返回一个 Cobra 命令，其中包含在每个应用程序模块中定义的查询命令(从 `main()` 函数作为 `sdk.ModuleClients` 数组传递)，以及一些其他较低级别的查询命令，例如块或验证器查询。使用 CLI 的命令 `appd query [query]` 调用查询命令。 +- 通过调用`txCmd` 函数添加**交易命令**。与 `queryCmd` 类似，该函数返回一个 Cobra 命令，其中包含在每个应用程序模块中定义的 tx 命令，以及较低级别的 tx 命令，如交易签名或广播。使用 CLI 的命令 `appd tx [tx]` 调用 Tx 命令。 -See an example of an application's main command-line file from the [nameservice tutorial](https://github.com/cosmos/sdk-tutorials/tree/master/nameservice) +请参阅 [nameservice 教程](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 +## 依赖项和 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 Cosmos SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. +::: 警告 +`go-grpc v1.34.0` 中引入的补丁使 gRPC 与 `gogoproto` 库不兼容，导致一些 [gRPC 查询](https://github.com/cosmos/cosmos-sdk/issues/8426) 恐慌。因此，Cosmos SDK 要求在你的 `go.mod` 中安装 `go-grpc <=v1.33.2`。 -To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: +为确保 gRPC 正常工作，**强烈建议**在您的应用程序的 `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. +请参阅 [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) 了解更多信息。 ::: -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): +这部分是可选的，因为开发人员可以自由选择他们的依赖管理器和项目构建方法。也就是说，当前最常用的版本控制框架是 [`go.mod`](https://github.com/golang/go/wiki/Modules)。它确保在整个应用程序中使用的每个库都以正确的版本导入。请参阅 [nameservice 教程](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://tutorials.cosmos.network/nameservice/tutorial/00-intro.html) +为了构建应用程序，通常使用 [Makefile](https://en.wikipedia.org/wiki/Makefile)。 Makefile 主要确保在构建应用程序的两个入口点 [`appd`](#node-client) 和 [`appd`](#application-interface) 之前运行 `go.mod`。请参阅 [nameservice 教程](https://tutorials.cosmos.network/nameservice/tutorial/00-intro.html) 中的 Makefile 示例 +++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/Makefile -## Next {hide} +## 下一个 {hide} -Learn more about the [Lifecycle of a transaction](./tx-lifecycle.md) {hide} +详细了解 [交易的生命周期](./tx-lifecycle.md) {hide} \ No newline at end of file diff --git a/docs/ja/basics/gas-fees.md b/docs/ja/basics/gas-fees.md index 2c2f36e256a8..1f699906ba50 100644 --- a/docs/ja/basics/gas-fees.md +++ b/docs/ja/basics/gas-fees.md @@ -1,54 +1,54 @@ -# Gas and Fees +# 汽油和费用 -This document describes the default strategies to handle gas and fees within a Cosmos SDK application. {synopsis} +本文档描述了在 Cosmos SDK 应用程序中处理 gas 和费用的默认策略。 {概要} -### Pre-requisite Readings +### 先决条件阅读 -- [Anatomy of a Cosmos SDK Application](./app-anatomy.md) {prereq} +- [Cosmos SDK 应用剖析](./app-anatomy.md) {prereq} -## Introduction to `Gas` and `Fees` +## `Gas` 和 `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: +在 Cosmos SDK 中，`gas` 是一个特殊的单元，用于跟踪执行过程中资源的消耗情况。 `gas` 通常在对存储进行读写时消耗，但如果需要进行昂贵的计算，它也可以消耗。它有两个主要目的/ -- Make sure blocks are not consuming too many resources and will be finalized. This is implemented by default in the Cosmos 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 Cosmos 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). +- 确保块不会消耗太多资源并且将被最终确定。这是通过 [block gas meter](#block-gas-meter) 在 Cosmos SDK 中默认实现的。 +- 防止来自最终用户的垃圾邮件和滥用。为此，在 [`message`](../building-modules/messages-and-queries.md#messages) 执行期间消耗的 `gas` 通常是定价的，从而产生 `fee`(`fees = gas * gas -价格`)。 “费用”通常必须由“消息”的发送者支付。请注意，Cosmos SDK 默认不强制执行`gas` 定价，因为可能有其他方法来防止垃圾邮件(例如带宽方案)。尽管如此，大多数应用程序将实施“费用”机制来防止垃圾邮件。这是通过 [`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 +在 Cosmos SDK 中，`gas` 是 `uint64` 的简单别名，由一个名为 _gas meter_ 的对象管理。燃气表实现了`GasMeter`接口 +++ 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. +- `GasConsumed()` 返回燃气表实例消耗的燃气量。 +- `GasConsumedToLimit()` 返回燃气表实例消耗的燃气量，或者达到限制。 +- `Limit()` 返回燃气表实例的限制。 `0` 如果燃气表是无限的。 +- `ConsumeGas(amount Gas,descriptor string)`消耗提供的`gas`量。如果 `gas` 溢出，它会因 `descriptor` 消息而恐慌。如果燃气表不是无限的，如果消耗的`gas`超过限制，它就会恐慌。 +- 如果燃气表实例消耗的燃气量严格高于限制，则`IsPastLimit()` 返回`true`，否则返回`false`。 +- 如果燃气表实例消耗的燃气量高于或等于限制，则`IsOutOfGas()` 返回`true`，否则返回`false`。 -The gas meter is generally held in [`ctx`](../core/context.md), and consuming gas is done with the following pattern: +gas 表一般保存在 [`ctx`](../core/context.md) 中，消耗 gas 的方式如下/ ```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). +默认情况下，Cosmos SDK 使用两种不同的燃气表，[主燃气表](#main-gas-metter[) 和[块燃气表](#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. +`ctx.GasMeter()` 是应用程序的主要燃气表。主燃气表通过`setDeliverState`在`BeginBlock`中初始化，然后在导致状态转换的执行序列期间跟踪燃气消耗，即最初由[`BeginBlock`](../core/baseapp.md#触发的那些beginblock)、[`DeliverTx`](../core/baseapp.md#delivertx) 和 [`EndBlock`](../core/baseapp.md#endblock)。在每个 `DeliverTx` 开始时，[`AnteHandler`](#antehandler) 中的主燃气表**必须设置为 0**，以便它可以跟踪每笔交易的燃气消耗。 -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). +Gas 消耗可以手动完成，通常由模块开发人员在 [`BeginBlocker`, `EndBlocker`](../building-modules/beginblock-endblock.md) 或 [`Msg` 服务](../building- modules/msg-services.md)，但大多数情况下，只要对存储进行读取或写入，它就会自动完成。这种自动gas消耗逻辑在一个名为[`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: +`ctx.BlockGasMeter()` 是燃气表，用于跟踪每个区块的燃气消耗并确保它不会超过某个限制。每次调用 [`BeginBlock`](../core/baseapp.md#beginblock) 时都会创建一个 `BlockGasMeter` 的新实例。 `BlockGasMeter` 是有限的，每个区块的 gas 限制在应用程序的共识参数中定义。默认情况下，Cosmos SDK 应用程序使用 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: +当一个新的 [transaction](../core/transactions.md) 正在通过 `DeliverTx` 处理时，会检查 `BlockGasMeter` 的当前值是否超过限制。如果是，`DeliverTx` 立即返回。即使是区块中的第一笔交易，这种情况也可能发生，因为“BeginBlock”本身可以消耗 gas。如果不是，则交易正常处理。在`DeliverTx`结束时，`ctx.BlockGasMeter()`跟踪的gas增加了处理交易消耗的数量/ ```go ctx.BlockGasMeter().ConsumeGas( @@ -59,7 +59,7 @@ ctx.BlockGasMeter().ConsumeGas( ## AnteHandler -The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`, before a Protobuf `Msg` service method for each `sdk.Msg` in the transaction. `AnteHandler`s have the following signature: +在“CheckTx”和“DeliverTx”期间为每个事务运行“AnteHandler”，在事务中每个“sdk.Msg”的 Protobuf“Msg”服务方法之前运行。 `AnteHandler`s 具有以下签名/ ```go // AnteHandler authenticates transactions, before their internal messages are handled. @@ -67,19 +67,19 @@ The `AnteHandler` is run for every transaction during `CheckTx` and `DeliverTx`, type AnteHandler func(ctx Context, tx Tx, simulate bool) (newCtx Context, result Result, abort bool) ``` -The `anteHandler` is not implemented in the core Cosmos 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: +`anteHandler` 不是在核心 Cosmos SDK 中实现的，而是在一个模块中实现的。这使开发人员可以选择适合其应用程序需要的 `AnteHandler` 版本。也就是说，今天的大多数应用程序都使用 [`auth` 模块](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth) 中定义的默认实现。以下是`anteHandler` 在普通 Cosmos SDK 应用程序中的作用/ -- 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: +- 验证交易类型是否正确。事务类型在实现`anteHandler`的模块中定义，它们遵循事务接口/ +++ 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`: + 这使开发人员可以使用各种类型来处理他们的应用程序事务。在默认的 `auth` 模块中，默认的交易类型是 `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). +- 验证交易中包含的每个 [`message`](../building-modules/messages-and-queries.md#messages) 的签名。每个“消息”应由一个或多个发送者签名，并且这些签名必须在“anteHandler”中进行验证。 +- 在`CheckTx`期间，验证交易提供的gas价格是否高于当地的`min-gas-prices`(提醒一下，gas-price可以从以下等式中扣除/`fees = gas * gas-价格`)。 `min-gas-prices` 是每个全节点的本地参数，在 `CheckTx` 期间用于丢弃不提供最低费用的交易。这确保了内存池不会被垃圾交易发送垃圾邮件。 +- 验证交易的发送者是否有足够的资金来支付“费用”。当最终用户生成交易时，他们必须指明以下 3 个参数中的 2 个(第三个是隐式参数)/`fees`、`gas` 和 `gas-prices`。这表明他们愿意为节点支付多少来执行他们的交易。提供的 `gas` 值存储在名为 `GasWanted` 的参数中以备后用。 +- 将 `newCtx.GasMeter` 设置为 0，限制为 `GasWanted`。 **这一步非常重要**，因为它不仅确保交易不会消耗无限的gas，而且在每个`DeliverTx`之间重置`ctx.GasMeter`(`ctx`设置为`newCtx`在运行`anteHandler` 之后，并且每次调用`DeliverTx` 时都会运行`anteHandler`)。 -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. +如上所述，`anteHandler` 返回交易在执行期间可以消耗的最大 `gas` 限制，称为 `GasWanted`。最终消耗的实际数量以`GasUsed`计价，因此我们必须有`GasUsed =< GasWanted`。当 [`DeliverTx`](../core/baseapp.md#delivertx) 返回时，`GasWanted` 和 `GasUsed` 都被中继到底层共识引擎。 -## Next {hide} +## 下一个 {hide} -Learn about [baseapp](../core/baseapp.md) {hide} +了解 [baseapp](../core/baseapp.md) {hide} \ No newline at end of file diff --git a/docs/ja/basics/query-lifecycle.md b/docs/ja/basics/query-lifecycle.md index a1e387c55301..29296df49a66 100644 --- a/docs/ja/basics/query-lifecycle.md +++ b/docs/ja/basics/query-lifecycle.md @@ -1,54 +1,54 @@ -# Query Lifecycle +# 查询生命周期 -This document describes the lifecycle of a query in a Cosmos SDK application, from the user interface to application stores and back. {synopsis} +本文档描述了 Cosmos SDK 应用程序中查询的生命周期，从用户界面到应用程序存储再返回。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Transaction Lifecycle](./tx-lifecycle.md) {prereq} +- [交易生命周期](./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. +[**query**](../building-modules/messages-and-queries.md#queries) 是应用程序的最终用户通过接口发出并由全节点处理的信息请求。用户可以直接从应用程序的存储或模块中查询有关网络、应用程序本身和应用程序状态的信息。请注意，查询不同于 [transactions](../core/transactions.md)(查看生命周期 [here](./tx-lifecycle.md))，特别是它们不需要处理共识(如它们不会触发状态转换)；它们可以由一个全节点完全处理。 -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. +为了解释查询生命周期，假设“MyQuery”正在请求由名为“simapp”的应用程序中的某个委托地址做出的委托列表。正如预期的那样，[`staking`](../../x/staking/spec/README.md) 模块处理这个查询。但首先，用户可以通过几种方式创建“MyQuery”。 -### 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: +应用程序的主界面是命令行界面。用户连接到全节点并直接从他们的机器运行 CLI - CLI 直接与全节点交互。要从他们的终端创建“MyQuery”，用户输入以下命令: ```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. +此查询命令由 [`staking`](../../x/staking/spec/README.md) 模块开发人员定义，并在创建 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. +要提供诸如“--node”(CLI 连接到的完整节点)之类的值，用户可以使用 [`app.toml`](../run-node/run-node.md#configuring-the -node-using-apptoml) 配置文件来设置它们或将它们作为标志提供。 -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. +CLI 理解一组特定的命令，由应用程序开发人员在分层结构中定义:从 [root command](../core/cli.md#root-command) (`simd`)，命令类型 ( `Myquery`)，包含命令(`staking`)和命令本身(`delegations`)的模块。因此，CLI 确切地知道哪个模块处理此命令并直接在那里传递调用。 ### 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 Cosmos SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. +::: 警告 +`go-grpc v1.34.0` 中引入的补丁使 gRPC 与 `gogoproto` 库不兼容，导致一些 [gRPC 查询](https://github.com/cosmos/cosmos-sdk/issues/8426) 恐慌。因此，Cosmos SDK 要求在你的 `go.mod` 中安装 `go-grpc <=v1.33.2`。 -To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: +为确保 gRPC 正常工作，**强烈建议**在您的应用程序的 `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. +请参阅 [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) 了解更多信息。 ::: -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. +在 Cosmos SDK v0.40 中引入的另一个用户可以进行查询的接口是 [gRPC](https://grpc.io) 对 [gRPC 服务器](../core/grpc_rest.md#grpc-server )。 端点被定义为 `.proto` 文件中的 [Protocol Buffers](https://developers.google.com/protocol-buffers) 服务方法，用 Protobuf 自己的语言无关接口定义语言 (IDL) 编写。 Protobuf 生态系统开发了从“*.proto”文件到各种语言的代码生成工具。 这些工具允许轻松构建 gRPC 客户端。 -One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC request for `MyQuery` using this client looks like: +其中一个工具是 [grpcurl](https://github.com/fullstorydev/grpcurl)，使用该客户端对 `MyQuery` 的 gRPC 请求如下所示: ```bash grpcurl \ @@ -60,89 +60,89 @@ grpcurl \ cosmos.staking.v1beta1.Query/Delegations # Fully-qualified service method name ``` -### REST +::: 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). +用户可以通过其进行查询的另一个接口是通过 HTTP 请求到 [REST 服务器](../core/grpc_rest.md#rest-server)。 REST 服务器完全从 Protobuf 服务自动生成，使用 [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway)。 -An example HTTP request for `MyQuery` looks like: +`MyQuery` 的 HTTP 请求示例如下所示: ```bash -GET http://localhost:1317/cosmos/staking/v1beta1/delegators/{delegatorAddr}/delegations +wget http://localhost:1317/cosmos/staking/v1beta1/delegators/{delegatorAddr}/delegations ``` -## How Queries are Handled by the CLI +## 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`. +上面的例子展示了外部用户如何通过查询节点的状态来与节点交互。要详细了解查询的确切生命周期，让我们深入研究 CLI 如何准备查询，以及节点如何处理它。从用户的角度来看，交互有点不同，但底层功能几乎相同，因为它们是由模块开发人员定义的相同命令的实现。这一步处理发生在 CLI、gRPC 或 REST 服务器中，并且大量涉及“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: +在执行 CLI 命令时创建的第一件事是 `client.Context`。 `client.Context` 是一个对象，它存储在用户端处理请求所需的所有数据。特别是，`client.Context` 存储以下内容: -- **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. +- **Codec**:应用程序使用的[encoder/decoder](../core/encoding.md)，用于在发出Tendermint RPC请求之前编组参数和查询，并将返回的响应解组为JSON对象. CLI 使用的默认编解码器是 Protobuf。 +- **Account Decoder**:来自 [`auth`](../..//x/auth/spec/README.md) 模块的帐户解码器，将 `[]byte` 转换为帐户。 +- **RPC 客户端**:请求将中继到的 Tendermint RPC 客户端或节点。 +- **密钥环**:[密钥管理器](../basics/accounts.md#keyring) 用于签署交易和处理其他使用密钥的操作。 +- **Output Writer**:一个 [Writer](https://golang.org/pkg/io/#Writer) 用于输出响应。 +- **Configurations**:用户为此命令配置的标志，包括`--height`，指定要查询的区块链高度和`--indent`，表示在JSON响应中添加缩进。 -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. +`client.Context` 还包含各种函数，例如 `Query()`，它检索 RPC 客户端并进行 ABCI 调用以将查询中继到全节点。 +++ 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. +`client.Context` 的主要作用是存储在与最终用户交互期间使用的数据并提供与这些数据交互的方法 - 它在全节点处理查询之前和之后使用。具体来说，在处理“MyQuery”时，“client.Context”用于对查询参数进行编码、检索全节点并写入输出。在被中继到全节点之前，查询需要被编码为“[]byte”形式，因为全节点与应用程序无关并且不了解特定类型。全节点(RPC 客户端)本身是使用 `client.Context` 检索的，它知道用户 CLI 连接到哪个节点。查询被中继到这个全节点进行处理。最后，`client.Context` 包含一个 `Writer`，用于在返回响应时写入输出。这些步骤将在后面的部分中进一步描述。 -### 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. +在生命周期的这一点上，用户创建了一个 CLI 命令，其中包含他们希望包含在查询中的所有数据。 `client.Context` 的存在是为了协助 `MyQuery` 的其余部分。现在，下一步是解析命令或请求，提取参数，并对所有内容进行编码。这些步骤都发生在他们与之交互的界面中的用户端。 -#### 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. +在我们的例子中(查询地址的委托)，`MyQuery` 包含一个 [address](./accounts.md#addresses) `delegatorAddress` 作为它的唯一参数。但是，请求只能包含“[]byte”，因为它将被中继到一个对应用程序类型没有固有知识的全节点的共识引擎(例如 Tendermint Core)。因此，`client.Context` 的`codec` 用于编组地址。 -Here is what the code looks like for the CLI command: +CLI 命令的代码如下所示: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/client/cli/query.go#L324-L327 -#### gRPC Query Client Creation +#### gRPC 查询客户端创建 -The Cosmos 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: +Cosmos SDK 利用从 Protobuf 服务生成的代码进行查询。 `staking` 模块的 `MyQuery` 服务生成一个 `queryClient`，CLI 将使用它进行查询。这是相关的代码: +++ 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()`. +在底层，`client.Context` 有一个 `Query()` 函数，用于检索预先配置的节点并将查询转发给它；该函数将查询完全限定的服务方法名称作为路径(在我们的例子中:`/cosmos.staking.v1beta1.Query/Delegations`)，并将参数作为参数。它首先检索用户配置的 RPC 客户端(称为 [**node**](../core/node.md))以将此查询中继到，并创建“ABCIQueryOptions”(为 ABCI 调用设置格式的参数) )。然后使用该节点进行 ABCI 调用，`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. +通过调用“ABCIQueryWithOptions()”，[全节点](../core/encoding.md) 接收到“MyQuery”，然后它将处理请求。请注意，虽然 RPC 是针对全节点的共识引擎(例如 Tendermint Core)进行的，但查询不是共识的一部分，不会广播到网络的其余部分，因为它们不需要网络需要的任何东西同意。 -Read more about ABCI Clients and Tendermint RPC in the Tendermint documentation [here](https://tendermint.com/rpc). +在 Tendermint 文档 [此处](https://tendermint.com/rpc) 中阅读有关 ABCI 客户端和 Tendermint 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. +当查询在从底层共识引擎中继后被全节点接收时，它现在正在一个理解应用程序特定类型并具有状态副本的环境中处理。 [`baseapp`](../core/baseapp.md) 实现了 ABCI [`Query()`](../core/baseapp.md#query) 函数并处理 gRPC 查询。查询路由被解析，它匹配现有服务方法的完全限定服务方法名称(最有可能在其中一个模块中)，然后`baseapp` 将请求中继到相关模块。 -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). +除了 gRPC 路由之外，`baseapp` 还处理四种不同类型的查询:`app`、`store`、`p2p` 和 `custom`。前三种类型(`app`、`store`、`p2p`)纯粹是应用级的，因此直接由`baseapp` 或stores 处理，但是`custom` 查询类型需要`baseapp` 将查询路由到模块的 [legacy 查询器](../building-modules/query-services.md#legacy-queriers)。要了解有关这些查询的更多信息，请参阅 [本指南](../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). +由于 `MyQuery` 具有来自 `staking` 模块的 Protobuf 完全限定服务方法名称(回想一下 `/cosmos.staking.v1beta1.Query/Delegations`)，`baseapp` 首先解析路径，然后使用其自己的内部 `GRPCQueryRouter ` 检索相应的 gRPC 处理程序，并将查询路由到模块。 gRPC 处理程序负责识别此查询，从应用程序的存储中检索适当的值，并返回响应。阅读有关查询服务的更多信息 [此处](../building-modules/query-services.md)。 -Once a result is received from the querier, `baseapp` begins the process of returning a response to the user. +一旦从查询器接收到结果，`baseapp` 就会开始向用户返回响应的过程。 -## 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. +由于 `Query()` 是一个 ABCI 函数，`baseapp` 将响应作为 [`abci.ResponseQuery`](https://tendermint.com/docs/spec/abci/abci.html#messages) 类型返回。 `client.Context` `Query()` 例程接收响应并且。 -### CLI Response +### CLI 响应 -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). +应用程序 [`codec`](../core/encoding.md) 用于将响应解组为 JSON，`client.Context` 将输出打印到命令行，应用任何配置，例如输出类型(文本、JSON 或 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. +这是一个包装！查询结果由 CLI 输出到控制台。 -## Next {hide} +## 下一个 {hide} -Read more about [accounts](./accounts.md). {hide} +阅读有关 [accounts](./accounts.md) 的更多信息。 {hide}} \ No newline at end of file diff --git a/docs/ja/basics/tx-lifecycle.md b/docs/ja/basics/tx-lifecycle.md index 4ac94c91c89c..ed89f80ede45 100644 --- a/docs/ja/basics/tx-lifecycle.md +++ b/docs/ja/basics/tx-lifecycle.md @@ -1,142 +1,142 @@ -# 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} +本文档描述了事务从创建到提交状态更改的生命周期。交易定义在 [不同的文档](../core/transactions.md) 中进行了描述。该交易将被称为“Tx”。 {概要} -### Pre-requisite Readings +### 先决条件阅读 -- [Anatomy of a Cosmos SDK Application](./app-anatomy.md) {prereq} +- [Cosmos SDK 应用剖析](./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](../core/cli.md), providing the type of transaction in `[command]`, arguments in `[args]`, and configurations such as gas prices in `[flags]`: +主要的应用程序界面之一是命令行界面。交易`Tx`可以通过用户从[命令行](../core/cli.md)输入以下格式的命令来创建，在`[command]`中提供交易类型，参数在`[args]`，以及 `[flags]` 中的 gas 价格等配置: ```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. +交易创建有几个必需和可选的标志。 `--from` 标志指定交易源自哪个 [account](./accounts.md)。例如，如果交易是发送硬币，则资金将从指定的“from”地址中提取。 -#### Gas and Fees +#### 汽油和费用 -Additionally, there are several [flags](../core/cli.md) users can use to indicate how much they are willing to pay in [fees](./gas-fees.md): +此外，还有几个 [flags](../core/cli.md) 用户可以用来表明他们愿意在 [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. +- `--gas`指的是`Tx`消耗了多少[gas](./gas-fees.md)，代表计算资源。 Gas 取决于交易，并且在执行之前不会精确计算，但可以通过提供 `auto` 作为 `--gas` 的值来估计。 +- `--gas-adjustment`(可选)可用于扩展`gas`以避免低估。例如，用户可以将他们的 gas 调整指定为 1.5 以使用 1.5 倍的估计 gas。 +- `--gas-prices` 指定用户愿意为每单位 gas 支付多少，可以是一种或多种面额的代币。例如，`--gas-prices=0.025uatom, 0.025upho` 表示用户愿意为每单位gas支付0.025uatom和0.025upho。 +- `--fees` 指定用户愿意支付的总费用。 +- `--timeout-height` 指定块超时高度，以防止 tx 提交超过特定高度。 -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. +支付费用的最终价值等于gas乘以gas价格。换句话说，`fees = ceil(gas * gasPrices)`。因此，由于可以使用 gas 价格计算费用，反之亦然，因此用户仅指定两者之一。 -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. +之后，验证者通过将给定或计算出的“gas-prices”与其本地“min-gas-prices”进行比较来决定是否将交易包含在他们的区块中。如果它的`gas-prices` 不够高，`Tx` 将被拒绝，因此激励用户支付更多。 -#### CLI Example +#### CLI 示例 -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. +应用程序“app”的用户可以在他们的 CLI 中输入以下命令来生成一个交易，将 1000uatom 从“senderAddress”发送到“recipientAddress”。它指定了他们愿意支付多少 gas:自动估算按比例放大 1.5 倍，每单位 gas 的 gas 价格为 0.025uatom。 ```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 [gRPC or REST interface](../core/grpc_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). +命令行是与应用程序交互的一种简单方法，但也可以使用 [gRPC 或 REST 接口](../core/grpc_rest.md) 或应用程序开发人员定义的其他一些入口点来创建“Tx”。从用户的角度来看，交互取决于他们使用的网络界面或钱包(例如，使用 [Lunie.io](https://lunie.io/#/) 创建 `Tx` 并使用 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. +每个接收到“Tx”的全节点(运行 Tendermint)都会发送一个 [ABCI 消息](https://tendermint.com/docs/spec/abci/abci.html#messages)， +`CheckTx`，到应用层检查有效性，并收到一个 `abci.ResponseCheckTx`。如果“Tx”通过检查，则将其保存在节点中 +[**Mempool**](https://tendermint.com/docs/tendermint-core/mempool.html#mempool)，每个节点独有的内存中交易池)等待包含在块中 - 诚实的节点将如果发现无效，则丢弃 `Tx`。在达成共识之前，节点会不断检查传入的交易并将其八卦给他们的对等方。 -### 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. +全节点执行无状态，然后在“CheckTx”期间对“Tx”进行有状态检查，目的是 +尽早识别并拒绝无效交易，以避免浪费计算。 -**_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. +**_Stateless_** 检查不需要节点访问状态——轻客户端或离线节点都可以 +它们 - 因此计算成本较低。无状态检查包括确保地址 +不为空，强制执行非负数，以及定义中指定的其他逻辑。 -**_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. +**_Stateful_** 根据提交的状态检查验证交易和消息。例子 +包括检查相关值是否存在并且能够进行交易，地址 +有足够的资金，并且发件人被授权或拥有正确的所有权进行交易。 +在任何给定时刻，全节点通常有[多个版本](../core/baseapp.md#volatile-states) +用于不同目的的应用程序的内部状态。例如，节点将执行状态 +在验证交易的过程中发生变化，但仍需要最后提交的副本 +state 以回答查询 - 他们不应该使用带有未提交更改的 state 进行响应。 -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`. +为了验证“Tx”，全节点调用“CheckTx”，其中包括 _stateless_ 和 _stateful_ +检查。进一步的验证发生在 [`DeliverTx`](#delivertx) 阶段。 `CheckTx` 去 +通过几个步骤，从解码“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. +当应用程序从底层共识引擎(例如 Tendermint)接收到 `Tx` 时，它仍然是 [encoded](../core/encoding.md) `[]byte` 形式，需要按顺序解组待处理。然后，调用 [`runTx`](../core/baseapp.md#runtx-and-runmsgs) 函数在 `runTxModeCheck` 模式下运行，这意味着该函数将运行所有检查但在执行消息和写入状态之前退出变化。 ### ValidateBasic -[`sdk.Msg`s](../core/transactions.md#messages) are extracted from `Tx`, and `ValidateBasic`, a method of the `sdk.Msg` interface implemented by the module developer, is run for each one. `ValidateBasic` 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 the account balance of an address. +[`sdk.Msg`s](../core/transactions.md#messages)从`Tx`中提取出来，运行模块开发者实现的`sdk.Msg`接口的方法`ValidateBasic`每一个人。 `ValidateBasic` 应该包括基本的 **stateless** 健全性检查。例如，如果消息是将硬币从一个地址发送到另一个地址，“ValidateBasic”可能会检查非空地址和非负硬币数量，但不需要了解状态，例如地址的帐户余额。 -### 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. +在 ValidateBasic 检查之后，运行 `AnteHandler`s。从技术上讲，它们是可选的，但在实践中，它们经常出现以执行与区块链交易相关的签名验证、gas 计算、费用扣除和其他核心操作。 -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. +缓存上下文的副本提供给 `AnteHandler`，它执行为事务类型指定的有限检查。使用副本允许 AnteHandler 在不修改最后提交的状态的情况下对 `Tx` 进行状态检查，并在执行失败时恢复到原始状态。 -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`. +例如，[`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth/spec) 模块 `AnteHandler` 检查和递增序列号，检查签名和帐号，并从交易的第一个签名者那里扣除费用 - 所有状态更改都是使用 `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 greater than their locally defined `min-gas-prices`. +[`Context`](../core/context.md) 保存了一个 `GasMeter`，它将跟踪在 `Tx` 的执行过程中使用了多少气体，被初始化。用户为“Tx”提供的气体量称为“GasWanted”。如果`GasConsumed`，即执行期间消耗的gas 量超过`GasWanted`，则执行将停止并且不会提交对状态缓存副本所做的更改。否则，`CheckTx` 设置 `GasUsed` 等于 `GasConsumed` 并在结果中返回它。在计算 gas 和费用值后，验证器节点检查用户指定的“gas-prices”是否大于他们本地定义的“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. +如果在 `CheckTx` 期间的任何时候 `Tx` 失败，它将被丢弃并且事务生命周期结束 +那里。否则，如果它成功通过`CheckTx`，默认协议是将其中继到peer +节点并将其添加到内存池，以便“Tx”成为包含在下一个块中的候选者。 -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. +**mempool** 用于跟踪所有全节点看到的交易。 +全节点保留他们看到的最后一个 `mempool.cache_size` 交易的**mempool cache**，作为第一行 +防御以防止重放攻击。理想情况下，`mempool.cache_size` 足够大以包含所有 +整个内存池中的交易。如果 mempool 缓存太小而无法跟踪所有 +交易，`CheckTx` 负责识别和拒绝重放的交易。 -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. +当前现有的预防措施包括费用和“序列”(nonce)计数器，以区分 +从相同但有效的交易重放交易。如果攻击者试图向具有许多 +“Tx”的副本，保留内存池缓存的全节点将拒绝相同的副本而不是运行 +“CheckTx”对所有这些。即使副本增加了“序列”号，攻击者 +因需要支付费用而感到沮丧。 -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). +验证器节点保留一个内存池以防止重放攻击，就像全节点一样，但也将其用作 +准备区块包含的未确认交易池。请注意，即使`Tx` +在这个阶段通过了所有的检查，后面还是有可能被发现无效的，因为 +`CheckTx` 不完全验证交易(即它实际上不执行消息)。 -## 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. +共识，验证节点就哪些交易达成一致的过程 +接受，发生在**轮**。每一轮都从提议者创建一个区块开始 +最近的交易并以**验证器**结束，具有投票权的特殊全节点 +为了达成共识，同意接受该区块或改为使用“nil”区块。验证节点 +执行共识算法，例如[Tendermint BFT](https://tendermint.com/docs/spec/consensus/consensus.html#terms)， +使用 ABCI 请求向应用程序确认交易，以达成本协议。 -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. +共识的第一步是**区块提案**。选择验证者中的一名提议者 +通过共识算法创建和提议一个块 - 为了包含一个“Tx”，它 +必须在这个提议者的内存池中。 -## 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. +共识的下一步是执行交易以完全验证它们。所有全节点 +收到来自正确提议者的区块提议的人通过调用 ABCI 函数执行交易 +[`BeginBlock`](./app-anatomy.md#beginblocker-and-endblocker)，每笔交易的`DeliverTx`， +和 [`EndBlock`](./app-anatomy.md#beginblocker-and-endblocker)。虽然每个全节点运行一切 +在本地，这个过程产生一个单一的、明确的结果，因为消息的状态转换是确定性的，而交易是 +在区块提案中明确排序。 ``` ----------------------- @@ -177,65 +177,65 @@ explicitly ordered in the block proposal. ### 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 Protobuf [`Msg` service](../building-modules/msg-services.md). - For `LegacyMsg` 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:** a Protobuf `Msg` service, a step up from `AnteHandler`, is responsible for executing each - message in the `Tx` and causes state transitions to persist in `deliverTxState`. - -- **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} +[`BaseApp`](../core/baseapp.md) 中定义的 `DeliverTx` ABCI 函数完成了大部分 +状态转换:按提交的顺序为块中的每个事务运行 +在达成共识期间。在幕后，`DeliverTx` 几乎与 `CheckTx` 相同，但调用 +[`runTx`](../core/baseapp.md#runtx) 在交付模式而不是检查模式下运行。 +全节点不使用它们的 `checkState`，而是使用 `deliverState`: + +- **Decoding:** 因为 `DeliverTx` 是一个 ABCI 调用，`Tx` 是以编码的 `[]byte` 形式接收的。 + 节点首先解组事务，使用应用程序中定义的 [`TxConfig`](./app-anatomy#register-codec)，然后在 `runTxModeDeliver` 中调用 `runTx`，它与 `CheckTx` 非常相似，但也执行并写入状态变化。 + +- **检查:**全节点再次调用`validateBasicMsgs`和`AnteHandler`。第二次检查 + 发生的原因是他们在添加到 Mempool 阶段期间可能没有看到相同的交易\ + 并且恶意提议者可能包含无效提议者。这里的一个区别是 + `AnteHandler` 不会将 `gas-prices` 与节点的 `min-gas-prices` 进行比较，因为该值是本地的 + 到每个节点 - 节点之间的不同值会产生不确定的结果。 + +- **`MsgServiceRouter`:** 虽然 `CheckTx` 会退出，`DeliverTx` 继续运行 + [`runMsgs`](../core/baseapp.md#runtx-and-runmsgs) 在事务中完全执行每个 `Msg`。 + 由于事务可能有来自不同模块的消息，BaseApp 需要知道哪个模块 + 找到合适的处理程序。这是使用`BaseApp` 的`MsgServiceRouter` 实现的，以便它可以由模块的Protobuf [`Msg` 服务](../building-modules/msg-services.md) 处理。 + 对于 `LegacyMsg` 路由，`Route` 函数通过 [module manager](../building-modules/module-manager.md) 调用以检索路由名称并找到遗留的 [`Handler`](../building-modules/msg-services.md#handler-type) 在模块中。 + +- **`Msg` 服务:** Protobuf `Msg` 服务，是 `AnteHandler` 的一个步骤，负责执行每个 + `Tx` 中的消息并导致状态转换在 `deliverTxState` 中持续存在。 + +- **Gas:** 在交付`Tx` 时，使用`GasMeter` 来跟踪有多少 + 正在使用气体；如果执行完成，`GasUsed` 被设置并在 + `abci.ResponseDeliverTx`。如果执行因 `BlockGasMeter` 或 `GasMeter` 已用完或其他原因而停止 + 错误，最后的延迟函数适当地错误或恐慌。 + +如果由于“Tx”无效或“GasMeter”耗尽而导致任何失败的状态更改， +事务处理终止并恢复任何状态更改。无效交易 +区块提议导致验证者节点拒绝该区块并改为投票给“nil”区块。 + +### 犯罪 + +最后一步是让节点提交块和状态更改。验证节点 +执行上一步执行状态转换以验证交易， +然后签署区块以确认它。不是验证器的完整节点不会 +参与共识 - 即他们不能投票 - 但听取投票以了解是否或 +他们不应该提交状态更改。 + +当他们收到足够多的验证者投票(2/3+ _precommits_ 由投票权加权)时，全节点提交一个新的区块以添加到区块链中，并且 +在应用层完成状态转换。生成一个新的状态根作为 +状态转换的默克尔证明。应用程序使用 [`Commit`](../core/baseapp.md#commit) +ABCI 方法继承自 [Baseapp](../core/baseapp.md);它通过以下方式同步所有状态转换 +将 `deliverState` 写入应用程序的内部状态。一旦状态发生变化 +已提交，`checkState` 从最近提交的状态和 `deliverState` 重新开始 +重置为 `nil` 以保持一致并反映更改。 + +请注意，并非所有区块都具有相同数量的交易，并且有可能达成共识 +导致一个 `nil` 块或一个根本没有的块。在公共区块链网络中，也有可能 +验证者是**拜占庭**或恶意的，这可能会阻止“Tx”在 +区块链。可能的恶意行为包括提议者决定通过以下方式审查“Tx” +将其从区块或投票反对区块的验证者中排除。 + +至此，一个“Tx”的交易生命周期结束:节点验证了其有效性， +通过执行其状态更改来交付它，并提交这些更改。 `Tx` 本身， +以 `[]byte` 形式存储在一个块中并附加到区块链中。 + +## 下一个 {hide} + +了解 [accounts](./accounts.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/README.md b/docs/ja/building-modules/README.md index c10e6e10b5ab..a7cfe3e8a900 100644 --- a/docs/ja/building-modules/README.md +++ b/docs/ja/building-modules/README.md @@ -1,17 +1,17 @@ -# Building Modules +# 构建模块 -This repository contains documentation on concepts developers need to know in order to build modules for Cosmos SDK applications. +此存储库包含有关开发人员为构建 Cosmos SDK 应用程序模块而需要了解的概念的文档。 -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) +1. [Cosmos SDK 模块介绍](./intro.md) +2. [`AppModule`接口和模块管理器](./module-manager.md) +3. [消息和查询](./messages-and-queries.md) +4. [`Msg`服务-处理消息](./msg-services.md) +5. [查询服务-处理查询](./query-services.md) +6. [BeginBlocker 和 EndBlocker](./beginblock-endblock.md) 7. [`Keeper`s](./keeper.md) -8. [Invariants](./invariants.md) +8. [不变量](./invariants.md) 9. [Genesis](./genesis.md) -10. [Module Interfaces](./module-interfaces.md) -11. [Standard Module Structure](./structure.md) -12. [Errors](./errors.md) -13. [In-Place Store Migrations](./upgrade.md) +10. [模块接口](./module-interfaces.md) +11. [标准模块结构](./structure.md) +12. [错误](./errors.md) +13. [就地存储迁移](./upgrade.md) \ No newline at end of file diff --git a/docs/ja/building-modules/beginblock-endblock.md b/docs/ja/building-modules/beginblock-endblock.md index e1dda1aff562..79738a14374b 100644 --- a/docs/ja/building-modules/beginblock-endblock.md +++ b/docs/ja/building-modules/beginblock-endblock.md @@ -1,35 +1,35 @@ -# BeginBlocker and EndBlocker +# BeginBlocker 和 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} +`BeginBlocker` 和 `EndBlocker` 是模块开发人员可以在他们的模块中实现的可选方法。当 [`BeginBlock`](../core/baseapp.md#beginblock) 和 [`EndBlock`](../core/baseapp.md #endblock) 从底层共识引擎接收 ABCI 消息。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Module Manager](./module-manager.md) {prereq} +- [模块管理器](./module-manager.md) {prereq} -## BeginBlocker and EndBlocker +## BeginBlocker 和 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. +`BeginBlocker` 和 `EndBlocker` 是模块开发人员向其模块添加逻辑自动执行的一种方式。这是一个应该谨慎使用的强大工具，因为复杂的自动功能可能会减慢甚至停止链条。 -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 `abci.go`. +需要时，`BeginBlocker` 和`EndBlocker` 作为[`AppModule` 接口](./module-manager.md#appmodule) 的一部分实现。 `module.go`中实现的接口的`BeginBlock`和`EndBlock`方法一般分别遵循`BeginBlocker`和`EndBlocker`方法，通常在`abci.go`中实现。 -The actual implementation of `BeginBlocker` and `EndBlocker` in `abci.go` are very similar to that of a [`Msg` service](./msg-services.md): +`abci.go` 中 `BeginBlocker` 和 `EndBlocker` 的实际实现与 [`Msg` 服务](./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`. +- 他们通常使用 [`keeper`](./keeper.md) 和 [`ctx`](../core/context.md) 来检索有关最新状态的信息。 +- 如果需要，他们使用 `keeper` 和 `ctx` 来触发状态转换。 +- 如果需要，他们可以通过 `ctx` 的 `EventManager` 发出 [`events`](../core/events.md)。 -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. +`EndBlocker` 的一个特殊性是它可以以 [`[]abci.ValidatorUpdates`](https://tendermint.com/docs/app-dev/abci- spec.html#validatorupdate)。这是实现自定义验证器更改的首选方式。 -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). +开发人员可以通过模块的管理器“SetOrderBeginBlocker”/“SetOrderEndBlocker”方法定义每个应用程序模块的“BeginBlocker”/“EndBlocker”函数之间的执行顺序。有关模块管理器的更多信息，请单击 [此处](./module-manager.md#manager)。 -See an example implementation of `BeginBlocker` from the `distr` module: +从 `disr` 模块查看 `BeginBlocker` 的示例实现: +++ https://github.com/cosmos/cosmos-sdk/blob/f33749263f4ecc796115ad6e789cb0f7cddf9148/x/distribution/abci.go#L14-L38 -and an example implementation of `EndBlocker` from the `staking` module: +以及来自 `staking` 模块的 `EndBlocker` 的示例实现: +++ https://github.com/cosmos/cosmos-sdk/blob/f33749263f4ecc796115ad6e789cb0f7cddf9148/x/staking/abci.go#L22-L27 -## Next {hide} +## 下一个 {hide} -Learn about [`keeper`s](./keeper.md) {hide} +了解 [`keeper`s](./keeper.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/errors.md b/docs/ja/building-modules/errors.md index 25a8327ac86c..94e498b806e8 100644 --- a/docs/ja/building-modules/errors.md +++ b/docs/ja/building-modules/errors.md @@ -1,46 +1,46 @@ -# Errors +# 错误 -This document outlines the recommended usage and APIs for error handling in Cosmos SDK modules. {synopsis} +本文档概述了 Cosmos SDK 模块中用于错误处理的推荐用法和 API。 {概要} -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}/errors.go`. Registration -of errors is handled via the `types/errors` package. +模块应该在 `x/{module}/errors.go` 中定义和注册它们的自定义错误。登记 +错误是通过 `types/errors` 包处理的。 -Example: +例子: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0/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 Cosmos SDK error. Typically, the code is monotonically increasing but does not -necessarily have to be. The only restrictions on error codes are the following: +每个自定义模块错误都必须提供代码空间，通常是模块名称 +(例如“分发”)并且每个模块都是唯一的，以及一个 uint32 代码。一起，代码空间和代码 +提供全球唯一的 Cosmos SDK 错误。通常，代码是单调递增的，但不会 +必须是。错误代码的唯一限制如下: -* Must be greater than one, as a code value of one is reserved for internal errors. -* Must be unique within the module. +* 必须大于 1，因为 1 的代码值是为内部错误保留的。 +* 在模块内必须是唯一的。 -Note, the Cosmos SDK provides a core set of *common* errors. These errors are defined in `types/errors/errors.go`. +请注意，Cosmos SDK 提供了一组核心的*常见*错误。这些错误在 `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. +自定义模块错误可以作为它们的具体类型返回，因为它们已经满足了 `error` +界面。但是，可以包装模块错误以提供进一步的上下文和含义以失败 +执行。 -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 Cosmos SDK's `errors` package provides an API to determine if -an error is of a particular kind via `Is`. +不管错误是否被包装，Cosmos SDK 的 `errors` 包提供了一个 API 来确定是否 +错误是通过`Is` 产生的一种特殊类型。 ## ABCI -If a module error is registered, the Cosmos 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. +如果注册了模块错误，Cosmos SDK `errors` 包允许提取 ABCI 信息 +通过`ABCIInfo` API。该包还提供了 `ResponseCheckTx` 和 `ResponseDeliverTx` 作为 +辅助 API 可自动从错误中获取 `CheckTx` 和 `DeliverTx` 响应。 \ No newline at end of file diff --git a/docs/ja/building-modules/genesis.md b/docs/ja/building-modules/genesis.md index 22934ede0d77..9f6f57dce7b2 100644 --- a/docs/ja/building-modules/genesis.md +++ b/docs/ja/building-modules/genesis.md @@ -1,56 +1,56 @@ -# 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} +- [模块管理器](./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. +从给定模块定义的创世状态的子集通常在 `genesis.proto` 文件中定义([更多信息](../core/encoding.md#gogoproto)关于如何定义 protobuf 消息)。定义模块的创世状态子集的结构通常称为“GenesisState”，它包含所有需要在创世过程中初始化的模块相关值。 -See an example of `GenesisState` protobuf message definition from the `auth` module: +查看来自 `auth` 模块的 `GenesisState` protobuf 消息定义示例: +++ 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. +接下来，我们将介绍模块开发人员需要实现的主要与创世相关的方法，以便他们的模块在 Cosmos SDK 应用程序中使用。 ### `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: +`DefaultGenesis()` 方法是一个简单的方法，它使用每个参数的默认值调用 `GenesisState` 的构造函数。查看来自 `auth` 模块的示例: +++ 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 parameters listed in `GenesisState`. See an example from the `auth` module: +调用 `ValidateGenesis(genesisState GenesisState)` 方法来验证提供的 `genesisState` 是否正确。它应该对“GenesisState”中列出的每个参数执行有效性检查。查看来自 `auth` 模块的示例: +++ 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). +除了与 `GenesisState` 直接相关的方法，模块开发者需要实现另外两个方法作为 [`AppModuleGenesis` 接口](./module-manager.md#appmodulegenesis) 的一部分(仅当模块需要初始化一个创世中状态的子集)。这些方法是 [`InitGenesis`](#initgenesis) 和 [`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`. +`InitGenesis` 方法在应用程序第一次启动时在 [`InitChain`](../core/baseapp.md#initchain) 期间执行。给定一个 `GenesisState`，它通过对 `GenesisState` 中的每个参数使用模块的 [`keeper`](./keeper.md) setter 函数来初始化模块管理的状态子集。 -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). +应用的[模块管理器](./module-manager.md#manager)负责依次调用应用的各个模块的`InitGenesis`方法。此顺序由应用程序开发人员通过管理器的`SetOrderGenesisMethod` 设置，该方法在[应用程序的构造函数](../basics/app-anatomy.md#constructor-function) 中调用。 -See an example of `InitGenesis` from the `auth` module: +请参阅“auth”模块中的“InitGenesis”示例: +++ 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. +每当进行状态导出时，都会执行“ExportGenesis”方法。它采用模块管理的状态子集的最新已知版本，并从中创建一个新的“GenesisState”。这主要用于需要通过硬分叉升级链时。 -See an example of `ExportGenesis` from the `auth` module. +请参阅“auth”模块中的“ExportGenesis”示例。 +++ https://github.com/cosmos/cosmos-sdk/blob/64b6bb5270e1a3b688c2d98a8f481ae04bb713ca/x/auth/genesis.go#L31-L42 -## Next {hide} +## 下一个 {hide} -Learn about [modules interfaces](module-interfaces.md) {hide} +了解 [模块接口](module-interfaces.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/intro.md b/docs/ja/building-modules/intro.md index ab13be36116d..9f4e29357e8e 100644 --- a/docs/ja/building-modules/intro.md +++ b/docs/ja/building-modules/intro.md @@ -1,19 +1,19 @@ -# Introduction to Cosmos SDK Modules +# Cosmos SDK 模块介绍 -Modules define most of the logic of Cosmos SDK applications. Developers compose modules 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} +模块定义了 Cosmos SDK 应用程序的大部分逻辑。开发人员使用 Cosmos SDK 将模块组合在一起，以构建他们自定义的特定于应用程序的区块链。本文档概述了 SDK 模块背后的基本概念以及如何进行模块管理。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} -- [Lifecycle of a Cosmos SDK transaction](../basics/tx-lifecycle.md) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} +- [Cosmos SDK 交易的生命周期](../basics/tx-lifecycle.md) {prereq} -## Role of Modules in a Cosmos SDK Application +## 模块在 Cosmos SDK 应用程序中的作用 -The Cosmos SDK can be thought of 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](./module-interfaces.md) to handle queries. +Cosmos SDK 可以被认为是区块链开发的 Ruby-on-Rails。它带有一个核心，可提供每个区块链应用程序所需的基本功能，例如 [ABCI 的样板实现](../core/baseapp.md) 与底层共识引擎进行通信，[`multistore`](. ./core/store.md#multistore) 来持久化状态，一个 [server](../core/node.md) 来形成一个全节点和一个 [interfaces](./module-interfaces.md) 来处理查询. -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 Cosmos SDK modules, making it increasingly easier to build complex blockchain applications. +在此核心之上，Cosmos SDK 使开发人员能够构建实现其应用程序业务逻辑的模块。换句话说，SDK 模块实现了应用程序的大部分逻辑，而核心负责布线并使模块能够组合在一起。最终目标是构建一个强大的开源 Cosmos SDK 模块生态系统，使构建复杂的区块链应用程序变得越来越容易。 -Cosmos 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 components of Cosmos SDK core, [`BaseApp`](../core/baseapp.md), to a module Protobuf [`Msg` service](./msg-services.md) that defines them. +Cosmos SDK 模块可以看作是状态机中的小状态机。他们通常使用 [main multistore](../core/store.md) 中的一个或多个 `KVStore` 来定义状态的子集，以及 [消息类型](./messages-and-查询.md#messages)。这些消息由 Cosmos SDK 核心的主要组件之一 [`BaseApp`](../core/baseapp.md) 路由到模块 Protobuf [`Msg` 服务](./msg-services.md)这定义了它们。 ``` + @@ -60,29 +60,29 @@ Cosmos SDK modules can be seen as little state-machines within the state-machine v ``` -As a result of this architecture, building a Cosmos 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. +由于这种架构，构建 Cosmos SDK 应用程序通常围绕编写模块来实现应用程序的专用逻辑，并将它们与现有模块组合以完成应用程序。开发人员通常会处理实现其特定用例所需逻辑但尚不存在的模块，并将使用现有模块实现更通用的功能，如抵押、账户或令牌管理。 -## How to Approach Building Modules as a Developer +## 作为开发人员如何处理构建模块 -While there are no definitive guidelines for writing modules, here are some important design principles developers should keep in mind when building them: +虽然编写模块没有明确的指导方针，但开发人员在构建模块时应牢记以下一些重要的设计原则: -- **Composability**: Cosmos 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 concerns 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 modules to be malicious. That is why module developers need to carefully think not only about how their module interacts 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`. +- **可组合性**:Cosmos SDK 应用程序几乎总是由多个模块组成。这意味着开发人员不仅需要仔细考虑他们的模块与 Cosmos SDK 核心的集成，还需要仔细考虑与其他模块的集成。前者是通过遵循 [here](#main-components-of-sdk-modules) 概述的标准设计模式来实现的，而后者是通过 [`keeper`]( ./keeper.md)。 +- **专业化**:**可组合性**特性的一个直接后果是模块应该是**专业化的**。开发人员应仔细确定其模块的范围，而不是将多个功能批量合并到同一个模块中。这种关注点分离使模块能够在其他项目中重用，并提高应用程序的可升级性。 **专业化**在 Cosmos SDK 的 [对象-能力模型](../core/ocap.md) 中也扮演着重要的角色。 +- **功能**:大多数模块需要读取和/或写入其他模块的存储。但是，在开源环境中，某些模块可能是恶意的。这就是为什么模块开发人员不仅需要仔细考虑他们的模块如何与其他模块交互，还要考虑如何访问模块的存储。 Cosmos SDK 采用面向功能的方法来实现模块间安全。这意味着模块定义的每个 store 都由一个 `key` 访问，该 `key` 由模块的 [`keeper`](./keeper.md) 持有。这个 `keeper` 定义了如何访问存储以及在什么条件下。对模块存储的访问是通过传递对模块的`keeper` 的引用来完成的。 -## Main Components of Cosmos SDK Modules +## Cosmos SDK 模块的主要组件 -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: +按照惯例，模块定义在`./x/` 子文件夹中(例如，`bank` 模块将定义在`./x/bank` 文件夹中)。它们通常共享相同的核心组件: -- 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. +- [`keeper`](./keeper.md)，用于访问模块的存储并更新状态。 +- 一个[`Msg`服务](./messages-and-queries.md#messages)，当消息被[`BaseApp`](../core/baseapp.md#message)路由到模块时，用于处理消息-routing)并触发状态转换。 +- [查询服务](./query-services.md)，当用户查询被[`BaseApp`](../core/baseapp.md#query-routing)路由到模块时，用于处理用户查询。 +- 接口，供最终用户查询模块定义的状态子集并创建模块中定义的自定义类型的“消息”。 -In addition to these components, modules implement the `AppModule` interface in order to be managed by the [`module manager`](./module-manager.md). +除了这些组件之外，模块还实现了`AppModule` 接口，以便由[`module manager`](./module-manager.md) 进行管理。 -Please refer to the [structure document](./structure.md) to learn about the recommended structure of a module's directory. +请参阅[结构文档](./structure.md) 了解推荐的模块目录结构。 -## Next {hide} +## 下一个 {hide} -Read more on the [`AppModule` interface and the `module manager`](./module-manager.md) {hide} +阅读更多关于 [`AppModule` 接口和 `module manager`](./module-manager.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/invariants.md b/docs/ja/building-modules/invariants.md index 2da814472114..ecadce80d4a6 100644 --- a/docs/ja/building-modules/invariants.md +++ b/docs/ja/building-modules/invariants.md @@ -1,20 +1,20 @@ -# 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} +不变量是应用程序的一个属性，它应该始终为真。在 Cosmos SDK 的上下文中，“不变量”是检查特定不变量的函数。这些功能可用于及早检测错误并对其采取行动以限制其潜在后果(例如，通过停止链)。它们在应用程序的开发过程中也很有用，可以通过模拟检测错误。 {概要} -## Pre-requisite Readings +## 先决条件阅读 - [Keepers](./keeper.md) {prereq} -## Implementing `Invariant`s +## 实现 `Invariant`s -An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant` type: +`Invariant` 是一个函数，用于检查模块中的特定不变量。模块 `Invariant` 必须遵循 `Invariant` 类型: +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/types/invariant.go#L9 -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. +`string` 返回值是不变消息，可以在打印日志时使用，`bool` 返回值是不变检查的实际结果。 -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: +实际上，每个模块在模块文件夹内的`./keeper/invariants.go` 文件中实现`Invariant`。标准是使用以下模型为每个不变量的逻辑分组实现一个“不变量”函数: ```go // Example for an Invariant that checks balance-related invariants @@ -26,7 +26,7 @@ func BalanceInvariants(k Keeper) sdk.Invariant { } ``` -Additionally, module developers should generally implement an `AllInvariants` function that runs all the `Invariant`s functions of the module: +此外，模块开发人员通常应该实现一个 `AllInvariants` 函数来运行模块的所有 `Invariant` 函数: ```go // AllInvariants runs all invariants of the module. @@ -45,7 +45,7 @@ func AllInvariants(k Keeper) sdk.Invariant { } ``` -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/module.go` file, typically only defers the call to a `RegisterInvariants` method implemented in the `keeper/invariants.go` file. The `RegisterInvariants` method registers a route for each `Invariant` function in the [`InvariantRegistry`](#invariant-registry): +最后，模块开发者需要实现 `RegisterInvariants` 方法作为 [`AppModule` 接口](./module-manager.md#appmodule) 的一部分。 实际上，在`module/module.go` 文件中实现的模块的`RegisterInvariants` 方法通常只将调用延迟到在`keeper/invariants.go` 文件中实现的`RegisterInvariants` 方法。 `RegisterInvariants` 方法为 [`InvariantRegistry`](#invariant-registry) 中的每个 `Invariant` 函数注册一个路由: ```go // RegisterInvariants registers all staking invariants @@ -57,28 +57,28 @@ func RegisterInvariants(ir sdk.InvariantRegistry, k Keeper) { } ``` -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). +有关更多信息，请参阅 [`staking` 模块中的 `Invariant` 实现示例](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. +`InvariantRegistry` 是一个注册表，其中注册了应用程序所有模块的 `Invariant`。每个 **application** 只有一个 `InvariantRegistry`，这意味着模块开发人员在构建模块时不需要实现他们自己的 `InvariantRegistry`。 **所有模块开发人员需要做的是在 `InvariantRegistry` 中注册他们模块的不变量，如上一节所述**。本节的其余部分提供有关 `InvariantRegistry` 本身的更多信息，不包含与模块开发人员直接相关的任何内容。 -At its core, the `InvariantRegistry` is defined in the Cosmos SDK as an interface: +在其核心，`InvariantRegistry` 在 Cosmos SDK 中被定义为一个接口: +++ 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: +通常，此接口在特定模块的“keeper”中实现。 `InvariantRegistry` 最常用的实现可以在 `crisis` 模块中找到: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/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). + 因此，`InvariantRegistry` 通常是通过在 [应用程序的构造函数](../basics/app-anatomy.md#constructor-function) 中实例化 `crisis` 模块的 `keeper` 来实例化的。 -`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: +`Invariant`s 可以通过 [`message`s](./messages-and-queries.md) 手动检查，但大多数情况下它们会在每个块的末尾自动检查。下面是来自“crisis”模块的一个例子: +++ 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). +在这两种情况下，如果 `Invariant` 之一返回 false，`InvariantRegistry` 可以触发特殊逻辑(例如，让应用程序恐慌并在日志中打印 `Invariant`s 消息)。 -## Next {hide} +## 下一个 {hide} -Learn about [genesis functionalities](./genesis.md) {hide} +了解 [创世功能](./genesis.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/keeper.md b/docs/ja/building-modules/keeper.md index 23c2e7921676..0f80ab539faa 100644 --- a/docs/ja/building-modules/keeper.md +++ b/docs/ja/building-modules/keeper.md @@ -1,22 +1,22 @@ -# 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} +`Keeper` 是指 Cosmos SDK 抽象，其作用是管理对由各种模块定义的状态子集的访问。 `Keeper`s 是特定于模块的，即模块定义的状态子集只能由该模块中定义的 `keeper` 访问。如果一个模块需要访问另一个模块定义的状态子集，则需要将第二个模块内部 `keeper` 的引用传递给第一个模块。这是在模块管理器实例化期间在`app.go` 中完成的。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Introduction to Cosmos SDK Modules](./intro.md) {prereq} +- [Cosmos SDK 模块介绍](./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. +Cosmos SDK 是一个框架，它使开发人员可以轻松地从头开始构建复杂的去中心化应用程序，主要是通过将模块组合在一起。随着 Cosmos SDK 开源模块生态系统的扩展，由于开发人员的疏忽或恶意，其中一些模块包含漏洞的可能性越来越大。 -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). +Cosmos SDK 采用[基于对象能力的方法](../core/ocap.md) 来帮助开发人员更好地保护他们的应用程序免受不需要的模块间交互的影响，而`keeper`s 是这种方法的核心。 `keeper` 可以从字面上理解为模块存储的看门人。模块中定义的每个存储(通常是 [`IAVL` Store](../core/store.md#iavl-store))都带有一个 `storeKey`，可以无限制地访问它。模块的 `keeper` 持有这个 `storeKey`(否则它应该保持不公开)，并定义 [methods](#implementing-methods) 以读取和写入存储。 -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. +对象能力方法背后的核心思想是只揭示完成工作所需的内容。在实践中，这意味着不是通过访问控制列表处理模块的权限，而是向模块 `keeper` 传递对它们需要访问的其他模块 `keeper` 的特定实例的引用(这是在[应用程序的构造函数](../basics/app-anatomy.md#constructor-function))。因此，一个模块只能通过另一个模块的“keeper”实例公开的方法与另一个模块中定义的状态子集交互。这是开发人员控制他们自己的模块与外部开发人员开发的模块之间的交互的好方法。 -## 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: +`keeper`s 通常在位于模块文件夹中的 `/keeper/keeper.go` 文件中实现。按照惯例，模块的类型 `keeper` 简称为 `Keeper`，通常遵循以下结构: ```go type Keeper struct { @@ -28,54 +28,54 @@ type Keeper struct { } ``` -For example, here is the type definition of the `keeper` from the `staking` module: +例如，这里是来自 `staking` 模块的 `keeper` 的类型定义: +++ 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 an `expected_keepers.go` file in the root of 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. -- `cdc` is the [codec](../core/encoding.md) used to marshall and unmarshall structs to/from `[]byte`. The `cdc` can be any of `codec.BinaryCodec`, `codec.JSONCodec` or `codec.Codec` based on your requirements. It can be either a proto or amino codec as long as they implement these interfaces. +- 预期的“keeper”是模块外部的“keeper”，该模块的内部“keeper”需要该模块。外部“keeper”作为接口列在内部“keeper”的类型定义中。这些接口本身是在模块文件夹根目录下的“expected_keepers.go”文件中定义的。在这种情况下，接口用于减少依赖项的数量，以及方便模块本身的维护。 +- `storeKey`s 授予对模块管理的 [multistore](../core/store.md)存储的访问权限。它们应始终不暴露于外部模块。 +- `cdc` 是 [codec](../core/encoding.md) 用于将结构编组和解组到/从 `[]byte`。 `cdc` 可以是 `codec.BinaryCodec`、`codec.JSONCodec` 或 `codec.Codec` 中的任何一种，具体取决于您的要求。只要它们实现了这些接口，它就可以是 proto 或氨基编解码器。 -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 them. +当然，可以为同一模块定义不同类型的内部 `keeper`(例如只读 `keeper`)。每种类型的 `keeper` 都有自己的构造函数，它是从 [应用程序的构造函数](../basics/app-anatomy.md) 调用的。这是实例化 `keeper` 的地方，开发人员确保将模块 `keeper` 的正确实例传递给需要它们的其他模块。 -## 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. +`Keeper`s 主要公开由其模块管理的存储的 getter 和 setter 方法。这些方法应该尽可能简单，并严格限于获取或设置请求的值，因为有效性检查应该已经通过 [`message`](./messages-and-) 的 `ValidateBasic()` 方法执行了query.md#messages) 和 [`Msg` 服务器](./msg-services.md) 当 `keeper`s' 方法被调用时。 -Typically, a *getter* method will have the following signature +通常，*getter* 方法将具有以下签名 ```go func (k Keeper) Get(ctx sdk.Context, key string) returnType ``` -and the method will 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. +1. 使用 `storeKey` 从 `ctx` 中检索适当的存储。 这是通过 `ctx` 的 `KVStore(storeKey sdk.StoreKey)` 方法完成的。 然后，为了方便和安全，最好使用`prefix.Store` 来仅访问所需的有限的存储子集。 +2. 如果存在，则使用存储的`Get(key []byte)`方法获取存储在位置`[]byte(key)`的`[]byte`值。 +3. 使用编解码器 `cdc` 将检索到的值从 `[]byte` 解组为 `returnType`。 返回值。 -Similarly, a *setter* method will have the following signature +同样，*setter* 方法将具有以下签名 ```go func (k Keeper) Set(ctx sdk.Context, key string, value valueType) ``` -and the method will 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`. It's preferred 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. +1. 使用 `storeKey` 从 `ctx` 中检索适当的存储。这是通过 `ctx` 的 `KVStore(storeKey sdk.StoreKey)` 方法完成的。为了方便和安全，最好使用 `prefix.Store` 来仅访问所需的有限的存储子集。 +2. 使用编解码器 `cdc` 将 `value` 编组为 `[]byte`。 +3. 使用 store 的 `Set(key []byte, value []byte)` 方法在位置 `key` 的 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). +有关更多信息，请参阅 `keeper` 的示例 [`staking` 模块中的方法实现](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. +[module `KVStore`](../core/store.md#kvstore-and-commitkvstore-interfaces) 还提供了一个 `Iterator()` 方法，该方法返回一个 `Iterator` 对象来迭代密钥域。 -This is an example from the `auth` module to iterate accounts: +这是一个来自 `auth` 模块的示例，用于迭代帐户: +++ https://github.com/cosmos/cosmos-sdk/blob/bf8809ef9840b4f5369887a38d8345e2380a567f/x/auth/keeper/account.go#L70-L83 -## Next {hide} +## 下一个 {hide} -Learn about [invariants](./invariants.md) {hide} +了解 [不变量](./invariants.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/messages-and-queries.md b/docs/ja/building-modules/messages-and-queries.md index 7e3bdb5bafdd..d50c82a2aca8 100644 --- a/docs/ja/building-modules/messages-and-queries.md +++ b/docs/ja/building-modules/messages-and-queries.md @@ -1,111 +1,111 @@ -# 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} +`Msg`s 和 `Queries` 是模块处理的两个主要对象。模块中定义的大多数核心组件，如 `Msg` 服务、`keeper`s 和 `Query` 服务，都用于处理 `message`s 和 `queries`。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Introduction to Cosmos SDK Modules](./intro.md) {prereq} +- [Cosmos SDK 模块介绍](./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. +`Msg`s 是其最终目标是触发状态转换的对象。它们包含在 [transactions](../core/transactions.md) 中，其中可能包含其中一个或多个。 -When a transaction is relayed from the underlying consensus engine to the Cosmos 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). +当交易从底层共识引擎中继到 Cosmos SDK 应用程序时，它首先被 [`BaseApp`](../core/baseapp.md) 解码。然后，事务中包含的每条消息都被提取并通过`BaseApp` 的`MsgServiceRouter` 路由到适当的模块，以便模块的[`Msg` 服务](./msg-services.md) 处理它。有关事务生命周期的更详细说明，请单击 [此处](../basics/tx-lifecycle.md)。 -### `Msg` Services +### `Msg` 服务 -Starting from v0.40, defining Protobuf `Msg` services is the recommended way to handle messages. A Protobuf `Msg` service should be created for each 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. +从 v0.40 开始，定义 Protobuf `Msg` 服务是处理消息的推荐方式。应该为每个模块创建 Protobuf `Msg` 服务，通常在 `tx.proto` 中(请参阅有关 [约定和命名](../core/encoding.md#faq) 的更多信息)。它必须为模块中的每条消息定义一个 RPC 服务方法。 -See an example of a `Msg` service definition from `x/bank` module: +查看来自 `x/bank` 模块的 `Msg` 服务定义示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L10-L17 -Each `Msg` service method must have exactly one argument, which must implement the `sdk.Msg` interface, and a Protobuf response. The naming convention is to call the RPC argument `Msg` and the RPC response `MsgResponse`. For example: +每个 `Msg` 服务方法必须只有一个参数，该参数必须实现 `sdk.Msg` 接口和一个 Protobuf 响应。命名约定是调用 RPC 参数 `Msg` 和 RPC 响应 `MsgResponse`。例如: ``` rpc Send(MsgSend) returns (MsgSendResponse); ``` -`sdk.Msg` interface is a simplified version of the Amino `LegacyMsg` interface described [below](#legacy-amino-msgs) with only `ValidateBasic()` and `GetSigners()` methods. For backwards compatibility with [Amino `LegacyMsg`s](#legacy-amino-msgs), existing `LegacyMsg` types should be used as the request parameter for `service` RPC definitions. Newer `sdk.Msg` types, which only support `service` definitions, should use canonical `Msg...` name. +`sdk.Msg` 接口是 [下文](#legacy-amino-msgs) 描述的 Amino `LegacyMsg` 接口的简化版本，只有 `ValidateBasic()` 和 `GetSigners()` 方法。为了向后兼容 [Amino `LegacyMsg`s](#legacy-amino-msgs)，现有的 `LegacyMsg` 类型应该用作 `service` RPC 定义的请求参数。较新的 `sdk.Msg` 类型只支持 `service` 定义，应该使用规范的 `Msg...` 名称。 -The Cosmos SDK uses Protobuf definitions to generate client and server code: +Cosmos SDK 使用 Protobuf 定义生成客户端和服务器代码: -* `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. -* Structures are generated for all RPC request and response types. +* `MsgServer` 接口定义了 `Msg` 服务的服务器 API，其实现在 [`Msg` 服务](./msg-services.md) 文档中进行了描述。 +* 为所有 RPC 请求和响应类型生成结构。 -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). +还生成了一个 `RegisterMsgServer` 方法，它应该用于在来自 [`AppModule` 接口](./module-manager.md#appmodule) 的 `RegisterServices` 方法中注册模块的 `MsgServer` 实现。 -In order for clients (CLI and grpc-gateway) to have these URLs registered, the Cosmos 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. +为了让客户端(CLI 和 grpc-gateway)注册这些 URL，Cosmos SDK 提供了函数 `RegisterMsgServiceDesc(registry codectypes.InterfaceRegistry, sd *grpc.ServiceDesc)`，应该在模块的 [`RegisterInterfaces`]( module-manager.md#appmodulebasic) 方法，使用原型生成的 `&_Msg_serviceDesc` 作为 `*grpc.ServiceDesc` 参数。 ### Legacy Amino `LegacyMsg`s -The following way of defining messages is deprecated and using [`Msg` services](#msg-services) is preferred. +不推荐使用以下定义消息的方式，首选使用 [`Msg` 服务](#msg-services)。 -Amino `LegacyMsg`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. +Amino `LegacyMsg`s 可以定义为 protobuf 消息。消息定义通常包括处理消息所需的参数列表，当最终用户想要创建包含所述消息的新事务时，他们将提供这些参数。 -A `LegacyMsg` 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 `sdk.Msg` interface: +`LegacyMsg` 通常伴随着一个标准的构造函数，它是从 [module's interface](./module-interfaces.md) 之一调用的。 `message`s 还需要实现 `sdk.Msg` 接口: +++ https://github.com/cosmos/cosmos-sdk/blob/4a1b2fba43b1052ca162b3a1e0b6db6db9c26656/types/tx_msg.go#L10-L33 -It extends `proto.Message` and contains the following methods: +它扩展了 `proto.Message` 并包含以下方法: -- `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 Cosmos 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. +- `Route() string`:此消息的路由名称。通常，模块中的所有“消息”都具有相同的路由，通常是模块的名称。 +- `Type() string`:消息的类型，主要用于 [events](../core/events.md)。这应该返回一个特定于消息的“字符串”，通常是消息本身的面额。 +- `ValidateBasic() error`:这个方法在处理`message`(在[`CheckTx`](../core/baseapp.md#checktx)和[`DeliverTx中)的早期就被`BaseApp`调用`](../core/baseapp.md#delivertx))，以便丢弃明显无效的消息。 `ValidateBasic` 应该只包括 *stateless* 检查，即不需要访问状态的检查。这通常包括检查消息的参数格式是否正确且有效(即“金额”对于传输而言严格为正数)。 +- `GetSignBytes() []byte`:返回消息的规范字节表示。用于生成签名。 +- `GetSigners() []AccAddress`:返回签名者列表。 Cosmos SDK 将确保交易中包含的每条“消息”都由此方法返回的列表中列出的所有签名者签名。 -See an example implementation of a `message` from the `gov` module: +查看来自 `gov` 模块的 `message` 的示例实现: +++ 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](../basics/query-lifecycle.md). +“查询”是应用程序的最终用户通过接口发出并由全节点处理的信息请求。全节点通过其共识引擎接收“查询”，并通过 ABCI 中继到应用程序。然后通过`BaseApp` 的`queryrouter` 将其路由到适当的模块，以便模块的查询服务(./query-services.md) 可以对其进行处理。要更深入地了解“查询”的生命周期，请单击 [此处](../basics/query-lifecycle.md)。 -### gRPC Queries +### gRPC 查询 -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`. +从 v0.40 开始，定义查询的首选方法是使用 [Protobuf 服务](https://developers.google.com/protocol-buffers/docs/proto#services)。应该在 `query.proto` 中为每个模块创建一个 `Query` 服务。该服务列出了以 `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). +作为`proto.Message`s，生成的`Response`类型默认实现[`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer)的`String()`方法。 -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). +还生成了一个 `RegisterQueryServer` 方法，应该用于在 [`AppModule` 接口](./module-manager.md#appmodule) 的 `RegisterServices` 方法中注册模块的查询服务器。 -### Legacy Queries +### 遗留查询 -Before the introduction of Protobuf and gRPC in the Cosmos SDK, there was usually no specific `query` object defined by module developers, contrary to `message`s. Instead, the Cosmos 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: +在 Cosmos SDK 中引入 Protobuf 和 gRPC 之前，通常没有模块开发人员定义的特定“查询”对象，与“消息”相反。相反，Cosmos SDK 采用了更简单的方法，使用简单的“路径”来定义每个“查询”。 `path` 包含 `query` 类型和处理它所需的所有参数。对于大多数模块查询，`path` 应该如下所示: -``` +`` 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`. +- `queryCategory` 是`query` 的类别，通常用于模块查询的`custom`。它用于区分 `BaseApp` 的 [`Query` 方法](../core/baseapp.md#query) 中不同类型的查询。 +- `baseApp` 的 [`queryRouter`](../core/baseapp.md#query-routing) 使用 `queryRoute` 将 `query` 映射到其模块。通常，`queryRoute` 应该是模块的名称。 +- 模块的 [`querier`](./query-services.md#legacy-queriers) 使用 `queryType` 将 `query` 映射到模块内适当的 `querier function`。 +- `args` 是处理 `query` 所需的实际参数。它们由最终用户填写。请注意，对于更大的查询，您可能更喜欢在请求 `req` 的 `Data` 字段而不是 `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: +每个`query`的`path`必须由模块开发者在模块的[命令行界面文件](./module-interfaces.md#query-commands)中定义。总的来说，模块开发者需要3个主要组件实现以使由其模块定义的状态子集可查询: -- 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). +- [`querier`](./query-services.md#legacy-queriers)，一旦它被[路由到模块](../core/baseapp.md#query-routing) 处理`query` )。 +- [查询命令](./module-interfaces.md#query-commands) 在模块的 CLI 文件中，其中指定了每个 `query` 的 `path`。 +- `query` 返回类型。通常在文件 `types/querier.go` 中定义，它们指定每个模块的 `queries` 的结果类型。这些自定义类型必须实现 [`fmt.Stringer`](https://golang.org/pkg/fmt/#Stringer) 的 `String()` 方法。 -### 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. +存储查询直接查询存储键。他们使用 `clientCtx.QueryABCI(req abci.RequestQuery)` 返回完整的 `abci.ResponseQuery` 并包含 Merkle 证明。 -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} +## 下一个 {hide} -Learn about [`Msg` services](./msg-services.md) {hide} +了解 [`Msg` 服务](./msg-services.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/module-interfaces.md b/docs/ja/building-modules/module-interfaces.md index afb51f0c343a..ee63ccd37183 100644 --- a/docs/ja/building-modules/module-interfaces.md +++ b/docs/ja/building-modules/module-interfaces.md @@ -1,135 +1,134 @@ -# Module Interfaces +# 模块接口 -This document details how to build CLI and REST interfaces for a module. Examples from various Cosmos SDK modules are included. {synopsis} +本文档详细介绍了如何为模块构建 CLI 和 REST 接口。包括来自各种 Cosmos SDK 模块的示例。 {概要} -## Prerequisite Readings +## 先决条件阅读 -- [Building Modules Intro](./intro.md) {prereq} +- [构建模块介绍](./intro.md) {prereq} -## CLI +##命令行界面 -One of the main interfaces for an application is the [command-line interface](../core/cli.md). This entrypoint adds commands from the application's modules enabling end-users to create [**messages**](./messages-and-queries.md#messages) wrapped in transactions and [**queries**](./messages-and-queries.md#queries). The CLI files are typically found in the module's `./client/cli` folder. +应用程序的主要界面之一是[命令行界面](../core/cli.md)。此入口点添加来自应用程序模块的命令，使最终用户能够创建包裹在事务中的 [**messages**](./messages-and-queries.md#messages) 和 [**queries**](./messages-和-queries.md#queries)。 CLI 文件通常位于模块的`./client/cli` 文件夹中。 -### Transaction Commands +### 交易命令 - In order to create messages that trigger state changes, end-users must create [transactions](../core/transactions.md) that wrap and deliver the messages. A transaction command creates a transaction that includes one or more messages. + 为了创建触发状态更改的消息，最终用户必须创建 [transactions](../core/transactions.md) 来包装和传递消息。事务命令创建包含一条或多条消息的事务。 - Transaction commands typically have their own `tx.go` file that lives within the module's `./client/cli` folder. The commands are specified in getter functions and the name of the function should include the name of the command. + 事务命令通常有自己的 `tx.go` 文件，该文件位于模块的 `./client/cli` 文件夹中。命令在 getter 函数中指定，函数名称应包含命令名称。 -Here is an example from the `x/bank` module: +以下是来自 `x/bank` 模块的示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/bank/client/cli/tx.go#L28-L63 -In the example, `NewSendTxCmd()` creates and returns the transaction command for a transaction that wraps and delivers `MsgSend`. `MsgSend` is the message used to send tokens from one account to another. +在该示例中，`NewSendTxCmd()` 为包装和传递 `MsgSend` 的交易创建并返回交易命令。 `MsgSend` 是用于将令牌从一个帐户发送到另一个帐户的消息。 -In general, the getter function does the following: +通常，getter 函数执行以下操作: -- **Constructs the command:** Read the [Cobra Documentation](https://godoc.org/github.com/spf13/cobra) for more detailed information on how to create commands. - - **Use:** Specifies the format of the user input required to invoke the command. In the example above, `send` is the name of the transaction command and `[from_key_or_address]`, `[to_address]`, and `[amount]` are the arguments. - - **Args:** The number of arguments the user provides. In this case, there are exactly three: `[from_key_or_address]`, `[to_address]`, and `[amount]`. - - **Short and Long:** Descriptions for the command. A `Short` description is expected. A `Long` description can be used to provide additional information that is displayed when a user adds the `--help` flag. - - **RunE:** Defines a function that can return an error. This is the function that is called when the command is executed. This function encapsulates all of the logic to create a new transaction. - - The function typically starts by getting the `clientCtx`, which can be done with `client.GetClientTxContext(cmd)`. The `clientCtx` contains information relevant to transaction handling, including information about the user. In this example, the `clientCtx` is used to retrieve the address of the sender by calling `clientCtx.GetFromAddress()`. - - If applicable, the command's arguments are parsed. In this example, the arguments `[to_address]` and `[amount]` are both parsed. - - A [message](./messages-and-queries.md) is created using the parsed arguments and information from the `clientCtx`. The constructor function of the message type is called directly. In this case, `types.NewMsgSend(fromAddr, toAddr, amount)`. Its good practice to call `msg.ValidateBasic()` after creating the message, which runs a sanity check on the provided arguments. - - Depending on what the user wants, the transaction is either generated offline or signed and broadcasted to the preconfigured node using `tx.GenerateOrBroadcastTxCLI(clientCtx, flags, msg)`. -- **Adds transaction flags:** All transaction commands must add a set of transaction [flags](#flags). The transaction flags are used to collect additional information from the user (e.g. the amount of fees the user is willing to pay). The transaction flags are added to the constructed command using `AddTxFlagsToCmd(cmd)`. -- **Returns the command:** Finally, the transaction command is returned. - -Each module must implement `NewTxCmd()`, which aggregates all of the transaction commands of the module. Here is an example from the `x/bank` module: +- **构造命令:** 阅读 [Cobra 文档](https://godoc.org/github.com/spf13/cobra) 以获取有关如何创建命令的更多详细信息。 + - **Use:** 指定调用命令所需的用户输入的格式。在上面的例子中，`send` 是交易命令的名称，`[from_key_or_address]`、`[to_address]` 和 `[amount]` 是参数。 + - **Args:** 用户提供的参数数量。在这种情况下，正好有三个:“[from_key_or_address]”、“[to_address]”和“[amount]”。 + - **短和长:** 命令的描述。需要“简短”描述。 “长”描述可用于提供在用户添加“--help”标志时显示的附加信息。 + - **RunE:** 定义一个可以返回错误的函数。这是执行命令时调用的函数。该函数封装了创建新事务的所有逻辑。 + - 该函数通常从获取 `clientCtx` 开始，这可以通过 `client.GetClientTxContext(cmd)` 来完成。 `clientCtx` 包含与事务处理相关的信息，包括有关用户的信息。在这个例子中，`clientCtx` 用于通过调用 `clientCtx.GetFromAddress()` 来检索发件人的地址。 + - 如果适用，将解析命令的参数。在这个例子中，参数 `[to_address]` 和 `[amount]` 都被解析。 + - [message](./messages-and-queries.md) 是使用解析的参数和来自`clientCtx` 的信息创建的。直接调用消息类型的构造函数。在这种情况下，`types.NewMsgSend(fromAddr, toAddr, amount)`。在创建消息后调用 `msg.ValidateBasic()` 是一种很好的做法，它会对提供的参数运行健全性检查。 + - 根据用户的需求，交易要么离线生成，要么使用 `tx.GenerateOrBroadcastTxCLI(clientCtx, flags, msg)` 签名并广播到预先配置的节点。 +- **添加事务标志:** 所有事务命令都必须添加一组事务[flags](#flags)。交易标志用于从用户那里收集附加信息)例如用户愿意支付的费用金额)。使用`AddTxFlagsToCmd(cmd)`将事务标志添加到构造的命令中。 +- **返回指令:** 最后返回交易指令。 +每个模块都必须实现`NewTxCmd()`，它聚合了模块的所有事务命令。以下是来自 `x/bank` 模块的示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/bank/client/cli/tx.go#L13-L26 -Each module must also implement the `GetTxCmd()` method for `AppModuleBasic` that simply returns `NewTxCmd()`. This allows the root command to easily aggregate all of the transaction commands for each module. Here is an example: +每个模块还必须为 `AppModuleBasic` 实现 `GetTxCmd()` 方法，该方法只返回 `NewTxCmd()`。这允许 root 命令轻松聚合每个模块的所有事务命令。下面是一个例子: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/bank/module.go#L75-L78 -### 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's `./client/cli` folder. Like transaction commands, they are specified in getter functions. Here is an example of a query command from the `x/auth` module: +[查询](./messages-and-queries.md#queries) 允许用户收集有关应用程序或网络状态的信息；它们由应用程序路由并由定义它们的模块处理。查询命令通常在模块的 `./client/cli` 文件夹中有自己的 `query.go` 文件。与事务命令一样，它们在 getter 函数中指定。以下是来自 `x/auth` 模块的查询命令示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/auth/client/cli/query.go#L75-L105 -In the example, `GetAccountCmd()` creates and returns a query command that returns the state of an account based on the provided account address. +在示例中，`GetAccountCmd()` 创建并返回一个查询命令，该命令根据提供的帐户地址返回帐户状态。 -In general, the getter function does the following: +通常，getter 函数执行以下操作: -- **Constructs the command:** Read the [Cobra Documentation](https://godoc.org/github.com/spf13/cobra) for more detailed information on how to create commands. - - **Use:** Specifies the format of the user input required to invoke the command. In the example above, `account` is the name of the query command and `[address]` is the argument. - - **Args:** The number of arguments the user provides. In this case, there is exactly one: `[address]`. - - **Short and Long:** Descriptions for the command. A `Short` description is expected. A `Long` description can be used to provide additional information that is displayed when a user adds the `--help` flag. - - **RunE:** Defines a function that can return an error. This is the function that is called when the command is executed. This function encapsulates all of the logic to create a new query. - - The function typically starts by getting the `clientCtx`, which can be done with `client.GetClientQueryContext(cmd)`. The `clientCtx` contains information relevant to query handling. - - If applicable, the command's arguments are parsed. In this example, the argument `[address]` is parsed. - - A new `queryClient` is initialized using `NewQueryClient(clientCtx)`. The `queryClient` is then used to call the appropriate [query](./messages-and-queries.md#grpc-queries). - - The `clientCtx.PrintProto` method is used to format the `proto.Message` object so that the results can be printed back to the user. -- **Adds query flags:** All query commands must add a set of query [flags](#flags). The query flags are added to the constructed command using `AddQueryFlagsToCmd(cmd)`. -- **Returns the command:** Finally, the query command is returned. +- **构造命令:** 阅读 [Cobra 文档](https://godoc.org/github.com/spf13/cobra) 以获取有关如何创建命令的更多详细信息。 + - **Use:** 指定调用命令所需的用户输入的格式。在上面的例子中，`account` 是查询命令的名称，`[address]` 是参数。 + - **Args:** 用户提供的参数数量。在这种情况下，只有一个:`[address]`。 + - **短和长:** 命令的描述。需要“简短”描述。 “长”描述可用于提供在用户添加“--help”标志时显示的附加信息。 + - **RunE:** 定义一个可以返回错误的函数。这是执行命令时调用的函数。该函数封装了创建新查询的所有逻辑。 + - 该函数通常从获取 `clientCtx` 开始，这可以通过 `client.GetClientQueryContext(cmd)` 来完成。 `clientCtx` 包含与查询处理相关的信息。 + - 如果适用，将解析命令的参数。在这个例子中，解析了参数`[address]`。 + - 使用 `NewQueryClient(clientCtx)` 初始化一个新的 `queryClient`。然后使用 `queryClient` 调用适当的 [query](./messages-and-queries.md#grpc-queries)。 + - `clientCtx.PrintProto` 方法用于格式化 `proto.Message` 对象，以便可以将结果打印回给用户。 +- **添加查询标志:** 所有查询命令都必须添加一组查询[flags](#flags)。使用`AddQueryFlagsToCmd(cmd)`将查询标志添加到构造的命令中。 +- **返回命令:** 最后返回查询命令。 -Each module must implement `GetQueryCmd()`, which aggregates all of the query commands of the module. Here is an example from the `x/auth` module: +每个模块都必须实现`GetQueryCmd()`，它聚合了模块的所有查询命令。以下是来自 `x/auth` 模块的示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/auth/client/cli/query.go#L25-L42 -Each module must also implement the `GetQueryCmd()` method for `AppModuleBasic` that returns the `GetQueryCmd()` function. This allows for the root command to easily aggregate all of the query commands for each module. Here is an example: +每个模块还必须为`AppModuleBasic` 实现`GetQueryCmd()` 方法，该方法返回`GetQueryCmd()` 函数。这允许 root 命令轻松聚合每个模块的所有查询命令。下面是一个例子: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/auth/module.go#L80-L83 -### Flags +### 标志 -[Flags](../core/cli.md#flags) allow users to customize commands. `--fees` and `--gas-prices` are examples of flags that allow users to set the [fees](../basics/gas-fees.md) and gas prices for their transactions. +[Flags](../core/cli.md#flags) 允许用户自定义命令。 `--fees` 和 `--gas-prices` 是允许用户为其交易设置 [fees](../basics/gas-fees.md) 和 gas 价格的标志示例。 -Flags that are specific to a module are typically created in a `flags.go` file in the module's `./client/cli` folder. When creating a flag, developers set the value type, the name of the flag, the default value, and a description about the flag. Developers also have the option to mark flags as _required_ so that an error is thrown if the user does not include a value for the flag. +特定于模块的标志通常在模块的 `./client/cli` 文件夹中的 `flags.go` 文件中创建。创建标志时，开发人员设置值类型、标志名称、默认值以及有关标志的描述。开发人员还可以选择将标志标记为 _required_，以便在用户不包含标志值时抛出错误。 -Here is an example that adds the `--from` flag to a command: +这是一个将 `--from` 标志添加到命令的示例: ```go cmd.Flags().String(FlagFrom, "", "Name or address of private key with which to sign") ``` -In this example, the value of the flag is a `String`, the name of the flag is `from` (the value of the `FlagFrom` constant), the default value of the flag is `""`, and there is a description that will be displayed when a user adds `--help` to the command. +在本例中，flag的值为`String`，flag的名称为`from`)`FlagFrom`常量的值)，flag的默认值为`""`，有 当用户将“--help”添加到命令时将显示的描述。 -Here is an example that marks the `--from` flag as _required_: +这是一个将 `--from` 标志标记为 _required_ 的示例: ```go cmd.MarkFlagRequired(FlagFrom) ``` -For more detailed information on creating flags, visit the [Cobra Documentation](https://github.com/spf13/cobra). +有关创建标志的更多详细信息，请访问 [Cobra 文档](https://github.com/spf13/cobra)。 -As mentioned in [transaction commands](#transaction-commands), there is a set of flags that all transaction commands must add. This is done with the `AddTxFlagsToCmd` method defined in the Cosmos SDK's `./client/flags` package. +如[事务命令](#transaction-commands) 中所述，所有事务命令都必须添加一组标志。这是通过 Cosmos SDK 的 `./client/flags` 包中定义的 `AddTxFlagsToCmd` 方法完成的。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/client/flags/flags.go#L94-L120 -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). +由于 `AddTxFlagsToCmd(cmd *cobra.Command)` 包括事务命令所需的所有基本标志，模块开发人员可以选择不添加任何自己的标志)改为指定参数通常更合适)。 -Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command. +类似地，有一个 `AddQueryFlagsToCmd(cmd *cobra.Command)` 来向模块查询命令添加通用标志。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/client/flags/flags.go#L85-L92 ## gRPC -[gRPC](https://grpc.io/) is a Remote Procedure Call (RPC) framework. RPC is the preferred way for external clients like wallets and exchanges to interact with a blockchain. +[gRPC](https://grpc.io/) 是一个远程过程调用 (RPC) 框架。 RPC 是钱包和交易所等外部客户端与区块链交互的首选方式。 -In addition to providing an ABCI query pathway, the Cosmos SDK provides a gRPC proxy server that routes gRPC query requests to ABCI query requests. +除了提供 ABCI 查询路径外，Cosmos SDK 还提供了 gRPC 代理服务器，将 gRPC 查询请求路由到 ABCI 查询请求。 -In order to do that, modules must implement `RegisterGRPCGatewayRoutes(clientCtx client.Context, mux *runtime.ServeMux)` on `AppModuleBasic` to wire the client gRPC requests to the correct handler inside the module. +为此，模块必须在“AppModuleBasic”上实现“RegisterGRPCGatewayRoutes(clientCtx client.Context, mux *runtime.ServeMux)”，以将客户端 gRPC 请求连接到模块内的正确处理程序。 -Here's an example from the `x/auth` module: +下面是来自 `x/auth` 模块的一个例子: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/auth/module.go#L68-L73 -## gRPC-gateway REST +## gRPC 网关 REST -Applications need to support web services that use HTTP requests (e.g. a web wallet like [Keplr](https://keplr.xyz)). [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. +应用程序需要支持使用 HTTP 请求的网络服务)例如像 [Keplr](https://keplr.xyz) 这样的网络钱包)。 [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) 将 REST 调用转换为 gRPC 调用，这可能对不使用 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 `x/auth` module: +想要公开 REST 查询的模块应该将 `google.api.http` 注释添加到它们的 `rpc` 方法中，例如下面来自 `x/auth` 模块的示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/auth/v1beta1/query.proto#L13-L29 -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). +gRPC 网关与应用程序和 Tendermint 一起在进程内启动。可以通过在 [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) 中设置 gRPC 配置 `enable` 来启用或禁用它。 -The Cosmos 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. +Cosmos SDK 提供了用于生成 [Swagger](https://swagger.io/) 文档 (`protoc-gen-swagger`) 的命令。在 [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) 中设置 `swagger` 定义是否应该自动注册 swagger 文档。 -## Next {hide} +## 下一个 {hide} -Read about the recommended [module structure](./structure.md) {hide} +阅读推荐的 [模块结构](./structure.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/module-manager.md b/docs/ja/building-modules/module-manager.md index 8987528008c5..a602b7717b80 100644 --- a/docs/ja/building-modules/module-manager.md +++ b/docs/ja/building-modules/module-manager.md @@ -1,82 +1,82 @@ -# 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} +Cosmos SDK 模块需要实现[`AppModule` 接口](#application-module-interfaces)，以便由应用程序的[模块管理器](#module-manager) 进行管理。模块管理器在 [`message` 和 `query` 路由](../core/baseapp.md#routing) 中扮演着重要的角色，并允许应用程序开发者设置各种函数的执行顺序，例如 [`BeginBlocker ` 和 `EndBlocker`](../basics/app-anatomy.md#begingblocker-and-endblocker)。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Introduction to Cosmos SDK Modules](./intro.md) {prereq} +- [Cosmos SDK 模块介绍](./intro.md) {prereq} -## Application Module Interfaces +## 应用模块接口 -Application module interfaces exist to facilitate the composition of modules together to form a functional Cosmos SDK application. There are 3 main application module interfaces: +应用程序模块接口的存在是为了便于将模块组合在一起以形成功能性 Cosmos SDK 应用程序。有3个主要的应用模块接口: -- [`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. +- [`AppModuleBasic`](#appmodulebasic) 用于独立模块功能。 +- [`AppModule`](#appmodule) 用于相互依赖的模块功能)与创世相关的功能除外)。 +- [`AppModuleGenesis`](#appmodulegenesis) 用于相互依赖的与创世相关的模块功能。 -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). +`AppModuleBasic` 接口的存在是为了定义模块的独立方法，即那些不依赖于应用程序中其他模块的方法。这允许在应用程序定义的早期构建基本应用程序结构，通常在[主应用程序文件](../basics/app-anatomy.md#core-application-file)的`init()`函数中. -The `AppModule` interface exists to define inter-dependent module methods. Many modules need to interact 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. +`AppModule` 接口用于定义相互依赖的模块方法。许多模块需要与其他模块交互，通常通过 [`keeper`s](./keeper.md)，这意味着需要一个接口，其中模块列出它们的 `keeper`s 和其他需要引用的方法另一个模块的对象。 `AppModule` 接口还使模块管理器能够设置模块方法之间的执行顺序，如 `BeginBlock` 和 `EndBlock`，这在模块之间的执行顺序在应用程序上下文中很重要的情况下很重要。 -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. +最后，创世功能“AppModuleGenesis”的接口与完整的模块功能“AppModule”分离，以便模块 +仅用于 genesis 可以利用 `Module` 模式，而无需定义许多占位符函数。 ### `AppModuleBasic` -The `AppModuleBasic` interface defines the independent methods modules need to implement. +`AppModuleBasic` 接口定义了模块需要实现的独立方法。 +++ 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.JSONCodec)`: 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.JSONCodec, 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 [gRPC and REST](../core/grpc_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. +- `Name()`:以 `string` 形式返回模块的名称。 +- `RegisterLegacyAminoCodec(*codec.LegacyAmino)`:为模块注册 `amino` 编解码器，用于向/从 `[]byte` 编组和解组结构，以便将它们保存在模块的 `KVStore` 中。 +- `RegisterInterfaces(codectypes.InterfaceRegistry)`:将模块的接口类型及其具体实现注册为`proto.Message`。 +- `DefaultGenesis(codec.JSONCodec)`:返回模块的默认 [`GenesisState`](./genesis.md#genesisstate)，编组为 `json.RawMessage`。默认的“GenesisState”需要由模块开发者定义，主要用于测试。 +- `ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`:用于验证模块定义的`GenesisState`，以`json.RawMessage`形式给出。它通常会在运行模块开发人员定义的自定义 [`ValidateGenesis`](./genesis.md#validategenesis) 函数之前解组 `json`。 +- `RegisterRESTRoutes(client.Context, *mux.Router)`:为模块注册 REST 路由。这些路由将用于将 REST 请求映射到模块以处理它们。有关更多信息，请参阅 [gRPC 和 REST](../core/grpc_rest.md)。 +- `RegisterGRPCGatewayRoutes(client.Context, *runtime.ServeMux)`:为模块注册 gRPC 路由。 +- `GetTxCmd()`:返回模块的根 [`Tx` 命令](./module-interfaces.md#tx)。最终用户使用此根命令的子命令来生成包含模块中定义的 [`message`s](./messages-and-queries.md#queries) 的新事务。 +- `GetQueryCmd()`:返回模块的根 [`query` 命令](./module-interfaces.md#query)。最终用户使用此根命令的子命令来生成对模块定义的状态子集的新查询。 -All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#basicmanager). +应用程序的所有`AppModuleBasic` 都由[`BasicManager`](#basicmanager) 管理。 ### `AppModuleGenesis` -The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` interface with two added methods. +`AppModuleGenesis` 接口是带有两个附加方法的 `AppModuleBasic` 接口的简单嵌入。 +++ 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.JSONCodec, 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.JSONCodec)`: 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. +- `InitGenesis(sdk.Context, codec.JSONCodec, json.RawMessage)`:初始化模块管理的状态子集。它在创世时)即链第一次启动时)被调用。 +- `ExportGenesis(sdk.Context, codec.JSONCodec)`:导出模块管理的最新状态子集，用于新的创世文件。当从现有链的状态启动新链时，每个模块都会调用 `ExportGenesis`。 -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.JSONCodec, json.RawMessage)` and `ExportGenesis(sdk.Context, codec.JSONCodec)` will generally be defined as methods of the concrete type implementing the `AppModule` interface. +它没有自己的管理器，并且与 [`AppModule`](#appmodule) 分开存在，仅用于实现创世功能的模块，这样它们就可以被管理而无需实现所有 `AppModule` 的方法.如果模块不仅在创世期间使用，`InitGenesis(sdk.Context, codec.JSONCodec, json.RawMessage)` 和 `ExportGenesis(sdk.Context, codec.JSONCodec)` 通常会被定义为实现的具体类型的方法`AppModule` 接口。 ### `AppModule` -The `AppModule` interface defines the inter-dependent methods that modules need to implement. +`AppModule` 接口定义了模块需要实现的相互依赖的方法。 +++ 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. +`AppModule`s 由 [模块管理器](#manager) 管理。该接口嵌入了`AppModuleGenesis`接口，以便管理器可以访问模块的所有独立和创世相互依赖的方法。这意味着实现 `AppModule` 接口的具体类型必须要么实现 `AppModuleGenesis`)以及扩展为 `AppModuleBasic`)的所有方法，或者包含一个作为参数的具体类型。 -Let us go through the methods of `AppModule`: +让我们来看看`AppModule`的方法: -- `RegisterInvariants(sdk.InvariantRegistry)`: Registers the [`invariants`](./invariants.md) of the module. If an invariant 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. +- `RegisterInvariants(sdk.InvariantRegistry)`:注册模块的[`invariants`](./invariants.md)。如果一个不变量偏离了它的预测值，[`InvariantRegistry`](./invariants.md#registry) 会触发适当的逻辑)大多数情况下链将被停止)。 +- `Route()`:返回 [`message`s](./messages-and-queries.md#messages) 的路由，由 [`BaseApp`](../core/baseapp.md#messages) 路由到模块。 md#消息路由)。 +- `QuerierRoute()`)不推荐使用):返回模块的查询路由的名称，用于 [`queries`](./messages-and-queries.md#queries) 是由 [`BaseApp`] 到模块的路由)../core/baseapp.md#query-routing)。 +- `LegacyQuerierHandler(*codec.LegacyAmino)`)不推荐使用):返回一个 [`querier`](./query-services.md#legacy-queriers) 给定查询 `path`，以便处理 `query`。 +- `RegisterServices(Configurator)`:允许模块注册服务。 +- `BeginBlock(sdk.Context, abci.RequestBeginBlock)`:此方法为模块开发人员提供了实现在每个块开始时自动触发的逻辑的选项。如果不需要在此模块的每个块的开头触发逻辑，则实现为空。 +- `EndBlock(sdk.Context, abci.RequestEndBlock)`:此方法为模块开发人员提供了实现在每个块结束时自动触发的逻辑的选项。这也是模块可以将验证器集更改通知底层共识引擎的地方)例如，`staking` 模块)。如果不需要在此模块的每个块的末尾触发逻辑，则实现为空。 -### 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`). +通常，各种应用程序模块接口在名为“module.go”的文件中实现，该文件位于模块的文件夹中)例如，“./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 `NewMsgServerImpl(k keeper)` function defined in `keeper/msg_server.go` and therefore needs to pass the module's [`keeper`](./keeper.md) as a parameter. +几乎每个模块都需要实现`AppModuleBasic` 和`AppModule` 接口。如果模块仅用于创世，它将实现`AppModuleGenesis`而不是`AppModule`。实现接口的具体类型可以添加实现接口的各种方法所需的参数。例如，`Route()`函数经常调用`keeper/msg_server.go`中定义的`NewMsgServerImpl(k keeper)`函数，因此需要将模块的[`keeper`](./keeper.md)作为一个参数。 ```go // example @@ -86,61 +86,61 @@ type AppModule struct { } ``` -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. +在上面的示例中，您可以看到“AppModule”具体类型引用了“AppModuleBasic”，而不是“AppModuleGenesis”。 那是因为`AppModuleGenesis` 只需要在专注于与创世相关功能的模块中实现。 在大多数模块中，具体的`AppModule` 类型将引用一个`AppModuleBasic`，并直接在`AppModule` 类型中实现`AppModuleGenesis` 的两个添加方法。 -If no parameter is required (which is often the case for `AppModuleBasic`), just declare an empty concrete type like so: +如果不需要参数)`AppModuleBasic` 通常就是这种情况)，只需声明一个空的具体类型，如下所示: ```go type AppModuleBasic struct{} ``` -## Module Managers +## 模块管理器 -Module managers are used to manage collections of `AppModuleBasic` and `AppModule`. +模块管理器用于管理`AppModuleBasic` 和`AppModule` 的集合。 -### `BasicManager` +### `基本管理器` -The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application: +`BasicManager` 是一个列出应用程序所有 `AppModuleBasic` 的结构: +++ 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.JSONCodec)`: Provides default genesis information for modules in the application by calling the [`DefaultGenesis(cdc codec.JSONCodec)`](./genesis.md#defaultgenesis) function of each module. It is used to construct a default genesis file for the application. -- `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`: Validates the genesis information modules by calling the [`ValidateGenesis(codec.JSONCodec, 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](../core/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`](../core/cli.md#transaction-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](../core/cli.md). -- `AddQueryCommands(rootQueryCmd *cobra.Command)`: Adds modules' query commands to the application's [`rootQueryCommand`](../core/cli.md#query-commands). This function is usually called function from the `main.go` function of the [application's command-line interface](../core/cli.md). +- `NewBasicManager(modules ...AppModuleBasic)`:构造函数。它获取应用程序的“AppModuleBasic”列表并构建一个新的“BasicManager”。该函数一般在[`app.go`](../basics/app-anatomy.md#core-application-file)的`init()`函数中调用，用于快速初始化应用程序模块的独立元素)单击 [此处])https://github.com/cosmos/gaia/blob/master/app/app.go#L59-L74)查看示例)。 +- `RegisterLegacyAminoCodec(cdc *codec.LegacyAmino)`:注册每个应用程序的`AppModuleBasic`的[`codec.LegacyAmino`s](../core/encoding.md#amino)。这个函数通常在[应用程序的构造](../basics/app-anatomy.md#constructor)的早期被调用。 +- `RegisterInterfaces(registry codectypes.InterfaceRegistry)`:注册每个应用程序`AppModuleBasic`的接口类型和实现。 +- `DefaultGenesis(cdc codec.JSONCodec)`:通过调用每个模块的[`DefaultGenesis(cdc codec.JSONCodec)`](./genesis.md#defaultgenesis)函数，为应用程序中的模块提供默认的创世信息。它用于为应用程序构建一个默认的创世文件。 +- `ValidateGenesis(cdc codec.JSONCodec, txEncCfg client.TxEncodingConfig, genesis map[string]json.RawMessage)`:通过调用[`ValidateGenesis(codec.JSONCodec, client.TxEncodingConfig, json.RawMessage)`验证创世信息模块](./genesis.md#validategenesis) 每个模块的函数。 +- `RegisterRESTRoutes(ctx client.Context, rtr *mux.Router)`:通过调用每个模块的 [`RegisterRESTRoutes`](./module-interfaces.md#register-routes) 函数，为模块注册 REST 路由。该函数通常从[应用程序的命令行界面](../core/cli.md)的`main.go`函数中调用。 +-`RegisterGRPCGatewayRoutes(clientCtx client.Context, rtr *runtime.ServeMux)`:为模块注册gRPC路由。 +- `AddTxCommands(rootTxCmd *cobra.Command)`:将模块的事务命令添加到应用程序的 [`rootTxCommand`](../core/cli.md#transaction-commands)。该函数通常从[应用程序的命令行界面](../core/cli.md)的`main.go`函数中调用。 +- `AddQueryCommands(rootQueryCmd *cobra.Command)`:将模块的查询命令添加到应用程序的 [`rootQueryCommand`](../core/cli.md#query-commands)。该函数通常从[应用程序的命令行界面](../core/cli.md)的`main.go`函数中调用。 ### `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: +`Manager` 是一个包含应用程序所有 `AppModule` 的结构，并定义了这些模块的几个关键组件之间的执行顺序: +++ 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.JSONCodec, 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.JSONCodec)`: 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). +- `NewManager(modules ...AppModule)`:构造函数。它获取应用程序的“AppModule”列表并构建一个新的“Manager”。它通常从应用程序的主要[构造函数](../basics/app-anatomy.md#constructor-function) 调用。 +- `SetOrderInitGenesis(moduleNames ...string)`:设置应用程序第一次启动时每个模块的 [`InitGenesis`](./genesis.md#initgenesis) 函数的调用顺序。这个函数一般是从应用程序的主[构造函数](../basics/app-anatomy.md#constructor-function)调用的。 +- `SetOrderExportGenesis(moduleNames ...string)`:设置在导出的情况下每个模块的 [`ExportGenesis`](./genesis.md#exportgenesis) 函数将被调用的顺序。这个函数一般是从应用程序的主[构造函数](../basics/app-anatomy.md#constructor-function)调用的。 +- `SetOrderBeginBlockers(moduleNames ...string)`:设置在每个块的开头调用每个模块的`BeginBlock()`函数的顺序。这个函数一般是从应用程序的主[构造函数](../basics/app-anatomy.md#constructor-function)调用的。 +- `SetOrderEndBlockers(moduleNames ...string)`:设置在每个块的末尾调用每个模块的`EndBlock()`函数的顺序。这个函数一般是从应用程序的主[构造函数](../basics/app-anatomy.md#constructor-function)调用的。 +- `RegisterInvariants(ir sdk.InvariantRegistry)`:注册每个模块的[invariants](./invariants.md)。 +- `RegisterRoutes(router sdk.Router, queryRouter sdk.QueryRouter, legacyQuerierCdc *codec.LegacyAmino)`:注册遗留 [`Msg`](./messages-and-queries.md#messages) 和 [`querier`](./query-services.md#legacy-queriers) 路由。 +- `RegisterServices(cfg Configurator)`:注册所有模块服务。 +- `InitGenesis(ctx sdk.Context, cdc codec.JSONCodec, genesisData map[string]json.RawMessage)`:在应用程序第一次调用时调用各个模块的[`InitGenesis`](./genesis.md#initgenesis)函数开始，按照 `OrderInitGenesis` 中定义的顺序。向底层共识引擎返回一个 `abci.ResponseInitChain`，其中可以包含验证器更新。 +- `ExportGenesis(ctx sdk.Context, cdc codec.JSONCodec)`:按照`OrderExportGenesis`中定义的顺序调用每个模块的[`ExportGenesis`](./genesis.md#exportgenesis)函数。 export 从之前存在的状态构造一个创世文件，主要用于需要对链进行硬分叉升级的时候。 +- `BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock)`:在每个块的开头，从 [`BaseApp`](../core/baseapp.md#beginblock) 调用这个函数，然后，调用每个模块的 [`BeginBlock`](./beginblock-endblock.md) 函数，按照 `OrderBeginBlockers` 中定义的顺序。它创建一个带有事件管理器的子 [context](../core/context.md) 来聚合从所有模块发出的 [events](../core/events.md)。该函数返回一个包含上述事件的 `abci.ResponseBeginBlock`。 +- `EndBlock(ctx sdk.Context, req abci.RequestEndBlock)`:在每个块的末尾，从 [`BaseApp`](../core/baseapp.md#endblock) 调用这个函数，然后，按照 `OrderEndBlockers` 中定义的顺序调用每个模块的 [`EndBlock`](./beginblock-endblock.md) 函数。它创建一个带有事件管理器的子 [context](../core/context.md) 来聚合从所有模块发出的 [events](../core/events.md)。该函数返回一个“abci.ResponseEndBlock”，其中包含上述事件以及验证器集更新)如果有)。 -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} +## 下一个 {hide} -Learn more about [`message`s and `queries`](./messages-and-queries.md) {hide} +详细了解 [`message`s 和 `queries`](./messages-and-queries.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/msg-services.md b/docs/ja/building-modules/msg-services.md index df3fc21ac4d0..8f99766851aa 100644 --- a/docs/ja/building-modules/msg-services.md +++ b/docs/ja/building-modules/msg-services.md @@ -1,102 +1,102 @@ -# `Msg` Services +# `Msg` 服务 -A Protobuf `Msg` service processes [messages](./messages-and-queries.md#messages). Protobuf `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} +Protobuf `Msg` 服务处理 [messages](./messages-and-queries.md#messages)。 Protobuf `Msg` 服务特定于定义它们的模块，并且只处理在所述模块中定义的消息。它们在 [`DeliverTx`](../core/baseapp.md#delivertx) 期间从 `BaseApp` 调用。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Module Manager](./module-manager.md) {prereq} -- [Messages and Queries](./messages-and-queries.md) {prereq} +- [模块管理器](./module-manager.md) {prereq} +- [消息和查询](./messages-and-queries.md) {prereq} -## Implementation of a module `Msg` service +## 模块`Msg`服务的实现 -Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses. +每个模块都应该定义一个 Protobuf `Msg` 服务，它将负责处理请求(实现 `sdk.Msg`)并返回响应。 -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. +正如 [ADR 031](../architecture/adr-031-msg-service.md) 中进一步描述的那样，这种方法的优点是明确指定返回类型并生成服务器和客户端代码。 -Protobuf generates a `MsgServer` interface based on a definition of `Msg` service. 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 `sdk.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `sdk.Msg`s: +Protobuf 根据 `Msg` 服务的定义生成一个 `MsgServer` 接口。模块开发人员的职责是通过实现在接收到每个 `sdk.Msg` 时应该发生的状态转换逻辑来实现这个接口。例如，这里是为 `x/bank` 生成的 `MsgServer` 接口，它暴露了两个 `sdk.Msg`: +++ 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`: +如果可能，现有模块的 [`Keeper`](keeper.md) 应该实现 `MsgServer`，否则可以创建嵌入 `Keeper` 的 `msgServer` 结构，通常在 `./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`: +`msgServer` 方法可以使用 `sdk.UnwrapSDKContext` 从 `context.Context` 参数方法中检索 `sdk.Context`: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/bank/keeper/msg_server.go#L27-L28 -`sdk.Msg` processing usually follows these 2 steps: +`sdk.Msg` 处理通常遵循以下 2 个步骤: -- 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. +- 首先，他们执行 *stateful* 检查以确保 `message` 有效。在这个阶段，已经调用了 `message` 的 `ValidateBasic()` 方法，这意味着已经执行了对消息的 *stateless* 检查(例如确保参数格式正确)。在 `msgServer` 方法中执行的检查可能更昂贵并且需要访问状态。例如，“transfer”消息的“msgServer”方法可能会检查发送帐户是否有足够的资金来实际执行转移。要访问状态，`msgServer` 方法需要调用 [`keeper`'s](./keeper.md) 的 getter 函数。 +- 然后，如果检查成功，`msgServer` 方法调用 [`keeper`'s](./keeper.md) setter 函数来实际执行状态转换。 -Before returning, `msgServer` methods generally emit one or more [events](../core/events.md) via the `EventManager` held in the `ctx`: +在返回之前，`msgServer` 方法通常通过 `ctx` 中保存的 `EventManager` 发出一个或多个 [events](../core/events.md): ```go ctx.EventManager().EmitEvent( sdk.NewEvent( - eventType, // e.g. sdk.EventTypeMessage for a message, types.CustomEventType for a custom event defined in the module + 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. +这些事件被转发回底层的共识引擎，服务提供商可以使用这些事件来围绕应用程序实现服务。单击 [此处](../core/events.md) 了解有关事件的更多信息。 -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)`: +调用的 `msgServer` 方法返回一个 `proto.Message` 响应和一个 `error`。然后使用 `sdk.WrapServiceResult(ctx sdk.Context, res proto.Message, err error)` 将这些返回值包装到 `*sdk.Result` 或 `error` 中: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc2/baseapp/msg_service_router.go#L104-L104 -This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`. +此方法负责将 `res` 参数编组到 protobuf，并将 `ctx.EventManager()` 上的任何事件附加到 `sdk.Result`。 +++ https://github.com/cosmos/cosmos-sdk/blob/d55c1a26657a0af937fa2273b38dcfa1bb3cff9f/proto/cosmos/base/abci/v1beta1/abci.proto#L81-L95 -This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module. +此图显示了 Protobuf `Msg` 服务的典型结构，以及消息如何通过模块传播。 -![Transaction flow](../uml/svg/transaction_flow.svg) +![交易流程](../uml/svg/transaction_flow.svg) -## Amino `LegacyMsg`s +## 氨基`LegacyMsg`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). +Cosmos SDK 中定义的 `handler` 类型将被弃用，取而代之的是 [`Msg` 服务](#implementation-of-a-module-msg-service)。 -Here is the typical structure of a `handler` function: +以下是`handler`函数的典型结构: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc2/types/handler.go#L4-L4 -Let us break it down: +让我们分解一下: -- The [`LegacyMsg`](./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). +- [`LegacyMsg`](./messages-and-queries.md#messages) 是正在处理的实际对象。 +- [`Context`](../core/context.md) 包含处理 `msg` 所需的所有必要信息，以及最新状态的分支。如果 `msg` 处理成功，`ctx` 中包含的状态的分支版本将被写入主状态(分支)。 +- 返回给“BaseApp”的“*Result”包含(除其他外)关于“handler”和[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`. +模块“handler”通常在模块文件夹内的“./handler.go”文件中实现。 [模块管理器](./module-manager.md) 用于将模块的`handler`s 添加到 +[应用程序的`router`](../core/baseapp.md#message-routing) 通过`Route()` 方法。通常， +manager 的 `Route()` 方法简单地构造了一个调用 `handler.go` 中定义的 `NewHandler()` 方法的路由。 +++ https://github.com/cosmos/cosmos-sdk/blob/228728cce2af8d494c8b4e996d011492139b04ab/x/gov/module.go#L143-L146 -### Implementation +### 执行 -`NewHandler` function dispatches a `LegacyMsg` to appropriate handler function, usually by using a switch statement: +`NewHandler` 函数将 `LegacyMsg` 分派给适当的处理函数，通常使用 switch 语句: +++ 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 `LegacyMsg` type. +首先，`NewHandler` 函数为上下文设置一个新的 `EventManager`，以隔离每个 `msg` 的事件。 +然后，一个简单的开关根据 `LegacyMsg` 类型调用适当的 `handler`。 -In this regard, `handler`s functions need to be implemented for each module `LegacyMsg`. This will also involve manual handler registration of `LegacyMsg` types. -`handler`s functions should return a `*Result` and an `error`. +对此，每个模块`LegacyMsg`都需要实现`handler`的功能。这也将涉及对 LegacyMsg 类型的手动处理程序注册。 +`handler` 的函数应该返回一个 `*Result` 和一个 `error`。 -## Telemetry +## 遥测 -New [telemetry metrics](../core/telemetry.md) can be created from `msgServer` methods when handling messages. +处理消息时，可以从 `msgServer` 方法创建新的 [遥测指标](../core/telemetry.md)。 -This is an example from the `x/auth/vesting` module: +这是来自 `x/auth/vesting` 模块的一个例子: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc1/x/auth/vesting/msg_server.go#L73-L85 -## Next {hide} +## 下一个 {hide} -Learn about [query services](./query-services.md) {hide} +了解 [查询服务](./query-services.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/query-services.md b/docs/ja/building-modules/query-services.md index fb8d6f9fda40..46235f6a3946 100644 --- a/docs/ja/building-modules/query-services.md +++ b/docs/ja/building-modules/query-services.md @@ -1,30 +1,30 @@ -# Query Services +# 查询服务 -A Protobuf 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} +Protobuf 查询服务处理 [`queries`](./messages-and-queries.md#queries)。查询服务特定于定义它们的模块，并且只处理在所述模块中定义的“查询”。它们是从`BaseApp` 的[`Query` 方法](../core/baseapp.md#query) 调用的。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Module Manager](./module-manager.md) {prereq} -- [Messages and Queries](./messages-and-queries.md) {prereq} +- [模块管理器](./module-manager.md) {prereq} +- [消息和查询](./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: +Cosmos SDK 中定义的 `querier` 类型将被弃用，以支持 [gRPC Services](#grpc-service)。它指定了一个 `querier` 函数的典型结构: +++ 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). +- `path` 是一个包含查询类型的 `string` 数组，也可以包含 `query` 参数。有关更多信息，请参阅 [`queries`](./messages-and-queries.md#queries)。 +- `req` 本身主要用于检索太大而无法放入 `path` 的参数。这是使用“req”的“Data”字段完成的。 +- [`Context`](../core/context.md) 包含处理`query` 所需的所有必要信息，以及最新状态的一个分支。它主要由 [`keeper`](./keeper.md) 用来访问状态。 +- 结果 `res` 返回给 `BaseApp`，使用应用程序的 [`codec`](../core/encoding.md) 进行编组。 -## Implementation of a module query service +##模块查询服务的实现 -### gRPC Service +### gRPC 服务 -When defining a Protobuf `Query` service, a `QueryServer` interface is generated for each module with all the service methods: +在定义 Protobuf `Query` 服务时，会为每个模块生成一个带有所有服务方法的 `QueryServer` 接口: ```go type QueryServer interface { @@ -33,17 +33,17 @@ type QueryServer interface { } ``` -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 Cosmos SDK provides a function `sdk.UnwrapSDKContext` to retrieve the `sdk.Context` from the provided -`context.Context`. +这些自定义查询方法应该由模块的 keeper 实现，通常在 `./keeper/grpc_query.go` 中。这些方法的第一个参数是一个通用的`context.Context`，而查询器方法一般需要一个`sdk.Context`的实例来读取 +从存储。因此，Cosmos SDK 提供了一个函数 `sdk.UnwrapSDKContext` 来从提供的对象中检索 `sdk.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: +模块遗留的“查询器”通常在模块文件夹内的“./keeper/querier.go”文件中实现。 [模块管理器](./module-manager.md) 用于通过`NewQuerier 将模块的`querier`s 添加到[应用程序的`queryRouter`](../core/baseapp.md#query-routing) ()` 方法。通常，管理器的`NewQuerier()` 方法简单地调用`keeper/querier.go` 中定义的`NewQuerier()` 方法，如下所示: ```go func NewQuerier(keeper Keeper) sdk.Querier { @@ -62,12 +62,12 @@ func NewQuerier(keeper Keeper) sdk.Querier { } ``` -This simple switch returns a `querier` function specific to the type of the received `query`. At this point of the [query lifecycle](../basics/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. +这个简单的开关返回一个特定于接收到的 `query` 类型的 `querier` 函数。 在 [查询生命周期](../basics/query-lifecycle.md) 的这一点上，`path` (`path[0]`) 的第一个元素包含查询的类型。 以下元素为空或包含处理查询所需的参数。 -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. +`querier` 函数本身非常简单。 他们通常使用 [`keeper`](./keeper.md) 从状态中获取一个或多个值。 然后，他们使用 [`codec`](../core/encoding.md) 对值进行编组，并返回作为结果获得的 `[]byte`。 -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. +要更深入地了解`querier`，请参阅此[`querier` 函数的示例实现](https://github.com/cosmos/cosmos-sdk/blob/7f59723d889b69ca19966167f0b3a7fec7a39e53/x/gov/keeper/querier.go ) 来自银行模块。 -## Next {hide} +## 下一个 {hide} -Learn about [`BeginBlocker` and `EndBlocker`](./beginblock-endblock.md) {hide} +了解 [`BeginBlocker` 和 `EndBlocker`](./beginblock-endblock.md) {hide} diff --git a/docs/ja/building-modules/simulator.md b/docs/ja/building-modules/simulator.md index 479d6141ced9..2c33ddaff45a 100644 --- a/docs/ja/building-modules/simulator.md +++ b/docs/ja/building-modules/simulator.md @@ -1,94 +1,94 @@ -# Module Simulation +# 模块模拟 -## Prerequisites +## 先决条件 -* [Cosmos Blockchain Simulator](./../using-the-sdk/simulation.md) +* [Cosmos 区块链模拟器](./../using-the-sdk/simulation.md) -## Synopsis +## 概要 -This document details how to define each module simulation functions to be -integrated with the application `SimulationManager`. +本文档详细介绍了如何定义每个模块的模拟功能 +与应用程序“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) + * [存储解码器](#store-decoders) + * [随机起源](#randomized-genesis) + * [随机参数](#randomized-parameters) + * [随机加权操作](#random-weighted-operations) + * [随机提案内容](#random-proposal-contents) +* [注册模块模拟功能](#registering-simulation-functions) +* [应用模拟器管理器](#app-simulator-manager) +* [模拟测试](#simulation-tests) -## Simulation package +## 模拟包 -Every module that implements the Cosmos 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. +每个实现 Cosmos SDK 模拟器的模块都需要有一个 `x//simulation` +包含模糊测试所需主要功能的包:存储 +解码器、随机创世状态和参数、加权操作和提议 +内容。 -### 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. +`AppImportExport` 需要注册存储解码器。这允许 +来自要解码的存储的键值对(_i.e_ unmarshalled) +到它们对应的类型。特别是，它将键匹配到具体类型 +然后将 `KVPair` 中的值解组为提供的类型。 -You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders. +您可以使用分发模块中的示例 [此处](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/x/distribution/simulation/decoder.go) 来实现您的存储解码器。 -### 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. +模拟器测试不同的场景和创世参数值 +为了充分测试特定模块的边缘情况。每个模块的 `simulator` 包必须公开一个 `RandomizedGenState` 函数以从给定的种子生成初始随机 `GenesisState`。 -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. +一旦模块创世参数是随机生成的(或使用密钥和 +`params` 文件中定义的值)，它们被编组为 JSON 格式并添加 +到应用程序 genesis JSON 以在模拟中使用它。 -You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/x/staking/simulation/genesis.go). +您可以查看有关如何创建随机创世的示例 [此处](https://github.com/cosmos/cosmos-sdk/blob/v0.42.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. +模拟器能够随机测试参数变化。每个模块的模拟器包必须包含一个“RandomizedParams”函数，它将在整个模拟生命周期中模拟模块的参数变化。 -You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/x/staking/simulation/params.go) +您可以在 [此处](https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/x/staking/simulation/params.go) 中查看完全测试参数更改所需的示例 -### Random weighted operations +### 随机加权操作 -Operations are one of the crucial parts of the Cosmos SDK simulation. They are the transactions -(`Msg`) that are simulated with random field values. The sender of the operation -is also assigned randomly. +操作是 Cosmos SDK 模拟的关键部分之一。他们是交易 +(`Msg`) 用随机字段值模拟。操作的发送者 +也是随机分配的。 -Operations on the simulation are simulated using the full [transaction cycle](../core/transactions.md) of a -`ABCI` application that exposes the `BaseApp`. +使用完整的 [事务周期](../core/transactions.md) 模拟模拟操作 +公开“BaseApp”的“ABCI”应用程序。 -Shown below is how weights are set: +下面显示的是如何设置权重: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/staking/simulation/operations.go#L18-L68 -As you can see, the weights are predefined in this case. Options exist to override this behavior with different weights. One option is to use `*rand.Rand` to define a random weight for the operation, or you can inject your own predefined weights. +如您所见，在这种情况下，权重是预定义的。存在使用不同权重覆盖此行为的选项。一种选择是使用 `*rand.Rand` 为操作定义随机权重，或者您可以注入自己的预定义权重。 -Here is how one can override the above package `simappparams`. +以下是如何覆盖上述包“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. +对于最后一个测试，一个名为 runsim 被使用，这用于并行化 go 测试实例，向 Github 提供信息和松弛集成以向您的团队了解模拟的运行方式。 -### Random proposal contents +### 随机提案内容 -Randomized governance proposals are also supported on the Cosmos SDK simulator. Each -module must define the governance proposal `Content`s that they expose and register -them to be used on the parameters. +Cosmos SDK 模拟器也支持随机治理提案。每个 +模块必须定义他们公开和注册的治理提案`内容` +它们用于参数。 -## Registering simulation functions +##注册模拟函数 -Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`: +现在所有必需的功能都已定义，我们需要将它们集成到`module.go` 中的模块模式中: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.0/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. +以下步骤是在应用程序级别设置“SimulatorManager”。这 +下一步需要模拟测试文件。 ```go type CustomApp struct { @@ -97,10 +97,10 @@ type CustomApp struct { } ``` -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. +然后在应用程序的实例化时，我们创建 `SimulationManager` +实例与我们创建`ModuleManager` 的方式相同，但这次我们只通过 +实现来自`AppModuleSimulation`的模拟功能的模块 +界面如上。 ```go func NewCustomApp(...) { diff --git a/docs/ja/building-modules/structure.md b/docs/ja/building-modules/structure.md index 3aaada0a829c..cb08dc695499 100644 --- a/docs/ja/building-modules/structure.md +++ b/docs/ja/building-modules/structure.md @@ -1,10 +1,10 @@ -# 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} +本文档概述了 Cosmos SDK 模块的推荐结构。 这些想法旨在作为建议加以应用。 鼓励应用程序开发人员改进模块结构和开发设计并做出贡献。 {概要} -## Structure +## 结构 -A typical Cosmos SDK module can be structured as follows: +一个典型的 Cosmos SDK 模块结构如下: ```shell proto @@ -18,11 +18,11 @@ proto       └── tx.proto ``` -- `{module_name}.proto`: The module's common message type definitions. -- `event.proto`: The module's message type definitions related to events. -- `genesis.proto`: The module's message type definitions related to genesis state. -- `query.proto`: The module's Query service and related message type definitions. -- `tx.proto`: The module's Msg service and related message type definitions. +- `{module_name}.proto`:模块的通用消息类型定义。 +- `event.proto`:与事件相关的模块消息类型定义。 +- `genesis.proto`:与创世状态相关的模块消息类型定义。 +- `query.proto`:模块的查询服务和相关的消息类型定义。 +- `tx.proto`:模块的消息服务和相关消息类型定义。 ```shell x/{module_name} @@ -72,24 +72,24 @@ x/{module_name} └── tx.pb.go ``` -- `client/`: The module's CLI client functionality implementation and the module's integration testing suite. -- `exported/`: The module's exported types - typically interface types. If a module relies on keepers from another module, it is expected to receive the keepers as interface contracts through the `expected_keepers.go` file (see below) in order to avoid a direct dependency on the module implementing the keepers. However, these interface contracts can define methods that operate on and/or return types that are specific to the module that is implementing the keepers and this is where `exported/` comes into play. The interface types that are defined in `exported/` use canonical types, allowing for the module to receive the keepers as interface contracts through the `expected_keepers.go` file. This pattern allows for code to remain DRY and also alleviates import cycle chaos. -- `keeper/`: The module's `Keeper` and `MsgServer` implementation. -- `module/`: The module's `AppModule` and `AppModuleBasic` implementation. -- `simulation/`: The module's [simulation](./simulator.html) package defines functions used by the blockchain simulator application (`simapp`). -- `spec/`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. -- The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers. - - `abci.go`: The module's `BeginBlocker` and `EndBlocker` implementations (this file is only required if `BeginBlocker` and/or `EndBlocker` need to be defined). - - `codec.go`: The module's registry methods for interface types. - - `errors.go`: The module's sentinel errors. - - `events.go`: The module's event types and constructors. - - `expected_keepers.go`: The module's [expected keeper](./keeper.html#type-definition) interfaces. - - `genesis.go`: The module's genesis state methods and helper functions. - - `keys.go`: The module's store keys and associated helper functions. - - `msgs.go`: The module's message type definitions and associated methods. - - `params.go`: The module's parameter type definitions and associated methods. - - `*.pb.go`: The module's type definitions generated by Protocol Buffers (as defined in the respective `*.proto` files above). +- `client/`:模块的 CLI 客户端功能实现和模块的集成测试套件。 +- `exported/`:模块的导出类型 - 通常是接口类型。如果一个模块依赖于另一个模块的 Keepers，则期望通过 `expected_keepers.go` 文件(见下文)接收作为接口合同的 Keeper，以避免直接依赖于实现 Keepers 的模块。但是，这些接口契约可以定义操作和/或返回特定于实现 Keepers 的模块的类型的方法，这就是“exported/”发挥作用的地方。 `exported/` 中定义的接口类型使用规范类型，允许模块通过 `expected_keepers.go` 文件接收作为接口合约的 Keeper。这种模式允许代码保持 DRY 并缓解导入周期混乱。 +- `keeper/`:模块的`Keeper` 和`MsgServer` 实现。 +- `module/`:模块的`AppModule` 和`AppModuleBasic` 实现。 +- `simulation/`:模块的 [simulation](./simulator.html) 包定义了区块链模拟器应用程序 (`simapp`) 使用的函数。 +- `spec/`:模块的规范文档概述了重要概念、状态存储结构以及消息和事件类型定义。 +- 根目录包括消息、事件和创世状态的类型定义，包括协议缓冲区生成的类型定义。 + - `abci.go`:模块的`BeginBlocker` 和`EndBlocker` 实现(只有在需要定义`BeginBlocker` 和/或`EndBlocker` 时才需要此文件)。 + - `codec.go`:模块的接口类型注册方法。 + - `errors.go`:模块的哨兵错误。 + - `events.go`:模块的事件类型和构造函数。 + - `expected_keepers.go`:模块的 [expected keeper](./keeper.html#type-definition) 接口。 + - `genesis.go`:模块的创世状态方法和辅助函数。 + - `keys.go`:模块的存储键和相关的辅助函数。 + - `msgs.go`:模块的消息类型定义和相关方法。 + - `params.go`:模块的参数类型定义和相关方法。 + - `*.pb.go`:由 Protocol Buffers 生成的模块类型定义(在上面相应的 `*.proto` 文件中定义)。 -## Next {hide} +## 下一个 {hide} -Learn about [Errors](./errors.md) {hide} +了解 [错误](./errors.md) {hide} \ No newline at end of file diff --git a/docs/ja/building-modules/upgrade.md b/docs/ja/building-modules/upgrade.md index 26630f9647be..bc746a40559e 100644 --- a/docs/ja/building-modules/upgrade.md +++ b/docs/ja/building-modules/upgrade.md @@ -1,27 +1,27 @@ -# Upgrading Modules +# 升级模块 -[In-Place Store Migrations](../core/upgrade.html) allow your modules to upgrade to new versions that include breaking changes. This document outlines how to build modules to take advantage of this functionality. {synopsis} +[就地存储迁移](../core/upgrade.html) 允许您的模块升级到包含重大更改的新版本。本文档概述了如何构建模块以利用此功能。 {概要} -## Prerequisite Readings +## 先决条件阅读 -- [In-Place Store Migration](../core/upgrade.md) {prereq} +- [就地存储迁移](../core/upgrade.md) {prereq} -## Consensus Version +## 共识版本 -Successful upgrades of existing modules require each `AppModule` to implement the function `ConsensusVersion() uint64`. +现有模块的成功升级需要每个`AppModule` 实现函数`ConsensusVersion() uint64`。 -- The versions must be hard-coded by the module developer. -- The initial version **must** be set to 1. +- 版本必须由模块开发人员硬编码。 +- 初始版本**必须**设置为 1。 -Consensus versions serve as state-breaking versions of app modules and must be incremented when the module introduces breaking changes. +共识版本用作应用程序模块的状态破坏版本，并且必须在模块引入破坏性更改时递增。 -## Registering Migrations +## 注册迁移 -To register the functionality that takes place during a module upgrade, you must register which migrations you want to take place. +要注册在模块升级期间发生的功能，您必须注册要发生的迁移。 -Migration registration takes place in the `Configurator` using the `RegisterMigration` method. The `AppModule` reference to the configurator is in the `RegisterServices` method. +迁移注册使用 `RegisterMigration` 方法在 `Configurator` 中进行。对配置器的“AppModule”引用位于“RegisterServices”方法中。 -You can register one or more migrations. If you register more than one migration script, list the migrations in increasing order and ensure there are enough migrations that lead to the desired consensus version. For example, to migrate to version 3 of a module, register separate migrations for version 1 and version 2 as shown in the following example: +您可以注册一个或多个迁移。如果您注册了多个迁移脚本，请按升序列出迁移，并确保有足够多的迁移可生成所需的共识版本。例如，要迁移到模块的第 3 版，请为第 1 版和第 2 版注册单独的迁移，如下例所示: ```golang func (am AppModule) RegisterServices(cfg module.Configurator) { @@ -35,13 +35,13 @@ func (am AppModule) RegisterServices(cfg module.Configurator) { } ``` -Since these migrations are functions that need access to a Keeper's store, use a wrapper around the keepers called `Migrator` as shown in this example: +由于这些迁移是需要访问 Keeper 存储的函数，因此请使用名为“Migrator”的 Keeper 包装器，如下例所示: +++ https://github.com/cosmos/cosmos-sdk/blob/6ac8898fec9bd7ea2c1e5c79e0ed0c3f827beb55/x/bank/keeper/migrations.go#L8-L21 -## Writing Migration Scripts +## 编写迁移脚本 -To define the functionality that takes place during an upgrade, write a migration script and place the functions in a `migrations/` directory. For example, to write migration scripts for the bank module, place the functions in `x/bank/migrations/`. Use the recommended naming convention for these functions. For example, `v043bank` is the script that migrates the package `x/bank/migrations/v043`: +要定义在升级期间发生的功能，请编写迁移脚本并将这些功能放在 `migrations/` 目录中。 例如，要为 bank 模块编写迁移脚本，请将函数放在 `x/bank/migrations/` 中。 对这些函数使用推荐的命名约定。 例如，`v043bank` 是迁移包`x/bank/migrations/v043` 的脚本: ```golang // Migrating bank module from version 1 to 2 @@ -50,4 +50,4 @@ func (m Migrator) Migrate1to2(ctx sdk.Context) error { } ``` -To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/36f68eb9e041e20a5bb47e216ac5eb8b91f95471/x/bank/legacy/v043/store.go#L41-L62). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../architecture/adr-028-public-key-addresses.md). +要查看在余额密钥迁移中实施的更改示例代码，请查看 [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/36f68eb9e041e20a5bb47e216ac5eb8b91f95471/x/bank/legacy/v043/store。 去#L41-L62)。 对于上下文，此代码引入了银行存储的迁移，该迁移更新了地址，以字节长度为前缀，如 [ADR-028](../architecture/adr-028-public-key-addresses.md) 中所述。 \ No newline at end of file diff --git a/docs/ja/core/README.md b/docs/ja/core/README.md index 21bdda87779b..0cc2b6d3abf7 100644 --- a/docs/ja/core/README.md +++ b/docs/ja/core/README.md @@ -1,22 +1,22 @@ -# Core Concepts +# 核心概念 -This repository contains reference documentation on the core concepts of the Cosmos SDK. +此存储库包含有关 Cosmos SDK 核心概念的参考文档。 1. [`BaseApp`](./baseapp.md) -2. [Transaction](./transactions.md) -3. [Context](./context.md) -4. [Node Client](./node.md) -5. [Store](./store.md) -6. [Encoding](./encoding.md) -7. [gRPC, REST and Tendermint Endpoints](./grpc_rest.md) -8. [Command-Line Interface](./cli.md) -9. [Events](./events.md) -10. [Telemetry](./telemetry.md) -11. [Object-Capabilities](./ocap.md) -12. [RunTx recovery middleware](./runtx_middleware.md) -13. [Simulation](./simulation.md) -14. [Protobuf documentation](./proto-docs.md) -15. [In-Place Store Migrations](./upgrade.md) +2. [交易](./transactions.md) +3. [上下文](./context.md) +4. [节点客户端](./node.md) +5. [存储](./store.md) +6. [编码](./encoding.md) +7. [gRPC、REST 和 Tendermint 端点](./grpc_rest.md) +8. [命令行界面](./cli.md) +9. [事件](./events.md) +10. [遥测](./telemetry.md) +11. [对象-能力](./ocap.md) +12. [RunTx恢复中间件](./runtx_middleware.md) +13. [模拟](./simulation.md) +14. [Protobuf 文档](./proto-docs.md) +15. [就地存储迁移](./upgrade.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 IBC in your application. +阅读完核心概念后，查看 [IBC 文档](../ibc/README.md) 了解更多 +关于 IBC 核心概念以及如何将 IBC 集成到您的应用程序中。 \ No newline at end of file diff --git a/docs/ja/core/baseapp.md b/docs/ja/core/baseapp.md index 7145894d893c..a94f2f327746 100644 --- a/docs/ja/core/baseapp.md +++ b/docs/ja/core/baseapp.md @@ -1,23 +1,23 @@ -# BaseApp +# 基础应用 -This document describes `BaseApp`, the abstraction that implements the core functionalities of a Cosmos SDK application. {synopsis} +本文档描述了“BaseApp”，它是实现 Cosmos SDK 应用程序核心功能的抽象。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} -- [Lifecycle of a Cosmos SDK transaction](../basics/tx-lifecycle.md) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} +- [Cosmos SDK 交易的生命周期](../basics/tx-lifecycle.md) {prereq} -## Introduction +## 介绍 -`BaseApp` is a base type that implements the core of a Cosmos SDK application, namely: +`BaseApp` 是一个基本类型，它实现了 Cosmos SDK 应用程序的核心，即: -- 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. +- [应用区块链接口](#abci)，用于状态机与底层共识引擎(例如 Tendermint)进行通信。 +- [服务路由器](#service-routers)，将消息和查询路由到适当的模块。 +- 不同的 [states](#states)，因为状态机可以根据收到的 ABCI 消息更新不同的易失性状态。 -The goal of `BaseApp` is to provide the fundamental layer of a Cosmos 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: +BaseApp 的目标是提供 Cosmos SDK 应用程序的基础层 +开发人员可以轻松扩展以构建自己的自定义应用程序。通常， +开发人员将为他们的应用程序创建自定义类型，如下所示: ```go type App struct { @@ -32,71 +32,71 @@ type App struct { } ``` -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. +使用“BaseApp”扩展应用程序可以让前者访问“BaseApp”的所有方法。 +这允许开发人员使用他们想要的模块组合他们的自定义应用程序，而不是 +必须关心实施 ABCI、服务路由器和状态的艰苦工作 +管理逻辑。 -## Type Definition +## 类型定义 -The `BaseApp` type holds many important parameters for any Cosmos SDK based application. +“BaseApp”类型为任何基于 Cosmos SDK 的应用程序保存了许多重要参数。 +++ 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 `sdk.Msg` requests to the appropriate - module `Msg` service for processing. Here a `sdk.Msg` refers to the transaction component that needs to be - processed by a service in order to update the application state, and not to ABCI message which implements - 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). +让我们来看看最重要的组件。 + +> **注意**:没有描述所有参数，仅描述最重要的参数。参考 +> 完整列表的类型定义。 + +首先，在应用程序引导期间初始化的重要参数: + +- [`CommitMultiStore`](./store.md#commitmultistore):这是应用程序的主存储， + 它保存在 [每个块的结尾](#commit) 提交的规范状态。这家存储 + **不** 缓存，这意味着它不用于更新应用程序的易失性(未提交)状态。 + `CommitMultiStore` 是一个多存储，意思是存储的存储。应用程序的每个模块 + 在 multi-store 中使用一个或多个 `KVStores` 来持久化它们的状态子集。 +- 数据库:`commitMultiStore` 使用 `db` 来处理数据持久性。 +- [`Msg` 服务路由器](#msg-service-router):`msgServiceRouter` 有助于将 `sdk.Msg` 请求路由到适当的 + 用于处理的模块 `Msg` 服务。这里的 `sdk.Msg` 指的是需要被处理的事务组件 + 由服务处理以更新应用程序状态，而不是实现 ABCI 消息 + 应用程序和底层共识引擎之间的接口。 +- [gRPC 查询路由器](#grpc-query-router):`grpcQueryRouter` 有助于将 gRPC 查询路由到 + 适当的模块进行处理。这些查询本身不是 ABCI 消息，但它们 + 被中继到相关模块的 gRPC `Query` 服务。 +- [`TxDecoder`](https://godoc.org/github.com/cosmos/cosmos-sdk/types#TxDecoder):用于解码 + 由底层 Tendermint 引擎中继的原始交易字节。 +- [`ParamStore`](#paramstore):用于获取和设置应​​用程序共识参数的参数存储。 +- [`AnteHandler`](#antehandler):这个handler用于处理签名验证，费用支付， + 和其他消息前执行检查何时收到交易。它在执行期间 + [`CheckTx/RecheckTx`](#checktx) 和 [`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 + [`BeginBlocker` 和 `EndBlocker`](../basics/app-anatomy.md#beginblocker-and-endblocker):这些是 + 当应用程序收到 `InitChain`、`BeginBlock` 和 `EndBlock` 时执行的函数 + 来自底层 Tendermint 引擎的 ABCI 消息。 + +然后，用于定义 [易失性状态](#volatile-states)(即缓存状态)的参数: + +- `checkState`:此状态在 [`CheckTx`](#checktx) 期间更新，并在 [`Commit`](#commit) 时重置。 +- `deliverState`:此状态在 [`DeliverTx`](#delivertx) 期间更新，并在上设置为 `nil` + [`Commit`](#commit) 并在 BeginBlock 上重新初始化。 + +最后，几个比较重要的参数: + +- `voteInfos`:此参数携带缺少预提交的验证器列表，或者 + 因为他们没有投票或因为提议者没有包括他们的投票。这个信息是 + 由 [Context](#context) 携带，应用程序可以将其用于各种事情，例如 + 惩罚缺席的验证者。 +- `minGasPrices`:该参数定义了节点接受的最低汽油价格。这是一个 + **local** 参数，意味着每个全节点可以设置不同的 `minGasPrices`。它用于 + [`CheckTx`](#checktx)期间的`AnteHandler`，主要作为垃圾邮件防护机制。交易 + 进入[mempool](https://tendermint.com/docs/tendermint-core/mempool.html#transaction-ordering) + 仅当交易的 gas 价格大于其中之一的最低 gas 价格时 + `minGasPrices`(例如，如果`minGasPrices == 1uatom,1photon`，则交易的`gas-price` 必须为 + 大于“1uatom”或“1photon”)。 +- `appVersion`:应用程序的版本。它设置在 + [应用程序的构造函数](../basics/app-anatomy.md#constructor-function)。 + +## 构造函数 ```go func NewBaseApp( @@ -107,288 +107,288 @@ func NewBaseApp( } ``` -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`. +`BaseApp` 构造函数非常简单。唯一值得注意的是 +可能提供额外的 [`options`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/options.go) +到`BaseApp`，它将按顺序执行它们。 `options` 通常是 `setter` 函数 +对于重要参数，例如`SetPruning()` 设置修剪选项或`SetMinGasPrices()` 设置 +节点的`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). +`BaseApp` 维护两个主要的 volatile 状态和一个根或主状态。主要状态 +是应用程序的规范状态和易失状态，`checkState` 和 `deliverState`， +用于处理在 [`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 states by using a mechanism called _store branching_ (performed by `CacheWrap` function). -The types can be illustrated as follows: +在内部，只有一个 `CommitMultiStore`，我们将其称为主状态或根状态。 +从这个根状态，我们通过使用一种称为 _store 分支_(由`CacheWrap` 函数执行)的机制派生出两个易失性状态。 +这些类型可以说明如下: -![Types](./baseapp_state_types.png) +![类型](./baseapp_state_types.png) -### InitChain State Updates +### InitChain 状态更新 -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 期间，通过分支设置了两个 volatile 状态，即 checkState 和 deliverState +根`CommitMultiStore`。任何后续的读取和写入都发生在 `CommitMultiStore` 的分支版本上。 +为了避免不必要的主状态往返，所有对分支存储的读取都被缓存。 ![InitChain](./baseapp_state-initchain.png) -### CheckTx State Updates +### CheckTx 状态更新 -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` 期间，`checkState`，它基于来自根的最后提交的状态 +存储，用于任何读取和写入。这里我们只执行 `AnteHandler` 并验证一个服务路由器 +交易中的每条消息都存在。注意，当我们执行 `AnteHandler` 时，我们分支 +已经分支的`checkState`。这有副作用，如果 `AnteHandler` 失败， +状态转换不会反映在`checkState`中——即`checkState`仅在 +成功。 ![CheckTx](./baseapp_state-checktx.png) -### BeginBlock State Updates +### BeginBlock 状态更新 -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` 期间，`deliverState` 被设置为在随后的`DeliverTx` ABCI 消息中使用。这 +`deliverState` 基于来自根存储的最后提交的状态并且是分支的。 +请注意，在 [`Commit`](#commit) 上，`deliverState` 设置为 `nil`。 ![BeginBlock](./baseapp_state-begin_block.png) -### DeliverTx State Updates +### DeliverTx 状态更新 -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”的状态流与“CheckTx”几乎相同，除了状态转换发生在 +执行交易中的 `deliverState` 和消息。与“CheckTx”类似，状态转换 +发生在双分支状态 - `deliverState`。成功的消息执行结果 +写入致力于`deliverState`。注意，如果消息执行失败，状态从 +AnteHandler 被持久化。 ![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` 期间，发生在 `deliverState` 中的所有状态转换最终都会写入 +根 `CommitMultiStore` 反过来提交到磁盘并产生一个新的应用程序 +根哈希。这些状态转换现在被认为是最终的。最后，`checkState` 被设置为 +新提交的状态和 `deliverState` 设置为 `nil` 以在 `BeginBlock` 上重置。 -![Commit](./baseapp_state-commit.png) +![提交](./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. +在 `InitChain` 期间，`RequestInitChain` 提供包含参数的 `ConsensusParams` +除了证据参数之外，还与块执行相关，例如最大气体和大小。如果这些 +参数非 nil，它们在 BaseApp 的 `ParamStore` 中设置。在幕后，`ParamStore` +实际上由一个 `x/params` 模块 `Subspace` 管理。这允许通过调整参数 +链上治理。 -## 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. +当应用程序接收到消息和查询时，它们必须被路由到适当的模块以进行处理。路由是通过“BaseApp”完成的，它包含一个用于消息的“msgServiceRouter”和一个用于查询的“grpcQueryRouter”。 -### `Msg` Service Router +### `Msg` 服务路由器 -[`sdk.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 Protobuf `Msg` service) to the appropriate module's `MsgServer` implementation. +[`sdk.Msg`s](#../building-modules/messages-and-queries.md#messages) 从交易中提取出来后需要路由，这些交易是通过 [` CheckTx`](#checktx) 和 [`DeliverTx`](#delivertx) ABCI 消息。为此，`BaseApp` 拥有一个 `msgServiceRouter`，它将完全限定的服务方法(`string`，在每个模块的 Protobuf `Msg` 服务中定义)映射到相应模块的 `MsgServer` 实现。 -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`. +[`BaseApp` 中包含的默认 `msgServiceRouter`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/baseapp/msg_service_router.go) 是无状态的。但是，某些应用程序可能希望使用更多有状态的路由机制，例如允许治理禁用某些路由或将它们指向新模块以进行升级。出于这个原因，`sdk.Context` 也被传递到每个 -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). +应用程序的 `msgServiceRouter` 使用应用程序的 [module manager](../building-modules/module-manager.md#manager)(通过 `RegisterServices` 方法)使用所有路由进行初始化，它本身使用所有路由进行初始化应用程序的 [constructor](../basics/app-anatomy.md#app-constructor) 中的应用程序模块。 -### gRPC Query Router +### gRPC 查询路由器 -Similar to `sdk.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 `QueryServer` 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. +与`sdk.Msg`s类似，[`queries`](../building-modules/messages-and-queries.md#queries)需要路由到相应模块的[`Query`服务](../建筑模块/查询服务.md)。为此，`BaseApp` 拥有一个 `grpcQueryRouter`，它将模块的完全限定服务方法(`string`，在它们的 Protobuf `Query` gRPC 中定义)映射到它们的 `QueryServer` 实现。 `grpcQueryRouter` 在查询处理的初始阶段被调用，可以通过直接向 gRPC 端点发送 gRPC 查询，也可以通过 Tendermint RPC 端点上的 [`Query` ABCI 消息](#query)。 -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). +就像 `msgServiceRouter` 一样，`grpcQueryRouter` 使用应用程序的 [module manager](../building-modules/module-manager.md)(通过 `RegisterServices` 方法)使用所有查询路由进行初始化，它本身使用应用程序的 [constructor](../basics/app-anatomy.md#app-constructor) 中的所有应用程序模块进行初始化。 -## Main ABCI Messages +## 主要 ABCI 消息 -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. +[应用-区块链接口](https://tendermint.com/docs/spec/abci/) (ABCI) 是一个通用接口，将状态机与共识引擎连接起来，形成一个功能齐全的全节点。它可以用任何语言包装，并且需要由每个特定于应用程序的区块链来实现，这些区块链构建在与 ABCI 兼容的共识引擎(如 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. +**不是**共识引擎的作用来定义交易的状态或有效性。通常，交易由共识引擎以‘[]bytes’的形式处理，并通过 ABCI 中继到应用程序进行解码和处理。在网络和共识过程的关键时刻(例如，一个区块的开始，一个区块的提交，一个未确认的交易的接收，......)，共识引擎发出 ABCI 消息供状态机执行。 -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) +在 Cosmos SDK 之上构建的开发人员不需要自己实现 ABCI，因为 BaseApp 带有接口的内置实现。让我们来看看`BaseApp` 实现的主要 ABCI 消息:[`CheckTx`](#checktx) 和 [`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 `sdk.Msg`s from the transaction. -2. Perform _stateless_ checks by calling `ValidateBasic()` on each of the `sdk.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 `sdk.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 `sdk.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 `sdk.Msg`'s fully-qualified service method matches on of the routes inside the `msgServiceRouter`, but do **not** actually - process `sdk.Msg`s. `sdk.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: +当新的未确认(即尚未包含在有效块中)时，底层共识引擎发送 `CheckTx` +交易由全节点接收。 `CheckTx`的作用是守护全节点的mempool +(其中存储未经确认的交易，直到它们被包含在一个块中)来自垃圾邮件交易。 +未经确认的交易仅在通过“CheckTx”时才会转发给对等方。 + +`CheckTx()` 可以执行 _stateful_ 和 _stateless_ 检查，但开发人员应该努力 +使它们轻便。在Cosmos SDK中，在[解码交易](./encoding.md)之后，实现了`CheckTx()` +做以下检查: + +1. 从交易中提取`sdk.Msg`。 +2. 通过对每个 `sdk.Msg` 调用 `ValidateBasic()` 来执行 _stateless_ 检查。这个完成了 + 首先，因为 _stateless_ 检查比 _stateful_ 检查的计算成本更低。如果 + `ValidateBasic()` 失败，`CheckTx` 在运行 _stateful_ 检查之前返回，从而节省资源。 +3. 对 [account](../basics/accounts.md) 执行非模块相关的 _stateful_ 检查。这一步主要是检查 + `sdk.Msg` 签名有效，提供足够的费用并且发送帐户 + 有足够的资金支付上述费用。请注意，这里没有精确的 [`gas`](../basics/gas-fees.md) 计数， + 因为不处理 `sdk.Msg`。通常，[`AnteHandler`](../basics/gas-fees.md#antehandler) 会检查 `gas` 是否提供 + 交易优于基于原始交易规模的最小参考气体量， + 为了避免垃圾邮件提供 0 gas 的交易。 +4.确保每个`sdk.Msg`的完全限定服务方法匹配`msgServiceRouter`内的路由，但实际上**不** + 处理`sdk.Msg`s。 `sdk.Msg`s 只在规范状态需要更新时才需要处理， + 这发生在`DeliverTx`期间。 + +步骤 2. 和 3. 由 [`RunTx()`](#runtx-antehandler-and-runmsgs) 中的 [`AnteHandler`](../basics/gas-fees.md#antehandler) 执行 +函数，`CheckTx()` 以 `runTxModeCheck` 模式调用。在`CheckTx()`的每一步中， +特殊的 [volatile state](#volatile-states) 称为 `checkState` 被更新。该状态用于保持 +跟踪每个事务的 `CheckTx()` 调用触发的临时更改，无需修改 +[主要规范状态](#main-state)。例如，当一个交易通过`CheckTx()`时， +交易费用从“checkState”中的发件人帐户中扣除。如果第二笔交易是 +在处理第一个之前从同一个帐户收到，并且该帐户已经消耗了所有 +在第一笔交易期间，`checkState` 中的资金，第二笔交易将失败 `CheckTx`() 和 +被拒绝。在任何情况下，发送方的账户在交易之前不会实际支付费用 +实际上包含在一个块中，因为 `checkState` 永远不会提交到主状态。这 +每次一个块被[提交](#commit)时，`checkState` 被重置为主状态的最新状态。 + +`CheckTx` 向 [`abci.ResponseCheckTx`](https://tendermint.com/docs/spec/abci/abci.html#messages) 类型的底层共识引擎返回响应。 +响应包含: + +- `代码(uint32)`:响应代码。 `0` 如果成功。 +- `Data ([]byte)`:结果字节，如果有的话。 +- `Log (string):` 应用程序记录器的输出。可能是不确定的。 +- `信息(字符串):` 附加信息。可能是不确定的。 +- `GasWanted (int64)`:交易请求的燃料量。它由用户在生成交易时提供。 +- `GasUsed (int64)`:交易消耗的气体量。在“CheckTx”期间，该值是通过将交易字节的标准成本乘以原始交易的大小来计算的。接下来是一个例子: +++ https://github.com/cosmos/cosmos-sdk/blob/7d7821b9af132b0f6131640195326aa02b6751db/x/auth/ante/basic.go#L104-L105 -- `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. +- `Events ([]cmn.KVPair)`:用于过滤和索引交易(例如按帐户)的键值标签。有关更多信息，请参阅 [`event`s](./events.md)。 +- `代码空间(字符串)`:代码的命名空间。 -#### RecheckTx +#### 重新检查Tx -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`. +在`Commit` 之后，`CheckTx` 将在节点本地内存池中剩余的所有交易上再次运行 +在过滤块中包含的那些之后。防止内存池重新检查所有交易 +每次提交块时，都可以设置配置选项`mempool.recheck=false`。作为 +Tendermint v0.32.1，一个额外的 `Type` 参数可用于 `CheckTx` 函数 +指示传入的事务是新的(`CheckTxType_New`)还是重新检查(`CheckTxType_Recheck`)。 +这允许在“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. +当底层共识引擎收到区块提议时，区块中的每笔交易都需要由应用程序处理。为此，底层共识引擎按顺序向每个交易的应用程序发送“DeliverTx”消息。 -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`. +在处理给定块的第一笔交易之前，在 [`BeginBlock`](#beginblock) 期间初始化名为 `deliverState` 的 [volatile state](#volatile-states)。每次通过`DeliverTx`处理交易时都会更新此状态，并在块被[提交](#commit)时提交到[主状态](#main-state)，在设置为“nil”之后. -`DeliverTx` performs the **exact same steps as `CheckTx`**, with a little caveat at step 3 and the addition of a fifth step: +`DeliverTx` 执行 ** 与 `CheckTx`** 完全相同的步骤，在第 3 步有一点需要注意，并增加了第五步: -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 `sdk.Msg` in the transaction, route to the appropriate module's Protobuf [`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`. +1. `AnteHandler` **不** 检查交易的 `gas-prices` 是否足够。那是因为检查的 `min-gas-prices` 值 `gas-prices` 是节点本地的，因此对于一个完整节点来说足够的可能不适用于另一个。这意味着提议者可能会免费包含交易，尽管他们没有这样做的动力，因为他们会从他们提议的区块的总费用中获得奖金。 +2.对于交易中的每个`sdk.Msg`，路由到相应模块的Protobuf [`Msg`服务](../building-modules/msg-services.md)。执行额外的 _stateful_ 检查，并且在 `deliverState` 的 `context` 中保存的分支多存储由模块的 `keeper` 更新。如果 `Msg` 服务成功返回，则保存在 `context` 中的分支多存储被写入 `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: +在 (2) 中概述的附加第五步期间，对存储的每次读/写都会增加“GasConsumed”的值。您可以找到每个操作的默认成本: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/store/types/gas.go#L164-L175 -At any point, if `GasConsumed > GasWanted`, the function returns with `Code != 0` and `DeliverTx` fails. +在任何时候，如果 `GasConsumed > GasWanted`，函数返回 `Code != 0` 并且 `DeliverTx` 失败。 -`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: +`DeliverTx` 向 [`abci.ResponseDeliverTx`](https://tendermint.com/docs/spec/abci/abci.html#delivertx) 类型的底层共识引擎返回响应。响应包含: -- `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. +- `代码(uint32)`:响应代码。 `0` 如果成功。 +- `Data ([]byte)`:结果字节，如果有的话。 +- `Log (string):` 应用程序记录器的输出。可能是不确定的。 +- `信息(字符串):` 附加信息。可能是不确定的。 +- `GasWanted (int64)`:交易请求的燃料量。它由用户在生成交易时提供。 +- `GasUsed (int64)`:交易消耗的气体量。在“DeliverTx”期间，该值的计算方法是将交易字节的标准成本乘以原始交易的大小，并在每次对存储进行读/写时添加 gas。 +- `Events ([]cmn.KVPair)`:用于过滤和索引交易(例如按帐户)的键值标签。有关更多信息，请参阅 [`event`s](./events.md)。 +- `代码空间(字符串)`:代码的命名空间。 -## RunTx, AnteHandler and RunMsgs +## RunTx、AnteHandler 和 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. +从 `CheckTx`/`DeliverTx` 调用 `RunTx` 来处理事务，以 `runTxModeCheck` 或 `runTxModeDeliver` 作为参数来区分两种执行模式。请注意，当 `RunTx` 接收到一个交易时，它已经被解码了。 -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. +`RunTx` 在被调用时所做的第一件事是通过以适当的模式(`runTxModeCheck` 或 `runTxModeDeliver`)调用 `getContextForTx()` 函数来检索 `context` 的 `CacheMultiStore`。这个 `CacheMultiStore` 是主存储的一个分支，具有缓存功能(用于查询请求)，在 `BeginBlock` 期间为 `DeliverTx` 实例化，并在前一个块的 `Commit` 期间为 `CheckTx` 实例化。之后，调用两个 `defer func()` 进行 [`gas`](../basics/gas-fees.md) 管理。它们在 `runTx` 返回时执行并确保 `gas` 实际消耗，并且会抛出错误(如果有)。 -After that, `RunTx()` calls `ValidateBasic()` on each `sdk.Msg`in the `Tx`, which runs preliminary _stateless_ validity checks. If any `sdk.Msg` fails to pass `ValidateBasic()`, `RunTx()` returns with an error. +之后，`RunTx()` 在 `Tx` 中的每个 `sdk.Msg` 上调用 `ValidateBasic()`，运行初步的 _stateless_ 有效性检查。如果任何 `sdk.Msg` 未能通过 `ValidateBasic()`，`RunTx()` 将返回一个错误。 -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. +然后，运行应用程序的 [`anteHandler`](#antehandler)(如果存在)。在准备这一步时，`checkState`/`deliverState` 的`context` 和`context` 的`CacheMultiStore` 都使用`cacheTxContext()` 函数进行了分支。 +++ 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. +这允许 `RunTx` 在 `anteHandler` 执行期间不提交对状态所做的更改，如果它最终失败。它还可以防止实现 `anteHandler` 的模块写入状态，这是 Cosmos SDK [object-capabilities](./ocap.md) 的重要组成部分。 -Finally, the [`RunMsgs()`](#runmsgs) function is called to process the `sdk.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. +最后，调用 [`RunMsgs()`](#runmsgs) 函数来处理 `Tx` 中的 `sdk.Msg`。在准备这一步时，就像`anteHandler`一样，`checkState`/`deliverState`的`context`和`context`的`CacheMultiStore`都使用`cacheTxContext()`函数进行分支。 -### 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. +`AnteHandler` 是一个特殊的处理程序，它实现了 `AnteHandler` 接口，用于在处理事务的内部消息之前对事务进行身份验证。 +++ 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: +`AnteHandler` 理论上是可选的，但仍然是公共区块链网络的一个非常重要的组成部分。它有 3 个主要目的: -- 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. +- 通过费用扣除和 [`sequence`](./transactions.md#transaction-generation) 检查，成为抵御垃圾邮件的主要防线和第二道防线(第一道防线是内存池)以防止交易重播。 +- 执行初步的 _stateful_ 有效性检查，例如确保签名有效或发件人有足够的资金来支付费用。 +- 通过收取交易费用，在激励利益相关者方面发挥作用。 -`BaseApp` holds an `anteHandler` as parameter that is initialized in the [application's constructor](../basics/app-anatomy.md#application-constructor). The most widely used `anteHandler` is the [`auth` module](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/auth/ante/ante.go). +`BaseApp` 持有一个 `anteHandler` 作为参数，该参数在 [应用程序的构造函数](../basics/app-anatomy.md#application-constructor) 中初始化。最广泛使用的`anteHandler`是[`auth`模块](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/auth/ante/ante.go)。 -Click [here](../basics/gas-fees.md#antehandler) for more on the `anteHandler`. +单击 [此处](../basics/gas-fees.md#antehandler) 了解有关 `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 `sdk.Msg`s. +`RunMsgs` 是从 `RunTx` 调用的，以 `runTxModeCheck` 作为参数来检查交易中每条消息的路由是否存在，并使用 `runTxModeDeliver` 来实际处理 `sdk.Msg`。 -First, it retrieves the `sdk.Msg`'s fully-qualified type name, by checking the `type_url` of the Protobuf `Any` representing the `sdk.Msg`. Then, using the application's [`msgServiceRouter`](#msg-service-router), it checks for the existence of `Msg` service method related to that `type_url`. At this point, if `mode == runTxModeCheck`, `RunMsgs` returns. Otherwise, if `mode == runTxModeDeliver`, the [`Msg` service](../building-modules/msg-services.md) RPC is executed, before `RunMsgs` returns. +首先，它通过检查代表 `sdk.Msg` 的 Protobuf `Any` 的 `type_url` 来检索 `sdk.Msg` 的完全限定类型名称。然后，使用应用程序的 [`msgServiceRouter`](#msg-service-router)，它会检查与该 `type_url` 相关的 `Msg` 服务方法是否存在。此时，如果`mode == runTxModeCheck`，则返回`RunMsgs`。否则，如果 `mode == runTxModeDeliver`，则在 `RunMsgs` 返回之前执行 [`Msg` 服务](../building-modules/msg-services.md) RPC。 -## Other ABCI Messages +## 其他 ABCI 消息 -### 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: +[`InitChain` ABCI 消息](https://tendermint.com/docs/app-dev/abci-spec.html#initchain) 是在链第一次启动时从底层 Tendermint 引擎发送的。它主要用于**初始化**参数和状态，如: -- [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. +- [共识参数](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters) 通过`setConsensusParams`。 +- [`checkState` 和`deliverState`](#volatile-states) 通过`setCheckState` 和`setDeliverState`。 +- [block gas meter](../basics/gas-fees.md#block-gas-meter)，用无限的gas来处理创世交易。 -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. +最后，`BaseApp` 的`InitChain(req abci.RequestInitChain)` 方法调用应用程序的[`initChainer()`](../basics/app-anatomy.md#initchainer) 以初始化主状态从“创世文件”中获取应用程序的名称，如果已定义，则调用每个应用程序模块的 [`InitGenesis`](../building-modules/genesis.md#initgenesis) 函数。 -### 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: +[`BeginBlock` ABCI 消息](#https://tendermint.com/docs/app-dev/abci-spec.html#beginblock) 当收到正确提议者创建的区块提议时从底层 Tendermint 引擎发送, 在为块中的每个事务运行 [`DeliverTx`](#delivertx) 之前。它允许开发人员在每个块的开头执行逻辑。在 Cosmos SDK 中，`BeginBlock(req abci.RequestBeginBlock)` 方法执行以下操作: -- Initialize [`deliverState`](#volatile-states) with the latest header using the `req abci.RequestBeginBlock` passed as parameter via the `setDeliverState` function. +- 使用通过`setDeliverState` 函数作为参数传递的`req abci.RequestBeginBlock` 使用最新的标头初始化[`deliverState`](#volatile-states)。 +++ 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`. + 此功能还会重置 [主燃气表](../basics/gas-fees.md#main-gas-meter)。 +- 使用 `maxGas` 限制初始化 [block gas meter](../basics/gas-fees.md#block-gas-meter)。块内消耗的“gas”不能超过“maxGas”。该参数在应用程序的共识参数中定义。 +- 运行应用程序的[`beginBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock)，主要运行[`BeginBlocker()`](../building-modules/beginblock) -endblock.md#beginblock) 每个应用程序模块的方法。 +- 设置应用程序的 [`VoteInfos`](https://tendermint.com/docs/app-dev/abci-spec.html#voteinfo)，即前一个区块的 _precommit_ 被包含在当前区块的提议者。此信息被携带到 [`Context`](./context.md) 中，以便它可以在 `DeliverTx` 和 `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. +[`EndBlock` ABCI 消息](#https://tendermint.com/docs/app-dev/abci-spec.html#endblock) 在 [`DeliverTx`](#delivertx) 之后从底层 Tendermint 引擎发送为为块中的每个事务运行。它允许开发人员在每个块的末尾执行逻辑。在Cosmos SDK中，批量`EndBlock(req abci.RequestEndBlock)`方法是运行应用程序的[`EndBlocker()`](../basics/app-anatomy.md#beginblocker-and-endblock)，主要是运行每个应用程序模块的 [`EndBlocker()`](../building-modules/beginblock-endblock.md#beginblock) 方法。 -### 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. +[`Commit` ABCI 消息](https://tendermint.com/docs/app-dev/abci-spec.html#commit) 是在全节点从 2/3 收到 _precommits_ 后从底层 Tendermint 引擎发送的+ 验证者(按投票权加权)。在 BaseApp 端，实现了 Commit(res abci.ResponseCommit) 函数以提交在 BeginBlock、DeliverTx 和 EndBlock 期间发生的所有有效状态转换，并为下一个块重置状态。 -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`. +为了提交状态转换，`Commit` 函数调用 `deliverState.ms` 上的 `Write()` 函数，其中 `deliverState.ms` 是主存储 `app.cms` 的分支多存储。然后，`Commit` 函数将`checkState` 设置为最新的头部(从`deliverState.ctx.BlockHeader` 获得)，将`deliverState` 设置为`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. +最后，`Commit` 将 `app.cms` 的承诺的哈希返回给底层的共识引擎。该散列用作下一个块的标头中的参考。 -### 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`. +[`Info` ABCI 消息](https://tendermint.com/docs/app-dev/abci-spec.html#info) 是来自底层共识引擎的简单查询，特别是用于将后者与应用程序同步在启动时发生的握手期间。调用时，来自 BaseApp 的 Info(res abci.ResponseInfo) 函数将返回应用程序的名称、版本和 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). +[`Query` ABCI 消息](https://tendermint.com/docs/app-dev/abci-spec.html#query) 用于服务从底层共识引擎接收的查询，包括通过 RPC 接收的查询，如 Tendermint RPC。它曾经是与应用程序构建接口的主要入口点，但随着 Cosmos SDK v0.40 中[gRPC 查询](../building-modules/query-services.md) 的引入，它的使用受到了更多限制。应用程序在实现 `Query` 方法时必须遵守一些规则，这些规则在 [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: +每个 Tendermint `query` 都带有一个 `path`，它是一个 `string`，表示要查询的内容。如果 `path` 匹配一个 gRPC 完全限定的服务方法，那么 `BaseApp` 会将查询推迟到 `grpcQueryRouter` 并让它按照 [above](#grpc-query-router) 的解释进行处理。否则，`path` 表示 gRPC 路由器(尚未)处理的查询。 `BaseApp` 用 `/` 分隔符分割 `path` 字符串。按照惯例，拆分字符串的第一个元素 (`splitted[0]`) 包含 `query` 的类别(`app`、`p2p`、`​​store` 或 `custom`)。 `Query(req abci.RequestQuery)` 方法的 `BaseApp` 实现是一个简单的调度程序，为这 4 种主要查询类别提供服务: -- 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 queries 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). +- 与应用程序相关的查询，例如查询应用程序的版本，通过 `handleQueryApp` 方法提供。 +- 对 multistore 的直接查询，由 `handlerQueryStore` 方法提供服务。这些直接查询不同于通过`app.queryRouter`的自定义查询，主要由第三方服务提供商使用，如区块浏览器。 +- P2P 查询，通过`handleQueryP2P` 方法提供服务。这些查询返回“app.addrPeerFilter”或“app.ipPeerFilter”，其中包含分别按地址或 IP 过滤的对等点列表。这些列表首先通过`BaseApp` 的[constructor](#constructor) 中的`options` 初始化。 +- 自定义查询，包括遗留查询(在引入 gRPC 查询之前)，通过 `handleQueryCustom` 方法提供。 `handleQueryCustom` 在使用从 `app.queryRouter` 获得的 `queryRoute` 将查询映射到相应模块的 [legacy `querier`](../building-modules/query-services.md#legacy-查询者)。 -## Next {hide} +## 下一个 {hide} -Learn more about [transactions](./transactions.md) {hide} +详细了解 [transactions](./transactions.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/cli.md b/docs/ja/core/cli.md index 9897d985c89e..6e42c4fa80c6 100644 --- a/docs/ja/core/cli.md +++ b/docs/ja/core/cli.md @@ -1,128 +1,128 @@ -# 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 a Cosmos SDK [**module**](../building-modules/intro.md) can be found [here](../building-modules/module-interfaces.md#cli). {synopsis} +本文档描述了命令行界面 (CLI) 如何在高层次上工作，用于 [**应用程序**](../basics/app-anatomy.md)。可以在 [此处](../building-modules/module-interfaces.md#) 找到为 Cosmos SDK [**module**](../building-modules/intro.md) 实现 CLI 的单独文档cli)。 {概要} -## Command-Line Interface +## 命令行界面 -### Example Command +### 示例命令 -There is no set way to create a CLI, but Cosmos 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. +创建 CLI 没有固定的方法，但 Cosmos SDK 模块通常使用 [Cobra 库](https://github.com/spf13/cobra)。使用 Cobra 构建 CLI 需要定义命令、参数和标志。 [**Commands**](#commands) 了解用户希望采取的操作，例如用于创建交易的 `tx` 和用于查询应用程序的 `query`。每个命令还可以有嵌套的子命令，这是命名特定事务类型所必需的。用户还提供**参数**，例如将硬币发送到的帐号，以及 [**Flags**](#flags) 来修改命令的各个方面，例如汽油价格或广播到哪个节点。 -Here is an example of a command a user might enter to interact with the simapp CLI `simd` in order to send some tokens: +下面是一个用户可能输入的命令示例，该命令与 simapp CLI `simd` 交互以发送一些令牌: ```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`. +- 整个应用程序“simd”的根命令。 +- 子命令`tx`，它包含让用户创建交易的所有命令。 +- 子命令 `bank` 指示将命令路由到哪个模块([`x/bank`](../../x/bank/spec/README.md) 在这种情况下是模块)。 +- 交易类型`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). +接下来的两个字符串是参数:用户希望发送的“from_address”、收件人的“to_address”以及他们想要发送的“金额”。最后，命令的最后几个字符串是可选标志，用于指示用户愿意支付多少费用(使用用于执行交易的 gas 量和用户提供的 gas 价格计算)。 -The CLI interacts with a [node](../core/node.md) to handle this command. The interface itself is defined in a `main.go` file. +CLI 与 [node](../core/node.md) 交互以处理此命令。接口本身在 main.go 文件中定义。 -### Building the CLI +### 构建 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: +`main.go` 文件需要有一个 `main()` 函数来创建一个根命令，所有应用程序命令都将作为子命令添加到该根命令中。 root 命令另外处理: -- **setting configurations** by reading in configuration files (e.g. the Cosmos 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). +- 通过读取配置文件(例如 Cosmos SDK 配置文件)来**设置配置**。 +- **向其添加任何标志**，例如`--chain-id`。 +- **通过调用应用程序的`MakeCodec()`函数(在`simapp`中称为`MakeTestEncodingConfig`)来实例化`codec`**。 [`codec`](../core/encoding.md) 用于对应用程序的数据结构进行编码和解码 - 存储只能持久化 `[]byte`，因此开发人员必须为其数据结构定义序列化格式或使用默认值 Protobuf。 +- **为所有可能的用户交互添加子命令**，包括[交易命令](#transaction-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: +`main()` 函数最终创建了一个执行器和 [execute](https://godoc.org/github.com/spf13/cobra#Command.Execute) 根命令。请参阅“simapp”应用程序中的“main()”函数示例: +++ 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. +文档的其余部分将详细说明每个步骤需要实现的内容，并包括来自 `simapp` CLI 文件的较小部分代码。 -## Adding Commands to the CLI +## 向 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. +每个应用程序 CLI 首先构造一个根命令，然后通过使用 `rootCmd.AddCommand()` 聚合子命令(通常带有进一步嵌套的子命令)来添加功能。应用程序的大部分独特功能在于其事务和查询命令，分别称为“TxCmd”和“QueryCmd”。 -### 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. +root 命令(称为“rootCmd”)是用户首先在命令行中键入以指示他们希望与哪个应用程序交互的命令。用于调用命令的字符串(“Use”字段)通常是后缀为“-d”的应用程序名称，例如`simd` 或 `gaiad`。 root 命令通常包括以下命令以支持应用程序中的基本功能。 -- **Status** command from the Cosmos 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 Cosmos SDK client tools, which includes a collection of subcommands for using the key functions in the Cosmos 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 Cosmos 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. +- 来自 Cosmos SDK rpc 客户端工具的 **Status** 命令，它打印有关连接的 [`Node`](../core/node.md) 状态的信息。节点的状态包括`NodeInfo`、`SyncInfo`和`ValidatorInfo`。 +- **Keys** [commands](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys) 来自 Cosmos SDK 客户端工具，其中包括用于使用Cosmos SDK 加密工具中的关键功能，包括添加新密钥并将其保存到密钥环、列出存储在密钥环中的所有公钥以及删除密钥。例如，用户可以输入 `simd keys add ` 来添加新密钥并将加密副本保存到密钥环，使用标志 `--recover` 从种子短语或标志`- -multisig` 将多个密钥组合在一起以创建一个多重签名密钥。有关 `add` 键命令的完整详细信息，请参阅代码 [此处](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/client/keys/add.go)。有关使用 `--keyring-backend` 存储密钥凭证的更多详细信息，请查看 [keyring docs](../run-node/keyring.md)。 +- 来自 Cosmos SDK 服务器包的 **Server** 命令。这些命令负责提供启动 ABCI Tendermint 应用程序所需的机制，并提供完全引导应用程序所需的 CLI 框架(基于 [cobra](github.com/spf13/cobra))。该包公开了两个核心函数:`StartCmd` 和 `ExportCmd`，它们分别创建用于启动应用程序和导出状态的命令。单击 [此处](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/server) 了解更多信息。 +- [**交易**](#transaction-commands) 命令。 +- [**查询**](#query-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. +接下来是来自“simapp”应用程序的“rootCmd”函数示例。它实例化根命令，添加 [_persistent_ flag](#flags) 和在每次执行之前运行的 `PreRun` 函数，并添加所有必要的子命令。 +++ https://github.com/cosmos/cosmos-sdk/blob/4eea4cafd3b8b1c2cd493886db524500c9dd745c/simapp/simd/cmd/root.go#L37-L150 -`rootCmd` has a function called `initAppConfig()` which is useful for setting the application's custom configs. -By default app uses Tendermint app config template from Cosmos SDK, which can be over-written via `initAppConfig()`. -Here's an example code to override default `app.toml` template. +`rootCmd` 有一个名为 `initAppConfig()` 的函数，它对于设置应用程序的自定义配置很有用。 +默认情况下，应用程序使用来自 Cosmos SDK 的 Tendermint 应用程序配置模板，可以通过 `initAppConfig()` 覆盖它。 +这是覆盖默认`app.toml`模板的示例代码。 +++ https://github.com/cosmos/cosmos-sdk/blob/4eea4cafd3b8b1c2cd493886db524500c9dd745c/simapp/simd/cmd/root.go#L84-L117 -The `initAppConfig()` also allows overriding the default Cosmos SDK's [server config](https://github.com/cosmos/cosmos-sdk/blob/4eea4cafd3b8b1c2cd493886db524500c9dd745c/server/config/config.go#L199). One example is the `min-gas-prices` config, which defines the minimum gas prices a validator is willing to accept for processing a transaction. By default, the Cosmos SDK sets this parameter to `""` (empty string), which forces all validators to tweak their own `app.toml` and set a non-empty value, or else the node will halt on startup. This might not be the best UX for validators, so the chain developer can set a default `app.toml` value for validators inside this `initAppConfig()` function. +`initAppConfig()` 还允许覆盖默认的 Cosmos SDK 的 [服务器配置](https://github.com/cosmos/cosmos-sdk/blob/4eea4cafd3b8b1c2cd493886db524500c9dd745c/server/config/config.go#L199)。一个例子是 `min-gas-prices` 配置，它定义了验证者在处理交易时愿意接受的最低 gas 价格。默认情况下，Cosmos SDK 将此参数设置为 `""`(空字符串)，这会强制所有验证器调整自己的 `app.toml` 并设置一个非空值，否则节点将在启动时停止。这可能不是验证器的最佳 UX，因此链开发人员可以在这个 `initAppConfig()` 函数中为验证器设置一个默认的 `app.toml` 值。 +++ https://github.com/cosmos/cosmos-sdk/blob/aa9b055ddb46aacd4737335a92d0b8a82d577341/simapp/simd/cmd/root.go#L101-L116 -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. +根级 `status` 和 `keys` 子命令在大多数应用程序中都很常见，并且不与应用程序状态交互。应用程序的大部分功能——用户实际上可以用它_做的事情——是由它的 `tx` 和 `query` 命令启用的。 -### 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`: +[Transactions](./transactions.md) 是包装 [`Msg`s](../building-modules/messages-and-queries.md#messages) 的对象，它们会触发状态更改。为了能够使用 CLI 界面创建交易，通常会在 `rootCmd` 中添加一个函数 `txCmd`: +++ 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: +这个 `txCmd` 函数为应用程序添加了最终用户可用的所有事务。这通常包括: -- **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, the signing command is necessary for every application. -- **Broadcast command** from the Cosmos 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. +- **签名命令**来自 [`auth`](../../x/auth/spec/README.md) 模块，用于在交易中签署消息。要启用多重签名，请添加 `auth` 模块的 `MultiSign` 命令。由于每笔交易都需要某种签名才能有效，因此每个应用程序都需要签名命令。 +- **来自 Cosmos SDK 客户端工具的广播命令**，用于广播交易。 +- **所有[模块事务命令](../building-modules/module-interfaces.md#transaction-commands)** 应用程序依赖，通过使用[基本模块管理器](../building- modules/module-manager.md#basic-manager) `AddTxCommands()` 函数。 -Here is an example of a `txCmd` aggregating these subcommands from the `simapp` application: +这是一个从“simapp”应用程序聚合这些子命令的“txCmd”示例: +++ 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`: +[**Queries**](../building-modules/messages-and-queries.md#queries) 是允许用户检索有关应用程序状态信息的对象。为了能够使用 CLI 界面创建交易，通常会在 `rootCmd` 中添加一个函数 `txCmd`: +++ 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: +这个 `queryCmd` 函数为应用程序添加了最终用户可用的所有查询。这通常包括: -- **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 Cosmos SDK rpc client tools, which displays the validator set of a given height. -- **Block command** from the Cosmos 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. +- **QueryTx** 和/或其他交易查询命令]来自`auth`模块，允许用户通过输入其哈希值、标签列表或区块高度来搜索交易。这些查询允许用户查看交易是否已包含在区块中。 +- 来自 `auth` 模块的 **Account 命令**，显示给定地址的帐户的状态(例如帐户余额)。 +- **Validator command** 来自 Cosmos SDK rpc 客户端工具，显示给定高度的验证器集。 +- 来自 Cosmos SDK rpc 客户端工具的 **Block 命令**，显示给定高度的块数据。 +- **所有[模块查询命令](../building-modules/module-interfaces.md#query-commands)** 应用程序依赖，使用[基本模块管理器](../building- modules/module-manager.md#basic-manager) `AddQueryCommands()` 函数。 -Here is an example of a `queryCmd` aggregating subcommands from the `simapp` application: +这是一个从“simapp”应用程序聚合子命令的“queryCmd”示例: +++ 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. +标志用于修改命令；开发人员可以使用 CLI 将它们包含在 `flags.go` 文件中。用户可以显式地将它们包含在命令中或通过在其 [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) 中预先配置它们。通常预先配置的标志包括用户希望与之交互的区块链的“--node”和“--chain-id”。 -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. +添加到命令的 _persistent_ 标志(与 _local_ 标志相对)超越其所有子命令:子命令将继承这些标志的配置值。此外，所有标志在添加到命令时都有默认值；有些关闭选项，但其他是用户需要覆盖以创建有效命令的空值。标志可以显式标记为 _required_ 以便在用户不提供值时自动抛出错误，但以不同方式处理意外丢失标志也是可以接受的。 -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: +标志直接添加到命令中(通常在定义模块命令的 [模块的 CLI 文件](../building-modules/module-interfaces.md#flags) 中)并且除了 `rootCmd` 持久标志之外没有任何标志必须添加在应用程序级别添加。通常为“--chain-id”(应用程序所属区块链的唯一标识符)添加一个 _persistent_ 标志到 root 命令。添加这个标志可以在`main()`函数中完成。添加此标志是有意义的，因为链 ID 不应在此应用程序 CLI 中跨命令更改。以下是来自“simapp”应用程序的示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/simd/cmd/root.go#L118-L119 -## 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: +每个标志都绑定到它各自命名的环境变量。然后环境变量的名称由两部分组成 - 大写的“basename”后跟标志的标志名称。 `-` 必须替换为 `_`。例如，基本名称为“GAIA”的应用程序的标志“--home”绑定到“GAIA_HOME”。它允许减少为常规操作键入的标志数量。例如，而不是: ```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 @@ -135,18 +135,18 @@ GAIA_KEYRING_BACKEND="test" 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. +应用程序的根命令使用 `PersistentPreRun()` cobra 命令属性来执行命令至关重要，因此所有子命令都可以访问服务器和客户端上下文。这些上下文最初被设置为它们的默认值，并且可能在它们各自的“PersistentPreRun()”函数中被修改，范围限定为命令。请注意，`client.Context` 通常预先填充有“默认”值，这些值可能对所有命令在必要时继承和覆盖很有用。 -Here is an example of an `PersistentPreRun()` function from `simapp``: +下面是一个来自 `simapp` 的 `PersistentPreRun()` 函数的例子: +++ 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`. +`SetCmdClientContextHandler` 调用通过 `ReadPersistentCommandFlags` 读取持久标志，它创建一个 `client.Context` 并在根命令的 `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. +`InterceptConfigsPreRunHandler` 调用创建了一个 viper 文字、默认的 `server.Context` 和一个记录器，并将其设置在根命令的 `Context` 上。 `server.Context` 将通过内部 `interceptConfigs` 调用修改并保存到磁盘，该调用根据提供的主路径读取或创建 Tendermint 配置。此外，`interceptConfigs` 还读取并加载应用程序配置 `app.toml`，并将其绑定到 `server.Context` viper 文字。这是至关重要的，因此应用程序不仅可以访问 CLI 标志，还可以访问此文件提供的应用程序配置值。 -## Next {hide} +## 下一个 {hide} -Learn about [events](./events.md) {hide} +了解 [事件](./events.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/context.md b/docs/ja/core/context.md index 83e694cf4d7e..a7b54ae479cf 100644 --- a/docs/ja/core/context.md +++ b/docs/ja/core/context.md @@ -1,31 +1,31 @@ -# 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} +`context` 是一种数据结构，旨在从一个函数传递到另一个函数，它携带有关应用程序当前状态的信息。它提供了对分支存储(整个状态的安全分支)以及有用的对象和信息的访问，如“gasMeter”、“块高度”、“共识参数”等。 {概要} -## Pre-requisites Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq} -- [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} +- [交易的生命周期](../basics/tx-lifecycle.md) {prereq} -## Context Definition +## 上下文定义 -The Cosmos 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. The `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. +Cosmos SDK `Context` 是一个自定义数据结构，它包含 Go 的 stdlib [`context`](https://golang.org/pkg/context) 作为其基础，并且在其定义中具有许多特定于宇宙 SDK。 `Context` 是事务处理不可或缺的一部分，因为它允许模块轻松访问 [`multistore`](./store.md#multistore) 中各自的 [store](./store.md#base-layer-kvstores) ) 并检索交易上下文，例如区块头和燃气表。 +++ 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 Cosmos 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: +- **Context:** 基本类型是 Go [Context](https://golang.org/pkg/context)，在 [Go Context Package](#go-context-package) 部分进一步解释以下。 +- **Multistore:** 每个应用程序的 `BaseApp` 都包含一个 [`CommitMultiStore`](./store.md#multistore)，它在创建 `Context` 时提供。调用 `KVStore()` 和 `TransientStore()` 方法允许模块使用它们唯一的 `StoreKey` 获取它们各自的 [`KVStore`](./store.md#base-layer-kvstores)。 +- **ABCI Header:** [header](https://tendermint.com/docs/spec/abci/abci.html#header) 是一种 ABCI 类型。它携带有关区块链状态的重要信息，例如当前区块的区块高度和提议者。 +- **Chain ID:** 区块所属区块链的唯一标识号。 +- **交易字节数:** 正在使用上下文处理的交易的 `[]byte` 表示。每笔交易都由 Cosmos SDK 的各个部分和共识引擎(例如 Tendermint)在其整个 [生命周期](../basics/tx-lifecycle.md) 中处理，其中一些对交易类型没有任何了解。因此，事务使用某种[编码格式](./encoding.md)，例如[Amino](./encoding.md)，被编组为通用的“[]byte”类型。 +- **Logger:** 来自 Tendermint 库的 `logger`。了解有关日志的更多信息 [此处](https://tendermint.com/docs/tendermint-core/how-to-read-logs.html#how-to-read-logs)。模块调用此方法来创建自己独特的特定于模块的记录器。 +- **VoteInfo:** ABCI 类型列表 [`VoteInfo`](https://tendermint.com/docs/spec/abci/abci.html#voteinfo)，其中包括验证器的名称和布尔值表明他们是否已经签署了区块。 +- **Gas Meters:** 具体来说，一个 [`gasMeter`](../basics/gas-fees.md#main-gas-meter) 用于当前正在使用上下文处理的交易和一个 [`blockGasMeter`](../basics/gas-fees.md#block-gas-meter) 用于它所属的整个块。用户指定他们希望为执行交易支付多少费用；这些燃气表跟踪到目前为止在交易或区块中使用了多少 [gas](../basics/gas-fees.md)。如果燃气表用完，则执行停止。 +- **CheckTx 模式:** 一个布尔值，指示交易应在“CheckTx”还是“DeliverTx”模式下处理。 +- **Min Gas Price:** 节点为了在其区块中包含交易而愿意接受的最低 [gas](../basics/gas-fees.md) 价格。此价格是由每个节点单独配置的本地值，因此**不应在导致状态转换的序列中使用的任何函数中使用**。 +- **Consensus Params:** ABCI 类型 [Consensus Parameters](https://tendermint.com/docs/spec/abci/apps.html#consensus-parameters)，指定区块链的某些限制，例如最大值一个块的气体。 +- **事件管理器:** 事件管理器允许任何有权访问 `Context` 的调用者发出 [`Events`](./events.md)。模块可以定义特定于模块的 + `Events` 通过定义各种 `Types` 和 `Attributes` 或使用在 `types/` 中找到的通用定义。客户可以订阅或查询这些“事件”。这些“事件”在整个“DeliverTx”、“BeginBlock”和“EndBlock”中收集，并返回给 Tendermint 进行索引。例如: ```go ctx.EventManager().EmitEvent(sdk.NewEvent( @@ -34,42 +34,42 @@ ctx.EventManager().EmitEvent(sdk.NewEvent( ) ``` -## 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. +[Golang Context Package](https://golang.org/pkg/context) 中定义了一个基本的`Context`。 一个`上下文` +是一种不可变的数据结构，它在 API 和进程之间承载请求范围的数据。 上下文 +还旨在启用并发并在 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: +上下文旨在**不可变**； 他们永远不应该被编辑。 相反，约定是 +使用“With”函数从其父级创建子上下文。 例如: ```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. +[Golang Context Package](https://golang.org/pkg/context) 文档指导开发者 +显式传递上下文 `ctx` 作为进程的第一个参数。 -## 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: +`Context` 包含一个 `MultiStore`，它允许使用 `CacheMultiStore` 进行分支和缓存功能 +(`CacheMultiStore` 中的查询被缓存以避免将来的往返)。 +每个“KVStore”都分支在一个安全且隔离的临时存储中。进程可以自由地将更改写入 +`CacheMultiStore`。如果状态转换序列没有问题地执行，存储分支可以 +提交到序列末尾的底层存储，或者在出现某些情况时忽略它们 +出错。 Context 的使用模式如下: -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()`. +1. 一个进程从它的父进程接收一个上下文`ctx`，它提供了需要的信息 + 执行过程。 +2. `ctx.ms` 是一个**分支存储**，即[multistore](./store.md#multistore) 的一个分支，以便进程在执行时可以对状态进行更改，不改变原来的`ctx.ms`。这对于保护底层 multistore 很有用，以防在执行过程中的某个时刻需要恢复更改。 +3. 进程在执行时可能会从 `ctx` 读取和写入。它可能会调用一个子进程并通过 + `ctx` 根据需要添加到它。 +4. 当子进程返回时，它检查结果是成功还是失败。如果失败，什么都没有 + 需要完成 - 分支 `ctx` 被简单地丢弃。如果成功，所做的更改 + `CacheMultiStore` 可以通过 `Write()` 提交给原始的 `ctx.ms`。 -For example, here is a snippet from the [`runTx`](./baseapp.md#runtx-and-runmsgs) function in -[`baseapp`](./baseapp.md): +例如，这里是 [`runTx`](./baseapp.md#runtx-and-runmsgs) 函数的一个片段 +[`baseapp`](./baseapp.md): ```go runMsgCtx, msCache := app.cacheTxContext(ctx, txBytes) @@ -85,16 +85,16 @@ if result.IsOK() { } ``` -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. +1. 在对事务中的消息调用 `runMsgs` 之前，它使用 `app.cacheTxContext()` + 分支和缓存上下文和多存储。 +2. `runMsgCtx` - 带有分支存储的上下文，在 `runMsgs` 中用于返回结果。 +3.如果进程运行在[`checkTxMode`](./baseapp.md#checktx)，则不需要写 + 更改 - 结果立即返回。 +4.如果进程在[`deliverTxMode`](./baseapp.md#delivertx)下运行，结果显示 + 成功运行所有消息后，分支多存储被写回原始。 -## Next {hide} +## 下一个 {hide} -Learn about the [node client](./node.md) {hide} +了解 [节点客户端](./node.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/encoding.md b/docs/ja/core/encoding.md index 3c3f6f822d4b..6c245cb026b3 100644 --- a/docs/ja/core/encoding.md +++ b/docs/ja/core/encoding.md @@ -1,105 +1,105 @@ -# Encoding +# 编码 -While encoding in the Cosmos SDK used to be mainly handled by `go-amino` codec, the Cosmos SDK is moving towards using `gogoprotobuf` for both state and client-side encoding. {synopsis} +虽然 Cosmos SDK 中的编码过去主要由 `go-amino` 编解码器处理，但 Cosmos SDK 正在转向使用 `gogoprotobuf` 进行状态和客户端编码。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} +- [Cosmos SDK 应用剖析](../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). +Cosmos SDK 使用两个二进制线编码协议，[Amino](https://github.com/tendermint/go-amino/) 是一个对象编码规范和 [Protocol Buffers](https://developers.google.com /protocol-buffers)，Proto3 的一个子集，扩展为 +接口支持。请参阅 [Proto3 规范](https://developers.google.com/protocol-buffers/docs/proto3) +有关 Proto3 的更多信息，Amino 在很大程度上兼容(但不兼容 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. +由于 Amino 具有显着的性能缺陷，基于反射，并且 +没有任何有意义的跨语言/客户端支持，协议缓冲区，特别是 +[gogoprotobuf](https://github.com/gogo/protobuf/)，用于代替 Amino。 +请注意，这个在 Amino 上使用 Protocol Buffers 的过程仍然是一个持续的过程。 -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. +Cosmos SDK 中类型的二进制线编码可以分为两个主要的 +类别、客户端编码和存储编码。客户端编码主要围绕 +围绕交易处理和签名，而存储编码围绕 +状态机转换中使用的类型以及最终存储在 Merkle 中的内容 +树。 -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. +对于存储编码，protobuf 定义可以存在于任何类型，并且通常会 +有一个基于氨基的“中介”类型。具体来说，基于protobuf的类型 +定义用于序列化和持久化，而基于氨基的类型 +用于状态机中的业务逻辑，它们可以来回转换。 +请注意，基于氨基的类型可能会在未来逐渐淘汰，因此开发人员 +应注意尽可能使用 protobuf 消息定义。 -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. +在`codec` 包中，存在两个核心接口，`Marshaler` 和`ProtoMarshaler`， +其中前者封装了当前的 Amino 接口，除了它对 +实现后者而不是通用`interface{}` 类型的类型。 -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. +此外，存在两种`Marshaler` 实现。第一个是 +`AminoCodec`，其中二进制和 JSON 序列化都通过 Amino 处理。这 +第二个是 `ProtoCodec`，其中处理二进制和 JSON 序列化 +通过 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 或 Protobuf 编码，但类型必须 +实现`ProtoMarshaler`。如果模块希望避免实现此接口 +对于他们的类型，他们可以直接使用 Amino 编解码器。 ### 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. +每个模块都使用 Amino 编解码器来序列化类型和接口。 这种编解码器通常 +仅在该模块的域中注册了类型和接口(例如消息)， +但也有像 `x/gov` 这样的例外。 每个模块都暴露了一个 `RegisterLegacyAminoCodec` 函数 +允许用户提供编解码器并注册所有类型。 一个应用程序 +将为每个必要的模块调用此方法。 -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: +如果模块没有基于 protobuf 的类型定义(见下文)，Amino +用于将原始线字节编码和解码为具体类型或接口: ```go bz := keeper.cdc.MustMarshal(typeOrInterface) keeper.cdc.MustUnmarshal(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`) +请注意，上述功能存在以长度为前缀的变体，这是 +通常用于数据需要流式传输或分组在一起时 +(例如`ResponseDeliverTx.Data`) ### Gogoproto -Modules are encouraged to utilize Protobuf encoding for their respective types. In the Cosmos SDK, we use the [Gogoproto](https://github.com/gogo/protobuf) specific implementation of the Protobuf spec that offers speed and DX improvements compared to the official [Google protobuf implementation](https://github.com/protocolbuffers/protobuf). +鼓励模块对其各自的类型使用 Protobuf 编码。在 Cosmos SDK 中，我们使用 Protobuf 规范的 [Gogoproto](https://github.com/gogo/protobuf) 特定实现，与官方 [Google protobuf 实现](https:// github.com/protocolbuffers/protobuf)。 -### Guidelines for protobuf message definitions +### protobuf 消息定义指南 -In addition to [following official Protocol Buffer guidelines](https://developers.google.com/protocol-buffers/docs/proto3#simple), we recommend using these annotations in .proto files when dealing with interfaces: +除了[遵循官方协议缓冲区指南](https://developers.google.com/protocol-buffers/docs/proto3#simple)，我们建议在处理接口时在 .proto 文件中使用这些注释: -- use `cosmos_proto.accepts_interface` to annote fields that accept interfaces -- pass the same fully qualified name as `protoName` to `InterfaceRegistry.RegisterInterface` -- annotate interface implementations with `cosmos_proto.implements_interface` -- pass the same fully qualified name as `protoName` to `InterfaceRegistry.RegisterInterface` +- 使用 `cosmos_proto.accepts_interface` 来注释接受接口的字段 +- 将与 `protoName` 相同的完全限定名称传递给 `InterfaceRegistry.RegisterInterface` +- 使用 `cosmos_proto.implements_interface` 注释接口实现 +- 将与 `protoName` 相同的完全限定名称传递给 `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 Cosmos SDK but are then passed to the underlying consensus engine to be relayed to -other peers. Since the underlying consensus engine is agnostic to the application, -the consensus engine accepts only transactions in the form of raw bytes. +Protobuf 的另一个重要用途是编码和解码 +[交易](./transactions.md)。事务由应用程序或 +Cosmos SDK，但随后被传递到底层共识引擎以中继到 +其他同龄人。由于底层共识引擎与应用程序无关， +共识引擎只接受原始字节形式的交易。 -- The `TxEncoder` object performs the encoding. -- The `TxDecoder` object performs the decoding. +- `TxEncoder` 对象执行编码。 +- `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](../../x/auth/spec/README.md): +这两个对象的标准实现可以在 [`auth` 模块](../../x/auth/spec/README.md) 中找到: +++ 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 -See [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md) for details of how a transaction is encoded. +有关交易如何编码的详细信息，请参阅 [ADR-020](../architecture/adr-020-protobuf-transaction-encoding.md)。 -### Interface Encoding and Usage of `Any` +### `Any` 的接口编码和使用 -The Protobuf DSL is strongly typed, which can make inserting variable-typed fields difficult. Imagine we want to create a `Profile` protobuf message that serves as a wrapper over [an account](../basics/accounts.md): +Protobuf DSL 是强类型的，这会使插入变量类型的字段变得困难。想象一下，我们想要创建一个 `Profile` protobuf 消息，作为 [an account](../basics/accounts.md) 的包装器: ```proto message Profile { @@ -110,11 +110,11 @@ message Profile { } ``` -In this `Profile` example, we hardcoded `account` as a `BaseAccount`. However, there are several other types of [user accounts related to vesting](../../x/auth/spec/05_vesting.md), such as `BaseVestingAccount` or `ContinuousVestingAccount`. All of these accounts are different, but they all implement the `AccountI` interface. How would you create a `Profile` that allows all these types of accounts with an `account` field that accepts an `AccountI` interface? +在这个 `Profile` 示例中，我们将 `account` 硬编码为 `BaseAccount`。但是，还有其他几种类型的[与归属相关的用户帐户](../../x/auth/spec/05_vesting.md)，例如“BaseVestingAccount”或“ContinuousVestingAccount”。所有这些帐户都不同，但它们都实现了`AccountI` 接口。您将如何创建一个允许所有这些类型帐户的“个人资料”，其中“帐户”字段接受“帐户I”接口？ +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/auth/types/account.go#L307-L330 -In [ADR-019](../architecture/adr-019-protobuf-state-encoding.md), it has been decided to use [`Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto)s to encode interfaces in protobuf. An `Any` contains an arbitrary serialized message as bytes, along with a URL that acts as a globally unique identifier for and resolves to that message's type. This strategy allows us to pack arbitrary Go types inside protobuf messages. Our new `Profile` then looks like: +在 [ADR-019](../architecture/adr-019-protobuf-state-encoding.md) 中，已决定使用 [`Any`](https://github.com/protocolbuffers/protobuf/blob /master/src/google/protobuf/any.proto)s 在 protobuf 中编码接口。 `Any` 包含一个任意序列化的字节消息，以及一个 URL，该 URL 充当全局唯一标识符并解析为该消息的类型。这种策略允许我们在 protobuf 消息中打包任意 Go 类型。我们的新“配置文件”看起来像: ```protobuf message Profile { @@ -127,7 +127,7 @@ message Profile { } ``` -To add an account inside a profile, we need to "pack" it inside an `Any` first, using `codectypes.NewAnyWithValue`: +要在配置文件中添加帐户，我们需要先将其“打包”到一个“Any”中，使用“codectypes.NewAnyWithValue”: ```go var myAccount AccountI @@ -150,9 +150,9 @@ bz, err := cdc.Marshal(profile) jsonBz, err := cdc.MarshalJSON(profile) ``` -To summarize, to encode an interface, you must 1/ pack the interface into an `Any` and 2/ marshal the `Any`. For convenience, the Cosmos SDK provides a `MarshalInterface` method to bundle these two steps. Have a look at [a real-life example in the x/auth module](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/auth/keeper/keeper.go#L218-L221). +总而言之，要对接口进行编码，您必须 1/ 将接口打包到 `Any` 中，并且 2/ 封送 `Any`。 为方便起见，Cosmos SDK 提供了一个 `MarshalInterface` 方法来捆绑这两个步骤。 看看 [x/auth 模块中的一个真实例子](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/auth/keeper/keeper.go#L218- L221)。 -The reverse operation of retrieving the concrete Go type from inside an `Any`, called "unpacking", is done with the `GetCachedValue()` on `Any`. +从 `Any` 内部检索具体 Go 类型的反向操作称为“解包”，是通过 `Any` 上的 `GetCachedValue()` 完成的。 ```go profileBz := ... // The proto-encoded bytes of a Profile, e.g. retrieved through gRPC. @@ -168,7 +168,7 @@ fmt.Printf("%T\n", myProfile.Account.GetCachedValue()) // Prints "BaseAccount", accAddr := myProfile.Account.GetCachedValue().(AccountI).GetAddress() ``` -It is important to note that for `GetCachedValue()` to work, `Profile` (and any other structs embedding `Profile`) must implement the `UnpackInterfaces` method: +需要注意的是，要让 `GetCachedValue()` 工作，`Profile`(以及任何其他嵌入 `Profile` 的结构)必须实现 `UnpackInterfaces` 方法: ```go func (p *Profile) UnpackInterfaces(unpacker codectypes.AnyUnpacker) error { @@ -181,77 +181,77 @@ func (p *Profile) UnpackInterfaces(unpacker codectypes.AnyUnpacker) error { } ``` -The `UnpackInterfaces` gets called recursively on all structs implementing this method, to allow all `Any`s to have their `GetCachedValue()` correctly populated. +`UnpackInterfaces` 在实现此方法的所有结构上被递归调用，以允许所有 `Any` 正确填充它们的 `GetCachedValue()`。 -For more information about interface encoding, and especially on `UnpackInterfaces` and how the `Any`'s `type_url` gets resolved using the `InterfaceRegistry`, please refer to [ADR-019](../architecture/adr-019-protobuf-state-encoding.md). +有关接口编码的更多信息，尤其是关于`UnpackInterfaces` 以及如何使用`InterfaceRegistry` 解析`Any` 的`type_url`，请参阅[ADR-019](../architecture/adr-019- protobuf-state-encoding.md)。 -#### `Any` Encoding in the Cosmos SDK +#### Cosmos SDK 中的`Any` 编码 -The above `Profile` example is a fictive example used for educational purposes. In the Cosmos SDK, we use `Any` encoding in several places (non-exhaustive list): +上面的“配置文件”示例是一个用于教育目的的虚构示例。在 Cosmos SDK 中，我们在几个地方使用了 `Any` 编码(非详尽列表): -- the `cryptotypes.PubKey` interface for encoding different types of public keys, -- the `sdk.Msg` interface for encoding different `Msg`s in a transaction, -- the `AccountI` interface for encodinig different types of accounts (similar to the above example) in the x/auth query responses, -- the `Evidencei` interface for encoding different types of evidences in the x/evidence module, -- the `AuthorizationI` interface for encoding different types of x/authz authorizations, -- the [`Validator`](https://github.com/cosmos/cosmos-sdk/blob/v0.42.5/x/staking/types/staking.pb.go#L306-L337) struct that contains information about a validator. +- 用于编码不同类型公钥的`cryptotypes.PubKey`接口， +- `sdk.Msg` 接口，用于在交易中编码不同的 `Msg`， +- 用于在 x/auth 查询响应中编码不同类型帐户(类似于上面的示例)的 `AccountI` 接口， +- 用于在 x/evidence 模块中编码不同类型证据的 `Evidencei` 接口， +- 用于对不同类型的 x/authz 授权进行编码的 `AuthorizationI` 接口， +- [`Validator`](https://github.com/cosmos/cosmos-sdk/blob/v0.42.5/x/staking/types/staking.pb.go#L306-L337) 结构包含有关验证器。 -A real-life example of encoding the pubkey as `Any` inside the Validator struct in x/staking is shown in the following example: +以下示例显示了在 x/staking 中的 Validator 结构内将公钥编码为“Any”的真实示例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/staking/types/validator.go#L40-L61 -## FAQ +## 常问问题 -1. How to create modules using protobuf encoding? +1.如何使用protobuf编码创建模块？ -**Defining module types** +**定义模块类型** -Protobuf types can be defined to encode: +可以定义 Protobuf 类型来编码: -- state +- 状态 - [`Msg`s](../building-modules/messages-and-queries.md#messages) -- [Query services](../building-modules/query-services.md) -- [genesis](../building-modules/genesis.md) +- [查询服务](../building-modules/query-services.md) +- [创世](../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) +我们鼓励开发者遵循行业指南:[Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style) +和 [Buf](https://buf.build/docs/style-guide)，请参阅 [ADR 023](../architecture/adr-023-protobuf-naming.md) 中的更多详细信息 -2. How to update modules to protobuf encoding? +2.如何将模块更新为protobuf编码？ -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. +如果模块不包含任何接口(例如`Account` 或`Content`)，那么它们 +可以简单地迁移任何现有类型 +通过其具体的 Amino 编解码器编码并持久化到 Protobuf(有关进一步的指导，请参见 1.)并接受“Marshaler”作为通过“ProtoCodec”实现的编解码器 +无需任何进一步的定制。 -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. +然而，如果一个模块类型组成了一个接口，它必须将它包装在 `skd.Any`(来自 `/types` 包)类型中。为此，模块级 .proto 文件必须使用 [`google.protobuf.Any`](https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto)各自的消息类型接口类型。 -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: +例如，在`x/evidence` 模块中定义了一个`Evidence` 接口，由`MsgSubmitEvidence` 使用。结构定义必须使用`sdk.Any`来包装证据文件。在proto文件中我们定义如下: ```protobuf // proto/cosmos/evidence/v1beta1/tx.proto message MsgSubmitEvidence { - string submitter = 1; - google.protobuf.Any evidence = 2 [(cosmos_proto.accepts_interface) = "Evidence"]; + 字符串提交者 = 1; + google.protobuf.Any evidence = 2 [(cosmos_proto.accepts_interface) = "Evidence"]; } -``` +`` -The Cosmos SDK `codec.Codec` interface provides support methods `MarshalInterface` and `UnmarshalInterface` to easy encoding of state to `Any`. +Cosmos SDK `codec.Codec` 接口提供支持方法 `MarshalInterface` 和 `UnmarshalInterface` 以轻松将状态编码为 `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: +模块应该使用`InterfaceRegistry`注册接口，它提供了一种注册接口的机制:`RegisterInterface(protoName string, iface interface{})`和实现:`RegisterImplementations(iface interface{}, impls ...proto.Message)`可以从 Any 中安全地解压，类似于使用 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: +此外，应该在反序列化中引入一个 `UnpackInterfaces` 阶段，以便在需要它们之前解压接口。直接或通过其成员之一包含 protobuf `Any` 的 Protobuf 类型应该实现 `UnpackInterfacesMessage` 接口: -```go -type UnpackInterfacesMessage interface { - UnpackInterfaces(InterfaceUnpacker) error +```Go +类型 UnpackInterfacesMessage 接口 { + UnpackInterfaces(InterfaceUnpacker) 错误 } -``` +`` -## Next {hide} +## 下一个 {hide} -Learn about [gRPC, REST and other endpoints](./grpc_rest.md) {hide} +了解 [gRPC、REST 和其他端点](./grpc_rest.md) {hide} diff --git a/docs/ja/core/events.md b/docs/ja/core/events.md index aa743d934697..78259d193732 100644 --- a/docs/ja/core/events.md +++ b/docs/ja/core/events.md @@ -1,43 +1,43 @@ -# 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} +`Event`s 是包含有关应用程序执行信息的对象。它们主要被区块浏览器和钱包等服务提供商用来跟踪各种消息和索引交易的执行。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} -- [Tendermint Documentation on Events](https://docs.tendermint.com/master/spec/abci/abci.html#events) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} +- [Tendermint 事件文档](https://docs.tendermint.com/master/spec/abci/abci.html#events) {prereq} -## Events +## 事件 -Events are implemented in the Cosmos SDK as an alias of the ABCI `Event` type and -take the form of: `{eventType}.{attributeKey}={attributeValue}`. +事件在 Cosmos SDK 中作为 ABCI `Event` 类型的别名实现，并且 +采用以下形式:`{eventType}.{attributeKey}={attributeValue}`。 +++ https://github.com/tendermint/tendermint/blob/v0.34.8/proto/tendermint/abci/types.proto#L304-L313 -An Event contains: +一个事件包含: -- A `type` to categorize the Event at a high-level; for example, the Cosmos SDK uses the `"message"` type to filter Events by `Msg`s. -- A list of `attributes` are key-value pairs that give more information about the categorized Event. For example, for the `"message"` type, we can filter Events by key-value pairs using `message.action={some_action}`, `message.module={some_module}` or `message.sender={some_sender}`. +- 一种“类型”，用于在高级别对事件进行分类；例如，Cosmos SDK 使用 `"message"` 类型通过 `Msg` 过滤事件。 +- `attributes` 列表是键值对，提供有关分类事件的更多信息。例如，对于 `"message"` 类型，我们可以使用 `message.action={some_action}`、`message.module={some_module}` 或 `message.sender={some_sender} 通过键值对过滤事件`. -::: tip -To parse the attribute values as strings, make sure to add `'` (single quotes) around each attribute value. +::: 小费 +要将属性值解析为字符串，请确保在每个属性值周围添加 `'`(单引号)。 ::: -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 Protobuf [`Msg` service](../building-modules/msg-services.md) -by using the [`EventManager`](#eventmanager). In addition, each module documents its Events under -`spec/xx_events.md`. +事件，`type` 和 `attributes` 在模块的 **per-module 基础** 定义 +`/types/events.go` 文件，并从模块的 Protobuf [`Msg` 服务](../building-modules/msg-services.md) 触发 +通过使用 [`EventManager`](#eventmanager)。此外，每个模块将其事件记录在 +`spec/xx_events.md`。 -Events are returned to the underlying consensus engine in the response of the following ABCI messages: +事件在以下 ABCI 消息的响应中返回到底层共识引擎: - [`BeginBlock`](./baseapp.md#beginblock) - [`EndBlock`](./baseapp.md#endblock) - [`CheckTx`](./baseapp.md#checktx) - [`DeliverTx`](./baseapp.md#delivertx) -### Examples +### 例子 -The following examples show how to query Events using the Cosmos SDK. +以下示例展示了如何使用 Cosmos SDK 查询事件。 | Event | Description | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -49,21 +49,21 @@ The following examples show how to query Events using the Cosmos SDK. ## 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`. +在 Cosmos SDK 应用程序中，事件由称为“EventManager”的抽象管理。 +在内部，“EventManager”跟踪一个事件的整个执行流程的列表 +交易或`BeginBlock`/`EndBlock`。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/types/events.go#L17-L25 -The `EventManager` comes with a set of useful methods to manage Events. The method -that is used most by module and application developers is `EmitEvent` that tracks -an Event in the `EventManager`. +`EventManager` 带有一组有用的方法来管理事件。 方法 +模块和应用程序开发人员使用最多的是“EmitEvent”，它跟踪 +`EventManager` 中的一个事件。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/types/events.go#L33-L37 -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: +模块开发人员应通过每条消息中的 `EventManager#EmitEvent` 处理事件发射 +`Handler` 和每个 `BeginBlock`/`EndBlock` 处理程序。 `EventManager` 是通过访问 +[`Context`](./context.md)，其中事件发射通常遵循以下模式: ```go ctx.EventManager().EmitEvent( @@ -71,7 +71,7 @@ ctx.EventManager().EmitEvent( ) ``` -Module's `handler` function should also set a new `EventManager` to the `context` to isolate emitted Events per `message`: +模块的 `handler` 函数还应该为 `context` 设置一个新的 `EventManager`，以隔离每个 `message` 发出的事件: ```go func NewHandler(keeper Keeper) sdk.Handler { @@ -80,12 +80,12 @@ func NewHandler(keeper Keeper) sdk.Handler { 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. +有关更详细的信息，请参阅 [`Msg` 服务](../building-modules/msg-services.md) 概念文档 +查看如何典型地实现事件并在模块中使用 `EventManager`。 -## Subscribing to Events +## 订阅事件 -You can use Tendermint's [Websocket](https://docs.tendermint.com/master/tendermint-core/subscription.html#subscribing-to-events-via-websocket) to subscribe to Events by calling the `subscribe` RPC method: +您可以使用 Tendermint 的 [Websocket](https://docs.tendermint.com/master/tendermint-core/subscription.html#subscribing-to-events-via-websocket) 通过调用 `subscribe` RPC 方法订阅 Events : ```json { @@ -98,16 +98,16 @@ You can use Tendermint's [Websocket](https://docs.tendermint.com/master/tendermi } ``` -The main `eventCategory` you can subscribe to are: +您可以订阅的主要`eventCategory`是: -- `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. +- `NewBlock`:包含在`BeginBlock` 和`EndBlock` 期间触发的事件。 +- `Tx`:包含在 `DeliverTx`(即事务处理)期间触发的事件。 +- `ValidatorSetUpdates`:包含块的验证器集更新。 -These Events are triggered from the `state` package after a block is committed. You can get the -full list of Event categories [on the Tendermint Godoc page](https://godoc.org/github.com/tendermint/tendermint/types#pkg-constants). +这些事件是在提交块后从 `state` 包触发的。 你可以得到 +事件类别的完整列表 [在 Tendermint Godoc 页面上](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.go` file of the `bank` module](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/bank/types/events.go)). Subscribing to this Event would be done like so: +`query` 的 `type` 和 `attribute` 值允许您过滤要查找的特定事件。 例如，一个 `transfer` 交易触发了一个类型为 `Transfer` 的 Event，并且将 `Recipient` 和 `Sender` 作为 `attributes`(在 `bank` 模块的 [`events.go` 文件中定义](https ://github.com/cosmos/cosmos-sdk/blob/v0.42.1/x/bank/types/events.go))。 订阅此事件的方式如下: ```json { @@ -120,14 +120,14 @@ The `type` and `attribute` value of the `query` allow you to filter the specific } ``` -where `senderAddress` is an address following the [`AccAddress`](../basics/accounts.md#addresses) format. +其中 `senderAddress` 是遵循 [`AccAddress`](../basics/accounts.md#addresses) 格式的地址。 -## Typed Events (coming soon) +## 类型事件(即将推出) -As previously described, Events are defined on a per-module basis. It is the responsibility of the module developer to define Event types and Event attributes. Except in the `spec/XX_events.md` file, these Event types and attributes are unfortunately not easily discoverable, so the Cosmos SDK proposes to use Protobuf-defined [Typed Events](../architecture/adr-032-typed-events.md) for emitting and querying Events. +如前所述，事件是在每个模块的基础上定义的。 定义事件类型和事件属性是模块开发人员的责任。 除了在`spec/XX_events.md`文件中，遗憾的是这些事件类型和属性不容易被发现，所以Cosmos SDK建议使用Protobuf定义的[Typed Events](../architecture/adr-032-typed-events .md) 用于发出和查询事件。 -The Typed Events proposal has not yet been fully implemented. Documentation is not yet available. +Typed Events 提案尚未完全实施。 文档尚不可用。 -## Next {hide} +## 下一个 {hide} -Learn about Cosmos SDK [telemetry](./telemetry.md) {hide} +了解 Cosmos SDK [遥测](./telemetry.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/grpc_rest.md b/docs/ja/core/grpc_rest.md index f7a84711b8f2..cafd4939bc5a 100644 --- a/docs/ja/core/grpc_rest.md +++ b/docs/ja/core/grpc_rest.md @@ -1,98 +1,98 @@ -# gRPC, REST, and Tendermint Endpoints +# gRPC、REST 和 Tendermint 端点 -This document presents an overview of all the endpoints a node exposes: gRPC, REST as well as some other endpoints. {synopsis} +本文档概述了节点公开的所有端点:gRPC、REST 以及其他一些端点。 {概要} -## 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`). +- gRPC 服务器(默认端口:`9090`)， +- REST 服务器(默认端口:`1317`)， +- Tendermint RPC 端点(默认端口:`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. +::: 小费 +该节点还暴露了一些其他端点，例如 Tendermint P2P 端点，或 [Prometheus 端点](https://docs.tendermint.com/master/nodes/metrics.html#metrics)，这些端点与宇宙 SDK。有关这些端点的更多信息，请参阅 [Tendermint 文档](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html#configuration)。 ::: -## gRPC Server +## 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 Cosmos SDK requires that `go-grpc <=v1.33.2` is installed in your `go.mod`. +::: 警告 +`go-grpc v1.34.0` 中引入的补丁使 gRPC 与 `gogoproto` 库不兼容，导致一些 [gRPC 查询](https://github.com/cosmos/cosmos-sdk/issues/8426) 恐慌。因此，Cosmos SDK 要求在你的 `go.mod` 中安装 `go-grpc <=v1.33.2`。 -To make sure that gRPC is working properly, it is **highly recommended** to add the following line in your application's `go.mod`: +为确保 gRPC 正常工作，**强烈建议**在您的应用程序的 `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. +请参阅 [issue #8392](https://github.com/cosmos/cosmos-sdk/issues/8392) 了解更多信息。 ::: -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 Cosmos 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. +Cosmos SDK v0.40 引入了 Protobuf 作为主要的 [encoding](./encoding) 库，这带来了广泛的基于 Protobuf 的工具，可以插入 Cosmos SDK。其中一个工具是 [gRPC](https://grpc.io)，这是一种现代开源高性能 RPC 框架，具有多种语言的良好客户端支持。 -Each module exposes a [Protobuf `Query` service](../building-modules/messages-and-queries.md#queries) that defines state queries. The `Query` services and a transaction service used to broadcast transactions are hooked up to the gRPC server via the following function inside the application: +每个模块公开一个定义状态查询的 [Protobuf `Query` 服务](../building-modules/messages-and-queries.md#queries)。 `Query` 服务和用于广播交易的交易服务通过应用程序中的以下函数连接到 gRPC 服务器: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-rc0/server/types/app.go#L39-L41 -Note: It is not possible to expose any [Protobuf `Msg` service](../building-modules/messages-and-queries.md#messages) endpoints via gRPC. Transactions must be generated and signed using the CLI or programatically before they can be broadcasted using gRPC. See [Generating, Signing, and Broadcasting Transactions](../run-node/txs.html) for more information. +注意:不可能通过 gRPC 公开任何 [Protobuf `Msg` 服务](../building-modules/messages-and-queries.md#messages) 端点。交易必须使用 CLI 或以编程方式生成和签名，然后才能使用 gRPC 进行广播。有关详细信息，请参阅 [生成、签名和广播事务](../run-node/txs.html)。 -The `grpc.Server` is a concrete gRPC server, which spawns and serves all gRPC query requests and a broadcast transaction request. This server can be configured inside `~/.simapp/config/app.toml`: +`grpc.Server` 是一个具体的 gRPC 服务器，它产生并服务所有 gRPC 查询请求和广播事务请求。这个服务器可以在`~/.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`. +- `grpc.enable = true|false` 字段定义是否应启用 gRPC 服务器。默认为“真”。 +- `grpc.address = {string}` 字段定义了服务器应该绑定到的地址(实际上是端口，因为主机应该保持在 `0.0.0.0`)。默认为`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}`. +:::小费 +`~/.simapp` 是存储节点配置和数据库的目录。默认情况下，它设置为`~/.{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. +一旦 gRPC 服务器启动，您就可以使用 gRPC 客户端向它发送请求。我们的 [与节点交互](../run-node/interact-node.md#using-grpc) 教程中给出了一些示例。 -An overview of all available gRPC endpoints shipped with the Cosmos SDK is [Protobuf documention](./proto-docs.md). +Cosmos SDK 附带的所有可用 gRPC 端点的概述是 [Protobuf 文档](./proto-docs.md)。 -## REST Server +## REST 服务器 -Cosmos SDK supports REST routes via gRPC-gateway. +Cosmos SDK 通过 gRPC 网关支持 REST 路由。 -All routes are configured under the following fields in `~/.simapp/config/app.toml`: +所有路由都在`~/.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. +- `api.enable = true|false` 字段定义是否应该启用 REST 服务器。默认为“假”。 +- `api.address = {string}` 字段定义了服务器应该绑定到的地址(实际上是端口，因为主机应该保持在 `0.0.0.0`)。默认为`tcp://0.0.0.0:1317`。 +- 在`~/.simapp/config/app.toml`中定义了一些额外的API配置选项，以及注释，请直接参考该文件。 -### gRPC-gateway REST Routes +### gRPC 网关 REST 路由 -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 Cosmos SDK offers REST routes via gRPC-gateway. +如果由于各种原因您无法使用 gRPC(例如，您正在构建一个 Web 应用程序，并且浏览器不支持构建 gRPC 的 HTTP2)，那么 Cosmos SDK 将通过 gRPC 网关提供 REST 路由。 -[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) is a tool to expose gRPC endpoints as REST endpoints. For each gRPC endpoint defined in a Protobuf `Query` service, the Cosmos SDK offers a REST equivalent. For instance, querying a balance could be done via the `/cosmos.bank.v1beta1.QueryAllBalances` 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 `Query` service, the corresponding REST endpoint is defined as an option: +[gRPC-gateway](https://grpc-ecosystem.github.io/grpc-gateway/) 是一种将 gRPC 端点公开为 REST 端点的工具。对于 Protobuf `Query` 服务中定义的每个 gRPC 端点，Cosmos SDK 提供了一个 REST 等价物。例如，查询余额可以通过 `/cosmos.bank.v1beta1.QueryAllBalances` gRPC 端点完成，或者通过 gRPC 网关 `"/cosmos/bank/v1beta1/balances/{address}"` REST 端点完成:两者都将返回相同的结果。对于 Protobuf `Query` 服务中定义的每个 RPC 方法，相应的 REST 端点被定义为一个选项: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.41.0/proto/cosmos/bank/v1beta1/query.proto#L19-L22 -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. +对于应用程序开发人员，gRPC 网关 REST 路由需要连接到 REST 服务器，这是通过调用 ModuleManager 上的 `RegisterGRPCGatewayRoutes` 函数来完成的。 ### 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. +[Swagger](https://swagger.io/)(或 OpenAPIv2)规范文件在 API 服务器上的 `/swagger` 路由下公开。 Swagger 是一个开放规范，描述了服务器所服务的 API 端点，包括描述、输入参数、返回类型以及关于每个端点的更多信息。 -Enabling the `/swagger` endpoint is configurable inside `~/.simapp/config/app.toml` via the `api.swagger` field, which is set to true by default. +启用 `/swagger` 端点可以通过 `api.swagger` 字段在 `~/.simapp/config/app.toml` 中进行配置，默认情况下该字段设置为 true。 -For application developers, you may want to generate your own Swagger definitions based on your custom modules. The Cosmos 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. +对于应用程序开发人员，您可能希望基于自定义模块生成自己的 Swagger 定义。 Cosmos SDK 的 [Swagger 生成脚本](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc4/scripts/protoc-swagger-gen.sh) 是一个很好的起点。 ## 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/). +独立于 Cosmos SDK，Tendermint 还公开了一个 RPC 服务器。这个RPC服务器可以通过`~/.simapp/config/config.toml`中`rpc`表下的参数调优来配置，默认监听地址是`tcp://0.0.0.0:26657`。 [此处](https://docs.tendermint.com/master/rpc/) 提供了所有 Tendermint RPC 端点的 OpenAPI 规范。 -Some Tendermint RPC endpoints are directly related to the Cosmos SDK: +一些 Tendermint RPC 端点与 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.QueryAllBalances`. 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. +- `/abci_query`:此端点将查询应用程序的状态。作为 `path` 参数，您可以发送以下字符串: + - 任何 Protobuf 完全限定的服务方法，例如`/cosmos.bank.v1beta1.QueryAllBalances`。 `data` 字段应该包含使用 Protobuf 编码为字节的方法的请求参数。 + - `/app/simulate`:这将模拟一个交易，并返回一些信息，例如使用的gas。 + - `/app/version`:这将返回应用程序的版本。 + - `/store/{path}`:这将直接查询存储。 + - `/p2p/filter/addr/{port}`:这将通过地址端口返回节点的 P2P 对等点的过滤列表。 + - `/p2p/filter/id/{id}`:这将根据 ID 返回节点的 P2P 对等点的过滤列表。 +- `/broadcast_tx_{aync,async,commit}`:这 3 个端点将向其他对等点广播交易。 CLI、gRPC 和 REST 公开了[一种广播交易的方法](./transactions.md#broadcasting-the-transaction)，但它们都在幕后使用了这 3 个 Tendermint RPC。 -## Comparison Table +## 比较表 | Name | Advantages | Disadvantages | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | @@ -100,6 +100,6 @@ Some Tendermint RPC endpoints are directly related to the Cosmos SDK: | 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} +## 下一个 {hide} -Learn about [the CLI](./cli.md) {hide} +了解 [CLI](./cli.md) {hide} diff --git a/docs/ja/core/node.md b/docs/ja/core/node.md index 04775f5d091d..71e0cfa5a6ed 100644 --- a/docs/ja/core/node.md +++ b/docs/ja/core/node.md @@ -1,32 +1,32 @@ -# Node Client (Daemon) +# 节点客户端(守护进程) -The main endpoint of a Cosmos 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} +Cosmos SDK 应用程序的主要端点是守护程序客户端，也称为全节点客户端。全节点运行状态机，从创世文件开始。它连接到运行相同客户端的对等点，以接收和中继交易、区块提案和签名。全节点由使用 Cosmos SDK 定义的应用程序和通过 ABCI 连接到应用程序的共识引擎组成。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq} +- [SDK 应用剖析](../basics/app-anatomy.md) {prereq} -## `main` function +## `main` 函数 -The full-node client of any Cosmos 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. +任何 Cosmos SDK 应用程序的全节点客户端都是通过运行 `main` 函数来构建的。客户端通常通过在应用程序名称后附加`-d` 后缀来命名(例如`appd` 用于名为`app` 的应用程序)，并且`main` 函数定义在`./appd/cmd/main 中。去`文件。运行此函数会创建一个带有一组命令的可执行文件“appd”。对于名为`app`的应用程序，主要命令是[`appd start`](#start-command)，它启动全节点。 -In general, developers will implement the `main.go` function with the following structure: +一般情况下，开发者会用以下结构实现`main.go`函数: -- First, an [`appCodec`](./encoding.md) is instantiated for the application. -- Then, the `config` is retrieved and config parameters are set. This mainly involves setting the Bech32 prefixes for [addresses](../basics/accounts.md#addresses). +- 首先，为应用程序实例化一个 [`appCodec`](./encoding.md)。 +- 然后，检索`config`并设置配置参数。这主要涉及为 [addresses](../basics/accounts.md#addresses) 设置 Bech32 前缀。 +++ 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 Cosmos SDK level. They should be shared by all Cosmos SDK-based applications. They include the most important command: the [`start` command](#start-command). -- Prepare and execute the `executor`. +- 使用[cobra](https://github.com/spf13/cobra)，创建全节点客户端的root命令。之后，使用`rootCmd`的`AddCommand()`方法添加应用程序的所有自定义命令。 +- 使用 `server.AddCommands()` 方法将默认服务器命令添加到 `rootCmd`。这些命令与上面添加的命令分开，因为它们是标准的并在 Cosmos SDK 级别定义。它们应该由所有基于 Cosmos SDK 的应用程序共享。它们包括最重要的命令:[`start` 命令](#start-command)。 +- 准备并执行`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 Cosmos SDK's application for demo purposes: +请参阅“simapp”应用程序中的“main”函数示例，用于演示目的的 Cosmos SDK 应用程序: -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/simapp/simd/main.go ++++ 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: +`start` 命令定义在 Cosmos SDK 的 `/server` 文件夹中。 它被添加到 [`main` 函数](#main-function) 中的全节点客户端的 root 命令中，并由最终用户调用以启动他们的节点: ```bash # For an example app named "app", the following command starts the full-node. @@ -36,37 +36,37 @@ appd start 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. +提醒一下，全节点由三个概念层组成:网络层、共识层和应用层。前两个通常捆绑在一个称为共识引擎(默认为 Tendermint Core)的实体中，而第三个是在 Cosmos SDK 的帮助下定义的状态机。目前，Cosmos SDK 使用 Tendermint 作为默认共识引擎，这意味着执行 start 命令来启动 Tendermint 节点。 -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. +`start` 命令的流程非常简单。首先，它从`context` 中检索`config` 以打开`db`(默认为[`leveldb`](https://github.com/syndtr/goleveldb) 实例)。这个 `db` 包含应用程序的最新已知状态(如果应用程序从第一次启动，则为空。 -With the `db`, the `start` command creates a new instance of the application using an `appCreator` function: +使用 `db`，`start` 命令使用 `appCreator` 函数创建应用程序的新实例: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/server/start.go#L227-L228 -Note that an `appCreator` is a function that fulfills the `AppCreator` signature: +请注意，`appCreator` 是一个满足 `AppCreator` 签名的函数: +++ 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`. +在实践中，[应用程序的构造函数](../basics/app-anatomy.md#constructor-function) 作为`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: +然后，`app` 的实例用于实例化一个新的 Tendermint 节点: +++ 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. +Tendermint节点可以用`app`创建，因为后者满足[`abci.Application`接口](https://github.com/tendermint/tendermint/blob/v0.34.0/abci/types/application.go# L7-L32)(假设 `app` 扩展了 [`baseapp`](./baseapp.md))。作为“NewNode”方法的一部分，Tendermint 确保应用程序的高度(即自创世以来的块数)等于 Tendermint 节点的高度。这两个高度之间的差值应始终为负值或为零。如果严格为负，`NewNode` 将重放区块，直到应用程序的高度达到 Tendermint 节点的高度。最后，如果应用程序的高度为`0`，Tendermint 节点将调用应用程序上的[`InitChain`](./baseapp.md#initchain) 以从创世文件中初始化状态。 -Once the Tendermint node is instanciated and in sync with the application, the node can be started: +一旦 Tendermint 节点被实例化并与应用程序同步，就可以启动该节点: +++ 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. +启动后，节点将引导其 RPC 和 P2P 服务器并开始拨号。在与对等方握手期间，如果节点意识到他们领先，它将顺序查询所有块以赶上。然后，它将等待来自验证者的新区块提议和区块签名以取得进展。 -## 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. +要了解如何具体运行节点并与之交互，请参阅我们的 [运行节点、API 和 CLI](../run-node/README.md) 指南。 -## Next {hide} +## 下一个 {hide} -Learn about the [store](./store.md) {hide} +了解 [store](./store.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/ocap.md b/docs/ja/core/ocap.md index c3cca32476b8..acd2a8494b31 100644 --- a/docs/ja/core/ocap.md +++ b/docs/ja/core/ocap.md @@ -2,74 +2,74 @@ ## 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. +> 我们假设一个繁荣的 Cosmos SDK 模块生态系统很容易组合成区块链应用程序，将包含有缺陷或恶意的模块。 -The Cosmos SDK is designed to address this threat by being the -foundation of an object capability system. +Cosmos SDK 旨在通过成为 +对象能力系统的基础。 -> 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." +> 1. 只有当对象 A 持有一个对象 A 才能向 B 发送消息 +> 参考 B。 +> 2.对象A只能获得对C的引用 +> 如果对象 A 收到一条包含对 C 的引用的消息。作为 +> 这两条规则的结果，一个对象可以获得一个引用 +> 只能通过预先存在的引用链到另一个对象。 +> 简而言之，“只有连通性才会产生连通性。” -For an introduction to object-capabilities, see this [Wikipedia article](https://en.wikipedia.org/wiki/Object-capability_model). +有关对象功能的介绍，请参阅此 [维基百科文章](https://en.wikipedia.org/wiki/Object-capability_model)。 -## Ocaps in practice +## 实践中的 Ocaps -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)}, +```Go +输入 AppAccount 结构 {...} +帐户 := &AppAccount{ + 地址:pub.Address(), + 硬币:sdk.Coins{sdk.NewInt64Coin("ATM", 100)}, } -sumValue := externalModule.ComputeSumValue(account) -``` +sumValue := externalModule.ComputeSumValue(账户) +`` -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. +`ComputeSumValue` 方法隐含了一个纯函数，但隐含的 +接受指针值的能力是修改该值的能力 +价值。首选方法签名应改为副本。 ```go sumValue := externalModule.ComputeSumValue(*account) ``` -In the Cosmos SDK, you can see the application of this principle in the -gaia app. +在 Cosmos SDK 中，可以看到这个原理的应用 +盖亚应用程序。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.41.4/simapp/app.go#L249-L273 -The following diagram shows the current dependencies between keepers. +下图显示了 Keeper 之间的当前依赖关系。 -![Keeper dependencies](../uml/svg/keeper_dependencies.svg) +![Keeper 依赖项](../uml/svg/keeper_dependencies.svg) -## Next {hide} +## 下一个 {hide} -Learn about the [`runTx` middleware](./runtx_middleware.md) {hide} +了解 [`runTx` 中间件](./runtx_middleware.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/runtx_middleware.md b/docs/ja/core/runtx_middleware.md index 7edf5e74e75e..fa1df148f0bf 100644 --- a/docs/ja/core/runtx_middleware.md +++ b/docs/ja/core/runtx_middleware.md @@ -1,37 +1,37 @@ -# RunTx recovery middleware +# RunTx 恢复中间件 -`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 Cosmos SDK application developers. +`BaseApp.runTx()` 函数处理在事务执行过程中可能发生的 Golang 恐慌，例如，keeper 面临无效状态并出现恐慌。 +根据恐慌类型使用不同的处理程序，例如默认的一个打印错误日志消息。 +恢复中间件用于为 Cosmos SDK 应用程序开发人员添加自定义紧急恢复。 -More context could be found in the corresponding [ADR-022](../architecture/adr-022-custom-panic-handling.md). +更多上下文可以在相应的 [ADR-022](../architecture/adr-022-custom-panic-handling.md) 中找到。 -Implementation could be found in the [recovery.go](../../baseapp/recovery.go) file. +可以在 [recovery.go](../../baseapp/recovery.go) 文件中找到实现。 -## Interface +## 界面 ```go type RecoveryHandler func(recoveryObj interface{}) error ``` -`recoveryObj` is a return value for `recover()` function from the `buildin` Golang package. +`recoveryObj` 是 `buildin` Golang 包中 `recover()` 函数的返回值。 -**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; +- 如果 `recoveryObj` 没有被处理并且应该传递给下一个恢复中间件，RecoveryHandler 返回 `nil`； +- 如果处理了 `recoveryObj`，RecoveryHandler 返回一个非零的 `error`； -## Custom RecoveryHandler register +##自定义RecoveryHandler注册 `BaseApp.AddRunTxRecoveryHandler(handlers ...RecoveryHandler)` -BaseApp method adds recovery middleware to the default recovery chain. +BaseApp 方法将恢复中间件添加到默认恢复链中。 -## 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{}) { @@ -43,7 +43,7 @@ func (k FooKeeper) Do(obj interface{}) { } ``` -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: +默认情况下，恐慌会被恢复，错误信息将被打印到日志中。 要覆盖该行为，我们应该注册一个自定义 RecoveryHandler: ```go // Cosmos SDK application constructor @@ -64,6 +64,6 @@ baseApp := baseapp.NewBaseApp(...) baseApp.AddRunTxRecoveryHandler(customHandler) ``` -## Next {hide} +## 下一个 {hide} -Learn about the [IBC](./../ibc/README.md) protocol {hide} +了解 [IBC](./../ibc/README.md) 协议 {hide} diff --git a/docs/ja/core/simulation.md b/docs/ja/core/simulation.md index fe1db23833a9..eea587c5c02c 100644 --- a/docs/ja/core/simulation.md +++ b/docs/ja/core/simulation.md @@ -1,65 +1,65 @@ -# Cosmos Blockchain Simulator - -The Cosmos SDK offers a full fledged simulation framework to fuzz test every -message defined by a module. - -On the Cosmos 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`). +# Cosmos 区块链模拟器 + +Cosmos SDK 提供了一个完整的模拟框架来模糊测试每个 +由模块定义的消息。 + +在 Cosmos SDK 上，此功能由 [`SimApp`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/app.go) 提供，它是一个 +用于运行 [`simulation`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation) 模块的 `Baseapp` 应用程序。 +该模块定义了所有的仿真逻辑以及操作 +随机参数，如账户、余额等。 + +##目标 + +区块链模拟器测试区块链应用程序在以下情况下的行为方式 +通过生成和发送随机消息来实现现实生活环境。 +这样做的目的是检测和调试可能导致活动链停止的故障， +通过提供有关模拟器运行的操作的日志和统计信息作为 +以及在发现故障时导出最新的应用程序状态。 + +它与集成测试的主要区别在于模拟器应用程序允许 +您可以传递参数来自定义正在模拟的链。 +这在尝试重现生成的错误时会派上用场 +提供的操作(随机与否)。 + +## 模拟命令 + +模拟应用程序有不同的命令，每个命令测试不同的 +故障类型: + +- `AppImportExport`:模拟器导出初始应用程序状态，然后它 + 使用导出的“genesis.json”作为输入创建一个新应用程序，检查 + 存储之间的不一致。 +- `AppSimulationAfterImport`:将两个模拟排在一起。第一个向第二个提供应用程序状态(_i.e_ genesis)。用于测试来自实时链的软件升级或硬分叉。 +- `AppStateDeterminism`:检查所有节点是否以相同的顺序返回相同的值。 +- `BenchmarkInvariants`:分析运行所有模块的不变量的性能(_i.e_ 顺序运行 [benchmark](https://golang.org/pkg/testing/#hdr-Benchmarks) 测试)。不变式检查 + 存储和被动跟踪器上的值之间的差异。例如:账户持有的总代币与总供应跟踪器。 +- `FullAppSimulation`:通用模拟模式。为给定数量的块运行链和指定的操作。测试模拟中没有“恐慌”。它还对每个“Period”运行不变检查，但它们没有进行基准测试。 + +每个模拟必须接收一组输入(_i.e_ 标志)，例如 +运行模拟的块、种子、块大小等。 +检查标志的完整列表 [此处](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/simapp/config.go#L32-L55)。 + +## 模拟器模式 + +除了各种输入和命令外，模拟器还以三种模式运行: + +1. 初始状态、模块参数和仿真完全随机 + 参数是**伪随机生成的**。 +2. 来自定义初始状态和模块参数的 `genesis.json` 文件。 + 此模式有助于在已知状态下运行模拟，例如需要测试应用程序的新(很可能是破坏性的)版本的实时网络导出。 +3. 来自`params.json` 文件，其中初始状态是伪随机生成的，但可以手动提供模块和模拟参数。 + 这允许更可控和确定性的模拟设置，同时允许状态空间仍然是伪随机模拟的。 + 可用参数列表在 [here](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/simulation/params.go#L44-L52) 中列出。 + +::: 小费 +这些模式并不相互排斥。所以你可以例如随机运行 +生成的创世状态(`1`)和手动生成的模拟参数(`3`)。 ::: -## Usage +## 用法 -This is a general example of how simulations are run. For more specific examples -check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/Makefile#L251-L287). +这是模拟运行方式的一般示例。更具体的例子 +检查 Cosmos 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 \ @@ -68,30 +68,30 @@ check the Cosmos SDK [Makefile](https://github.com/cosmos/cosmos-sdk/blob/v0.40. -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 Cosmos SDK-based application - -Learn how you can integrate the simulation into your Cosmos SDK-based application: - -- Application Simulation Manager -- [Building modules: Simulator](../building-modules/simulator.md) -- Simulator tests +## 调试技巧 + +以下是遇到模拟失败时的一些建议: + +- 在发现失败的高度导出应用程序状态。你可以这样做 + 通过将 `-ExportStatePath` 标志传递给模拟器。 +- 使用`-Verbose` 日志。他们可以为您提供有关所有操作的更好提示 + 涉及。 +- 减少模拟`-Period`。这将运行不变量检查更多 + 频繁地。 +- 使用 `-PrintAllInvariants` 一次性打印所有失败的不变量。 +- 尝试使用另一个 `-Seed`。如果它可以重现相同的错误并且失败 + 您将花更少的时间运行模拟。 +- 减少`-NumBlocks`。应用程序在之前高度的状态如何 + 失败？ +- 使用 `-SimulateEveryOperation` 在每个操作上运行不变量。 _注意_:这个 + 会减慢你的模拟**很多**。 +- 尝试将日志添加到未记录的操作中。你必须定义一个 + [记录器](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/x/staking/keeper/keeper.go#L66-L69) 在你的“Keeper”上。 + +## 在基于 Cosmos SDK 的应用程序中使用模拟 + +了解如何将模拟集成到基于 Cosmos SDK 的应用程序中: + +- 应用仿真经理 +- [建筑模块:模拟器](../building-modules/simulator.md) +- 模拟器测试 \ No newline at end of file diff --git a/docs/ja/core/store.md b/docs/ja/core/store.md index 1263e1b2ec7e..ddab41a7dc9c 100644 --- a/docs/ja/core/store.md +++ b/docs/ja/core/store.md @@ -1,14 +1,14 @@ -# Store +#存储 -A store is a data structure that holds the state of the application. {synopsis} +存储是保存应用程序状态的数据结构。 {概要} -### Pre-requisite Readings +### 先决条件阅读 -- [Anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} -## Introduction to Cosmos SDK Stores +## Cosmos SDK存储介绍 -The Cosmos SDK comes with a large set of stores to persist the state of applications. By default, the main store of Cosmos 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. +Cosmos SDK 附带了大量存储来持久化应用程序的状态。 默认情况下，Cosmos SDK 应用程序的主存储是一个“multistore”，即存储的存储。 开发人员可以根据他们的应用程序需求将任意数量的键值存储添加到多存储中。 multistore 的存在是为了支持 Cosmos SDK 的模块化，因为它允许每个模块声明和管理自己的状态子集。 多存储中的键值存储只能通过特定的能力`key`访问，该能力通常保存在声明存储的模块的[`keeper`](../building-modules/keeper.md)中。 ``` +-----------------------------------------------------+ @@ -50,204 +50,204 @@ The Cosmos SDK comes with a large set of stores to persist the state of applicat 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: +在其核心，Cosmos SDK `store` 是一个对象，它包含一个 `CacheWrapper` 并具有一个 `GetStoreType()` 方法: +++ 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: +`GetStoreType` 是一个返回存储类型的简单方法，而一个 `CacheWrapper` 是一个简单的接口，它通过 `Write` 方法实现存储读取缓存和写入分支: +++ 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) +分支和缓存在 Cosmos SDK 中无处不在，并且需要在每种存储类型上实现。一个存储分支创建一个隔离的、临时的存储分支，可以在不影响主要底层存储的情况下传递和更新。这用于触发临时状态转换，如果发生错误，可以稍后恢复。在 [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`: +提交存储是一种能够提交对底层树或数据库所做更改的存储。 Cosmos SDK 通过使用 `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: +`Committer` 是一个接口，它定义了将更改持久化到磁盘的方法: +++ 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`. +`CommitID` 是状态树的确定性提交。它的哈希值返回到底层的共识引擎并存储在块头中。请注意，提交存储接口有多种用途，其中之一是确保不是每个对象都可以提交存储。作为 Cosmos SDK 的 [object-capabilities 模型](./ocap.md) 的一部分，只有 `baseapp` 应该具有提交存储的能力。例如，这就是为什么模块通常用来访问存储的 `ctx.KVStore()` 方法返回一个 `KVStore` 而不是 `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. +Cosmos SDK 提供了多种存储类型，最常用的是 [`CommitMultiStore`](#multistore)、[`KVStore`](#kvstore) 和 [`GasKv` store](#gaskv-store)。 [其他类型的存储](#other-stores) 包括`Transient` 和`TraceKV` 存储。 -## 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: +每个 Cosmos SDK 应用程序都在其根部拥有一个多存储以保持其状态。 multistore 是一个遵循 `Multistore` 接口的 `KVStores` 存储: +++ 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). +如果启用了跟踪，那么分支 multistore 将首先将所有底层的 `KVStore` 包装在 [`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: +Cosmos SDK 中使用的`Multistore` 的主要类型是`CommitMultiStore`，它是`Multistore` 接口的扩展: +++ 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. +至于具体实现，[`rootMulti.Store`] 是 `CommitMultiStore` 接口的首选实现。 +++ 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). +`rootMulti.Store` 是一个围绕 `db` 构建的基础层多存储，其上可以安装多个 `KVStores`，并且是 [`baseapp`](./baseapp.md) 中使用的默认多存储存储. -### CacheMultiStore +### CacheMultiStore -Whenever the `rootMulti.Store` needs to be branched, a [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/store/cachemulti/store.go) is used. +每当 `rootMulti.Store` 需要分支时，一个 [`cachemulti.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.42.1/store/cachemulti/store.go) 是用过的。 +++ 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 caches all read queries. `Store.GetKVStore()` returns the store from `Store.stores`, and `Store.Write()` recursively calls `CacheWrap.Write()` on all the substores. +`cachemulti.Store` 在其构造函数中分支所有子存储(为每个子存储创建一个虚拟存储)并将它们保存在 `Store.stores` 中。此外缓存所有读取查询。 `Store.GetKVStore()` 从`Store.stores` 返回存储，并且`Store.Write()` 在所有子存储上递归调用`CacheWrap.Write()`。 -## Base-layer KVStores +## 基础层 KVStores -### `KVStore` and `CommitKVStore` Interfaces +### `KVStore` 和 `CommitKVStore` 接口 -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. +`KVStore` 是一个简单的键值存储，用于存储和检索数据。 `CommitKVStore` 是一个也实现了 `Committer` 的 `KVStore`。默认情况下，安装在`baseapp` 的主`CommitMultiStore` 中的存储是`CommitKVStore`。 `KVStore` 接口主要用于限制模块访问提交者。 -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. +模块使用单个“KVStore”来管理全局状态的子集。 `KVStores` 可以被持有特定键的对象访问。这个`key` 应该只暴露给定义存储的模块的 [`keeper`](../building-modules/keeper.md)。 -`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. +`CommitKVStore`s 由它们各自的 `key` 代理声明，并安装在应用程序的 [multistore](#multistore) 上的[主应用程序文件](../basics/app-anatomy.md#core-application-file )。在同一个文件中，`key` 也被传递给负责管理 store 的模块的 `keeper`。 +++ 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: +除了传统的`Get` 和`Set` 方法，`KVStore` 必须提供一个`Iterator(start, end)` 方法，该方法返回一个`Iterator` 对象。它用于迭代一系列键，通常是共享公共前缀的键。以下是银行模块 keeper 的示例，用于迭代所有帐户余额: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/x/bank/keeper/view.go#L115-L134 -### `IAVL` Store +### `IAVL`存储 -The default implementation of `KVStore` and `CommitKVStore` used in `baseapp` is the `iavl.Store`. +`baseapp` 中使用的 `KVStore` 和 `CommitKVStore` 的默认实现是 `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: +`iavl`存储基于 [IAVL 树](https://github.com/tendermint/iavl)，这是一种自平衡二叉树，可保证: -- `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). +- `Get` 和 `Set` 操作的复杂度为 O(log n)，其中 n 是树中元素的数量。 +- 迭代有效地返回范围内的排序元素。 +- 每个树版本都是不可变的，即使在提交后也可以检索(取决于修剪设置)。 -The documentation on the IAVL Tree is located [here](https://github.com/cosmos/iavl/blob/v0.15.0-rc5/docs/overview.md). +关于 IAVL 树的文档位于 [此处](https://github.com/cosmos/iavl/blob/v0.15.0-rc5/docs/overview.md)。 -### `DbAdapter` Store +### `DbAdapter` 存储 -`dbadapter.Store` is a adapter for `dbm.DB` making it fulfilling the `KVStore` interface. +`dbadapter.Store` 是 `dbm.DB` 的适配器，使其实现 `KVStore` 接口。 +++ 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) +`dbadapter.Store` 嵌入了 `dbm.DB`，这意味着大部分 `KVStore` 接口功能都已实现。其他功能(主要是杂项)是手动实现的。此存储主要用于 [Transient Stores](#transient-stores) -### `Transient` Store +### `瞬态`存储 -`Transient.Store` is a base-layer `KVStore` which is automatically discarded at the end of the block. +`Transient.Store` 是一个基础层 `KVStore`，它在块的末尾被自动丢弃。 +++ 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. +`Transient.Store` 是一个带有 `dbm.NewMemDB()` 的 `dbadapter.Store`。所有`KVStore` 方法都被重用。当调用`Store.Commit()` 时，会分配一个新的`dbadapter.Store`，丢弃之前的引用并使其垃圾回收。 -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). +这种类型的存储对于保留仅与每个块相关的信息很有用。一个例子是存储参数更改(即，如果块中的参数发生更改，则将 bool 设置为“true”)。 +++ 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: +瞬态存储通常通过 [`context`](./context.md) 通过 `TransientStore()` 方法访问: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/types/context.go#L232-L235 -## KVStore Wrappers +## KVStore 包装器 ### CacheKVStore -`cachekv.Store` is a wrapper `KVStore` which provides buffered writing / cached reading functionalities over the underlying `KVStore`. +`cachekv.Store` 是一个包装器 `KVStore`，它在底层 `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). +每当需要分支 IAVL 存储以创建隔离存储时(通常当我们需要改变可能会在以后恢复的状态时)，就会使用这种类型。 -#### `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. +`Store.Get()` 首先检查 `Store.cache` 是否具有与键相关联的值。如果该值存在，则函数返回它。如果没有，该函数调用`Store.parent.Get()`，将结果缓存在`Store.cache`中，并返回它。 -#### `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()` caches a new pair, the `cValue.dirty` is set `true` so when `Store.Write()` is called it can be written to the underlying store. +`Store.Set()` 将键值对设置为 `Store.cache`。 `cValue` 具有字段dirty bool，指示缓存值是否与底层值不同。当`Store.Set()`缓存一个新对时，`cValue.dirty`被设置为`true`，所以当`Store.Write()`被调用时，它可以被写入底层存储。 -#### `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. +`Store.Iterator()` 必须遍历缓存项和原始项。在`Store.iterator()` 中，为每个迭代器生成两个迭代器，并合并。 `memIterator` 本质上是 `KVPairs` 的一部分，用于缓存项。 `mergeIterator` 是两个迭代器的组合，遍历是在两个迭代器上有序进行的。 -### `GasKv` Store +### `GasKv`存储 -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. +Cosmos SDK 应用程序使用 [`gas`](../basics/gas-fees.md) 来跟踪资源使用情况并防止垃圾邮件。 [`GasKv.Store`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/store/gaskv/store.go) 是一个 `KVStore` 包装器，可以自动消耗每个 Gas读取或写入存储的时间。它是在 Cosmos SDK 应用程序中跟踪存储使用情况的首选解决方案。 +++ 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`: +当父`KVStore`的方法被调用时，`GasKv.Store`会根据`Store.gasConfig`自动消耗适量的gas: +++ 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): +默认情况下，所有 `KVStores` 在检索时都包含在 `GasKv.Stores` 中。这是在 [`context`](./context.md) 的 `KVStore()` 方法中完成的: +++ 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`存储 -`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`. +`tracekv.Store` 是一个包装器 `KVStore`，它在底层 `KVStore` 上提供操作跟踪功能。如果在父“MultiStore”上启用跟踪，Cosmos SDK 会自动在所有“KVStore”上应用它。 +++ 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{}`. +当每个 `KVStore` 方法被调用时，`tracekv.Store` 会自动将 `traceOperation` 记录到 `Store.writer`。 `traceOperation.Metadata` 填充为 `Store.context` 当它不为零时。 `TraceContext` 是一个 `map[string]interface{}`。 -### `Prefix` Store +### `Prefix` 存储 -`prefix.Store` is a wrapper `KVStore` which provides automatic key-prefixing functionalities over the underlying `KVStore`. +`prefix.Store` 是一个包装器 `KVStore`，它在底层的 `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`. +当调用`Store.{Get, Set}()` 时，存储将调用转发给其父级，键以`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. +当调用`Store.Iterator()` 时，它不会简单地给`Store.prefix` 加上前缀，因为它不能按预期工作。在这种情况下，即使某些元素不是以前缀开头，也会遍历它们。 -### `ListenKv` Store +### `ListenKv`存储 -`listenkv.Store` is a wrapper `KVStore` which provides state listening capabilities over the underlying `KVStore`. -It is applied automatically by the Cosmos SDK on any `KVStore` whose `StoreKey` is specified during state streaming configuration. -Additional information about state streaming configuration can be found in the [store/streaming/README.md](../../store/streaming/README.md). +`listenkv.Store` 是一个包装器 `KVStore`，它提供了对底层 `KVStore` 的状态监听功能。 +它由 Cosmos SDK 自动应用于任何在状态流配置期间指定了“StoreKey”的“KVStore”。 +有关状态流配置的其他信息可以在 [store/streaming/README.md](../../store/streaming/README.md) 中找到。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.44.1/store/listenkv/store.go#L11-L18 -When `KVStore.Set` or `KVStore.Delete` methods are called, `listenkv.Store` automatically writes the operations to the set of `Store.listeners`. +当调用`KVStore.Set` 或`KVStore.Delete` 方法时，`listenkv.Store` 会自动将操作写入到`Store.listeners` 集合中。 -## New Store package (`store/v2`) +## 新存储包 (`store/v2`) -The SDK is in the process of transitioning to use the types listed here as the default interface for state storage. At the time of writing, these cannot be used within an application and are not directly compatible with the `CommitMultiStore` and related types. +SDK 正在过渡到使用此处列出的类型作为状态存储的默认接口。在撰写本文时，这些无法在应用程序中使用，并且与 `CommitMultiStore` 和相关类型不直接兼容。 -### `BasicKVStore` interface +### `BasicKVStore` 接口 -An interface providing only the basic CRUD functionality (`Get`, `Set`, `Has`, and `Delete` methods), without iteration or caching. This is used to partially expose components of a larger store, such as a `flat.Store`. +仅提供基本 CRUD 功能(`Get`、`Set`、`Has` 和 `Delete` 方法)的接口，没有迭代或缓存。这用于部分公开较大存储的组件，例如`flat.Store`。 -### Flat Store +### 平铺 -`flat.Store` is the new default persistent store, which internally decouples the concerns of state storage and commitment scheme. Values are stored directly in the backing key-value database (the "storage" bucket), while the value's hash is mapped in a separate store which is able to generate a cryptographic commitment (the "state commitment" bucket, implmented with `smt.Store`). +`flat.Store` 是新的默认持久化存储，它在内部解耦了状态存储和承诺方案的关注点。值直接存储在后备键值数据库(“存储”存储桶)中，而值的哈希映射到能够生成加密承诺的单独存储(“状态承诺”存储桶，使用 `smt.存储`)。 -This can optionally be constructed to use different backend databases for each bucket. +这可以选择性地构建为对每个存储桶使用不同的后端数据库。 - + -### SMT Store +### SMT存储 -A `BasicKVStore` which is used to partially expose functions of an underlying store (for instance, to allow access to the commitment store in `flat.Store`). +一个 `BasicKVStore`，用于部分公开底层存储的功能(例如，允许访问 `flat.Store` 中的承诺存储)。 -## Next {hide} +## 下一个 {hide} -Learn about [encoding](./encoding.md) {hide} +了解 [encoding](./encoding.md) {hide} diff --git a/docs/ja/core/telemetry.md b/docs/ja/core/telemetry.md index 2a16578867bc..6558ac678626 100644 --- a/docs/ja/core/telemetry.md +++ b/docs/ja/core/telemetry.md @@ -1,18 +1,18 @@ -# 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`. +Cosmos SDK 使运营商和开发人员能够深入了解 +他们的应用程序通过使用“遥测”包。 Cosmos SDK 目前支持 +启用内存和普罗米修斯作为遥测接收器。 这允许查询和抓取的能力 +来自单个公开 API 端点的指标 -- `/metrics?format={text|prometheus}`，默认值为 +`文本`。 -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. +如果通过配置启用遥测，则通过以下方式注册单个全局指标收集器 +[go-metrics](https://github.com/armon/go-metrics) 库。 这允许发射和收集 +指标通过简单的 API 调用。 -Example: +例子: ```go func EndBlocker(ctx sdk.Context, k keeper.Keeper) { @@ -22,24 +22,24 @@ func EndBlocker(ctx sdk.Context, k keeper.Keeper) { } ``` -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: +开发人员可以直接使用 `telemetry` 包，它提供了指标 API 的包装器 +包括添加有用的标签，或者他们必须直接使用 `go-metrics` 库。 最好 +为度量添加尽可能多的上下文和足够的维度，因此“遥测”包 +建议。 无论使用何种包或方法，Cosmos SDK 都支持以下指标 +类型: -* 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. +模块的某些组件将自动将其名称添加为标签(例如“BeginBlock”)。 +运营商还可以为应用程序提供一组全局标签，这些标签将应用于所有 +使用`telemetry` 包(例如chain-id)发出的指标。 全局标签以列表形式提供 +[名称，值] 元组。 -Example: +例子: ```toml global-labels = [ @@ -47,30 +47,30 @@ global-labels = [ ] ``` -## 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. +开发人员应该注意支持具有足够维度和粒度的指标 +有用，但不会增加超出接收器限制的基数。 一般的经验法则是不要 +超过 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 +* 开始/结束拦截器时间 +* 使用的 TX 气体 +* 使用块气体 +* 铸造的代币数量 +* 创建的帐户数量 -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 | |:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------| diff --git a/docs/ja/core/transactions.md b/docs/ja/core/transactions.md index 773897677b84..6ede416dc2d1 100644 --- a/docs/ja/core/transactions.md +++ b/docs/ja/core/transactions.md @@ -1,112 +1,112 @@ -# Transactions +# 交易 -`Transactions` are objects created by end-users to trigger state changes in the application. {synopsis} +`Transactions` 是由最终用户创建的对象，用于触发应用程序中的状态更改。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} -## Transactions +## 交易 -Transactions are comprised of metadata held in [contexts](./context.md) and [`sdk.Msg`s](../building-modules/messages-and-queries.md) that trigger state changes within a module through the module's Protobuf [`Msg` service](../building-modules/msg-services.md). +事务由保存在 [contexts](./context.md) 和 [`sdk.Msg`s](../building-modules/messages-and-queries.md) 中的元数据组成，这些元数据通过模块的 Protobuf [`Msg` 服务](../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 `sdk.Msg` 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). +当用户想要与应用程序交互并进行状态更改(例如发送硬币)时，他们会创建交易。在将交易广播到网络之前，每个交易的 `sdk.Msg` 都必须使用与适当帐户关联的私钥进行签名。然后，交易必须包含在区块中，通过共识过程由网络进行验证和批准。要阅读有关交易生命周期的更多信息，请单击 [此处](../basics/tx-lifecycle.md)。 -## Type Definition +## 类型定义 -Transaction objects are Cosmos SDK types that implement the `Tx` interface +交易对象是实现了“Tx”接口的 Cosmos SDK 类型 +++ 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 contained `sdk.Msg`s - one transaction may have one or multiple 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 `sdk.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. +- **GetMsgs:** 解包交易并返回包含的 `sdk.Msg` 列表 - 一个交易可能有一个或多个消息，由模块开发人员定义。 +- **ValidateBasic:** 包括 ABCI 消息使用的轻量级 [_stateless_](../basics/tx-lifecycle.md#types-of-checks) 检查 [`CheckTx`](./baseapp.md#checktx)和 [`DeliverTx`](./baseapp.md#delivertx) 以确保交易不是无效的。例如，[`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x/auth) 模块的 `StdTx` `ValidateBasic` 函数检查其交易是否由正确的数字签名签名者的数量，并且费用不超过用户的最高限额。请注意，此函数与用于 sdk.Msg 的 ValidateBasic 函数不同，后者仅对消息执行基本的有效性检查。例如，当 [`runTx`](./baseapp.md#runtx) 正在检查从 [`auth`](https://github.com/cosmos/cosmos-sdk/tree/master/x /auth/spec) 模块，它首先在每条消息上运行 `ValidateBasic`，然后运行 ​​`auth` 模块 AnteHandler，它为交易本身调用 `ValidateBasic`。 -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). +作为开发人员，您应该很少直接操作“Tx”，因为“Tx”实际上是用于生成交易的中间类型。相反，开发人员应该更喜欢 `TxBuilder` 接口，您可以在 [下文](#transaction-generation) 中了解更多信息。 -### Signing Transactions +### 签署交易 -Every message in a transaction must be signed by the addresses specified by its `GetSigners`. The Cosmos SDK currently allows signing transactions in two different ways. +交易中的每条消息都必须由其 `GetSigners` 指定的地址签名。 Cosmos SDK 目前允许以两种不同的方式签署交易。 -#### `SIGN_MODE_DIRECT` (preferred) +#### `SIGN_MODE_DIRECT`(首选) -The most used implementation of the `Tx` interface is the Protobuf `Tx` message, which is used in `SIGN_MODE_DIRECT`: +`Tx` 接口最常用的实现是 Protobuf `Tx` 消息，它在 `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 Cosmos 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)): +由于 Protobuf 序列化不是确定性的，Cosmos SDK 使用额外的“TxRaw”类型来表示交易签名的固定字节。任何用户都可以为交易生成有效的“body”和“auth_info”，并使用 Protobuf 序列化这两条消息。 “TxRaw”然后固定用户的“body”和“auth_info”的精确二进制表示，分别称为“body_bytes”和“auth_info_bytes”。由交易的所有签名者签署的文档是`SignDoc`(使用[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. +一旦由所有签名者签名，`body_bytes`、`auth_info_bytes` 和`signatures` 将被收集到`TxRaw` 中，其序列化字节在网络上广播。 #### `SIGN_MODE_LEGACY_AMINO_JSON` -The legacy implemention of the `Tx` interface is the `StdTx` struct from `x/auth`: +`Tx` 接口的遗留实现是来自 `x/auth` 的 `StdTx` 结构: +++ 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`: +所有签名者签署的文件是`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. +使用 Amino JSON 将其编码为字节。一旦所有签名都被收集到 `StdTx` 中，`StdTx` 就会使用 Amino JSON 进行序列化，并且这些字节将通过网络广播。 -#### 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). +正在讨论其他符号模式，最著名的是“SIGN_MODE_TEXTUAL”。如果您想了解更多关于它们的信息，请参阅 [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 Cosmos SDK's `TxBuilder`, -- broadcast the transaction using one of the available interfaces. +- 决定要放入交易的消息， +- 使用 Cosmos SDK 的 `TxBuilder` 生成交易， +- 使用可用接口之一广播交易。 -The next paragraphs will describe each of these components, in this order. +下一段将按此顺序描述这些组件中的每一个。 -### Messages +### 消息 -::: tip -Module `sdk.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. +::: 小费 +不要将模块 `sdk.Msg` 与 [ABCI Messages](https://tendermint.com/docs/spec/abci/abci.html#messages) 混淆，后者定义了 Tendermint 和应用程序层之间的交互。 ::: -**Messages** (or `sdk.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`. +**消息**(或`sdk.Msg`s)是特定于模块的对象，在它们所属的模块范围内触发状态转换。模块开发者通过向 Protobuf [`Msg` 服务](../building-modules/msg-services.md) 添加方法来为他们的模块定义消息，并实现相应的 `MsgServer`。 -Each `sdk.Msg`s is related to exactly one Protobuf [`Msg` service](../building-modules/msg-services.md) RPC, defined inside each module's `tx.proto` file. An SKD app router automatically maps every `sdk.Msg` to a corresponding RPC. Protobuf generates a `MsgServer` interface for each module `Msg` service, and the module developer needs to implement this interface. -This design puts more responsibility on module developers, allowing application developers to reuse common functionalities without having to implement state transition logic repetitively. +每个 `sdk.Msg` 都与一个 Protobuf [`Msg` 服务](../building-modules/msg-services.md) RPC 相关，在每个模块的 `tx.proto` 文件中定义。 SKD 应用路由器会自动将每个 `sdk.Msg` 映射到相应的 RPC。 Protobuf 为每个模块`Msg`服务生成一个`MsgServer`接口，模块开发者需要实现这个接口。 +这种设计让模块开发人员承担更多责任，允许应用程序开发人员重用通用功能，而无需重复实现状态转换逻辑。 -To learn more about Protobuf `Msg` services and how to implement `MsgServer`, click [here](../building-modules/msg-services.md). +要了解有关 Protobuf `Msg` 服务以及如何实现 `MsgServer` 的更多信息，请单击 [此处](../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`. +虽然消息包含状态转换逻辑的信息，但事务的其他元数据和相关信息存储在“TxBuilder”和“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: +`TxBuilder` 接口包含与交易生成密切相关的数据，最终用户可以自由设置以生成所需的交易: +++ 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`, a note or comment 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. +- `Msg`s，交易中包含的 [messages](#messages) 数组。 +- `GasLimit`，用户选择的选项，用于计算他们需要支付多少汽油。 +- `备忘录`，随交易一起发送的注释或评论。 +- `FeeAmount`，用户愿意支付的最大费用金额。 +- `TimeoutHeight`，直到交易有效的区块高度。 +- `Signatures`，来自交易所有签名者的签名数组。 -As there are currently two sign modes for signing transactions, there are also two implementations of `TxBuilder`: +由于目前有两种签署交易的签名模式，因此也有两种`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`. +- [wrapper](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/tx/builder.go#L19-L33) 用于为 `SIGN_MODE_DIRECT` 创建交易， +- [StdTxBuilder](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/x/auth/legacy/legacytx/stdtx_builder.go#L14-L20) 用于`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: +然而，`TxBuilder` 的两个实现应该远离最终用户，因为他们应该更喜欢使用总体的 `TxConfig` 接口: +++ 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. +`TxConfig` 是用于管理事务的应用程序范围的配置。最重要的是，它保存了有关是否使用“SIGN_MODE_DIRECT”或“SIGN_MODE_LEGACY_AMINO_JSON”签署每个交易的信息。通过调用`txBuilder := txConfig.NewTxBuilder()`，将使用适当的符号模式创建一个新的`TxBuilder`。 -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: +一旦 `TxBuilder` 被上面公开的 setter 正确填充，`TxConfig` 也将负责正确编码字节(同样，使用 `SIGN_MODE_DIRECT` 或 `SIGN_MODE_LEGACY_AMINO_JSON`)。这是如何使用 `TxEncoder()` 方法生成和编码交易的伪代码片段: ```go txBuilder := txConfig.NewTxBuilder() @@ -116,15 +116,15 @@ 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](../core/cli.md), [gRPC and/or REST interface](../core/grpc_rest.md), typically found in the application's `./cmd` folder. These interfaces allow users to interact with the application through command-line. +应用程序开发人员通过创建 [命令行接口](../core/cli.md)、[gRPC 和/或 REST 接口](../core/grpc_rest.md) 来创建应用程序的入口点，通常在 应用程序的`./cmd` 文件夹。 这些接口允许用户通过命令行与应用程序交互。 -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: +对于[命令行界面](../building-modules/module-interfaces.md#cli)，模块开发人员创建子命令以作为子命令添加到应用程序顶级事务命令`TxCmd`。 CLI 命令实际上将事务处理的所有步骤捆绑到一个简单的命令中:创建消息、生成事务和广播。 有关具体示例，请参阅 [与节点交互](../run-node/interact-node.md) 部分。 使用 CLI 进行的示例事务如下所示: ```bash simd tx send $MY_VALIDATOR_ADDRESS $RECIPIENT 1000stake @@ -132,24 +132,24 @@ 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 Cosmos SDK's RPC layer. The principal usage of gRPC is in the context of modules' [`Query` services](../building-modules). However, the Cosmos SDK also exposes a few other module-agnostic gRPC services, one of them being the `Tx` service: +[gRPC](https://grpc.io) 在 Cosmos SDK 0.40 中引入，作为 Cosmos SDK 的 RPC 层的主要组件。 gRPC 的主要用途是在模块的 [`Query` 服务](../building-modules) 的上下文中。但是，Cosmos SDK 还公开了一些其他与模块无关的 gRPC 服务，其中之一是“Tx”服务: +++ 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. +`Tx` 服务公开了一些实用功能，例如模拟交易或查询交易，以及一种广播交易的方法。 -Examples of broadcasting and simulating a transaction are shown [here](../run-node/txs.md#programmatically-with-go). +[此处](../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 /cosmos/tx/v1beta1/txs` endpoint. +每个 gRPC 方法都有其对应的 REST 端点，使用 [gRPC-gateway](https://github.com/grpc-ecosystem/grpc-gateway) 生成。因此，除了使用 gRPC，您还可以使用 HTTP 在 `POST /cosmos/tx/v1beta1/txs` 端点上广播相同的事务。 -An example can be seen [here](../run-node/txs.md#using-rest) +可以看到一个例子 [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. +上面介绍的三种方法实际上是对 Tendermint RPC `/broadcast_tx_{async,sync,commit}` 端点的更高抽象，记录在 [此处](https://docs.tendermint.com/master/rpc/#/Tx)。这意味着您可以直接使用 Tendermint RPC 端点来广播交易，如果您愿意的话。 -## Next {hide} +## 下一个 {hide} -Learn about the [context](./context.md) {hide} +了解 [context](./context.md) {hide} \ No newline at end of file diff --git a/docs/ja/core/upgrade.md b/docs/ja/core/upgrade.md index 04ec80865df2..85354c230a33 100644 --- a/docs/ja/core/upgrade.md +++ b/docs/ja/core/upgrade.md @@ -1,26 +1,26 @@ -# In-Place Store Migrations +# 就地存储迁移 -::: warning -Read and understand all of the in-place store migration documentation before you run a migration on a live chain. +::: 警告 +在实时链上运行迁移之前，请阅读并理解所有就地存储迁移文档。 ::: -Upgrade your app modules smoothly with custom in-place store migration logic. {synopsis} +使用自定义就地存储迁移逻辑顺利升级您的应用程序模块。 {概要} -The Cosmos SDK uses two methods to perform upgrades. +Cosmos SDK 使用两种方法来执行升级。 -- Exporting the entire application state to a JSON file using the `export` CLI command, making changes, and then starting a new binary with the changed JSON file as the genesis file. See [Chain Upgrade Guide to v0.42](https://docs.cosmos.network/v0.42/migrations/chain-upgrade-guide-040.html). +- 使用 `export` CLI 命令将整个应用程序状态导出到 JSON 文件，进行更改，然后使用更改后的 JSON 文件作为创世文件启动一个新的二进制文件。参见[链升级指南 v0.42](https://docs.cosmos.network/v0.42/migrations/chain-upgrade-guide-040.html)。 -- Version v0.44 and later can perform upgrades in place to significantly decrease the upgrade time for chains with a larger state. Use the [Module Upgrade Guide](../building-modules/upgrade.md) to set up your application modules to take advantage of in-place upgrades. +- v0.44 及更高版本可以执行就地升级，以显着减少具有更大状态的链的升级时间。使用 [模块升级指南](../building-modules/upgrade.md) 设置您的应用程序模块以利用就地升级。 -This document provides steps to use the In-Place Store Migrations upgrade method. +本文档提供了使用就地存储迁移升级方法的步骤。 -## Tracking Module Versions +## 跟踪模块版本 -Each module gets assigned a consensus version by the module developer. The consensus version serves as the breaking change version of the module. The Cosmos SDK keeps track of all module consensus versions in the x/upgrade `VersionMap` store. During an upgrade, the difference between the old `VersionMap` stored in state and the new `VersionMap` is calculated by the Cosmos SDK. For each identified difference, the module-specific migrations are run and the respective consensus version of each upgraded module is incremented. +模块开发人员为每个模块分配了一个共识版本。共识版本作为模块的突破性变更版本。 Cosmos SDK 会跟踪 x/upgrade `VersionMap` 存储中的所有模块共识版本。在升级过程中，存储在 state 中的旧 `VersionMap` 和新的 `VersionMap` 之间的差异由 Cosmos SDK 计算。对于每个识别出的差异，将运行特定于模块的迁移，并递增每个升级模块的相应共识版本。 -## Genesis State +##创世状态 -When starting a new chain, the consensus version of each module must be saved to state during the application's genesis. To save the consensus version, add the following line to the `InitChainer` method in `app.go`: +当启动一条新链时，每个模块的共识版本必须在应用程序的创世过程中保存到状态。要保存共识版本，请将以下行添加到“app.go”中的“InitChainer”方法中: ```diff func (app *MyApp) InitChainer(ctx sdk.Context, req abci.RequestInitChain) abci.ResponseInitChain { @@ -30,33 +30,33 @@ func (app *MyApp) InitChainer(ctx sdk.Context, req abci.RequestInitChain) abci.R } ``` -This information is used by the Cosmos SDK to detect when modules with newer versions are introduced to the app. +Cosmos SDK 使用此信息来检测何时将具有较新版本的模块引入应用程序。 -### Consensus Version +### 共识版本 -The consensus version is defined on each app module by the module developer and serves as the breaking change version of the module. The consensus version informs the Cosmos SDK on which modules need to be upgraded. For example, if the bank module was version 2 and an upgrade introduces bank module 3, the Cosmos SDK upgrades the bank module and runs the "version 2 to 3" migration script. +共识版本由模块开发者在每个应用模块上定义，作为模块的突破性变更版本。共识版本通知 Cosmos SDK 哪些模块需要升级。例如，如果银行模块是版本 2，并且升级引入了银行模块 3，Cosmos SDK 会升级银行模块并运行“版本 2 到 3”迁移脚本。 -### Version Map +### 版本映射 -The version map is a mapping of module names to consensus versions. The map is persisted to x/upgrade's state for use during in-place migrations. When migrations finish, the updated version map is persisted to state. +版本映射是模块名称到共识版本的映射。映射被持久化到 x/upgrade 的状态以在就地迁移期间使用。迁移完成后，更新后的版本映射将被持久化以保持状态。 -## Upgrade Handlers +## 升级处理程序 -Upgrades use an `UpgradeHandler` to facilitate migrations. The `UpgradeHandler` functions implemented by the app developer must conform to the following function signature. These functions retrieve the `VersionMap` from x/upgrade's state and return the new `VersionMap` to be stored in x/upgrade after the upgrade. The diff between the two `VersionMap`s determines which modules need upgrading. +升级使用 `UpgradeHandler` 来促进迁移。应用开发者实现的 `UpgradeHandler` 函数必须符合以下函数签名。这些函数从 x/upgrade 的状态中检索 `VersionMap`，并在升级后返回新的 `VersionMap` 以存储在 x/upgrade 中。两个 `VersionMap` 之间的差异决定了哪些模块需要升级。 ```go type UpgradeHandler func(ctx sdk.Context, plan Plan, fromVM VersionMap) (VersionMap, error) ``` -Inside these functions, you must perform any upgrade logic to include in the provided `plan`. All upgrade handler functions must end with the following line of code: +在这些函数中，您必须执行任何升级逻辑以包含在提供的“计划”中。 所有升级处理程序函数都必须以以下代码行结束: ```go return app.mm.RunMigrations(ctx, cfg, fromVM) ``` -## Running Migrations +## 运行迁移 -Migrations are run inside of an `UpgradeHandler` using `app.mm.RunMigrations(ctx, cfg, vm)`. The `UpgradeHandler` functions describe the functionality to occur during an upgrade. The `RunMigration` function loops through the `VersionMap` argument and runs the migration scripts for all versions that are less than the versions of the new binary app module. After the migrations are finished, a new `VersionMap` is returned to persist the upgraded module versions to state. +使用 `app.mm.RunMigrations(ctx, cfg, vm)` 在 `UpgradeHandler` 内部运行迁移。 `UpgradeHandler` 函数描述了升级过程中发生的功能。 `RunMigration` 函数循环遍历 `VersionMap` 参数，并为低于新二进制应用程序模块版本的所有版本运行迁移脚本。 迁移完成后，将返回一个新的“VersionMap”以将升级后的模块版本保存到状态。 ```go cfg := module.NewConfigurator(...) @@ -72,15 +72,15 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -To learn more about configuring migration scripts for your modules, see the [Module Upgrade Guide](../building-modules/upgrade.md). +要了解有关为模块配置迁移脚本的更多信息，请参阅 [模块升级指南](../building-modules/upgrade.md)。 -## Adding New Modules During Upgrades +## 在升级过程中添加新模块 -You can introduce entirely new modules to the application during an upgrade. New modules are recognized because they have not yet been registered in `x/upgrade`'s `VersionMap` store. In this case, `RunMigrations` calls the `InitGenesis` function from the corresponding module to set up its initial state. +您可以在升级期间向应用程序引入全新的模块。 新模块被识别是因为它们尚未在 `x/upgrade` 的 `VersionMap` 存储中注册。 在这种情况下，`RunMigrations` 从相应的模块调用 `InitGenesis` 函数来设置其初始状态。 -### Add StoreUpgrades for New Modules +### 为新模块添加 StoreUpgrades -All chains preparing to run in-place store migrations will need to manually add store upgrades for new modules and then configure the store loader to apply those upgrades. This ensures that the new module's stores are added to the multistore before the migrations begin. +所有准备运行就地存储迁移的连锁存储都需要为新模块手动添加存储升级，然后配置存储加载程序以应用这些升级。 这可确保在迁移开始之前将新模块的存储添加到多存储中。 ```go upgradeInfo, err := app.UpgradeKeeper.ReadUpgradeInfoFromDisk() @@ -101,14 +101,14 @@ if upgradeInfo.Name == "my-plan" && !app.UpgradeKeeper.IsSkipHeight(upgradeInfo. } ``` -## Overwriting Genesis Functions +## 覆盖创世函数 -The Cosmos SDK offers modules that the application developer can import in their app. These modules often have an `InitGenesis` function already defined. +Cosmos SDK 提供了应用程序开发人员可以在其应用程序中导入的模块。 这些模块通常已经定义了一个 `InitGenesis` 函数。 -You can write your own `InitGenesis` function for an imported module. To do this, manually trigger your custom genesis function in the upgrade handler. +您可以为导入的模块编写自己的 `InitGenesis` 函数。 为此，请在升级处理程序中手动触发您的自定义创世函数。 -::: warning -You MUST manually set the consensus version in the version map passed to the `UpgradeHandler` function. Without this, the SDK will run the Module's existing `InitGenesis` code even if you triggered your custom function in the `UpgradeHandler`. +::: 警告 +您必须在传递给 `UpgradeHandler` 函数的版本映射中手动设置共识版本。 如果没有这个，即使您在 `UpgradeHandler` 中触发了自定义函数，SDK 也会运行模块现有的 `InitGenesis` 代码。 ::: ```go @@ -128,7 +128,7 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -If you do not have a custom genesis function and want to skip the module's default genesis function, you can simply register the module with the version map in the `UpgradeHandler` as shown in the example: +如果你没有自定义的创世函数并且想跳过模块的默认创世函数，你可以简单地在 `UpgradeHandler` 中使用版本映射注册模块，如示例所示: ```go import foo "github.com/my/module/foo" @@ -143,10 +143,10 @@ app.UpgradeKeeper.SetUpgradeHandler("my-plan", func(ctx sdk.Context, plan upgrad }) ``` -## Syncing a Full Node to an Upgraded Blockchain +## 将完整节点同步到升级后的区块链 -You can sync a full node to an existing blockchain which has been upgraded using Cosmovisor +您可以将完整节点同步到已使用 Cosmovisor 升级的现有区块链 -In order to successfully sync, you must start with the initial binary that the blockchain started with at genesis. If all Software Upgrade Plans contain binary instruction then you can run Cosmovisor with auto download option to automatically handle downloading and switching to the binaries associated with each sequential upgrade. Otherwise you need to manually provide all binaries to Cosmovisor. +为了成功同步，您必须从区块链在创世时开始的初始二进制文件开始。 如果所有软件升级计划都包含二进制指令，那么您可以运行带有自动下载选项的 Cosmovisor，以自动处理下载和切换到与每个顺序升级相关的二进制文件。 否则，您需要手动向 Cosmovisor 提供所有二进制文件。 -To learn more about Cosmovisor, see the [Cosmovisor Quick Start](../run-node/cosmovisor.md). +要了解有关 Cosmovisor 的更多信息，请参阅 [Cosmovisor 快速入门](../run-node/cosmovisor.md)。 \ No newline at end of file diff --git a/docs/ja/ibc/README.md b/docs/ja/ibc/README.md index f76a2703f82a..13f6533898e4 100644 --- a/docs/ja/ibc/README.md +++ b/docs/ja/ibc/README.md @@ -1,14 +1,14 @@ # IBC -This repository contains reference documentation for the IBC protocol integration and concepts: +此存储库包含 IBC 协议集成和概念的参考文档: -1. [Overview](./overview.md) -2. [Integration](./integration.md) -3. [Customization](./custom.md) -4. [Relayer](./relayer.md) -5. [Governance Proposals](./proposals.md) +1. [概述](./overview.md) +2. [集成](./integration.md) +3. [自定义](./custom.md) +4. [中继器](./relayer.md) +5. [治理提案](./proposals.md) -**NOTE**: The IBC module has been moved to its [own repository](https://github.com/cosmos/ibc-go). +**注意**:IBC 模块已移至其[自己的存储库](https://github.com/cosmos/ibc-go)。 -After reading about IBC, head on to the [Building Modules -documentation](../building-modules/README.md) to learn more about the process of building modules. +阅读完 IBC 后，请前往 [构建模块 +文档](../building-modules/README.md) 以了解有关构建模块过程的更多信息。 diff --git a/docs/ja/ibc/custom.md b/docs/ja/ibc/custom.md index 0bef693f1aed..b36a3b1661aa 100644 --- a/docs/ja/ibc/custom.md +++ b/docs/ja/ibc/custom.md @@ -1,37 +1,37 @@ -# Customization +# 定制 -Learn how to configure your application to use IBC and send data packets to other chains. {synopsis} +了解如何配置您的应用程序以使用 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). +本文档可作为想要编写自己的 Inter-blockchain 的开发人员的指南 +自定义 [用例] 的通信协议 (IBC) 应用程序 (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. +由于IBC协议的模块化设计，IBC +应用程序开发人员不需要关心客户端的底层细节， +连接和证明验证。然而，对较低级别的简要说明 +给出堆栈以便应用程序开发人员可以对 IBC 有一个高级别的理解 +协议。然后文档详细介绍了与应用程序最相关的抽象层 +开发人员(通道和端口)，并描述如何定义自己的自定义数据包，以及 +`IBCModule` 回调。 -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. +要让您的模块通过 IBC 进行交互，您必须:绑定到端口，定义您自己的数据包数据和确认结构以及如何对它们进行编码/解码，并实现 +`IBCModule` 接口。以下是如何编写 IBC 应用程序的更详细说明 +模块正确。 -## Pre-requisites Readings +## 先决条件阅读 -- [IBC Overview](./overview.md)) {prereq} -- [IBC default integration](./integration.md) {prereq} +- [IBC 概览](./overview.md)) {prereq} +- [IBC 默认集成](./integration.md) {prereq} -## Create a custom IBC application module +##创建自定义IBC应用程序模块 -### Implement `IBCModule` Interface and callbacks +### 实现`IBCModule` 接口和回调 -The Cosmos SDK expects all IBC modules to implement the [`IBCModule` -interface](https://github.com/cosmos/ibc-go/tree/main/modules/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. +Cosmos SDK 期望所有 IBC 模块都实现 [`IBCModule` +接口](https://github.com/cosmos/ibc-go/tree/main/modules/core/05-port/types/module.go)。这 +接口包含 IBC 期望模块实现的所有回调。本节将介绍 +在通道握手执行期间调用的回调。 -Here are the channel handshake callbacks that modules are expected to implement: +以下是模块预期实现的通道握手回调: ```go // Called by IBC Handler on MsgOpenInit @@ -148,32 +148,32 @@ OnChanCloseConfirm( } ``` -#### 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. +* `ChanOpenInit` 回调应该验证 `MsgChanOpenInit.Version` 是否有效 +* `ChanOpenTry` 回调应该验证 `MsgChanOpenTry.Version` 是有效的，并且 `MsgChanOpenTry.CounterpartyVersion` 是有效的。 +* `ChanOpenAck` 回调应该验证 `MsgChanOpenAck.CounterpartyVersion` 是否有效并受支持。 -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`. +版本必须是字符串，但可以实现任何版本控制结构。如果您的应用程序计划 +有线性版本，然后推荐语义版本控制。如果您的应用程序计划发布 +主要版本之间的各种功能，然后建议使用相同的版本控制方案 +作为IBC。此版本控制方案指定了版本标识符和兼容的功能集 +那个标识符。有效的版本选择包括选择兼容的版本标识符 +您的应用程序对该版本支持的功能子集。该结构用于此 +方案可以在“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. +ICS20 目前使用单个支持的版本实现基本字符串匹配。 -### Bind Ports +### 绑定端口 -Currently, ports must be bound on app initialization. A module may bind to ports in `InitGenesis` -like so: +目前，端口必须在应用程序初始化时绑定。模块可以绑定到 `InitGenesis` 中的端口 +像这样: ```go func InitGenesis(ctx sdk.Context, keeper keeper.Keeper, state types.GenesisState) { @@ -198,17 +198,17 @@ func InitGenesis(ctx sdk.Context, keeper keeper.Keeper, state types.GenesisState } ``` -### 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/ibc-go/tree/main/modules/apps/transfer/module.go). +通过通道连接的模块必须就它们通过通道发送的应用程序数据达成一致。 +通道，以及他们将如何编码/解码它。 IBC 未指定此过程，因为它已启动 +到每个应用模块来决定如何执行这个协议。 然而，对于大多数 +应用程序这将在通道握手期间作为版本协商发生。 虽然更多 +可以在通道开启握手内部实现复杂的版本协商，一个非常 +[ibc-transfer 模块](https://github.com/cosmos/ibc-go/tree/main/modules/apps/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`. +因此，模块必须定义它的自定义数据包数据结构，以及定义良好的方法 +将其编码和解码为`[]byte`。 ```go // Custom packet data defined in application module @@ -225,7 +225,7 @@ DecodePacketData(encoded []byte) (CustomPacketData) { } ``` -Then a module must encode its packet data before sending it through IBC. +然后，模块必须在通过 IBC 发送数据包数据之前对其进行编码。 ```go // Sending custom application packet data @@ -234,8 +234,8 @@ 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. +接收数据包的模块必须将“PacketData”解码为它期望的结构，以便它可以 +采取行动。 ```go // Receiving custom application packet data (in OnRecvPacket) @@ -243,31 +243,31 @@ 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. +正如 IBC 期望模块实现通道握手回调一样，IBC 也期望模块 +实现回调以处理通过通道的数据包流。 -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. +一旦模块 A 和模块 B 相互连接，中继器就可以开始中继数据包和 +在频道上来回确认。 -![IBC packet flow diagram](https://media.githubusercontent.com/media/cosmos/ics/master/spec/ics-004-channel-and-packet-semantics/packet-state-machine.png) +![IBC数据包流程图](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. +1.模块A通过IBC模块发送数据包 +2.数据包被模块B接收 +3. 如果模块 B 写入数据包的确认，则模块 A 将处理 + 确认 +4.如果在超时前没有成功接收到数据包，则模块A处理 + 数据包超时。 -##### 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`. +模块不通过回调发送数据包，因为模块发起发送的动作 +数据包发送到 IBC 模块，而不是将消息发送到 IBC 的数据包流的其他部分 +模块必须通过使用回调触发端口绑定模块的执行。因此，要发送一个 +一个模块只需要在“IBCChannelKeeper”上调用“SendPacket”。 ```go // retrieve the dynamic capability for this channel @@ -279,21 +279,21 @@ packet.Data = data 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. +::: 警告 +为了防止模块在它们不拥有的通道上发送数据包，IBC 期望 +模块为数据包的源通道传递正确的通道能力。 ::: -##### 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. +为了处理接收数据包，模块必须实现`OnRecvPacket` 回调。 这得到 +在 IBC 证明数据包有效并正确处理后，由 IBC 模块调用 +守门员。 因此，`OnRecvPacket` 回调只需要关心使适当的状态 +更改给定的数据包数据而不必担心数据包是否有效。 -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. +模块可以将确认作为字节字符串返回并将其返回给 IBC 处理程序。 +IBC 处理程序然后将提交该数据包的确认，以便中继器可以中继 +确认返回发送器模块。 ```go OnRecvPacket( @@ -322,41 +322,41 @@ OnRecvPacket( } ``` -::: 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/ibc-go/tree/main/modules/apps/transfer/module.go). +::: 警告 +如果我们想要整个接收包执行，`OnRecvPacket` 应该 **only** 返回一个错误 +(包括 IBC 处理)要恢复。这将允许在这种情况下重放数据包 +中继中的一些错误导致数据包处理失败。 + +如果在处理数据包数据时发生了一些应用级错误，在大多数情况下，我们会 +不希望数据包处理恢复。相反，我们可能希望将此失败编码为 +确认并完成对数据包的处理。这将确保数据包无法重放， +并且还将允许发送方模块在收到消息时潜在地补救这种情况 +承认。这种技术的一个例子是在 `ibc-transfer` 模块的 +[`OnRecvPacket`](https://github.com/cosmos/ibc-go/tree/main/modules/apps/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. +注意:大多数区块链模块都希望使用同步执行模型，在该模型中模块处理和写入确认 +对于从 IBC 模块接收到的数据包。 -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. +正如分组数据对 IBC 是不透明的，确认同样是不透明的。模块必须通过和 +接收带有 IBC 模块的确认作为字节字符串。 -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/ibc-go/tree/main/modules/core/04-channel/types). +因此，模块必须就如何编码/解码确认达成一致。创建一个的过程 +确认结构连同它的编码和解码，非常类似于分组数据 +上面的例子。 [ICS 04](https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics#acknowledgement-envelope) +指定推荐的确认格式。此确认类型可以从 +[频道类型](https://github.com/cosmos/ibc-go/tree/main/modules/core/04-channel/types)。 -While modules may choose arbitrary acknowledgement structs, a default acknowledgement types is provided by IBC [here](https://github.com/cosmos/ibc-go/blob/main/proto/ibc/core/channel/v1/channel.proto): +虽然模块可以选择任意确认结构，但 IBC [此处](https://github.com/cosmos/ibc-go/blob/main/proto/ibc/core/channel/v1/channel.原型): ```proto // Acknowledgement is the recommended acknowledgement format to be used by @@ -375,17 +375,17 @@ message Acknowledgement { } ``` -#### 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. +在模块写入确认后，中继器可以将确认中继回发送器模块。 发送模块可以 +然后使用`OnAcknowledgementPacket`回调处理确认。 的内容 +确认完全取决于通道上的模块(就像分组数据一样)； 然而，它 +可能经常包含有关数据包是否被成功处理的信息 +如果数据包处理失败，一些额外的数据可能对补救有用。 -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. +由于模块负责就分组数据的编码/解码标准达成一致，并且 +确认，IBC 会将确认作为 `[]byte` 传递给这个回调。 回调 +负责解码确认并处理它。 ```go OnAcknowledgementPacket( @@ -402,14 +402,14 @@ OnAcknowledgementPacket( } ``` -#### 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. +如果在成功接收数据包之前达到数据包的超时时间或 +对方通道端在数据包被成功接收之前关闭，然后接收 +链无法再处理它。 因此，发送链必须使用 +`OnTimeoutPacket` 来处理这种情况。 IBC 模块将再次验证超时是否为 +确实有效，所以我们的模块只需要实现一次做什么的状态机逻辑 +超时时间已到，无法再接收数据包。 ```go OnTimeoutPacket( @@ -422,9 +422,9 @@ OnTimeoutPacket( ### 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`. +如上所述，模块必须实现 IBC 模块接口(其中包含通道 +握手回调和数据包处理回调)。 这个接口的具体实现 +必须使用模块名称注册为 IBC `Router` 上的路由。 ```go // app.go @@ -443,22 +443,22 @@ ibcRouter.AddRoute(moduleName, moduleCallbacks) 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. +有关 IBC 应用程序的实际工作示例，您可以查看“ibc-transfer”模块 +它实现了上面讨论的所有内容。 -Here are the useful parts of the module to look at: +以下是要查看的模块的有用部分: -[Binding to transfer -port](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/genesis.go) +[绑定转移 +端口](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/types/genesis.go) -[Sending transfer -packets](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/keeper/relay.go) +[发送转账 +数据包](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/keeper/relay.go) -[Implementing IBC -callbacks](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/module.go) +[实施IBC +回调](https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/module.go) -## Next {hide} +## 下一个 {hide} -Learn about [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/intro.md) {hide} +了解 [构建模块](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/intro.md) {hide} diff --git a/docs/ja/ibc/integration.md b/docs/ja/ibc/integration.md index cadf9899b5ac..f8d37c161f49 100644 --- a/docs/ja/ibc/integration.md +++ b/docs/ja/ibc/integration.md @@ -1,28 +1,28 @@ -# Integration +# 一体化 -Learn how to integrate IBC to your application and send data packets to other chains. {synopsis} +了解如何将 IBC 集成到您的应用程序并将数据包发送到其他链。 {概要} -This document outlines the required steps to integrate and configure the [IBC -module](https://github.com/cosmos/ibc-go/tree/main/modules/core) to your Cosmos SDK application and -send fungible token transfers to other chains. +本文档概述了集成和配置 [IBC +模块](https://github.com/cosmos/ibc-go/tree/main/modules/core) 到您的 Cosmos SDK 应用程序和 +将可替代的代币转移发送到其他链。 -## Integrating the IBC module +## 集成IBC模块 -Integrating the IBC module to your Cosmos SDK-based application is straighforward. The general changes can be summarized in the following steps: +将 IBC 模块集成到基于 Cosmos SDK 的应用程序非常简单。一般的变化可以概括为以下步骤: -- 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` +- 为`App` 类型的新模块定义额外的`Keeper` 字段 +- 添加模块的`StoreKeys`并初始化它们的`Keepers` +- 为 `ibc` 和 `evidence` 模块设置相应的路由器和路由 +- 将模块添加到模块`Manager` +- 将模块添加到`Begin/EndBlockers` 和`InitGenesis` +- 更新模块“SimulationManager”以启用模拟 -### Module `BasicManager` and `ModuleAccount` permissions +### 模块`BasicManager` 和`ModuleAccount` 权限 -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. +第一步是将以下模块添加到`BasicManager`:`x/capability`、`x/ibc`、 +`x/evidence` 和 `x/ibc-transfer`。之后，我们需要授予`Minter`和`Burner`权限 +`ibc-transfer``ModuleAccount` 用于铸造和销毁中继代币。 ```go // app.go @@ -44,9 +44,9 @@ var ( ) ``` -### Application fields +### 应用领域 -Then, we need to register the `Keepers` as follows: +然后，我们需要按如下方式注册`Keepers`: ```go // app.go @@ -70,10 +70,10 @@ type App struct { ### 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. +在初始化期间，除了初始化 IBC `Keepers`(对于 `x/ibc`，以及 +`x/ibc-transfer` 模块)，我们需要通过能力模块授予特定的能力 +`ScopedKeepers` 以便我们可以验证每个 IBC 的对象能力权限 +渠道。 ```go func NewApp(...args) *App { @@ -110,26 +110,26 @@ func NewApp(...args) *App { } ``` -### 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/ibc-go/blob/main/modules/core/05-port/types/router.go) on the -IBC module. +IBC 需要知道哪个模块绑定到哪个端口，以便它可以将数据包路由到 +适当的模块并调用适当的回调。端口到模块名称的映射由 +IBC 的港口“Keeper”。但是，模块名称到相关回调的映射已经完成 +由港口 +[`Router`](https://github.com/cosmos/ibc-go/blob/main/modules/core/05-port/types/router.go) 在 +IBC 模块。 -Adding the module routes allows the IBC handler to call the appropriate callback when processing a -channel handshake or a packet. +添加模块路由允许 IBC 处理程序在处理一个 +通道握手或数据包。 -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. +所需的第二个“路由器”是证据模块路由器。这个路由器处理一般 +证据提交并将业务逻辑路由到每个注册的证据处理程序。在这种情况下 +IBC的，需要提交[轻客户端的证据 +不当行为](https://github.com/cosmos/ics/tree/master/spec/ics-002-client-semantics#misbehaviour) +为了冻结客户端并防止发送/接收更多数据包。 -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. +目前，`Router` 是静态的，因此必须在应用程序初始化时对其进行初始化和正确设置。 +一旦设置了`Router`，就不能添加新的路由。 ```go // app.go @@ -161,7 +161,7 @@ func NewApp(...args) *App { ### 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). +为了使用 IBC，我们需要将新模块添加到模块 `Manager` 和 `SimulationManager`，以防您的应用程序支持 [simulations](./../building-modules/simulator.md)。 ```go // app.go @@ -191,24 +191,24 @@ func NewApp(...args) *App { // .. continues ``` -### Application ABCI Ordering +### 应用 ABCI 订购 -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. +IBC 的一项新增功能是存储在 staking 模块中的“HistoricalEntries”概念。 +每个条目都包含此链的“Header”和“ValidatorSet”的历史信息，这些信息被存储 +在“BeginBlock”调用期间的每个高度。 需要历史信息来反省 +过去在任何给定高度的历史信息，以便在此期间验证轻客户端“ConsensusState” +连接握手。 -The IBC module also has -[`BeginBlock`](https://github.com/cosmos/ibc-go/blob/main/modules/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/ibc/tree/master/spec/client/ics-009-loopback-client) to connect two -different modules from the same chain. +IBC 模块还具有 +[`BeginBlock`](https://github.com/cosmos/ibc-go/blob/main/modules/core/02-client/abci.go) 逻辑为 +好。 这是可选的，因为只有在您的应用程序使用 [localhost +客户端](https://github.com/cosmos/ibc/tree/master/spec/client/ics-009-loopback-client) 连接两个 +来自同一链的不同模块。 -::: tip -Only register the ibc module to the `SetOrderBeginBlockers` if your application will use the -localhost (_aka_ loopback) client. -::: +::: 小费 +如果您的应用程序将使用 +本地主机(_aka_ 环回)客户端。 +::: ```go // app.go @@ -235,14 +235,14 @@ func NewApp(...args) *App { // .. continues ``` -::: warning -**IMPORTANT**: The capability module **must** be declared first in `SetOrderInitGenesis` +::: 警告 +**重要**:功能模块**必须**在`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 Cosmos SDK's -[`SimApp`](https://github.com/cosmos/ibc-go/blob/main/testing/simapp/app.go). +而已！ 您现在已经连接了 IBC 模块，现在可以发送可替代的代币 +不同的链。 如果您想更广泛地了解更改，请查看 Cosmos SDK 的 +[`SimApp`](https://github.com/cosmos/ibc-go/blob/main/testing/simapp/app.go)。 -## Next {hide} +## 下一个 {hide} -Learn about how to create [custom IBC modules](./custom.md) for your application {hide} +了解如何为您的应用程序创建 [自定义 IBC 模块](./custom.md) {hide} \ No newline at end of file diff --git a/docs/ja/ibc/overview.md b/docs/ja/ibc/overview.md index 3a754e5dcd42..597b79f0c11f 100644 --- a/docs/ja/ibc/overview.md +++ b/docs/ja/ibc/overview.md @@ -1,149 +1,149 @@ -# IBC Overview +# IBC 概览 -Learn what IBC is, its components, and use cases. {synopsis} +了解 IBC 是什么、它的组件和用例。 {概要} -## What is the Inter-Blockchain Communication Protocol (IBC)? +## 什么是区块链间通信协议(IBC)？ -This document is a guide for developers who want to write their own IBC apps for custom use cases. +本文档是为想要为自定义用例编写自己的 IBC 应用程序的开发人员提供的指南。 -The modular design of the IBC protocol means that IBC app developers do not require in-depth knowledge of the low-level details of clients, connections, and proof verification. This brief explanation of the lower levels of the stack is provided so that app developers can gain a high-level understanding of the IBC protocol. +IBC 协议的模块化设计意味着 IBC 应用程序开发人员不需要深入了解客户端、连接和证明验证的低级细节。提供了对堆栈较低级别的简要说明，以便应用程序开发人员可以获得对 IBC 协议的高级理解。 -The abstraction layer details on channels and ports are relevant for app developers. You can define your own custom packets and IBCModule callbacks. +通道和端口的抽象层详细信息与应用程序开发人员相关。您可以定义自己的自定义数据包和 IBCModule 回调。 -The following requirements must be met for a module to interact over IBC: +模块必须满足以下要求才能通过 IBC 进行交互: -- Bind to one or more ports +- 绑定到一个或多个端口 -- Define the packet data +- 定义数据包数据 -- Define optional acknowledgement structures and methods to encode and decode them +- 定义可选的确认结构和方法来编码和解码它们 -- Implement the IBCModule interface +- 实现 IBCModule 接口 -## Components Overview +## 组件概述 -This section describes the IBC components and links to the repos. +本节介绍 IBC 组件和存储库链接。 -### [Clients](https://github.com/cosmos/ibc-go/blob/main/modules/core/02-client) +### [客户端](https://github.com/cosmos/ibc-go/blob/main/modules/core/02-client) -IBC clients are light clients that are identified by a unique client id. IBC clients track the consensus states of other blockchains and the proof specs of those blockchains that are required to properly verify proofs against the client's consensus state. A client can be associated with any number of connections to multiple chains. The supported IBC clients are: +IBC 客户端是由唯一客户端 ID 标识的轻客户端。 IBC 客户跟踪其他区块链的共识状态，以及根据客户的共识状态正确验证证明所需的那些区块链的证明规范。一个客户端可以与多个链的任意数量的连接相关联。支持的 IBC 客户端是: -- [Solo Machine light client](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/06-solomachine): devices such as phones, browsers, or laptops. -- [Tendermint light client](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/07-tendermint): The default for Cosmos SDK-based chains. -- [Localhost (loopback) client](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/09-localhost): Useful for testing, simulation, and relaying packets to modules on the same application. +- [Solo Machine 轻客户端](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/06-solomachine):手机、浏览器或笔记本电脑等设备。 +- [Tendermint 轻客户端](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/07-tendermint):基于 Cosmos SDK 的链的默认值。 +- [Localhost (loopback) client](https://github.com/cosmos/ibc-go/blob/main/modules/light-clients/09-localhost):用于测试、模拟和将数据包中继到模块相同的应用程序。 -### [Connections](https://github.com/cosmos/ibc-go/blob/main/modules/core/03-connection) +### [连接](https://github.com/cosmos/ibc-go/blob/main/modules/core/03-connection) -Connections encapsulate two `ConnectionEnd` objects on two separate blockchains. Each `ConnectionEnd` is associated with a client of the other blockchain (the 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 facilitating all cross-chain verification of IBC state. A connection can be associated with any number of channels. +Connections 将两个“ConnectionEnd”对象封装在两个独立的区块链上。每个“ConnectionEnd”都与另一个区块链(交易对手区块链)的客户端相关联。连接握手负责验证每个链上的轻客户端对于其各自的交易对手是否正确。连接一旦建立，负责促进 IBC 状态的所有跨链验证。一个连接可以与任意数量的通道相关联。 -### [Proofs](https://github.com/cosmos/ibc-go/blob/main/modules/core/23-commitment) and [Paths](https://github.com/cosmos/ibc-go/blob/main/modules/core/24-host) +### [证明](https://github.com/cosmos/ibc-go/blob/main/modules/core/23-commitment) 和 [路径](https://github.com/cosmos/ibc- go/blob/main/modules/core/24-host) -In IBC, blockchains do not directly pass messages to each other over the network. +在 IBC 中，区块链不会直接通过网络相互传递消息。 -- To communicate, a blockchain commits some state to a precisely defined path reserved for a specific message type and a specific counterparty. For example, a blockchain that stores a specific connectionEnd as part of a handshake or a packet intended to be relayed to a module on the counterparty chain. +- 为了进行通信，区块链将一些状态提交到为特定消息类型和特定交易对手保留的精确定义的路径。例如，将特定 connectionEnd 作为握手或旨在中继到交易对手链上的模块的数据包的一部分存储的区块链。 -- A relayer process monitors for updates to these paths and relays messages by submitting the data stored under the path along with a proof of that data to the counterparty chain. +- 中继器进程监视这些路径的更新并通过将存储在路径下的数据连同该数据的证明提交给交易对手链来中继消息。 -- The paths that all IBC implementations must support for committing IBC messages are defined in [ICS-24 host requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements). +- 所有 IBC 实现必须支持提交 IBC 消息的路径在 [ICS-24 主机要求](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-要求)。 -- The proof format that all implementations must produce and verify is defined in [ICS-23 implementation](https://github.com/confio/ics23). +- 所有实现必须生成和验证的证明格式在 [ICS-23 实现](https://github.com/confio/ics23) 中定义。 -### [Capabilities](./ocap.md) +### [功能](./ocap.md) -IBC is intended to work in execution environments where modules do not necessarily trust each other. IBC must authenticate module actions on ports and channels so that only modules with the appropriate permissions can use the channels. This security 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 returns a dynamic capability that the module must claim to use that port or channel. This binding strategy prevents other modules from using that port or channel since those modules do not own the appropriate capability. +IBC 旨在在模块不一定相互信任的执行环境中工作。 IBC 必须验证端口和通道上的模块操作，以便只有具有适当权限的模块才能使用通道。这种安全性是使用 [动态功能](../architecture/adr-003-dynamic-capability-store.md) 实现的。在绑定到端口或为模块创建通道时，IBC 返回一个动态功能，模块必须声明使用该端口或通道。此绑定策略可防止其他模块使用该端口或通道，因为这些模块不拥有相应的功能。 -While this explanation 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 模块根本不需要与这些较低级别的抽象进行交互。 IBC 应用程序开发人员的相关抽象层是通道和端口。 -Write your IBC applications as self-contained **modules**. A module on one blockchain can communicate with other modules on other blockchains by sending, receiving, and acknowledging packets through channels that are uniquely identified by the `(channelID, portID)` tuple. +将您的 IBC 应用程序编写为独立的**模块**。一个区块链上的模块可以通过发送、接收和确认数据包来与其他区块链上的其他模块通信，这些数据包通过由 `(channelID, portID)` 元组唯一标识的通道。 -A useful analogy is to consider IBC modules as internet apps on a computer. A channel can then be conceptualized as an IP connection, with the IBC portID is like an IP port, and the IBC channelID is like an IP address. A single instance of an IBC module can communicate on the same port with any number of other modules and IBC correctly routes all packets to the relevant module using the `(channelID, portID)` tuple. An IBC module can also communicate with another IBC module over multiple ports by sending each `(portID<->portID)` packet stream on a different unique channel. +一个有用的类比是将 IBC 模块视为计算机上的 Internet 应用程序。然后可以将通道概念化为 IP 连接，IBC portID 类似于 IP 端口，IBC channelID 类似于 IP 地址。 IBC 模块的单个实例可以在同一端口上与任意数量的其他模块通信，并且 IBC 使用“(channelID, portID)”元组将所有数据包正确路由到相关模块。通过在不同的唯一通道上发送每个`(portID<->portID)` 数据包流，IBC 模块还可以通过多个端口与另一个 IBC 模块通信。 -### [Ports](https://github.com/cosmos/ibc-go/blob/main/modules/core/05-port) +### [端口](https://github.com/cosmos/ibc-go/blob/main/modules/core/05-port) -An IBC module can 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 that operate on the same ledger, binding a port returns the dynamic object capability. To take action on a particular port, for example, to open a channel with its portID, a module must provide the dynamic object capability to the IBC handler. This requirement prevents a malicious module from opening channels with ports it does not own. +IBC 模块可以绑定到任意数量的端口。每个端口必须由唯一的“portID”标识。由于 IBC 旨在通过在同一账本上运行的互不信任的模块来确保安全，因此绑定端口会返回动态对象功能。要对特定端口执行操作，例如，使用其端口 ID 打开通道，模块必须向 IBC 处理程序提供动态对象功能。此要求可防止恶意模块打开带有它不拥有的端口的通道。 -IBC modules are responsible for claiming the capability that is returned on `BindPort`. +IBC 模块负责声明在`BindPort` 上返回的能力。 -### [Channels](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) +### [频道](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) -An IBC channel can be established between two IBC ports. A port is exclusively owned by a single module. IBC packets are sent over channels. Just as IP packets contain the destination IP address, IP port, the source IP address, and source IP port, IBC packets contain the destination portID, channelID, the source portID, and channelID. The IBC packets enable IBC to correctly route the packets to the destination module, while also allowing modules receiving packets to know the sender module. +可以在两个 IBC 端口之间建立 IBC 通道。一个端口由一个模块独占所有。 IBC 数据包通过通道发送。正如 IP 数据包包含目标 IP 地址、IP 端口、源 IP 地址和源 IP 端口一样，IBC 数据包包含目标端口 ID、通道 ID、源端口 ID 和通道 ID。 IBC 数据包使 IBC 能够正确地将数据包路由到目标模块，同时还允许接收数据包的模块知道发送方模块。 -- A channel can be `ORDERED` so that packets from a sending module must be processed by the receiving module in the order they were sent. +- 通道可以是“ORDERED”的，因此来自发送模块的数据包必须由接收模块按照它们发送的顺序进行处理。 -- Recommended, a channel may be `UNORDERED` so that packets from a sending module are processed in the order they arrive, which may not be the order the packets were sent. +- 推荐，通道可以是“无序”，以便来自发送模块的数据包按照它们到达的顺序进行处理，这可能不是发送数据包的顺序。 -Modules may choose which channels they wish to communicate over with. IBC expects modules to implement callbacks that are called during the channel handshake. These callbacks may do custom channel initialization logic. If an error is returned, the channel handshake fails. By returning errors on callbacks, modules can programmatically reject and accept channels. +模块可以选择他们希望通过哪些通道进行通信。 IBC 期望模块实现在通道握手期间调用的回调。这些回调可以执行自定义通道初始化逻辑。如果返回错误，则通道握手失败。通过在回调中返回错误，模块可以以编程方式拒绝和接受通道。 -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: +通道握手是一个 4 步握手。简而言之，如果给定的链 A 想要使用已经建立的连接打开与链 B 的通道: -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. +1. 链 A 发送一个 `ChanOpenInit` 消息来通知链 B 的通道初始化尝试。 +2. 链 B 发送 `ChanOpenTry` 消息尝试打开链 A 上的通道。 +3. 链 A 发送 `ChanOpenAck` 消息以标记其通道结束状态为打开。 +4. 链B发送`ChanOpenConfirm`消息将其通道结束状态标记为开放。 -If all of these actions happen successfully, the channel is open on both sides. At each step in the handshake, the module associated with the `ChannelEnd` executes its callback for that step of the handshake. So on `ChanOpenInit`, the module on chain A has its callback `OnChanOpenInit` executed. +如果所有这些操作都成功发生，则通道在双方都是开放的。在握手的每一步，与“ChannelEnd”关联的模块都会为握手的那一步执行回调。所以在`ChanOpenInit`上，链A上的模块执行了它的回调`OnChanOpenInit`。 -Just as ports came with dynamic capabilities, channel initialization returns 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: `OnChanOpenInit` on the initializing chain or `OnChanOpenTry` on the other chain. +正如端口具有动态功能一样，通道初始化返回模块**必须**声明的动态功能，以便它们可以传递功能来验证通道操作，例如发送数据包。通道功能在握手的第一部分传递到回调中:初始化链上的“OnChanOpenInit”或另一条链上的“OnChanOpenTry”。 -### [Packets](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) +### [数据包](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) -Modules communicate with each other by sending packets over IBC channels. All IBC packets contain: +模块通过在 IBC 通道上发送数据包来相互通信。所有 IBC 数据包都包含: -- Destination `portID` +- 目的地`portID` -- Destination `channelID` +- 目的地`channelID` -- Source `portID` +- 源`portID` -- Source `channelID` +- 来源`channelID` - These port and channels allow the modules to know the sender module of a given packet. + 这些端口和通道允许模块知道给定数据包的发送模块。 -- A sequence to optionally enforce ordering +- 可选择强制排序的序列 -- `TimeoutTimestamp` and `TimeoutHeight` +- `TimeoutTimestamp` 和 `TimeoutHeight` - When non-zero, these timeout values 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. Packet data is completely opaque to IBC handlers. The sender module must encode their application-specific packet information into the `Data` field of packets. The receiver module must decode that `Data` back to the original application data. +模块在 IBC 数据包的“Data []byte”字段内相互发送自定义应用程序数据。数据包数据对 IBC 处理程序是完全不透明的。发送器模块必须将其特定于应用程序的数据包信息编码到数据包的“数据”字段中。接收器模块必须将该“数据”解码回原始应用程序数据。 -### [Receipts and Timeouts](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) +### [收据和超时](https://github.com/cosmos/ibc-go/blob/main/modules/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. Packets must specify a timeout height or timeout timestamp after which a packet can no longer be successfully received on the destination chain. +由于 IBC 在分布式网络上工作，并依赖潜在故障的中继器在分类账之间中继消息，因此 IBC 必须处理数据包没有及时或根本没有发送到目的地的情况。数据包必须指定超时高度或超时时间戳，在此之后，目标链上将无法再成功接收数据包。 -If the timeout is 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, and so on). +如果达到超时，则可以向原始链提交数据包证明超时，然后原始链可以执行特定于应用程序的逻辑来使数据包超时，可能通过回滚数据包发送更改(退还发件人任何锁定的资金，以及很快)。 -In ORDERED channels, a timeout of a single packet in the channel closes the channel. 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. +在 ORDERED 通道中，通道中单个数据包的超时将关闭通道。如果数据包序列‘n’超时，那么在不违反按发送顺序处理数据包的有序通道合同的情况下，无法成功接收序列‘k > n’的数据包。由于 ORDERED 通道强制执行此不变量，因此数据包 n 的指定超时未在目标链上接收到序列 n 的证据足以使数据包 n 超时并关闭通道。 -In the UNORDERED case, packets can be received in any order. IBC writes a packet receipt for each sequence it has received in the UNORDERED channel. This receipt contains no information and 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, proof that a packet receipt does not exist is required for the packet's sequence by the specified timeout. Of course, timing out a packet on an UNORDERED channel triggers the application specific timeout logic for that packet, and does not close the channel. +在 UNORDERED 情况下，可以按任何顺序接收数据包。 IBC 为它在 UNORDERED 通道中收到的每个序列写入一个数据包接收。此接收不包含任何信息，只是一个标记，旨在表示 UNORDERED 通道已按指定顺序接收到数据包。要使 UNORDERED 通道上的数据包超时，需要在指定的超时时间内为数据包的序列证明不存在数据包接收。当然，在 UNORDERED 通道上超时数据包会触发该数据包的应用程序特定超时逻辑，并且不会关闭通道。 -For this reason, most modules that use UNORDERED channels are recommended as they require less liveness guarantees to function effectively for users of that channel. +因此，建议使用大多数使用 UNORDERED 频道的模块，因为它们需要较少的活跃度保证才能为该频道的用户有效运行。 -### [Acknowledgements](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) +### [致谢](https://github.com/cosmos/ibc-go/blob/main/modules/core/04-channel) -Modules also write application-specific acknowledgements when processing a packet. Acknowledgements can be done: +处理数据包时，模块还会编写特定于应用程序的确认。可以进行确认: -- Synchronously on `OnRecvPacket` if the module processes packets as soon as they are received from IBC module. +- 如果模块在从 IBC 模块接收到数据包后立即处理数据包，则在 `OnRecvPacket` 上同步。 -- Asynchronously if module processes packets at some later point after receiving the packet. +- 如果模块在接收数据包后的某个时间点处理数据包，则异步。 -This acknowledgement data is opaque to IBC much like the packet `Data` and is treated by IBC as a simple byte string `[]byte`. The receiver modules must encode their acknowledgement so that the sender module can decode it correctly. How the acknowledgement is encoded should be decided through version negotiation during the channel handshake. +这个确认数据对 IBC 来说是不透明的，就像数据包“Data”一样，被 IBC 视为一个简单的字节串“[]byte”。接收器模块必须对其确认进行编码，以便发送器模块可以正确解码。如何编码确认应通过通道握手期间的版本协商来决定。 -The acknowledgement can encode whether the packet processing succeeded or failed, along with additional information that allows the sender module to take appropriate action. +确认可以编码数据包处理是成功还是失败，以及允许发送方模块采取适当行动的附加信息。 -After the acknowledgement has been written by the receiving chain, a relayer relays the acknowledgement back to the original sender module which then executes application-specific acknowledgment logic using the contents of the acknowledgement. This acknowledgement can involve rolling back packet-send changes in the case of a failed acknowledgement (refunding senders). +在接收链写入确认后，中继器将确认中继回原始发送器模块，然后使用确认的内容执行特定于应用程序的确认逻辑。此确认可能涉及在确认失败(退款发送方)的情况下回滚数据包发送更改。 -After 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. +在原始发送者链上成功收到确认后，IBC 模块删除相应的数据包承诺，因为它不再需要。 -## Further Readings and Specs +## 进一步阅读和规格 -To learn more about IBC, check out the following specifications: +要了解有关 IBC 的更多信息，请查看以下规格: -- [IBC specs](https://github.com/cosmos/ibc/tree/master/spec) -- [IBC protocol on the Cosmos SDK](https://github.com/cosmos/ibc-go/tree/main/docs) +- [IBC 规范](https://github.com/cosmos/ibc/tree/master/spec) +- [Cosmos SDK 上的IBC 协议](https://github.com/cosmos/ibc-go/tree/main/docs) -## Next {hide} +## 下一个 {hide} -Learn about how to [integrate](./integration.md) IBC to your application {hide} +了解如何 [integrate](./integration.md) IBC 到您的应用程序 {hide} diff --git a/docs/ja/ibc/proposals.md b/docs/ja/ibc/proposals.md index 064858311b7a..b424b12d5930 100644 --- a/docs/ja/ibc/proposals.md +++ b/docs/ja/ibc/proposals.md @@ -1,38 +1,38 @@ -# Governance Proposals +# 治理提案 -In uncommon situations, a highly valued client may become frozen due to uncontrollable -circumstances. A highly valued client might have hundreds of channels being actively used. -Some of those channels might have a significant amount of locked tokens used for ICS 20. +在不常见的情况下，高价值客户可能会因无法控制而被冻结 +情况。一个高价值的客户可能有数百个渠道正在被积极使用。 +其中一些频道可能有大量用于 ICS 20 的锁定令牌。 -If the one third of the validator set of the chain the client represents decides to collude, -they can sign off on two valid but conflicting headers each signed by the other one third -of the honest validator set. The light client can now be updated with two valid, but conflicting -headers at the same height. The light client cannot know which header is trustworthy and therefore -evidence of such misbehaviour is likely to be submitted resulting in a frozen light client. +如果客户端所代表的链中三分之一的验证者决定串通， +他们可以签署两个有效但相互冲突的标头，每个标头都由另一个三分之一签名 +诚实的验证者集。轻客户端现在可以更新为两个有效但相互冲突的 +相同高度的标题。轻客户端无法知道哪个头是值得信赖的，因此 +提交此类不当行为的证据很可能会导致冻结轻客户端。 -Frozen light clients cannot be updated under any circumstance except via a governance proposal. -Since a quorum of validators can sign arbitrary state roots which may not be valid executions -of the state machine, a governance proposal has been added to ease the complexity of unfreezing -or updating clients which have become "stuck". Without this mechanism, validator sets would need -to construct a state root to unfreeze the client. Unfreezing clients, re-enables all of the channels -built upon that client. This may result in recovery of otherwise lost funds. +除非通过治理提案，否则在任何情况下都不能更新冻结的轻客户端。 +由于法定人数的验证者可以签署可能不是有效执行的任意状态根 +在状态机中，添加了治理提案以减轻解冻的复杂性 +或更新已“卡住”的客户端。如果没有这种机制，验证器集将需要 +构造一个状态根来解冻客户端。解冻客户端，重新启用所有渠道 +建立在那个客户之上。这可能会导致收回其他损失的资金。 -Tendermint light clients may become expired if the trusting period has passed since their -last update. This may occur if relayers stop submitting headers to update the clients. +如果信任期已过，Tendermint 轻客户端可能会过期 +最后更新。如果中继器停止提交标头以更新客户端，则可能会发生这种情况。 -An unplanned upgrade by the counterparty chain may also result in expired clients. If the counterparty -chain undergoes an unplanned upgrade, there may be no commitment to that upgrade signed by the validator -set before the chain-id changes. In this situation, the validator set of the last valid update for the -light client is never expected to produce another valid header since the chain-id has changed, which will -ultimately lead the on-chain light client to become expired. +交易对手链的计划外升级也可能导致客户过期。如果对方 +链经历了计划外的升级，验证者可能不会对该升级做出承诺 +在链 ID 更改之前设置。在这种情况下，最后一个有效更新的验证器集 +轻客户端永远不会产生另一个有效的头，因为链 ID 已经改变，这将 +最终导致链上轻客户端过期。 -In the case that a highly valued light client is frozen, expired, or rendered non-updateable, a -governance proposal may be submitted to update this client, known as the subject client. The -proposal includes the client identifier for the subject, the client identifier for a substitute -client, and an initial height to reference the substitute client from. Light client implementations -may implement custom updating logic, but in most cases, the subject will be updated with information -from the substitute client, if the proposal passes. The substitute client is used as a "stand in" -while the subject is on trial. It is best practice to create a substitute client *after* the subject -has become frozen to avoid the substitute from also becoming frozen. An active substitute client -allows headers to be submitted during the voting period to prevent accidental expiry once the proposal -passes. +如果高价值的轻客户端被冻结、过期或不可更新， +可以提交治理提案以更新此客户端，称为主题客户端。这 +提议包括主题的客户标识符，替代的客户标识符 +客户端，以及引用替代客户端的初始高度。轻客户端实现 +可以实现自定义更新逻辑，但大多数情况下，主题会更新信息 +如果提案通过，则来自替代客户。替代客户端用作“替身” +在受审期间。最佳做法是在主题之后*创建替代客户端 +已被冻结以避免替代品也被冻结。一个活跃的替代客户 +允许在投票期间提交标题，以防止提案一旦过期 +通过。 \ No newline at end of file diff --git a/docs/ja/ibc/relayer.md b/docs/ja/ibc/relayer.md index a91515633e25..6bf57122626b 100644 --- a/docs/ja/ibc/relayer.md +++ b/docs/ja/ibc/relayer.md @@ -1,43 +1,43 @@ -# Relayer +# 中继器 -## Prerequisites Readings +## 先决条件阅读 -- [IBC Overview](./overview.md) {prereq} -- [Events](https://github.com/cosmos/cosmos-sdk/blob/master/docs/core/events.md) {prereq} +- [IBC 概览](./overview.md) {prereq} +- [事件](https://github.com/cosmos/cosmos-sdk/blob/master/docs/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/ibc-go/blob/main/modules/core/spec/06_events.md). +为基础应用程序处理的每个事务发出事件以指示执行 +一些客户可能想要了解的逻辑。这在中继 IBC 数据包时非常有用。 +任何使用 IBC 的消息都会为执行中定义的相应 TAO 逻辑发出事件 +[IBC 事件规范](https://github.com/cosmos/ibc-go/blob/main/modules/core/spec/06_events.md)。 -In the Cosmos 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. +在 Cosmos SDK 中，可以假设每条消息都有一个类型为“message”的事件， +属性键`action`，以及表示发送消息类型的属性值 +(`channel_open_init` 将是`MsgChannelOpenInit` 的属性值)。如果中继器查询 +对于事务事件，它可以使用此事件类型/属性键对拆分消息事件。 -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`). +带有属性键“module”的事件类型“message”可能会针对单个事件多次发出 +由于应用程序回调而产生的消息。可以假设执行的任何 TAO 逻辑都会导致 +具有属性值“ibc_”的模块事件发射(02-client 发射“ibc_client”)。 -### Subscribing with Tendermint +### 订阅 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. +通过 [Tendermint 的 Websocket](https://docs.tendermint.com/master/rpc/) 调用 Tendermint RPC 方法 `Subscribe` 将使用以下方法返回事件 +Tendermint 对它们的内部表示。而不是像他们一样接收事件列表 +发出后，Tendermint 将返回类型 `map[string][]string`，它映射了 +从 `.` 到 `attribute_value`。这会导致事件的提取 +订购是非平凡的，但仍然可能。 -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. +中继者应该使用 `message.action` 键来提取交易中的消息数量 +以及发送的 IBC 交易类型。对于字符串数组中的每个 IBC 交易 +`message.action`，应该从其他事件字段中提取必要的信息。如果 +`send_packet` 出现在 `message.action` 值的索引 2 处，中继器将需要使用 +键“send_packet.packet_sequence”的索引 2 处的值。应该对每个人重复这个过程 +中继数据包所需的一条信息。 -## Example Implementations +## 示例实现 - [Golang Relayer](https://github.com/iqlusioninc/relayer) -- [Hermes](https://github.com/informalsystems/ibc-rs/tree/master/relayer) -- [Typescript Relayer](https://github.com/confio/ts-relayer) +- [爱马仕](https://github.com/informalsystems/ibc-rs/tree/master/relayer) +- [Typescript Relayer](https://github.com/confio/ts-relayer) \ No newline at end of file diff --git a/docs/ja/ibc/upgrades/README.md b/docs/ja/ibc/upgrades/README.md index 3856081d57df..3bd12cf0e096 100644 --- a/docs/ja/ibc/upgrades/README.md +++ b/docs/ja/ibc/upgrades/README.md @@ -1,8 +1,8 @@ -### Upgrading IBC Chains Overview +### 升级 IBC 链概述 -This directory contains information on how to upgrade an IBC chain without breaking counterparty clients and connections. +该目录包含有关如何在不中断交易对手客户端和连接的情况下升级 IBC 链的信息。 -IBC-connnected chains must be able to upgrade without breaking connections to other chains. Otherwise there would be a massive disincentive towards upgrading and disrupting high-value IBC connections, thus preventing chains in the IBC ecosystem from evolving and improving. Many chain upgrades may be irrelevant to IBC, however some upgrades could potentially break counterparty clients if not handled correctly. Thus, any IBC chain that wishes to perform a IBC-client-breaking upgrade must perform an IBC upgrade in order to allow counterparty clients to securely upgrade to the new light client. +IBC 连接的链必须能够在不中断与其他链的连接的情况下升级。否则，升级和破坏高价值 IBC 连接将受到巨大阻碍，从而阻止 IBC 生态系统中的链发展和改进。许多链升级可能与 IBC 无关，但如果处理不当，某些升级可能会破坏交易对手客户。因此，任何希望执行 IBC 客户端中断升级的 IBC 链都必须执行 IBC 升级，以允许交易对手客户端安全地升级到新的轻客户端。 -1. The [quick-guide](./quick-guide.md) describes how IBC-connected chains can perform client-breaking upgrades and how relayers can securely upgrade counterparty clients using the Cosmos SDK. -2. The [developer-guide](./developer-guide.md) is a guide for developers intending to develop IBC client implementations with upgrade functionality. +1. [quick-guide](./quick-guide.md) 描述了 IBC 连接的链如何执行客户端中断升级以及中继器如何使用 Cosmos SDK 安全地升级交易对手客户端。 +2. [developer-guide](./developer-guide.md) 是为打算开发具有升级功能的 IBC 客户端实现的开发人员提供的指南。 \ No newline at end of file diff --git a/docs/ja/ibc/upgrades/developer-guide.md b/docs/ja/ibc/upgrades/developer-guide.md index 41990abfed4b..ca85ebef0da0 100644 --- a/docs/ja/ibc/upgrades/developer-guide.md +++ b/docs/ja/ibc/upgrades/developer-guide.md @@ -1,10 +1,10 @@ -# IBC Client Developer Guide to Upgrades +# IBC 客户端开发人员升级指南 -Learn how to implement upgrade functionality for your custom IBC client. {synopsis} +了解如何为您的自定义 IBC 客户端实施升级功能。 {概要} -As mentioned in the [README](./README.md), it is vital that high-value IBC clients can upgrade along with their underlying chains to avoid disruption to the IBC ecosystem. Thus, IBC client developers will want to implement upgrade functionality to enable clients to maintain connections and channels even across chain upgrades. +正如 [README](./README.md) 中提到的，高价值 IBC 客户可以与其底层链一起升级以避免对 IBC 生态系统的破坏至关重要。 因此，IBC 客户端开发人员将希望实现升级功能，使客户端即使在链升级中也能保持连接和通道。 -The IBC protocol allows client implementations to provide a path to upgrading clients given the upgraded client state, upgraded consensus state and proofs for each. +IBC 协议允许客户端实现提供升级客户端的路径，给定升级的客户端状态、升级的共识状态和每个证明。 ```go // Upgrade functions @@ -24,17 +24,17 @@ VerifyUpgradeAndUpdateState( ) (upgradedClient ClientState, upgradedConsensus ConsensusState, err error) ``` -Note that the clients should have prior knowledge of the merkle path that the upgraded client and upgraded consensus states will use. The height at which the upgrade has occurred should also be encoded in the proof. The Tendermint client implementation accomplishes this by including an `UpgradePath` in the ClientState itself, which is used along with the upgrade height to construct the merkle path under which the client state and consensus state are committed. +请注意，客户端应该事先了解升级的客户端和升级的共识状态将使用的默克尔路径。发生升级的高度也应在证明中编码。 Tendermint 客户端实现通过在 ClientState 本身中包含一个 `UpgradePath` 来实现这一点，它与升级高度一起用于构建提交客户端状态和共识状态的默克尔路径。 -Developers must ensure that the `UpgradeClientMsg` does not pass until the last height of the old chain has been committed, and after the chain upgrades, the `UpgradeClientMsg` should pass once and only once on all counterparty clients. +开发者必须确保`UpgradeClientMsg`在旧链的最后一个高度提交之前不会通过，并且在链升级后，`UpgradeClientMsg`应该在所有交易对手客户端上只通过一次。 -Developers must ensure that the new client adopts all of the new Client parameters that must be uniform across every valid light client of a chain (chain-chosen parameters), while maintaining the Client parameters that are customizable by each individual client (client-chosen parameters) from the previous version of the client. +开发人员必须确保新客户端采用所有新客户端参数，这些参数必须在链的每个有效轻客户端上统一(链选择参数)，同时维护可由每个单独客户端自定义的客户端参数(客户端选择参数) ) 来自先前版本的客户端。 -Upgrades must adhere to the IBC Security Model. IBC does not rely on the assumption of honest relayers for correctness. Thus users should not have to rely on relayers to maintain client correctness and security (though honest relayers must exist to maintain relayer liveness). While relayers may choose any set of client parameters while creating a new `ClientState`, this still holds under the security model since users can always choose a relayer-created client that suits their security and correctness needs or create a Client with their desired parameters if no such client exists. +升级必须遵守 IBC 安全模型。 IBC 不依赖于诚实中继者的正确性假设。因此，用户不应该依赖中继器来维护客户端的正确性和安全性(尽管必须存在诚实的中继器才能保持中继器的活跃度)。虽然中继器可以在创建新的“ClientState”时选择任何一组客户端参数，但这仍然适用于安全模型，因为用户始终可以选择适合其安全性和正确性需求的中继器创建的客户端，或者在以下情况下创建具有所需参数的客户端不存在这样的客户。 -However, when upgrading an existing client, one must keep in mind that there are already many users who depend on this client's particular parameters. We cannot give the upgrading relayer free choice over these parameters once they have already been chosen. This would violate the security model since users who rely on the client would have to rely on the upgrading relayer to maintain the same level of security. Thus, developers must make sure that their upgrade mechanism allows clients to upgrade the chain-specified parameters whenever a chain upgrade changes these parameters (examples in the Tendermint client include `UnbondingPeriod`, `ChainID`, `UpgradePath`, etc.), while ensuring that the relayer submitting the `UpgradeClientMsg` cannot alter the client-chosen parameters that the users are relying upon (examples in Tendermint client include `TrustingPeriod`, `TrustLevel`, `MaxClockDrift`, etc). +但是，在升级现有客户端时，必须记住已经有许多用户依赖于该客户端的特定参数。一旦这些参数已经被选择，我们就不能让升级中继器自由选择这些参数。这将违反安全模型，因为依赖客户端的用户将不得不依赖升级中继器来维持相同级别的安全性。因此，开发人员必须确保他们的升级机制允许客户端在链升级更改这些参数时升级链指定的参数(Tendermint 客户端中的示例包括 `UnbondingPeriod`、`ChainID`、`UpgradePath` 等)，而确保提交 `UpgradeClientMsg` 的中继器不能更改用户所依赖的客户端选择的参数(Tendermint 客户端中的示例包括 `TrustingPeriod`、`TrustLevel`、`MaxClockDrift` 等)。 -Developers should maintain the distinction between Client parameters that are uniform across every valid light client of a chain (chain-chosen parameters), and Client parameters that are customizable by each individual client (client-chosen parameters); since this distinction is necessary to implement the `ZeroCustomFields` method in the `ClientState` interface: +开发人员应区分链的每个有效轻客户端统一的客户端参数(链选择参数)和每个单独客户端可自定义的客户端参数(客户端选择参数)；因为这种区别对于在 `ClientState` 接口中实现 `ZeroCustomFields` 方法是必要的: ```go // Utility function that zeroes out any client customizable fields in client state @@ -43,4 +43,4 @@ Developers should maintain the distinction between Client parameters that are un ZeroCustomFields() ClientState ``` -Counterparty clients can upgrade securely by using all of the chain-chosen parameters from the chain-committed `UpgradedClient` and preserving all of the old client-chosen parameters. This enables chains to securely upgrade without relying on an honest relayer, however it can in some cases lead to an invalid final `ClientState` if the new chain-chosen parameters clash with the old client-chosen parameter. This can happen in the Tendermint client case if the upgrading chain lowers the `UnbondingPeriod` (chain-chosen) to a duration below that of a counterparty client's `TrustingPeriod` (client-chosen). Such cases should be clearly documented by developers, so that chains know which upgrades should be avoided to prevent this problem. The final upgraded client should also be validated in `VerifyUpgradeAndUpdateState` before returning to ensure that the client does not upgrade to an invalid `ClientState`. +交易对手客户端可以通过使用链提交的“UpgradedClient”中的所有链选择参数并保留所有旧的客户端选择参数来安全地升级。 这使链能够在不依赖诚实中继器的情况下安全地升级，但是在某些情况下，如果新的链选择参数与旧的客户端选择参数发生冲突，它可能会导致无效的最终“ClientState”。 如果升级链将“UnbondingPeriod”(链选择)降低到低于交易对手客户“TrustingPeriod”(客户端选择)的持续时间，则在 Tendermint 客户端情况下可能会发生这种情况。 此类情况应由开发人员明确记录，以便链知道应避免进行哪些升级以防止出现此问题。 最终升级的客户端还应在返回之前在“VerifyUpgradeAndUpdateState”中进行验证，以确保客户端不会升级到无效的“ClientState”。 \ No newline at end of file diff --git a/docs/ja/ibc/upgrades/quick-guide.md b/docs/ja/ibc/upgrades/quick-guide.md index 3027d05ad3a4..47652345cbe3 100644 --- a/docs/ja/ibc/upgrades/quick-guide.md +++ b/docs/ja/ibc/upgrades/quick-guide.md @@ -1,50 +1,50 @@ -# How to Upgrade IBC Chains and their Clients +# 如何升级 IBC 链及其客户端 -Learn how to upgrade your chain and counterparty clients. {synopsis} +了解如何升级您的链和交易对手客户。 {概要} -The information in this doc for upgrading chains is relevant to Cosmos SDK chains. However, the guide for counterparty clients is relevant to any Tendermint client that enables upgrades. +本文档中有关升级链的信息与 Cosmos SDK 链相关。但是，针对交易对手客户的指南与任何支持升级的 Tendermint 客户端相关。 -### IBC Client Breaking Upgrades +### IBC 客户端中断升级 -IBC-connected chains must perform an IBC upgrade if their upgrade will break counterparty IBC clients. The current IBC protocol supports upgrading tendermint chains for a specific subset of IBC-client-breaking upgrades. Here is the exhaustive list of IBC client-breaking upgrades and whether the IBC protocol currently supports such upgrades. +如果 IBC 连接链的升级会破坏交易对手 IBC 客户端，则它们必须执行 IBC 升级。当前的 IBC 协议支持针对 IBC 客户端破坏升级的特定子集升级 Tendermint 链。以下是 IBC 客户端破坏性升级的详尽列表以及 IBC 协议当前是否支持此类升级。 -IBC currently does **NOT** support unplanned upgrades. All of the following upgrades must be planned and committed to in advance by the upgrading chain, in order for counterparty clients to maintain their connections securely. +IBC 目前确实**不**支持计划外升级。以下所有升级都必须由升级链提前计划和承诺，以便交易对手客户安全地保持其连接。 -Note: Since upgrades are only implemented for Tendermint clients, this doc only discusses upgrades on Tendermint chains that would break counterparty IBC Tendermint Clients. +注意:由于升级仅针对 Tendermint 客户端实施，本文档仅讨论会破坏交易对手 IBC Tendermint 客户端的 Tendermint 链上的升级。 -1. Changing the Chain-ID: **Supported** -2. Changing the UnbondingPeriod: **Partially Supported**, chains may increase the unbonding period with no issues. However, decreasing the unbonding period may irreversibly break some counterparty clients. Thus, it is **not recommended** that chains reduce the unbonding period. -3. Changing the height (resetting to 0): **Supported**, so long as chains remember to increment the revision number in their chain-id. -4. Changing the ProofSpecs: **Supported**, this should be changed if the proof structure needed to verify IBC proofs is changed across the upgrade. Ex: Switching from an IAVL store, to a SimpleTree Store -5. Changing the UpgradePath: **Supported**, this might involve changing the key under which upgraded clients and consensus states are stored in the upgrade store, or even migrating the upgrade store itself. -6. Migrating the IBC store: **Unsupported**, as the IBC store location is negotiated by the connection. -7. Upgrading to a backwards compatible version of IBC: Supported -8. Upgrading to a non-backwards compatible version of IBC: **Unsupported**, as IBC version is negotiated on connection handshake. -9. Changing the Tendermint LightClient algorithm: **Partially Supported**. Changes to the light client algorithm that do not change the ClientState or ConsensusState struct may be supported, provided that the counterparty is also upgraded to support the new light client algorithm. Changes that require updating the ClientState and ConsensusState structs themselves are theoretically possible by providing a path to translate an older ClientState struct into the new ClientState struct; however this is not currently implemented. +1.更改链ID:**支持** +2. 更改 UnbondingPeriod:**部分支持**，链可能会增加解绑时间，没有问题。然而，缩短解绑期可能会不可逆转地破坏一些交易对手客户。因此，**不建议**链条缩短解绑期。 +3. 更改高度(重置为 0):**支持**，只要链记住在其链 ID 中增加修订号。 +4. 更改 ProofSpecs:**支持**，如果在升级过程中验证 IBC 证明所需的证明结构发生变化，则应更改此项。例如:从 IAVL 存储切换到 SimpleTree 存储 +5.更改升级路径:**支持**，这可能涉及更改升级存储中存储升级客户端和共识状态的密钥，甚至迁移升级存储本身。 +6. 迁移 IBC 存储:**不支持**，因为 IBC 存储位置由连接协商。 +7. 升级到向后兼容的 IBC 版本:支持 +8. 升级到非向后兼容的 IBC 版本:**不支持**，因为 IBC 版本是在连接握手时协商的。 +9. 更改 Tendermint LightClient 算法:**部分支持**。可能支持不改变 ClientState 或 ConsensusState 结构的轻客户端算法更改，前提是交易对手也升级为支持新的轻客户端算法。通过提供将旧的 ClientState 结构转换为新的 ClientState 结构的路径，理论上可以进行需要更新 ClientState 和 ConsensusState 结构本身的更改；但是，目前尚未实施。 -### Step-by-Step Upgrade Process for Cosmos SDK chains +### Cosmos SDK 链的分步升级过程 -If the IBC-connected chain is conducting an upgrade that will break counterparty clients, it must ensure that the upgrade is first supported by IBC using the list above and then execute the upgrade process described below in order to prevent counterparty clients from breaking. +如果连接 IBC 的链正在进行会破坏交易对手客户端的升级，则必须确保 IBC 首先使用上面的列表支持升级，然后执行下面描述的升级过程，以防止交易对手客户端被破坏。 -1. Create an `UpgradeProposal` with an IBC ClientState in the `UpgradedClientState` field and a `UpgradePlan` in the `Plan` field. Note that the proposal `Plan` must specify an upgrade height **only** (no upgrade time), and the `ClientState` should only include the fields common to all valid clients and zero out any client-customizable fields (such as TrustingPeriod). -2. Vote on and pass the `UpgradeProposal` +1. 创建一个 `UpgradeProposal`，在 `UpgradedClientState` 字段中包含一个 IBC ClientState，在 `Plan` 字段中创建一个 `UpgradePlan`。请注意，提案`Plan` 必须指定升级高度**only**(无升级时间)，并且`ClientState` 应仅包含所有有效客户端共有的字段，并将任何客户端可自定义的字段清零(例如TrustingPeriod )。 +2. 投票通过`UpgradeProposal` -Upon the `UpgradeProposal` passing, the upgrade module will commit the UpgradedClient under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedClient`. On the block right before the upgrade height, the upgrade module will also commit an initial consensus state for the next chain under the key: `upgrade/UpgradedIBCState/{upgradeHeight}/upgradedConsState`. +在“UpgradeProposal”通过后，升级模块将提交key下的UpgradedClient:“upgrade/UpgradedIBCState/{upgradeHeight}/upgradedClient”。在升级高度之前的区块上，升级模块还将为下一条链提交初始共识状态，密钥为:`upgrade/UpgradedIBCState/{upgradeHeight}/upgradedConsState`。 -Once the chain reaches the upgrade height and halts, a relayer can upgrade the counterparty clients to the last block of the old chain. They can then submit the proofs of the `UpgradedClient` and `UpgradedConsensusState` against this last block and upgrade the counterparty client. +一旦链达到升级高度并停止，中继器可以将交易对手客户端升级到旧链的最后一个区块。然后，他们可以针对最后一个区块提交“UpgradedClient”和“UpgradedConsensusState”的证明并升级交易对手客户端。 -### Step-by-Step Upgrade Process for Relayers Upgrading Counterparty Clients +### 中继器升级交易对手的分步升级过程 -Once the upgrading chain has committed to upgrading, relayers must wait till the chain halts at the upgrade height before upgrading counterparty clients. This is because chains may reschedule or cancel upgrade plans before they occur. Thus, relayers must wait till the chain reaches the upgrade height and halts before they can be sure the upgrade will take place. +一旦升级链承诺升级，中继者必须等到链停止在升级高度后才能升级对手客户端。这是因为连锁存储可能会在升级计划发生之前重新安排或取消升级计划。因此，中继者必须等到链达到升级高度并停止，然后才能确定升级会发生。 -Thus, the upgrade process for relayers trying to upgrade the counterparty clients is as follows: +因此，中继器尝试升级交易对手客户端的升级过程如下: -1. Wait for the upgrading chain to reach the upgrade height and halt -2. Query a full node for the proofs of `UpgradedClient` and `UpgradedConsensusState` at the last height of the old chain. -3. Update the counterparty client to the last height of the old chain using the `UpdateClient` msg. -4. Submit an `UpgradeClient` msg to the counterparty chain with the `UpgradedClient`, `UpgradedConsensusState` and their respective proofs. -5. Submit an `UpdateClient` msg to the counterparty chain with a header from the new upgraded chain. +1.等待升级链到达升级高度并停止 +2.查询旧链最后一个高度的`UpgradedClient`和`UpgradedConsensusState`的证明的全节点。 +3. 使用 `UpdateClient` msg 将交易对手客户端更新到旧链的最后一个高度。 +4. 向交易对手链提交“UpgradeClient”消息，其中包含“UpgradedClient”、“UpgradedConsensusState”及其各自的证明。 +5. 向交易对手链提交一个 `UpdateClient` 消息，其中包含来自新升级链的标头。 -The Tendermint client on the counterparty chain will verify that the upgrading chain did indeed commit to the upgraded client and upgraded consensus state at the upgrade height (since the upgrade height is included in the key). If the proofs are verified against the upgrade height, then the client will upgrade to the new client while retaining all of its client-customized fields. Thus, it will retain its old TrustingPeriod, TrustLevel, MaxClockDrift, etc; while adopting the new chain-specified fields such as UnbondingPeriod, ChainId, UpgradePath, etc. Note, this can lead to an invalid client since the old client-chosen fields may no longer be valid given the new chain-chosen fields. Upgrading chains should try to avoid these situations by not altering parameters that can break old clients. For an example, see the UnbondingPeriod example in the supported upgrades section. +交易对手链上的 Tendermint 客户端会在升级高度验证升级链确实提交给升级的客户端和升级的共识状态(因为升级高度包含在密钥中)。如果根据升级高度验证证明，则客户端将升级到新客户端，同时保留其所有客户端自定义字段。因此，它将保留其旧的 TrustingPeriod、TrustLevel、MaxClockDrift 等；同时采用新的链指定字段，例如 UnbondingPeriod、ChainId、UpgradePath 等。请注意，这可能会导致客户端无效，因为在给定新的链选择字段的情况下，旧的客户端选择字段可能不再有效。升级链应该通过不改变可能破坏旧客户端的参数来尝试避免这些情况。有关示例，请参阅支持的升级部分中的 UnbondingPeriod 示例。 -The upgraded consensus state will serve purely as a basis of trust for future `UpdateClientMsgs` and will not contain a consensus root to perform proof verification against. Thus, relayers must submit an `UpdateClientMsg` with a header from the new chain so that the connection can be used for proof verification again. +升级后的共识状态将纯粹作为未来“UpdateClientMsgs”的信任基础，并且不包含用于执行证明验证的共识根。因此，中继者必须提交一个带有来自新链的标头的“UpdateClientMsg”，以便连接可以再次用于证明验证。 \ No newline at end of file diff --git a/docs/ja/intro/README.md b/docs/ja/intro/README.md index 219c08ba240c..2c196ba1449a 100644 --- a/docs/ja/intro/README.md +++ b/docs/ja/intro/README.md @@ -1,10 +1,10 @@ -# Introduction +# 介绍 -This introduction gives a quick start on the Cosmos SDK. +本介绍提供了 Cosmos SDK 的快速入门。 -1. [Overview](./overview.md) -2. [Application-Specific Blockchains](./why-app-specific.md) -3. [Architecture of a Cosmos SDK Application](./sdk-app-architecture.md) -4. [Cosmos SDK Design Overview](./sdk-design.md) +1. [概述](./overview.md) +2. [特定应用区块链](./why-app-specific.md) +3. [Cosmos SDK 应用架构](./sdk-app-architecture.md) +4. [Cosmos SDK 设计概述](./sdk-design.md) -After reading the introduction material, head over to the [basics](../basics/README.md) to learn more. +阅读介绍材料后，请前往 [basics](../basics/README.md) 了解更多信息。 diff --git a/docs/ja/intro/overview.md b/docs/ja/intro/overview.md index 5755be9ef1b2..d8629bc01515 100644 --- a/docs/ja/intro/overview.md +++ b/docs/ja/intro/overview.md @@ -1,33 +1,33 @@ -# High-level Overview +# 高级概述 -## What is the Cosmos SDK? +## 什么是 Cosmos 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**. +[Cosmos SDK](https://github.com/cosmos/cosmos-sdk) 是一个开源框架，用于构建多资产公共权益证明(PoS)区块链< /df>，如 Cosmos Hub，以及许可的权威证明 (PoA) 区块链。使用 Cosmos SDK 构建的区块链通常称为 **特定于应用程序的区块链**。 -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 Cosmos 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 that allows developers to better reason about the security of interactions between modules. For a deeper look at capabilities, jump to [Object-Capability Model](../core/ocap.md). +Cosmos SDK 的目标是让开发人员能够轻松地从头开始创建可以与其他区块链进行本地互操作的自定义区块链。我们将 Cosmos SDK 设想为类似 npm 的框架，以在 [Tendermint](https://github.com/tendermint/tendermint) 之上构建安全的区块链应用程序。基于 SDK 的区块链由可组合的 [模块](../building-modules/intro.md) 构建而成，其中大部分是开源的，可供任何开发人员使用。任何人都可以为 Cosmos SDK 创建一个模块，集成已经构建的模块就像将它们导入区块链应用程序一样简单。更重要的是，Cosmos SDK 是一个基于能力的系统，它允许开发人员更好地推理模块之间交互的安全性。要更深入地了解功能，请跳转到 [Object-Capability Model](../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. +当今区块链世界的一个开发范式是像以太坊这样的虚拟机区块链，其中开发通常围绕在现有区块链之上构建分散式应用程序作为一组智能合约。虽然智能合约对于某些用例非常有用，例如一次性应用程序(例如 ICO)，但它们通常无法构建复杂的去中心化平台。更一般地说，智能合约在灵活性、主权和性能方面可能会受到限制。 -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-app-specific.md) 的更多信息。 -## Why the Cosmos SDK? +## 为什么是 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: +Cosmos SDK 是当今构建自定义应用程序特定区块链的最先进框架。以下是您可能要考虑使用 Cosmos SDK 构建分散式应用程序的几个原因: -- The default consensus engine available within the Cosmos 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 Cosmos SDK is open source and designed to make it easy to build blockchains out of composable [modules](../../x/). As the ecosystem of open source Cosmos SDK modules grows, it will become increasingly easier to build complex decentralised platforms with it. -- The Cosmos 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. +- Cosmos SDK 中可用的默认共识引擎是 [Tendermint Core](https://github.com/tendermint/tendermint)。 Tendermint 是现存最(也是唯一)成熟的 BFT 共识引擎。它在整个行业中被广泛使用，被认为是构建权益证明系统的黄金标准共识引擎。 +- Cosmos SDK 是开源的，旨在使从可组合的 [模块](../../x/) 构建区块链变得容易。随着开源 Cosmos SDK 模块生态系统的发展，使用它构建复杂的去中心化平台将变得越来越容易。 +- Cosmos 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/) 或 [Kava](https://www.kava.io/)。 [更多](https://cosmos.network/ecosystem) 是基于 Cosmos SDK 构建的。 -## Getting started with the Cosmos SDK +## Cosmos SDK 入门 -- Learn more about the [architecture of a Cosmos SDK application](./sdk-app-architecture.md) -- Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://cosmos.network/docs/tutorial) +- 详细了解 [Cosmos SDK 应用程序的架构](./sdk-app-architecture.md) +- 通过 [Cosmos SDK 教程](https://cosmos.network/docs/tutorial) 了解如何从头开始构建特定于应用程序的区块链 -## Next {hide} +## 下一个 {hide} -Learn about [application-specific blockchains](./why-app-specific.md) {hide} +了解 [特定于应用程序的区块链](./why-app-specific.md) {hide} \ No newline at end of file diff --git a/docs/ja/intro/sdk-app-architecture.md b/docs/ja/intro/sdk-app-architecture.md index fff0b29fa676..46a8833dac46 100644 --- a/docs/ja/intro/sdk-app-architecture.md +++ b/docs/ja/intro/sdk-app-architecture.md @@ -1,12 +1,12 @@ -# Blockchain Architecture +# 区块链架构 -## State machine +## 状态机 -At its core, a blockchain is a [replicated deterministic state machine](https://en.wikipedia.org/wiki/State_machine_replication). +区块链的核心是一个[复制的确定性状态机](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 和一个事务 T，状态机将返回一个新的状态 S'。 ``` +--------+ +--------+ @@ -16,7 +16,7 @@ Given a state S and a transaction T, the state machine will return a new state S +--------+ +--------+ ``` -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 和一个交易块 B，状态机将返回一个新的状态 S'。 ``` +--------+ +--------+ @@ -26,13 +26,13 @@ In practice, the transactions are bundled in blocks to make the process more eff +--------+ +--------+ ``` -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 Cosmos SDK will be described more in depth in the following sections. But first, let us see how the state-machine is replicated using **Tendermint**. +Cosmos SDK 为开发人员提供了最大的灵活性来定义其应用程序的状态、事务类型和状态转换函数。 使用 Cosmos SDK 构建状态机的过程将在以下部分进行更深入的描述。 但首先，让我们看看如何使用 **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. +多亏了 Cosmos SDK，开发人员只需定义状态机，[*Tendermint*](https://tendermint.com/docs/introduction/what-is-tendermint.html) 将为他们处理网络上的复制 . ``` ^ +-------------------------------+ ^ @@ -50,13 +50,13 @@ Blockchain node | | Consensus | | v +-------------------------------+ v ``` -[Tendermint](https://docs.tendermint.com/v0.34/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. +[Tendermint](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html) 是一个与应用程序无关的引擎，负责处理区块链。实际上，这意味着 Tendermint 负责传播和排序交易字节。 Tendermint Core 依靠同名的拜占庭容错 (BFT) 算法来就交易顺序达成共识。 -The Tendermint [consensus algorithm](https://docs.tendermint.com/v0.34/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://docs.tendermint.com/v0.34/spec/consensus/consensus.html#prevote-step-height-h-round-r)* and a *[precommit](https://docs.tendermint.com/v0.34/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. +Tendermint [共识算法](https://docs.tendermint.com/v0.34/introduction/what-is-tendermint.html#consensus-overview) 与一组称为 *Validators* 的特殊节点一起工作。验证者负责向区块链添加交易块。在任何给定的块上，都有一个验证器集 V。 V 中的一个验证器由算法选择作为下一个块的提议者。如果超过三分之二的 V 签署了 *[prevote](https://docs.tendermint.com/v0.34/spec/consensus/consensus.html#prevote-step-height-h-round -r)* 和一个 *[precommit](https://docs.tendermint.com/v0.34/spec/consensus/consensus.html#precommit-step-height-h-round-r)*，以及如果它包含的所有交易都是有效的。验证器集可以通过写入状态机的规则进行更改。 ## ABCI -Tendermint passes transactions to the application through an interface called the [ABCI](https://docs.tendermint.com/v0.34/spec/abci/), which the application must implement. +Tendermint 通过名为 [ABCI](https://docs.tendermint.com/v0.34/spec/abci/) 的接口将交易传递给应用程序，应用程序必须实现该接口。 ``` +---------------------+ @@ -76,18 +76,18 @@ Tendermint passes transactions to the application through an interface called th +---------------------+ ``` -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. +请注意，**Tendermint 仅处理交易字节**。它不知道这些字节的含义。 Tendermint 所做的就是确定性地对这些交易字节进行排序。 Tendermint 通过 ABCI 将字节传递给应用程序，并期望返回代码来通知它包含在交易中的消息是否已成功处理。 -Here are the most important messages of the ABCI: +以下是 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://docs.tendermint.com/v0.34/tendermint-core/mempool.html#mempool) 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://docs.tendermint.com/v0.34/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](../building-modules/msg-services.md) RPC 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. +- `CheckTx`:当 Tendermint Core 收到交易时，会将其传递给应用程序以检查是否满足一些基本要求。 `CheckTx` 用于保护全节点的内存池免受垃圾邮件交易的影响。一个名为 [`AnteHandler`](../basics/gas-fees.md#antehandler) 的特殊处理程序用于执行一系列验证步骤，例如检查是否有足够的费用和验证签名。如果检查有效，则将交易添加到 [mempool](https://docs.tendermint.com/v0.34/tendermint-core/mempool.html#mempool) 并中继到对等节点。请注意，“CheckTx”不会处理交易(即不会发生状态修改)，因为它们尚未包含在区块中。 +- `DeliverTx`:当 Tendermint Core 收到一个[有效区块](https://docs.tendermint.com/v0.34/spec/blockchain/blockchain.html#validation) 时，区块中的每笔交易都会被传递给通过“DeliverTx”申请以进行处理。正是在这个阶段发生了状态转换。 `AnteHandler` 与实际的 [`Msg` 服务](../building-modules/msg-services.md) RPC 一起为事务中的每条消息再次执行。 +- `BeginBlock`/`EndBlock`:这些消息在每个块的开始和结束时执行，无论该块是否包含交易。触发逻辑的自动执行很有用。但是请谨慎进行，因为计算成本高的循环可能会减慢您的区块链，如果循环是无限的，甚至会冻结它。 -Find a more detailed view of the ABCI methods from the [Tendermint docs](https://docs.tendermint.com/v0.34/spec/abci/abci.html#overview). +从 [Tendermint 文档](https://docs.tendermint.com/v0.34/spec/abci/abci.html#overview) 中找到有关 ABCI 方法的更详细视图。 -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). +任何基于 Tendermint 构建的应用程序都需要实现 ABCI 接口，以便与底层的本地 Tendermint 引擎进行通信。幸运的是，您不必实现 ABCI 接口。 Cosmos SDK 以 [baseapp](./sdk-design.md#baseapp) 的形式提供了它的样板实现。 -## Next {hide} +## 下一个 {hide} -Read about the [high-level design principles of the Cosmos SDK](./sdk-design.md) {hide} +阅读 [Cosmos SDK 的高级设计原则](./sdk-design.md) {hide} \ No newline at end of file diff --git a/docs/ja/intro/sdk-design.md b/docs/ja/intro/sdk-design.md index ce5fb12c5db0..10e53533d641 100644 --- a/docs/ja/intro/sdk-design.md +++ b/docs/ja/intro/sdk-design.md @@ -1,35 +1,35 @@ -# Main Components of the Cosmos SDK +# Cosmos SDK 的主要组成部分 -The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the Cosmos 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. +Cosmos SDK 是一个框架，可促进在 Tendermint 之上开发安全状态机。 Cosmos SDK 的核心是 Golang 中 [ABCI](./sdk-app-architecture.md#abci) 的样板实现。它带有一个 [`multistore`](../core/store.md#multistore) 来持久化数据和一个 [`router`](../core/baseapp.md#routing) 来处理事务。 -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`: +下面是一个简化的视图，说明在通过“DeliverTx”从 Tendermint 传输时，构建在 Cosmos SDK 之上的应用程序如何处理事务: -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. +1. 解码从 Tendermint 共识引擎接收到的 `transactions`(记住 Tendermint 只处理 `[]bytes`)。 +2. 从 `transactions` 中提取 `messages` 并进行基本的完整性检查。 +3. 将每条消息路由到适当的模块，以便对其进行处理。 +4. 提交状态更改。 -## `baseapp` +## `基础应用` -`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection 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 Cosmos SDK application tutorial: +`baseapp` 是 Cosmos SDK 应用程序的样板实现。它带有 ABCI 的实现，用于处理与底层共识引擎的连接。通常，Cosmos SDK 应用程序通过将“baseapp”嵌入到 [`app.go`](../basics/app-anatomy.md#core-application-file) 中来扩展它。请参阅 Cosmos SDK 应用程序教程中的示例: +++ 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). +`baseapp` 的目标是在存储和可扩展状态机之间提供一个安全的接口，同时尽可能少地定义状态机(忠于 ABCI)。 -For more on `baseapp`, please click [here](../core/baseapp.md). +有关`baseapp`的更多信息，请单击[此处](../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. +Cosmos SDK 提供了一个 [`multistore`](../core/store.md#multistore) 用于持久化状态。 multistore 允许开发者声明任意数量的 [`KVStores`](../core/store.md#base-layer-kvstores)。这些 `KVStores` 只接受 `[]byte` 类型作为值，因此任何自定义结构都需要在存储之前使用 [a codec](../core/encoding.md) 进行编组。 -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) +多存储抽象用于将状态划分为不同的隔间，每个隔间由自己的模块管理。有关 multistore 的更多信息，请单击 [此处](../core/store.md#multistore) -## Modules +## 模块 -The power of the Cosmos SDK lies in its modularity. Cosmos 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 Cosmos SDK is responsible for routing each message to its respective module. +Cosmos SDK 的强大之处在于其模块化。 Cosmos SDK 应用程序是通过聚合一组可互操作的模块来构建的。每个模块定义状态的一个子集并包含自己的消息/事务处理器，而 Cosmos SDK 负责将每条消息路由到其各自的模块。 -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: +下面是一个简化的视图，当它在有效块中接收时，每个全节点的应用程序如何处理交易: ``` + @@ -76,16 +76,16 @@ Here is a simplified view of how a transaction is processed by the application o 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. +每个模块都可以看作是一个小的状态机。开发者需要定义模块处理的状态的子集，以及修改状态的自定义消息类型(*注:*`messages`是`baseapp`从`transactions`中提取的)。一般来说，每个模块在 `multistore` 中声明自己的 `KVStore` 来持久化它定义的状态的子集。大多数开发人员在构建自己的模块时需要访问其他 3rd 方模块。由于 Cosmos SDK 是一个开放的框架，部分模块可能是恶意的，这意味着需要安全原则来推理模块间的交互。这些原则基于 [object-capabilities](../core/ocap.md)。实际上，这意味着不是让每个模块为其他模块保留访问控制列表，而是每个模块实现称为“keeper”的特殊对象，可以将其传递给其他模块以授予一组预定义的功能。 -Cosmos SDK modules are defined in the `x/` folder of the Cosmos SDK. Some core modules include: +Cosmos SDK 模块定义在 Cosmos SDK 的 `x/` 文件夹中。一些核心模块包括: -- `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. +- `x/auth`:用于管理账户和签名。 +- `x/bank`:用于启用代币和代币转账。 +- `x/staking` + `x/slashing`:用于构建权益证明区块链。 -In addition to the already existing modules in `x/`, that anyone can use in their app, the Cosmos SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://tutorials.cosmos.network/). +除了 `x/` 中已经存在的模块，任何人都可以在他们的应用程序中使用，Cosmos SDK 允许您构建自己的自定义模块。您可以查看 [教程中的示例](https://tutorials.cosmos.network/)。 -## Next {hide} +## 下一个 {hide} -Learn more about the [anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {hide} +详细了解 [Cosmos SDK 应用程序剖析](../basics/app-anatomy.md) {hide} \ No newline at end of file diff --git a/docs/ja/intro/why-app-specific.md b/docs/ja/intro/why-app-specific.md index eb3e850e6676..fbb8113393f1 100644 --- a/docs/ja/intro/why-app-specific.md +++ b/docs/ja/intro/why-app-specific.md @@ -1,10 +1,10 @@ -# 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 interact with the nodes. +特定于应用程序的区块链是为操作单个应用程序而定制的区块链。 开发人员不是在像以太坊这样的底层区块链之上构建分散式应用程序，而是从头开始构建自己的区块链。 这意味着构建一个全节点客户端、一个轻客户端，以及与节点交互的所有必要接口(CLI、REST 等)。 ``` ^ +-------------------------------+ ^ @@ -22,56 +22,56 @@ Blockchain node | | Consensus | | 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. +早在 2014 年，以太坊等虚拟机区块链就满足了对更多可编程性的需求。当时，可用于构建去中心化应用程序的选项非常有限。大多数开发人员会建立在复杂且有限的比特币脚本语言之上，或者分叉难以使用和定制的比特币代码库。 -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: +虚拟机区块链带来了新的价值主张。他们的状态机包含一个虚拟机，能够解释称为智能合约的图灵完备程序。这些智能合约非常适合一次性事件(例如 ICO)等用例，但它们可能无法构建复杂的去中心化平台。原因如下: -- 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 severely 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 10x 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. +- 智能合约通常是用特定的编程语言开发的，可以被底层虚拟机解释。这些编程语言通常不成熟，并且本质上受到虚拟机本身的限制。例如，以太坊虚拟机不允许开发者实现代码的自动执行。开发者也受限于 EVM 的基于账户的系统，他们只能从有限的一组功能中进行选择以进行加密操作。这些只是示例，但它们暗示智能合约环境通常缺乏**灵活性**。 +- 智能合约都由同一个虚拟机运行。这意味着它们在争夺资源，这会严重制约**性能**。即使状态机被分成多个子集(例如通过分片)，智能合约仍然需要由虚拟机进行交互，与在状态机级别实现的本机应用程序相比，这将限制性能(我们的基准测试显示，删除虚拟机后，性能提高了 10 倍)。 +- 智能合约共享相同底层环境的另一个问题是由此导致的**主权**限制。去中心化应用程序是一个涉及多个参与者的生态系统。如果应用程序建立在通用虚拟机区块链上，利益相关者对其应用程序的主权非常有限，最终会被底层区块链的治理所取代。如果应用程序中存在错误，则几乎无能为力。 -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://docs.tendermint.com/v0.34/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. +- 在 Cosmos 区块链中，状态机通常通过称为 [ABCI](https://docs.tendermint.com/v0.34/spec/abci/) 的接口连接到底层共识引擎。这个接口可以用任何编程语言包装，这意味着开发人员可以用他们选择的编程语言构建他们的状态机。 -- 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), ...). Typically the choice will be made 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. +- 开发人员可以在多个框架中进行选择来构建他们的状态机。目前使用最广泛的是 Cosmos SDK，但也有其他的(例如 [Lotion](https://github.com/nomic-io/lotion)、[Weave](https://github.com/iov-one/编织)，...)。通常，将根据他们想要使用的编程语言做出选择(Cosmos SDK 和 Weave 使用 Golang，Lotion 使用 Javascript，......)。 +- ABCI 还允许开发人员交换其特定于应用程序的区块链的共识引擎。今天，只有 Tendermint 可以投入生产，但未来预计会出现其他共识引擎。 +- 即使他们满足于框架和共识引擎，如果他们的原始形式不能完全符合他们的要求，开发人员仍然可以自由地调整它们。 +- 开发人员可以自由探索各种权衡(例如，验证器数量与交易吞吐量、安全性与异步可用性等)和设计选择(用于存储的 DB 或 IAVL 树、UTXO 或帐户模型等) . +- 开发者可以实现代码的自动执行。在 Cosmos SDK 中，可以在每个块的开头和结尾自动触发逻辑。他们还可以自由选择在他们的应用程序中使用的加密库，而不是在虚拟机区块链的情况下受到底层环境提供的内容的限制。 -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 alternatives for each of the core building blocks will emerge, giving more options to developers. +上面的列表包含一些示例，显示了特定于应用程序的区块链为开发人员提供了多少灵活性。 Cosmos 和 Cosmos SDK 的目标是使开发人员工具尽可能通用和可组合，以便堆栈的每个部分都可以在不失去兼容性的情况下进行分叉、调整和改进。随着社区的发展，每个核心构建块的更多替代方案将会出现，为开发人员提供更多选择。 -### 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 blockchain. Next are some of the benefits an application-specific blockchain brings in terms of performance: +使用智能合约构建的去中心化应用程序本质上受到底层环境的性能限制。对于去中心化应用程序优化性能，它需要构建为特定于应用程序的区块链。接下来是特定于应用程序的区块链在性能方面带来的一些好处: -- Developers of application-specific blockchains can choose to operate with a novel consensus engine such as Tendermint BFT. Compared to Proof-of-Work (used by most virtual-machine blockchains today), it offers significant gains in throughput. -- An application-specific blockchain only operates a single application, so that the application does not compete with others for computation and storage. This is the opposite of most non-sharded virtual-machine blockchains today, where smart contracts all compete for computation and storage. -- 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. +- 特定应用区块链的开发人员可以选择使用一种新颖的共识引擎，例如 Tendermint BFT。与工作量证明(当今大多数虚拟机区块链使用)相比，它在吞吐量方面提供了显着的收益。 +- 特定于应用程序的区块链仅运行单个应用程序，因此该应用程序不会与其他应用程序竞争计算和存储。这与当今大多数非分片虚拟机区块链相反，智能合约都在竞争计算和存储。 +- 即使虚拟机区块链提供基于应用程序的分片以及高效的共识算法，性能仍然会受到虚拟机本身的限制。真正的吞吐量瓶颈是状态机，并且需要由虚拟机解释交易显着增加了处理它们的计算复杂性。 -### 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. +- 开发人员可以在构建特定于应用程序的区块链时选择 Golang 等经过验证的编程语言，而不是通常不成熟的智能合约编程语言。 +- 开发人员不受底层虚拟机提供的加密功能的限制。他们可以使用自己的自定义密码学，并依赖经过充分审核的密码库。 +- 开发人员不必担心底层虚拟机中的潜在错误或可利用机制，从而更容易推理应用程序的安全性。 -### 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 of the application have full control over the entire chain. This ensures that the community will not be stuck if a bug is discovered, and that it has the freedom to choose how it is going to evolve. +这里的根本问题是应用程序的治理和网络的治理不一致​​。这个问题由特定于应用程序的区块链解决。由于特定于应用程序的区块链专门运行单个应用程序，因此应用程序的利益相关者可以完全控制整个链。这确保了社区在发现错误时不会被卡住，并且可以自由选择如何发展。 -## Next {hide} +## 下一个 {hide} -Learn more about the [high-level architecture](./sdk-app-architecture.md) of a Cosmos SDK application {hide} +详细了解 Cosmos SDK 应用程序的 [高级架构](./sdk-app-architecture.md) {hide} \ No newline at end of file diff --git a/docs/ja/migrations/README.md b/docs/ja/migrations/README.md index 805322d2b3f2..1d98ec9e9ce4 100644 --- a/docs/ja/migrations/README.md +++ b/docs/ja/migrations/README.md @@ -1,6 +1,6 @@ -# Migrations +# 迁移 -This document contains all the migration guides to update your app and modules to Cosmos SDK v0.44. +本文档包含将您的应用程序和模块更新到 Cosmos SDK v0.44 的所有迁移指南。 -1. [Chain Upgrade Guide to v0.44](./chain-upgrade-guide-044.md) -2. [REST Endpoints Migration](./rest.md) +1. [链升级指南到v0.44](./chain-upgrade-guide-044.md) +2. [REST端点迁移](./rest.md) \ No newline at end of file diff --git a/docs/ja/migrations/chain-upgrade-guide-044.md b/docs/ja/migrations/chain-upgrade-guide-044.md index 380881be0291..9c4750ac56a5 100644 --- a/docs/ja/migrations/chain-upgrade-guide-044.md +++ b/docs/ja/migrations/chain-upgrade-guide-044.md @@ -1,56 +1,56 @@ -# Chain Upgrade Guide to v0.44 +# 链升级指南到 v0.44 -This document provides guidelines for a chain upgrade from v0.42 to v0.44 and an example of the upgrade process using `simapp`. {synopsis} +本文档提供了从 v0.42 到 v0.44 的链式升级指南以及使用“simapp”的升级过程示例。 {概要} -::: tip -You must upgrade to Stargate v0.42 before upgrading to v0.44. If you have not done so, please see [Chain Upgrade Guide to v0.42](/v0.42/migrations/chain-upgrade-guide-040.html). Please note, v0.43 was discontinued shortly after being released and all chains should upgrade directly to v0.44 from v0.42. +::: 小费 +在升级到 v0.44 之前，您必须升级到 Stargate v0.42。如果您还没有这样做，请参阅[链升级指南到 v0.42](/v0.42/migrations/chain-upgrade-guide-040.html)。请注意，v0.43 发布后不久就停产了，所有链应直接从 v0.42 升级到 v0.44。 ::: -## Prerequisite Readings +## 先决条件阅读 -- [Upgrading Modules](../building-modules/upgrade.html) {prereq} -- [In-Place Store Migrations](../core/upgrade.html) {prereq} +- [升级模块](../building-modules/upgrade.html) {prereq} +- [就地存储迁移](../core/upgrade.html) {prereq} - [Cosmovisor](../run-node/cosmovisor.html) {prereq} -Cosmos SDK v0.44 introduces a new way of handling chain upgrades that no longer requires exporting state to JSON, making the necesssary changes, and then creating a new chain with the modified JSON as the new genesis file. +Cosmos SDK v0.44 引入了一种处理链升级的新方法，不再需要将状态导出到 JSON，进行必要的更改，然后使用修改后的 JSON 作为新的创世文件创建新链。 -The IBC module for the Cosmos SDK has moved to its [own repository](https://github.com/cosmos/ibc-go) for v0.42 and later versions. If you are using IBC, make sure to also go through the [IBC migration docs](https://github.com/cosmos/ibc-go/blob/main/docs/migrations/ibc-migration-043.md). +Cosmos SDK 的 IBC 模块已移至 v0.42 及更高版本的[自己的存储库](https://github.com/cosmos/ibc-go)。如果您正在使用 IBC，请确保还通过 [IBC 迁移文档](https://github.com/cosmos/ibc-go/blob/main/docs/migrations/ibc-migration-043.md)。 -Instead of starting a new chain, the upgrade binary will read the existing database and perform in-place store migrations. This new way of handling chain upgrades can be used alongside [Cosmovisor](../run-node/cosmovisor.html) to make the upgrade process seamless. +升级二进制文件将读取现有数据库并执行就地存储迁移，而不是启动新链。这种处理链升级的新方法可以与 [Cosmovisor](../run-node/cosmovisor.html) 一起使用，使升级过程无缝。 -## In-Place Store Migrations +## 就地存储迁移 -We recommend using [In-Place Store Migrations](../core/upgrade.html) to upgrade your chain from v0.42 to v0.44. The first step is to make sure all your modules follow the [Module Upgrade Guide](../building-modules/upgrade.html). The second step is to add an [upgrade handler](../core/upgrade.html#running-migrations) to `app.go`. +我们建议使用 [In-Place Store Migrations](../core/upgrade.html) 将您的链从 v0.42 升级到 v0.44。第一步是确保您的所有模块都遵循 [模块升级指南](../building-modules/upgrade.html)。第二步是向`app.go`添加一个[升级处理程序](../core/upgrade.html#running-migrations)。 -In this document, we'll provide an example of what the upgrade handler looks like for a chain upgrading module versions for the first time. It's critical to note that the initial consensus version of each module must be set to `1` rather than `0` or else the upgrade handler will re-initialize each module. +在本文档中，我们将首次提供一个示例，说明链升级模块版本的升级处理程序的样子。需要注意的是，每个模块的初始共识版本必须设置为“1”而不是“0”，否则升级处理程序将重新初始化每个模块。 -In addition to migrating existing modules, the upgrade handler also performs store upgrades for new modules. In the example below, we'll be adding store migrations for two new modules made available in v0.44: `x/authz` and `x/feegrant`. +除了迁移现有模块之外，升级处理程序还为新模块执行存储升级。在下面的示例中，我们将为 v0.44 中提供的两个新模块添加存储迁移:`x/authz` 和 `x/feegrant`。 -## Using Cosmovisor +## 使用 Cosmovisor -We recommend validators use [Cosmovisor](../run-node/cosmovisor.html), which is a process manager for running application binaries. For security reasons, we recommend validators build their own upgrade binaries rather than enabling the auto-download option. Validators may still choose to use the auto-download option if the necessary security guarantees are in place (i.e. the URL provided in the upgrade proposal for the downloadable upgrade binary includes a proper checksum). +我们建议验证器使用 [Cosmovisor](../run-node/cosmovisor.html)，这是一个用于运行应用程序二进制文件的进程管理器。出于安全原因，我们建议验证器构建自己的升级二进制文件，而不是启用自动下载选项。如果必要的安全保证到位(即，可下载升级二进制文件的升级建议中提供的 URL 包括正确的校验和)，验证者仍然可以选择使用自动下载选项。 -::: tip -If validators would like to enable the auto-download option, and they are currently running an application using Cosmos SDK `v0.42`, they will need to use Cosmovisor [`v0.1`](https://github.com/cosmos/cosmos-sdk/releases/tag/cosmovisor%2Fv0.1.0). Later versions of Cosmovisor do not support Cosmos SDK `v0.42` or earlier if the auto-download option is enabled. +::: 小费 +如果验证者想要启用自动下载选项，并且他们当前正在使用 Cosmos SDK `v0.42` 运行应用程序，他们将需要使用 Cosmovisor [`v0.1`](https://github.com/ cosmos/cosmos-sdk/releases/tag/cosmovisor%2Fv0.1.0)。如果启用了自动下载选项，更高版本的 Cosmovisor 不支持 Cosmos SDK `v0.42` 或更早版本。 ::: -Validators can use the auto-restart option to prevent unnecessary downtime during the upgrade process. The auto-restart option will automatically restart the chain with the upgrade binary once the chain has halted at the proposed upgrade height. With the auto-restart option, validators can prepare the upgrade binary in advance and then relax at the time of the upgrade. +验证者可以使用自动重启选项来防止升级过程中出现不必要的停机。一旦链在建议的升级高度停止，自动重启选项将使用升级二进制文件自动重启链。使用自动重启选项，验证者可以提前准备升级二进制文件，然后在升级时放松。 -## Migrating app.toml +## 迁移 app.toml -With the update to `v0.44`, new server configuration options have been added to `app.toml`. The updates include new configuration sections for Rosetta and gRPC Web as well as a new configuration option for State Sync. Check out the default [`app.toml`](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/server/config/toml.go) file in the latest version of `v0.44` for more information. +随着对 `v0.44` 的更新，新的服务器配置选项已添加到 `app.toml`。更新包括 Rosetta 和 gRPC Web 的新配置部分以及状态同步的新配置选项。查看最新版本的默认 [`app.toml`](https://github.com/cosmos/cosmos-sdk/blob/release/v0.44.x/server/config/toml.go) 文件`v0.44` 了解更多信息。 -## Example: Simapp Upgrade +## 示例:Simapp 升级 -The following example will walk through the upgrade process using `simapp` as our blockchain application. We will be upgrading `simapp` from v0.42 to v0.44. We will be building the upgrade binary ourselves and enabling the auto-restart option. +以下示例将使用“simapp”作为我们的区块链应用程序来完成升级过程。我们将把 `simapp` 从 v0.42 升级到 v0.44。我们将自己构建升级二进制文件并启用自动重启选项。 -::: tip -In the following example, we start a new chain from `v0.42`. The binary for this version will be the genesis binary. For validators using Cosmovisor for the first time on an existing chain, either the binary for the current version of the chain should be used as the genesis binary (i.e. the starting binary) or validators should update the `current` symbolic link to point to the upgrade directory. For more information, see [Cosmovisor](../run-node/cosmovisor.html). +::: 小费 +在下面的例子中，我们从 `v0.42` 开始一个新链。此版本的二进制文件将是创世二进制文件。对于第一次在现有链上使用 Cosmovisor 的验证者，要么将链当前版本的二进制文件用作创世二进制文件(即起始二进制文件)，要么验证器应更新“当前”符号链接以指向升级目录。有关详细信息，请参阅 [Cosmovisor](../run-node/cosmovisor.html)。 ::: -### Initial Setup +### 初始设置 -From within the `cosmos-sdk` repository, check out the latest `v0.42.x` release: +从 `cosmos-sdk` 存储库中，查看最新的 `v0.42.x` 版本: ``` git checkout release/v0.42.x @@ -108,21 +108,21 @@ Create a new key for the validator, then add a genesis account and transaction: ./build/simd collect-gentxs ``` -Now that our node is initialized and we are ready to start a new `simapp` chain, let's set up `cosmovisor` and the genesis binary. +现在我们的节点已经初始化，我们准备开始一个新的 `simapp` 链，让我们设置 `cosmovisor` 和 genesis 二进制文件。 -### Cosmovisor Setup +### Cosmovisor 设置 -Install the `cosmovisor` binary: +安装 `cosmovisor` 二进制文件: ``` go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@v0.1.0 ``` -::: tip -If you are using go `v1.15` or earlier, you will need to change out of the `cosmos-sdk` directory, run `go get` instead of `go install`, and then change back into the `cosmos-sdk` repository. +::: 小费 +如果你使用的是 go `v1.15` 或更早版本，你需要把 `cosmos-sdk` 目录改出，运行 `go get` 而不是 `go install`，然后再改回 `cosmos-sdk ` 存储库。 ::: -Set the required environment variables: +设置所需的环境变量: ``` export DAEMON_NAME=simd @@ -135,14 +135,14 @@ Set the optional environment variable to trigger an automatic restart: export DAEMON_RESTART_AFTER_UPGRADE=true ``` -Create the folder for the genesis binary and copy the `v0.42.x` binary: +为 genesis 二进制文件创建文件夹并复制 `v0.42.x` 二进制文件: ``` mkdir -p $DAEMON_HOME/cosmovisor/genesis/bin cp ./build/simd $DAEMON_HOME/cosmovisor/genesis/bin ``` -Now that `cosmovisor` is installed and the genesis binary has been added, let's add the upgrade handler to `simapp/app.go` and prepare the upgrade binary. +现在已经安装了 `cosmovisor` 并添加了 genesis 二进制文件，让我们将升级处理程序添加到 `simapp/app.go` 并准备升级二进制文件。 ### Chain Upgrade @@ -160,7 +160,7 @@ Add the following to `simapp/app.go` inside `NewSimApp` and after `app.UpgradeKe app.registerUpgradeHandlers() ``` -Add the following to `simapp/app.go` after `NewSimApp` (to learn more about the upgrade handler, see the [In-Place Store Migrations](../core/upgrade.html)): +将以下内容添加到 `NewSimApp` 之后的 `simapp/app.go`(要了解有关升级处理程序的更多信息，请参阅 [In-Place Store Migrations](../core/upgrade.html)): ```go func (app *SimApp) registerUpgradeHandlers() { @@ -217,15 +217,14 @@ Build the `simd` binary for `v0.44.x` (the upgrade binary): make build ``` -Create the folder for the upgrade binary and copy the `v0.44.x` binary: +为升级二进制文件创建文件夹并复制 `v0.44.x` 二进制文件: ``` mkdir -p $DAEMON_HOME/cosmovisor/upgrades/v0.44/bin cp ./build/simd $DAEMON_HOME/cosmovisor/upgrades/v0.44/bin ``` -Now that we have added the upgrade handler and prepared the upgrade binary, we are ready to start `cosmovisor` and simulate the upgrade proposal process. - +现在我们已经添加了升级处理程序并准备了升级二进制文件，我们准备启动 `cosmovisor` 并模拟升级建议过程。 ### Upgrade Proposal Start the node using `cosmovisor`: @@ -234,7 +233,7 @@ Start the node using `cosmovisor`: cosmovisor start ``` -Open a new terminal window and submit an upgrade proposal along with a deposit and a vote (these commands must be run within 20 seconds of each other): +打开一个新的终端窗口并提交升级建议以及存款和投票(这些命令必须在 20 秒内运行): ``` ./build/simd tx gov submit-proposal software-upgrade v0.44 --title upgrade --description upgrade --upgrade-height 20 --from validator --yes @@ -242,4 +241,4 @@ Open a new terminal window and submit an upgrade proposal along with a deposit a ./build/simd tx gov vote 1 yes --from validator --yes ``` -Confirm the chain automatically upgrades at height 20. +确认链在高度 20 自动升级。 diff --git a/docs/ja/migrations/pre-upgrade.md b/docs/ja/migrations/pre-upgrade.md index 00b4c54e2142..6f0e10bc222b 100644 --- a/docs/ja/migrations/pre-upgrade.md +++ b/docs/ja/migrations/pre-upgrade.md @@ -1,14 +1,14 @@ -# Pre-Upgrade Handling +# 升级前处理 -Cosmovisor supports custom pre-upgrade handling. Use pre-upgrade handling when you need to implement application config changes that are required in the newer version before you perform the upgrade. +Cosmovisor 支持自定义升级前处理。 当您需要在执行升级之前实施较新版本中所需的应用程序配置更改时，请使用升级前处理。 -Using Cosmovisor pre-upgrade handling is optional. If pre-upgrade handling is not implemented, the upgrade continues. +使用 Cosmovisor 升级前处理是可选的。 如果未实施升级前处理，升级将继续。 -For example, make the required new-version changes to `app.toml` settings during the pre-upgrade handling. The pre-upgrade handling process means that the file does not have to be manually updated after the upgrade. +例如，在升级前处理期间对 `app.toml` 设置进行所需的新版本更改。 升级前处理过程意味着升级后无需手动更新文件。 -Before the application binary is upgraded, Cosmovisor calls a `pre-upgrade` command that can be implemented by the application. +在应用程序二进制文件升级之前，Cosmovisor 调用了一个可由应用程序实现的“pre-upgrade”命令。 -The `pre-upgrade` command does not take in any command-line arguments and is expected to terminate with the following exit codes: +`pre-upgrade` 命令不接受任何命令行参数，预计会以以下退出代码终止: | Exit status code | How it is handled in Cosmosvisor | |------------------|---------------------------------------------------------------------------------------------------------------------| @@ -19,7 +19,7 @@ The `pre-upgrade` command does not take in any command-line arguments and is exp ## Sample -Here is a sample structure of the `pre-upgrade` command: +以下是“pre-upgrade”命令的示例结构: ```go func preUpgradeCommand() *cobra.Command { @@ -44,7 +44,7 @@ func preUpgradeCommand() *cobra.Command { } ``` -Ensure that the pre-upgrade command has been registered in the application: +确保已在应用程序中注册了 pre-upgrade 命令: ```go rootCmd.AddCommand( diff --git a/docs/ja/migrations/rest.md b/docs/ja/migrations/rest.md index faec5bc735d0..ffc16204dd2f 100644 --- a/docs/ja/migrations/rest.md +++ b/docs/ja/migrations/rest.md @@ -1,20 +1,20 @@ -# REST Endpoints Migration +# REST 端点迁移 -Migrate to gRPC-Gateway REST endpoints. Legacy REST endpoints were marked as deprecated in v0.40 and will be removed in v0.45. {synopsis} +迁移到 gRPC-Gateway REST 端点。旧版 REST 端点在 v0.40 中被标记为已弃用，并将在 v0.45 中删除。 {概要} -::: warning -Two Legacy REST endpoints (`POST /txs` and `POST /txs/encode`) were removed ahead of schedule in v0.44 due to a security vulnerability. +::: 警告 +由于安全漏洞，在 v0.44 中提前删除了两个旧版 REST 端点(`POST /txs` 和 `POST /txs/encode`)。 ::: -## Legacy REST Endpoints +## 传统 REST 端点 -Cosmos SDK versions v0.39 and earlier registered REST endpoints using a package called `gorilla/mux`. These REST endpoints were marked as deprecated in v0.40 and have since been referred to as legacy REST endpoints. Legacy REST endpoints will be officially removed in v0.45. +Cosmos SDK 版本 v0.39 和更早版本使用名为“gorilla/mux”的包注册了 REST 端点。这些 REST 端点在 v0.40 中被标记为已弃用，此后被称为旧版 REST 端点。传统 REST 端点将在 v0.45 中正式删除。 -## gRPC-Gateway REST Endpoints +## gRPC 网关 REST 端点 -Following the Protocol Buffers migration in v0.40, Cosmos SDK has been set to take advantage of a vast number of gRPC tools and solutions. v0.40 introduced new REST endpoints generated from [gRPC `Query` services](../building-modules/query-services.md) using [grpc-gateway](https://grpc-ecosystem.github.io/grpc-gateway/). These new REST endpoints are referred to as gRPC-Gateway REST endpoints. +随着 v0.40 中的 Protocol Buffers 迁移，Cosmos SDK 已被设置为利用大量 gRPC 工具和解决方案。 v0.40 引入了使用 [grpc-gateway](https://grpc-ecosystem.github.io/grpc) 从 [gRPC `Query` 服务](../building-modules/query-services.md) 生成的新 REST 端点-网关/)。这些新的 REST 端点称为 gRPC-Gateway REST 端点。 -## Migrating to New REST Endpoints +## 迁移到新的 REST 端点 | Legacy REST Endpoint | Description | New gRPC-gateway REST Endpoint | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | @@ -76,6 +76,6 @@ Following the Protocol Buffers migration in v0.40, Cosmos SDK has been set to ta | `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 +## 迁移到 gRPC -Instead of hitting REST endpoints as described above, the Cosmos 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 can be found [here](../run-node/txs.md#programmatically-with-go). +Cosmos SDK 并没有像上面描述的那样访问 REST 端点，而是公开了一个 gRPC 服务器。 任何客户端都可以使用 gRPC 而不是 REST 与节点进行交互。 可以在 [此处](../core/grpc_rest.md) 中找到与节点通信的不同方式的概述，可以在 [此处](../run-node /txs.md#programmatically-with-go)。 \ No newline at end of file diff --git a/docs/ja/modules/README.md b/docs/ja/modules/README.md index a0bfab3599e8..45ed8776217d 100644 --- a/docs/ja/modules/README.md +++ b/docs/ja/modules/README.md @@ -1,25 +1,25 @@ -# List of Modules +# 模块列表 -Here are some production-grade modules that can be used in Cosmos SDK applications, along with their respective documentation: +以下是一些可用于 Cosmos SDK 应用程序的生产级模块及其各自的文档: -- [Auth](auth/) - Authentication of accounts and transactions for Cosmos SDK applications. -- [Authz](authz/) - Authorization for accounts to perform actions on behalf of other accounts. -- [Bank](bank/) - Token transfer functionalities. -- [Capability](capability/) - Object capability implementation. -- [Crisis](crisis/) - Halting the blockchain under certain circumstances (e.g. if an invariant is broken). -- [Distribution](distribution/) - Fee distribution, and staking token provision distribution. -- [Epoching](epoching/) - Allows modules to queue messages for execution at a certain block height. -- [Evidence](evidence/) - Evidence handling for double signing, misbehaviour, etc. -- [Feegrant](feegrant/) - Grant fee allowances for executing transactions. -- [Governance](gov/) - On-chain proposals and voting. -- [Mint](mint/) - Creation of new units of staking token. -- [Params](params/) - Globally available parameter store. -- [Slashing](slashing/) - Validator punishment mechanisms. -- [Staking](staking/) - Proof-of-Stake layer for public blockchains. -- [Upgrade](upgrade/) - Software upgrades handling and coordination. +- [Auth](auth/) - Cosmos SDK 应用程序的账户和交易认证。 +- [Authz](authz/) - 授权账户代表其他账户执行操作。 +- [银行](bank/) - 代币转移功能。 +- [Capability](capability/) - 对象能力实现。 +- [Crisis](crisis/) - 在某些情况下停止区块链(例如，如果不变量被破坏)。 +- [Distribution](distribution/) - 费用分配和抵押代币供应分配。 +- [Epoching](epoching/) - 允许模块将消息排队以在特定块高度执行。 +- [Evidence](evidence/) - 双重签名、不当行为等的证据处理。 +- [Feegrant](feegrant/) - 授予执行交易的费用津贴。 +- [治理](gov/) - 链上提案和投票。 +- [Mint](mint/) - 创建新的抵押代币单位。 +- [Params](params/) - 全局可用的参数存储。 +- [Slashing](slashing/) - 验证者惩罚机制。 +- [Staking](staking/) - 公共区块链的权益证明层。 +- [升级](upgrade/) - 软件升级处理和协调。 -To learn more about the process of building modules, visit the [building modules reference documentation](/building-modules/intro.html). +要了解有关构建模块过程的更多信息，请访问 [构建模块参考文档](/building-modules/intro.html)。 -## IBC +## 国际商业银行 -The IBC module for the SDK has moved to its [own repository](https://github.com/cosmos/ibc-go). +SDK 的 IBC 模块已移至其[自己的存储库](https://github.com/cosmos/ibc-go)。 \ No newline at end of file diff --git a/docs/ja/modules/auth/01_concepts.md b/docs/ja/modules/auth/01_concepts.md index a0475f058c65..ff31a73d7b8e 100644 --- a/docs/ja/modules/auth/01_concepts.md +++ b/docs/ja/modules/auth/01_concepts.md @@ -1,39 +1,39 @@ -# Concepts +# 概念 -**Note:** The auth module is different from the [authz module](../modules/authz/). +**注意:** auth 模块与 [authz 模块](../modules/authz/) 不同。 -The differences are: +区别在于: -* `auth` - authentication of accounts and transactions for Cosmos SDK applications and is responsible for specifying the base transaction and account types. -* `authz` - authorization for accounts to perform actions on behalf of other accounts and enables a granter to grant authorizations to a grantee that allows the grantee to execute messages on behalf of the granter. +* `auth` - Cosmos SDK 应用程序的账户和交易认证，负责指定基本交易和账户类型。 +* `authz` - 授权账户代表其他账户执行操作，并允许授予者向被授予者授予授权，允许被授予者代表授予者执行消息。 -## Gas & Fees +## 汽油和费用 -Fees serve two purposes for an operator of the network. +费用对网络运营商有两个目的。 -Fees limit the growth of the state stored by every full node and allow for -general purpose censorship of transactions of little economic value. Fees -are best suited as an anti-spam mechanism where validators are disinterested in -the use of the network and identities of users. +费用限制了每个完整节点存储的状态的增长，并允许 +对经济价值不大的交易进行通用审查。费用 +最适合作为验证者不感兴趣的反垃圾邮件机制 +网络的使用和用户的身份。 -Fees are determined by the gas limits and gas prices transactions provide, where -`fees = ceil(gasLimit * gasPrices)`. Txs incur gas costs for all state reads/writes, -signature verification, as well as costs proportional to the tx size. Operators -should set minimum gas prices when starting their nodes. They must set the unit -costs of gas in each token denomination they wish to support: +费用由交易提供的 gas 限额和 gas 价格决定，其中 +`费用 = ceil(gasLimit * gasPrices)`。 Txs 会为所有状态读/写产生 gas 成本， +签名验证，以及与 tx 大小成正比的成本。运营商 +应该在启动节点时设置最低 gas 价格。他们必须设置单位 +他们希望支持的每种代币面额的 gas 成本: `simd start ... --minimum-gas-prices=0.00001stake;0.05photinos` -When adding transactions to mempool or gossipping transactions, validators check -if the transaction's gas prices, which are determined by the provided fees, meet -any of the validator's minimum gas prices. In other words, a transaction must -provide a fee of at least one denomination that matches a validator's minimum -gas price. +将交易添加到内存池或八卦交易时，验证器会检查 +如果交易的gas价格(由提供的费用决定)满足 +任何验证者的最低 gas 价格。换句话说，交易必须 +提供至少一种与验证者最低费用相匹配的面额的费用 +气价。 -Tendermint does not currently provide fee based mempool prioritization, and fee -based mempool filtering is local to node and not part of consensus. But with -minimum gas prices set, such a mechanism could be implemented by node operators. +Tendermint 目前不提供基于费用的内存池优先排序，并且费用 +基于内存池的过滤是节点本地的，而不是共识的一部分。但是随着 +设置最低gas价格，这种机制可以由节点运营商实施。 -Because the market value for tokens will fluctuate, validators are expected to -dynamically adjust their minimum gas prices to a level that would encourage the -use of the network. +由于代币的市场价值会波动，验证者预计 +动态调整他们的最低汽油价格到一个水平，以鼓励 +网络的使用。 \ No newline at end of file diff --git a/docs/ja/modules/auth/02_state.md b/docs/ja/modules/auth/02_state.md index 3a92585b5de2..23ab10bb84fa 100644 --- a/docs/ja/modules/auth/02_state.md +++ b/docs/ja/modules/auth/02_state.md @@ -1,25 +1,24 @@ -# State +# 状态 -## Accounts +## 帐户 -Accounts contain authentication information for a uniquely identified external user of an SDK blockchain, -including public key, address, and account number / sequence number for replay protection. For efficiency, -since account balances must also be fetched to pay fees, account structs also store the balance of a user -as `sdk.Coins`. +帐户包含 SDK 区块链唯一标识的外部用户的身份验证信息， +包括用于重放保护的公钥、地址和帐号/序列号。 为了效率， +由于还必须获取帐户余额以支付费用，因此帐户结构还存储用户的余额 +作为`sdk.Coins`。 -Accounts are exposed externally as an interface, and stored internally as -either a base account or vesting account. Module clients wishing to add more -account types may do so. +帐户作为接口对外公开，在内部存储为 +基本账户或归属账户。 希望添加更多模块的客户 +帐户类型可能会这样做。 -- `0x01 | Address -> ProtocolBuffer(account)` +- `0x01 | 地址 -> ProtocolBuffer(account)` -### Account Interface - -The account interface exposes methods to read and write standard account information. -Note that all of these methods operate on an account struct confirming to the -interface - in order to write the account to the store, the account keeper will -need to be used. +###账户界面 +帐户接口公开了读取和写入标准帐户信息的方法。 +请注意，所有这些方法都在一个帐户结构上运行，以确认 +接口 - 为了将帐户写入存储，帐户管理员将 +需要使用。 ```go // AccountI is an interface used to store coins at a given address within state. // It presumes a notion of sequence numbers for replay protection, @@ -47,10 +46,10 @@ type AccountI interface { } ``` -#### Base Account +#### 基本帐户 -A base account is the simplest and most common account type, which just stores all requisite -fields directly in a struct. +基本帐户是最简单和最常见的帐户类型，它只存储所有必需的 +字段直接在结构中。 ```protobuf // BaseAccount defines a base account type. It contains all the necessary fields @@ -64,6 +63,6 @@ message BaseAccount { } ``` -### Vesting Account +### 归属账户 -See [Vesting](05_vesting.md). +请参阅[归属](05_vesting.md)。 \ No newline at end of file diff --git a/docs/ja/modules/auth/03_antehandlers.md b/docs/ja/modules/auth/03_antehandlers.md index 561f0dd2455e..942eb47778a3 100644 --- a/docs/ja/modules/auth/03_antehandlers.md +++ b/docs/ja/modules/auth/03_antehandlers.md @@ -1,36 +1,36 @@ -# AnteHandlers +# 前处理程序 -The `x/auth` module presently has no transaction handlers of its own, but does expose the special `AnteHandler`, used for performing basic validity checks on a transaction, such that it could be thrown out of the mempool. -The `AnteHandler` can be seen as a set of decorators that check transactions within the current context, per [ADR 010](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/docs/architecture/adr-010-modular-antehandler.md). +`x/auth` 模块目前没有自己的事务处理程序，但确实公开了特殊的 `AnteHandler`，用于对事务执行基本的有效性检查，以便它可以被抛出内存池。 +根据 [ADR 010](https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/docs/架构/adr-010-modular-antehandler.md)。 -Note that the `AnteHandler` is called on both `CheckTx` and `DeliverTx`, as Tendermint proposers presently have the ability to include in their proposed block transactions which fail `CheckTx`. +请注意，在 `CheckTx` 和 `DeliverTx` 上都调用了 `AnteHandler`，因为 Tendermint 提议者目前能够将失败的 `CheckTx` 包含在他们提议的区块交易中。 -## Decorators +## 装饰器 -The auth module provides `AnteDecorator`s that are recursively chained together into a single `AnteHandler` in the following order: +auth 模块提供了 `AnteDecorator`s，它们按以下顺序递归地链接到单个 `AnteHandler` 中: -- `SetUpContextDecorator`: Sets the `GasMeter` in the `Context` and wraps the next `AnteHandler` with a defer clause to recover from any downstream `OutOfGas` panics in the `AnteHandler` chain to return an error with information on gas provided and gas used. +- `SetUpContextDecorator`:在 `Context` 中设置 `GasMeter`，并用 defer 子句包装下一个 `AnteHandler`，以从 `AnteHandler` 链中的任何下游 `OutOfGas` 恐慌中恢复，并返回有关所提供气体的信息的错误和使用的气体。 -- `RejectExtensionOptionsDecorator`: Rejects all extension options which can optionally be included in protobuf transactions. +- `RejectExtensionOptionsDecorator`:拒绝所有可以选择包含在 protobuf 事务中的扩展选项。 -- `MempoolFeeDecorator`: Checks if the `tx` fee is above local mempool `minFee` parameter during `CheckTx`. +- `MempoolFeeDecorator`:在`CheckTx`期间检查`tx`费用是否高于本地内存池`minFee`参数。 -- `ValidateBasicDecorator`: Calls `tx.ValidateBasic` and returns any non-nil error. +- `ValidateBasicDecorator`:调用`tx.ValidateBasic` 并返回任何非零错误。 -- `TxTimeoutHeightDecorator`: Check for a `tx` height timeout. +- `TxTimeoutHeightDecorator`:检查`tx` 高度超时。 -- `ValidateMemoDecorator`: Validates `tx` memo with application parameters and returns any non-nil error. +- `ValidateMemoDecorator`:使用应用程序参数验证 `tx` 备忘录并返回任何非零错误。 -- `ConsumeGasTxSizeDecorator`: Consumes gas proportional to the `tx` size based on application parameters. +- `ConsumeGasTxSizeDecorator`:根据应用程序参数消耗与`tx` 大小成比例的gas。 -- `DeductFeeDecorator`: Deducts the `FeeAmount` from first signer of the `tx`. If the `x/feegrant` module is enabled and a fee granter is set, it deducts fees from the fee granter account. +- `DeductFeeDecorator`:从 `tx` 的第一个签名者中扣除 `FeeAmount`。如果启用了 `x/feegrant` 模块并设置了费用授予者，它会从费用授予者帐户中扣除费用。 -- `SetPubKeyDecorator`: Sets the pubkey from a `tx`'s signers that does not already have its corresponding pubkey saved in the state machine and in the current context. +- `SetPubKeyDecorator`:从`tx` 的签名者设置公钥，该签名者还没有在状态机和当前上下文中保存其相应的公钥。 -- `ValidateSigCountDecorator`: Validates the number of signatures in `tx` based on app-parameters. +- `ValidateSigCountDecorator`:根据应用参数验证 `tx` 中的签名数量。 -- `SigGasConsumeDecorator`: Consumes parameter-defined amount of gas for each signature. This requires pubkeys to be set in context for all signers as part of `SetPubKeyDecorator`. +- `SigGasConsumeDecorator`:为每个签名消耗参数定义的气体量。这需要在上下文中为所有签名者设置公钥作为“SetPubKeyDecorator”的一部分。 -- `SigVerificationDecorator`: Verifies all signatures are valid. This requires pubkeys to be set in context for all signers as part of `SetPubKeyDecorator`. +- `SigVerificationDecorator`:验证所有签名是否有效。这需要在上下文中为所有签名者设置公钥作为“SetPubKeyDecorator”的一部分。 -- `IncrementSequenceDecorator`: Increments the account sequence for each signer to prevent replay attacks. +- `IncrementSequenceDecorator`:为每个签名者增加账户序列以防止重放攻击。 \ No newline at end of file diff --git a/docs/ja/modules/auth/04_keepers.md b/docs/ja/modules/auth/04_keepers.md index 130d3a6ea31a..ab9435a4d27d 100644 --- a/docs/ja/modules/auth/04_keepers.md +++ b/docs/ja/modules/auth/04_keepers.md @@ -1,11 +1,11 @@ -# Keepers +# 守门员 -The auth module only exposes one keeper, the account keeper, which can be used to read and write accounts. +auth 模块只暴露了一个keeper，accountkeeper，可以用来读写账户。 -## Account Keeper +## 帐户管理员 -Presently only one fully-permissioned account keeper is exposed, which has the ability to both read and write -all fields of all accounts, and to iterate over all stored accounts. +目前只暴露了一个完全许可的帐户管理员，它具有读写能力 +所有帐户的所有字段，并遍历所有存储的帐户。 ```go // AccountKeeperI is the interface contract that x/auth's keeper implements. diff --git a/docs/ja/modules/auth/05_vesting.md b/docs/ja/modules/auth/05_vesting.md index acc37e3dac11..3dc98dc58c5c 100644 --- a/docs/ja/modules/auth/05_vesting.md +++ b/docs/ja/modules/auth/05_vesting.md @@ -1,68 +1,68 @@ -# Vesting - -- [Vesting](#vesting) - - [Intro and Requirements](#intro-and-requirements) - - [Note](#note) - - [Vesting Account Types](#vesting-account-types) - - [Vesting Account Specification](#vesting-account-specification) - - [Determining Vesting & Vested Amounts](#determining-vesting--vested-amounts) - - [Continuously Vesting Accounts](#continuously-vesting-accounts) - - [Periodic Vesting Accounts](#periodic-vesting-accounts) - - [Delayed/Discrete Vesting Accounts](#delayeddiscrete-vesting-accounts) - - [Transferring/Sending](#transferringsending) - - [Keepers/Handlers](#keepershandlers) - - [Delegating](#delegating) - - [Keepers/Handlers](#keepershandlers-1) - - [Undelegating](#undelegating) - - [Keepers/Handlers](#keepershandlers-2) +# 归属 + +- [归属](#vesting) + - [介绍和要求](#intro-and-requirements) + - [注意](#note) + - [归属账户类型](#vesting-account-types) + - [归属账户规范](#vesting-account-specification) + - [确定归属和归属金额](#determining-vesting--vested-amounts) + - [持续归属账户](#continuously-vesting-accounts) + - [定期归属账户](#periodic-vesting-accounts) + - [延迟/离散归属账户](#delayeddiscrete-vesting-accounts) + - [传输/发送](#transferringsending) + - [守护者/处理者](#keepershandlers) + - [委托](#delegating) + - [守护者/处理者](#keepershandlers-1) + - [取消委派](#取消委派) + - [守护者/处理者](#keepershandlers-2) - [Keepers & Handlers](#keepers--handlers) - - [Genesis Initialization](#genesis-initialization) - - [Examples](#examples) - - [Simple](#simple) + - [创世初始化](#genesis-initialization) + - [例子](#examples) + - [简单](#simple) - [Slashing](#slashing) - - [Periodic Vesting](#periodic-vesting) - - [Glossary](#glossary) - -## Intro and Requirements - -This specification defines the vesting account implementation that is used by -the Cosmos Hub. The requirements for this vesting account is that it should be -initialized during genesis with a starting balance `X` and a vesting end -time `ET`. A vesting account may be initialized with a vesting start time `ST` -and a number of vesting periods `P`. If a vesting start time is included, the -vesting period does not begin until start time is reached. If vesting periods -are included, the vesting occurs over the specified number of periods. - -For all vesting accounts, the owner of the vesting account is able to delegate -and undelegate from validators, however they cannot transfer coins to another -account until those coins are vested. This specification allows for four -different kinds of vesting: - -- Delayed vesting, where all coins are vested once `ET` is reached. -- Continous vesting, where coins begin to vest at `ST` and vest linearly with -respect to time until `ET` is reached -- Periodic vesting, where coins begin to vest at `ST` and vest periodically -according to number of periods and the vesting amount per period. -The number of periods, length per period, and amount per period are -configurable. A periodic vesting account is distinguished from a continuous -vesting account in that coins can be released in staggered tranches. For -example, a periodic vesting account could be used for vesting arrangements -where coins are relased quarterly, yearly, or over any other function of -tokens over time. -- Permanent locked vesting, where coins are locked forever. Coins in this account can -still be used for delegating and for governance votes even while locked. - -## Note - -Vesting accounts can be initialized with some vesting and non-vesting coins. -The non-vesting coins would be immediately transferable. DelayedVesting and -ContinuousVesting accounts can be created with normal messages after genesis. -Other types of vesting accounts must be created at genesis, or as -part of a manual network upgrade. The current specification only allows -for _unconditional_ vesting (ie. there is no possibility of reaching `ET` and -having coins fail to vest). - -## Vesting Account Types + - [定期归属](#periodic-vesting) + - [词汇表](#glossary) + +## 介绍和要求 + +该规范定义了由以下人员使用的归属账户实现 +宇宙中心。这个归属账户的要求是它应该是 +在创世期间用起始余额“X”和归属结束初始化 +时间`ET`。归属账户可以用归属开始时间`ST`初始化 +和一些归属期`P`。如果包括归属开始时间，则 +归属期直到开始时间才开始。如果归属期 +包括在内，归属发生在指定的时期数。 + +对于所有归属账户，归属账户的所有者可以委托 +并从验证者那里取消委托，但是他们不能将硬币转移到另一个 +帐户，直到这些硬币归属。该规范允许四个 +不同类型的归属: + +- 延迟归属，一旦达到“ET”，所有硬币都归属。 +- 连续归属，其中硬币开始归属于“ST”并线性归属于 +关于到达“ET”的时间 +- 定期归属，硬币开始归属于“ST”并定期归属 +根据期数和每期的行权金额。 +期数、每期长度和每期金额为 +可配置。定期归属账户有别于连续的 +该代币的归属账户可以分批释放。为了 +例如，定期归属账户可用于归属安排 +硬币每季度、每年或通过任何其他功能发布 +随着时间的推移令牌。 +- 永久锁定归属，硬币永久锁定。这个账户里的币可以 +即使在锁定时，仍可用于委托和治理投票。 + +## 笔记 + +归属账户可以用一些归属和非归属代币初始化。 +非归属代币将可立即转让。延迟归属和 +可以在创世后使用普通消息创建ContinuousVesting 帐户。 +其他类型的归属账户必须在创世时创建，或作为 +手动网络升级的一部分。目前的规范只允许 +对于_无条件_归属(即，不可能达到“ET”和 +有硬币无法归属)。 + +## 归属账户类型 ```go // VestingAccount defines an interface that any vesting account type must @@ -114,9 +114,9 @@ type Periods []Period +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/vesting/v1beta1/vesting.proto#L64-L73 -In order to facilitate less ad-hoc type checking and assertions and to support -flexibility in account balance usage, the existing `x/bank` `ViewKeeper` interface -is updated to contain the following: +为了促进较少的临时类型检查和断言并支持 +账户余额使用的灵活性，现有的`x/bank``ViewKeeper`接口 +更新为包含以下内容: ```go type ViewKeeper interface { @@ -136,31 +136,30 @@ type ViewKeeper interface { ## Vesting Account Specification -Given a vesting account, we define the following in the proceeding operations: - -- `OV`: The original vesting coin amount. It is a constant value. -- `V`: The number of `OV` coins that are still _vesting_. It is derived by -`OV`, `StartTime` and `EndTime`. This value is computed on demand and not on a -per-block basis. -- `V'`: The number of `OV` coins that are _vested_ (unlocked). This value is -computed on demand and not a per-block basis. -- `DV`: The number of delegated _vesting_ coins. It is a variable value. It is -stored and modified directly in the vesting account. -- `DF`: The number of delegated _vested_ (unlocked) coins. It is a variable -value. It is stored and modified directly in the vesting account. -- `BC`: The number of `OV` coins less any coins that are transferred -(which can be negative or delegated). It is considered to be balance of the -embedded base account. It is stored and modified directly in the vesting account. - +给定一个归属账户，我们在处理操作中定义以下内容: + +- `OV`:原始归属币数量。 它是一个常数值。 +- `V`:仍然 _vesting_ 的 `OV` 代币数量。 它是由 +`OV`、`StartTime` 和 `EndTime`。 该值是按需计算的，而不是根据 +每块基础。 +- `V'`:_vested_(解锁)的 `OV` 硬币数量。 这个值是 +按需计算，而不是按块计算。 +- `DV`:委托_vesting_硬币的数量。 它是一个可变值。 它是 +直接在归属账户中存储和修改。 +- `DF`:委托的 _vested_(解锁)硬币的数量。 它是一个变量 +价值。 它直接在归属账户中存储和修改。 +- `BC`:`OV` 硬币的数量减去任何转移的硬币 +(可以是否定的或委托的)。 它被认为是平衡的 +嵌入式基本帐户。 它直接在归属账户中存储和修改。 ### Determining Vesting & Vested Amounts -It is important to note that these values are computed on demand and not on a -mandatory per-block basis (e.g. `BeginBlocker` or `EndBlocker`). +需要注意的是，这些值是按需计算的，而不是根据 +强制每个块基础(例如`BeginBlocker` 或`EndBlocker`)。 #### Continuously Vesting Accounts -To determine the amount of coins that are vested for a given block time `T`, the -following is performed: +为了确定在给定的区块时间“T”内归属的代币数量， +执行以下操作: 1. Compute `X := T - StartTime` 2. Compute `Y := EndTime - StartTime` @@ -194,10 +193,10 @@ func (cva ContinuousVestingAccount) GetVestingCoins(t Time) Coins { ### Periodic Vesting Accounts -Periodic vesting accounts require calculating the coins released during each -period for a given block time `T`. Note that multiple periods could have passed -when calling `GetVestedCoins`, so we must iterate over each period until the -end of that period is after `T`. +定期归属账户需要计算每个时期释放的硬币 +给定区块时间‘T’的时间段。 请注意，多个时期可能已经过去 +当调用`GetVestedCoins`时，我们必须迭代每个周期，直到 +那个时期的结束是在“T”之后。 1. Set `CT := StartTime` 2. Set `V' := 0` @@ -236,9 +235,9 @@ func (pva PeriodicVestingAccount) GetVestingCoins(t Time) Coins { #### Delayed/Discrete Vesting Accounts -Delayed vesting accounts are easier to reason about as they only have the full -amount vesting up until a certain time, then all the coins become vested (unlocked). -This does not include any unlocked coins the account may have initially. +延迟归属账户更容易推理，因为它们只有完整的 +金额归属到某个时间，然后所有硬币都归属(解锁)。 +这不包括帐户最初可能拥有的任何解锁硬币。 ```go func (dva DelayedVestingAccount) GetVestedCoins(t Time) Coins { @@ -256,16 +255,16 @@ func (dva DelayedVestingAccount) GetVestingCoins(t Time) Coins { ### Transferring/Sending -At any given time, a vesting account may transfer: `min((BC + DV) - V, BC)`. +在任何给定时间，归属账户可以转移:`min((BC + DV) - V, BC)`。 -In other words, a vesting account may transfer the minimum of the base account -balance and the base account balance plus the number of currently delegated -vesting coins less the number of coins vested so far. +换句话说，一个归属账户可以转移基础账户的最小值 +余额和基本账户余额加上当前委托的数量 +归属代币少于迄今为止归属代币的数量。 -However, given that account balances are tracked via the `x/bank` module and that -we want to avoid loading the entire account balance, we can instead determine -the locked balance, which can be defined as `max(V - DV, 0)`, and infer the -spendable balance from that. +然而，鉴于账户余额是通过 `x/bank` 模块跟踪的，并且 +我们想避免加载整个帐户余额，我们可以改为确定 +锁定余额，可以定义为`max(V - DV, 0)`，并推断出 +可花费的余额。 ```go func (va VestingAccount) LockedCoins(t Time) Coins { @@ -292,8 +291,8 @@ func (k Keeper) LockedCoins(ctx Context, addr AccAddress) Coins { #### Keepers/Handlers -The corresponding `x/bank` keeper should appropriately handle sending coins -based on if the account is a vesting account or not. +相应的`x/bank` 管理员应该适当地处理发送硬币 +根据账户是否为归属账户。 ```go func (k Keeper) SendCoins(ctx Context, from Account, to Account, amount Coins) { @@ -313,7 +312,7 @@ func (k Keeper) SendCoins(ctx Context, from Account, to Account, amount Coins) { ### Delegating -For a vesting account attempting to delegate `D` coins, the following is performed: +对于尝试委托“D”币的归属账户，执行以下操作: 1. Verify `BC >= D > 0` 2. Compute `X := min(max(V - DV, 0), D)` (portion of `D` that is vesting) @@ -332,8 +331,8 @@ func (va VestingAccount) TrackDelegation(t Time, balance Coins, amount Coins) { } ``` -**Note** `TrackDelegation` only modifies the `DelegatedVesting` and `DelegatedFree` -fields, so upstream callers MUST modify the `Coins` field by subtracting `amount`. +**注意** `TrackDelegation` 只修改了 `DelegatedVesting` 和 `DelegatedFree` +字段，因此上游调用者必须通过减去 `amount` 来修改 `Coins` 字段。 #### Keepers/Handlers @@ -351,9 +350,9 @@ func DelegateCoins(t Time, from Account, amount Coins) { ### Undelegating -For a vesting account attempting to undelegate `D` coins, the following is performed: -NOTE: `DV < D` and `(DV + DF) < D` may be possible due to quirks in the rounding of -delegation/undelegation logic. +对于试图取消“D”代币委托的归属账户，执行以下操作: +注意:`DV < D` 和 `(DV + DF) < D` 可能是由于四舍五入的怪癖 +委托/取消委托逻辑。 1. Verify `D > 0` 2. Compute `X := min(DF, D)` (portion of `D` that should become free, prioritizing free coins) @@ -371,18 +370,17 @@ func (cva ContinuousVestingAccount) TrackUndelegation(amount Coins) { } ``` -**Note** `TrackUnDelegation` only modifies the `DelegatedVesting` and `DelegatedFree` -fields, so upstream callers MUST modify the `Coins` field by adding `amount`. - -**Note**: If a delegation is slashed, the continuous vesting account ends up -with an excess `DV` amount, even after all its coins have vested. This is because -undelegating free coins are prioritized. +**注意** `TrackUnDelegation` 只修改了 `DelegatedVesting` 和 `DelegatedFree` +字段，因此上游调用者必须通过添加 `amount` 来修改 `Coins` 字段。 -**Note**: The undelegation (bond refund) amount may exceed the delegated -vesting (bond) amount due to the way undelegation truncates the bond refund, -which can increase the validator's exchange rate (tokens/shares) slightly if the -undelegated tokens are non-integral. +**注**:如果授权被削减，则持续归属账户结束 +即使在所有代币都已归属之后，也有多余的“DV”金额。 这是因为 +优先考虑取消授权的免费硬币。 +**注**:取消委托(退押金)金额可能会超过委托 +由于取消授权截断了债券退款的方式，归属(债券)金额， +如果 +未委托代币是非完整的。 #### Keepers/Handlers ```go @@ -401,25 +399,24 @@ func UndelegateCoins(to Account, amount Coins) { ## Keepers & Handlers -The `VestingAccount` implementations reside in `x/auth`. However, any keeper in -a module (e.g. staking in `x/staking`) wishing to potentially utilize any vesting -coins, must call explicit methods on the `x/bank` keeper (e.g. `DelegateCoins`) -opposed to `SendCoins` and `SubtractCoins`. - -In addition, the vesting account should also be able to spend any coins it -receives from other users. Thus, the bank module's `MsgSend` handler should -error if a vesting account is trying to send an amount that exceeds their -unlocked coin amount. +`VestingAccount` 实现驻留在 `x/auth` 中。 然而，任何门将 +希望潜在地利用任何归属的模块(例如在`x/staking`中进行质押) +硬币，必须在`x/bank` keeper 上调用显式方法(例如`DelegateCoins`) +与“SendCoins”和“SubtractCoins”相反。 -See the above specification for full implementation details. +另外，归属账户也应该可以花掉任何币吧 +从其他用户接收。 因此，银行模块的 `MsgSend` 处理程序应该 +如果归属账户试图发送超过其数量的金额，则会出现错误 +解锁的硬币数量。 +有关完整的实现细节，请参阅上述规范。 ## Genesis Initialization -To initialize both vesting and non-vesting accounts, the `GenesisAccount` struct -includes new fields: `Vesting`, `StartTime`, and `EndTime`. Accounts meant to be -of type `BaseAccount` or any non-vesting type have `Vesting = false`. The -genesis initialization logic (e.g. `initFromGenesisState`) must parse -and return the correct accounts accordingly based off of these fields. +要初始化归属和非归属账户，“GenesisAccount”结构 +包括新字段:“Vesting”、“StartTime”和“EndTime”。 帐户应该是 +“BaseAccount”类型或任何非归属类型具有“Vesting = false”。 这 +创世初始化逻辑(例如`initFromGenesisState`)必须解析 +并根据这些字段相应地返回正确的帐户。 ```go type GenesisAccount struct { @@ -455,7 +452,7 @@ func ToAccount(gacc GenesisAccount) Account { ### Simple -Given a continuous vesting account with 10 vesting coins. +给定一个具有 10 个归属币的连续归属账户。 ``` OV = 10 diff --git a/docs/ja/modules/auth/06_params.md b/docs/ja/modules/auth/06_params.md index 1250aaa319bf..441668f69c2a 100644 --- a/docs/ja/modules/auth/06_params.md +++ b/docs/ja/modules/auth/06_params.md @@ -1,6 +1,6 @@ # Parameters -The auth module contains the following parameters: +auth 模块包含以下参数: | Key | Type | Example | | ---------------------- | --------------- | ------- | diff --git a/docs/ja/modules/auth/07_client.md b/docs/ja/modules/auth/07_client.md index 0e0129be5d5c..f80d9ac01bb6 100644 --- a/docs/ja/modules/auth/07_client.md +++ b/docs/ja/modules/auth/07_client.md @@ -1,22 +1,22 @@ -# Client +# 客户 -# Auth +# 认证 -## CLI +##命令行界面 -A user can query and interact with the `auth` module using the CLI. +用户可以使用 CLI 查询“auth”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `auth` state. +`query` 命令允许用户查询 `auth` 状态。 ```bash simd query auth --help ``` -#### account +#### 帐户 -The `account` command allow users to query for an account by it's address. +`account` 命令允许用户通过其地址查询帐户。 ```bash simd query auth account [address] [flags] diff --git a/docs/ja/modules/auth/README.md b/docs/ja/modules/auth/README.md index 4e6be13c88d8..c110de37dfcb 100644 --- a/docs/ja/modules/auth/README.md +++ b/docs/ja/modules/auth/README.md @@ -1,39 +1,39 @@ -# `auth` +# `认证` -## Abstract +## 摘要 -This document specifies the auth module of the Cosmos SDK. +本文档指定了 Cosmos SDK 的 auth 模块。 -The auth module is responsible for specifying the base transaction and account types -for an application, since the SDK itself is agnostic to these particulars. It contains -the ante handler, where all basic transaction validity checks (signatures, nonces, auxiliary fields) -are performed, and exposes the account keeper, which allows other modules to read, write, and modify accounts. +auth 模块负责指定基础交易和账户类型 +对于应用程序，因为 SDK 本身与这些细节无关。它包含 +ante 处理程序，其中所有基本交易有效性检查(签名、随机数、辅助字段) +执行，并暴露帐户管理器，允许其他模块读取、写入和修改帐户。 -This module is used in the Cosmos Hub. +该模块用于 Cosmos Hub。 -## Contents +## 内容 -1. **[Concepts](01_concepts.md)** +1. **[概念](01_concepts.md)** - [Gas & Fees](01_concepts.md#gas-&-fees) -2. **[State](02_state.md)** - - [Accounts](02_state.md#accounts) +2. **[状态](02_state.md)** + - [账户](02_state.md#accounts) 3. **[AnteHandlers](03_antehandlers.md)** - - [Handlers](03_antehandlers.md#handlers) + - [处理程序](03_antehandlers.md#handlers) 4. **[Keepers](04_keepers.md)** - - [Account Keeper](04_keepers.md#account-keeper) -5. **[Vesting](05_vesting.md)** - - [Intro and Requirements](05_vesting.md#intro-and-requirements) - - [Vesting Account Types](05_vesting.md#vesting-account-types) - - [Vesting Account Specification](05_vesting.md#vesting-account-specification) + - [账户管理员](04_keepers.md#account-keeper) +5. **[归属](05_vesting.md)** + - [介绍和要求](05_vesting.md#intro-and-requirements) + - [归属账户类型](05_vesting.md#vesting-account-types) + - [归属账户规范](05_vesting.md#vesting-account-specification) - [Keepers & Handlers](05_vesting.md#keepers-&-handlers) - - [Genesis Initialization](05_vesting.md#genesis-initialization) - - [Examples](05_vesting.md#examples) - - [Glossary](05_vesting.md#glossary) -6. **[Parameters](06_params.md)** -7. **[Client](07_client.md)** - - **[Auth](07_client.md#auth)** + - [创世初始化](05_vesting.md#genesis-initialization) + - [例子](05_vesting.md#examples) + - [词汇](05_vesting.md#glossary) +6. **[参数](06_params.md)** +7. **[客户端](07_client.md)** + - **[认证](07_client.md#auth)** - [CLI](07_client.md#cli) - [gRPC](07_client.md#grpc) - [REST](07_client.md#rest) - - **[Vesting](07_client.md#vesting)** - - [CLI](07_client.md#vesting#cli) + - **[归属](07_client.md#vesting)** + - [CLI](07_client.md#vesting#cli) \ No newline at end of file diff --git a/docs/ja/modules/authz/01_concepts.md b/docs/ja/modules/authz/01_concepts.md index 29053b94bc76..d13f1a501ece 100644 --- a/docs/ja/modules/authz/01_concepts.md +++ b/docs/ja/modules/authz/01_concepts.md @@ -1,41 +1,41 @@ -# Concepts +# 概念 -## Authorization and Grant +## 授权和授予 -The `x/authz` module defines interfaces and messages grant authorizations to perform actions -on behalf of one account to other accounts. The design is defined in the [ADR 030](../../../docs/architecture/adr-030-authz-module.md). +`x/authz` 模块定义接口和消息授予执行操作的权限 +代表一个账户到其他账户。该设计在 [ADR 030](../../../docs/architecture/adr-030-authz-module.md) 中定义。 -A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter. -Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details. +*grant* 是受让人代表授予人执行消息的许可。 +授权是一个接口，必须由具体的授权逻辑实现以验证和执行授权。授权是可扩展的，甚至可以在定义 Msg 方法的模块之外为任何 Msg 服务方法定义。有关更多详细信息，请参阅下一节中的“SendAuthorization”示例。 -**Note:** The authz module is different from the [auth (authentication)](../modules/auth/) module that is responsible for specifying the base transaction and account types. +**注意:** authz 模块不同于 [auth(身份验证)](../modules/auth/) 模块，后者负责指定基础交易和账户类型。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/authz/authorizations.go#L11-L25 -## Built-in Authorizations +## 内置授权 -The Cosmos SDK `x/authz` module comes with following authorization types: +Cosmos SDK `x/authz` 模块带有以下授权类型: -### SendAuthorization +###发送授权 -`SendAuthorization` implements the `Authorization` interface for the `cosmos.bank.v1beta1.MsgSend` Msg. It takes a `SpendLimit` that specifies the maximum amount of tokens the grantee can spend. The `SpendLimit` is updated as the tokens are spent. +`SendAuthorization` 为 `cosmos.bank.v1beta1.MsgSend` 消息实现了 `Authorization` 接口。它需要一个 `SpendLimit` 来指定受赠者可以花费的最大代币数量。 `SpendLimit` 会随着代币的花费而更新。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/bank/v1beta1/authz.proto#L10-L19 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/bank/types/send_authorization.go#L25-L40 -- `spend_limit` keeps track of how many coins are left in the authorization. +- `spend_limit` 跟踪授权中剩余的硬币数量。 -### GenericAuthorization +### 通用授权 -`GenericAuthorization` implements the `Authorization` interface that gives unrestricted permission to execute the provided Msg on behalf of granter's account. +`GenericAuthorization` 实现了 `Authorization` 接口，该接口授予代表授予者帐户执行提供的 Msg 的不受限制的权限。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/authz/v1beta1/authz.proto#L14-L19 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/x/authz/generic_authorization.go#L18-L31 -- `msg` stores Msg type URL. +- `msg` 存储消息类型的 URL。 -## Gas +## 气体 -In order to prevent DoS attacks, granting `StakeAuthorization`s with `x/authz` incurs gas. `StakeAuthorization` allows you to authorize another account to delegate, undelegate, or redelegate to validators. The authorizer can define a list of validators they allow or deny delegations to. The Cosmos SDK iterates over these lists and charge 10 gas for each validator in both of the lists. +为了防止 DoS 攻击，使用 `x/authz` 授予 `StakeAuthorization`s 会产生 gas。 `StakeAuthorization` 允许您授权另一个帐户委派、取消委派或重新委派给验证者。授权人可以定义他们允许或拒绝委托的验证器列表。 Cosmos SDK 迭代这些列表，并为两个列表中的每个验证器收取 10 gas。 \ No newline at end of file diff --git a/docs/ja/modules/authz/02_state.md b/docs/ja/modules/authz/02_state.md index 97dfc8667315..8ae10145315f 100644 --- a/docs/ja/modules/authz/02_state.md +++ b/docs/ja/modules/authz/02_state.md @@ -1,11 +1,11 @@ -# State +# 状态 -## Grant +## 授予 -Grants are identified by combining granter address (the address bytes of the granter), grantee address (the address bytes of the grantee) and Authorization type (its type URL). Hence we only allow one grant for the (granter, grantee, Authorization) triple. +授权通过组合授权者地址(授权者的地址字节)、被授权者地址(被授权者的地址字节)和授权类型(其类型 URL)来标识。 因此，我们只允许对 (granter, grantee, Authorization) 三元组进行一次授权。 -- Grant: `0x01 | granter_address_len (1 byte) | granter_address_bytes | grantee_address_len (1 byte) | grantee_address_bytes | msgType_bytes-> ProtocolBuffer(AuthorizationGrant)` +- 授予:`0x01 | granter_address_len (1 字节) | granter_address_bytes | grantee_address_len (1 字节) | grantee_address_bytes | msgType_bytes-> ProtocolBuffer(AuthorizationGrant)` -The grant object encapsulates an `Authorization` type and an expiration timestamp: +grant 对象封装了一个 `Authorization` 类型和一个过期时间戳: -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/authz/v1beta1/authz.proto#L21-L26 ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/authz/v1beta1/authz.proto#L21-L26 \ No newline at end of file diff --git a/docs/ja/modules/authz/03_messages.md b/docs/ja/modules/authz/03_messages.md index edd3489ae8d3..692897febc7f 100644 --- a/docs/ja/modules/authz/03_messages.md +++ b/docs/ja/modules/authz/03_messages.md @@ -1,42 +1,42 @@ -# Messages +# 消息 -In this section we describe the processing of messages for the authz module. +在本节中，我们将描述 authz 模块的消息处理。 -## MsgGrant +## 消息授权 -An authorization grant is created using the `MsgGrant` message. -If there is already a grant for the `(granter, grantee, Authorization)` triple, then the new grant overwrites the previous one. To update or extend an existing grant, a new grant with the same `(granter, grantee, Authorization)` triple should be created. +使用“MsgGrant”消息创建授权许可。 +如果已经有对 `(granter, grantee, Authorization)` 三元组的授权，那么新的授权会覆盖之前的授权。要更新或扩展现有授权，应创建具有相同“(授权者、被授权者、授权)”三元组的新授权。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/authz/v1beta1/tx.proto#L32-L37 -The message handling should fail if: +如果出现以下情况，消息处理应该会失败: -- both granter and grantee have the same address. -- provided `Expiration` time is less than current unix timestamp. -- provided `Grant.Authorization` is not implemented. -- `Authorization.MsgTypeURL()` is not defined in the router (there is no defined handler in the app router to handle that Msg types). +- 授予者和受赠者的地址相同。 +- 提供的`Expiration` 时间小于当前的 unix 时间戳。 +- 如果没有实现`Grant.Authorization`。 +- `Authorization.MsgTypeURL()` 未在路由器中定义(应用路由器中没有定义的处理程序来处理该消息类型)。 -## MsgRevoke +## 消息撤销 -A grant can be removed with the `MsgRevoke` message. +可以使用 `MsgRevoke` 消息删除授权。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/authz/v1beta1/tx.proto#L60-L64 -The message handling should fail if: +如果出现以下情况，消息处理应该会失败: -- both granter and grantee have the same address. -- provided `MsgTypeUrl` is empty. +- 授予者和受赠者的地址相同。 +- 假设 `MsgTypeUrl` 为空。 -NOTE: The `MsgExec` message removes a grant if the grant has expired. +注意:如果授权已过期，`MsgExec` 消息将删除授权。 -## MsgExec +## 消息执行 -When a grantee wants to execute a transaction on behalf of a granter, they must send `MsgExec`. +当受赠人想要代表受赠人执行交易时，他们必须发送“MsgExec”。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-beta1/proto/cosmos/authz/v1beta1/tx.proto#L47-L53 -The message handling should fail if: +如果出现以下情况，消息处理应该会失败: -- provided `Authorization` is not implemented. -- grantee doesn't have permission to run the transaction. -- if granted authorization is expired. +- 前提是未实现“授权”。 +- 受让人无权运行交易。 +- 如果授予的授权已过期。 \ No newline at end of file diff --git a/docs/ja/modules/authz/04_events.md b/docs/ja/modules/authz/04_events.md index 053984ba80ef..6c69fcaf2eb5 100644 --- a/docs/ja/modules/authz/04_events.md +++ b/docs/ja/modules/authz/04_events.md @@ -1,3 +1,3 @@ -# Events +# 事件 -The authz module emits proto events defined in [the Protobuf reference](../../../core/proto-docs.md#cosmos/authz/v1beta1/event.proto). +authz 模块发出在 [Protobuf 参考](../../../core/proto-docs.md#cosmos/authz/v1beta1/event.proto) 中定义的 proto 事件。 \ No newline at end of file diff --git a/docs/ja/modules/authz/05_client.md b/docs/ja/modules/authz/05_client.md index 5b27e58e817e..5639c05fd536 100644 --- a/docs/ja/modules/authz/05_client.md +++ b/docs/ja/modules/authz/05_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `authz` module using the CLI. +用户可以使用 CLI 查询“authz”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `authz` state. +`query` 命令允许用户查询 `authz` 状态。 ```bash simd query authz --help @@ -14,7 +14,7 @@ simd query authz --help #### grants -The `grants` command allows users to query grants for a granter-grantee pair. If the message type URL is set, it selects grants only for that message type. +`grants` 命令允许用户查询授权者-被授权者对的授权。 如果设置了消息类型 URL，则它只为该消息类型选择授权。 ```bash simd query authz grants [granter-addr] [grantee-addr] [msg-type-url]? [flags] diff --git a/docs/ja/modules/authz/README.md b/docs/ja/modules/authz/README.md index 065ef5d9ef1d..1587c3d40aee 100644 --- a/docs/ja/modules/authz/README.md +++ b/docs/ja/modules/authz/README.md @@ -1,23 +1,23 @@ # `authz` -## Contents +## 内容 -## Abstract +## 摘要 -`x/authz` is an implementation of a Cosmos SDK module, per [ADR 30](../../../docs/architecture/adr-030-authz-module.md), that allows -granting arbitrary privileges from one account (the granter) to another account (the grantee). Authorizations must be granted for a particular Msg service method one by one using an implementation of the `Authorization` interface. +`x/authz` 是 Cosmos SDK 模块的实现，根据 [ADR 30](../../../docs/architecture/adr-030-authz-module.md)，它允许 +从一个帐户(授予者)向另一个帐户(被授予者)授予任意权限。 必须使用“授权”接口的实现为特定的消息服务方法一一授予授权。 -1. **[Concept](01_concepts.md)** - - [Authorization and Grant](01_concepts.md#Authorization-and-Grant) - - [Built-in Authorizations](01_concepts.md#Built-in-Authorizations) - - [Gas](01_concepts.md#gas) -2. **[State](02_state.md)** -3. **[Messages](03_messages.md)** - - [MsgGrant](03_messages.md#MsgGrant) - - [MsgRevoke](03_messages.md#MsgRevoke) - - [MsgExec](03_messages.md#MsgExec) -4. **[Events](04_events.md)** -5. **[Client](05_client.md)** - - [CLI](05_client.md#cli) - - [gRPC](05_client.md#grpc) - - [REST](05_client.md#rest) +1. **[概念](01_concepts.md)** + - [授权和授予](01_concepts.md#Authorization-and-Grant) + - [内置授权](01_concepts.md#Built-in-Authorizations) + - [气体](01_concepts.md#gas) +2. **[状态](02_state.md)** +3. **[消息](03_messages.md)** + - [MsgGrant](03_messages.md#MsgGrant) + - [MsgRevoke](03_messages.md#MsgRevoke) + - [MsgExec](03_messages.md#MsgExec) +4. **[事件](04_events.md)** +5. **[客户端](05_client.md)** + - [CLI](05_client.md#cli) + - [gRPC](05_client.md#grpc) + - [REST](05_client.md#rest) \ No newline at end of file diff --git a/docs/ja/modules/bank/01_state.md b/docs/ja/modules/bank/01_state.md index a8edcd3218ce..119387557e4a 100644 --- a/docs/ja/modules/bank/01_state.md +++ b/docs/ja/modules/bank/01_state.md @@ -1,15 +1,15 @@ -# State +# 状态 -The `x/bank` module keeps state of three primary objects: +`x/bank` 模块保持三个主要对象的状态: -1. Account balances -2. Denomination metadata -3. The total supply of all balances +1. 账户余额 +2. 面额元数据 +3. 所有余额的总供应量 -In addition, the `x/bank` module keeps the following indexes to manage the -aforementioned state: +此外，`x/bank` 模块保存了以下索引来管理 +上述状态: -- Supply Index: `0x0 | byte(denom) -> byte(amount)` -- Denom Metadata Index: `0x1 | byte(denom) -> ProtocolBuffer(Metadata)` -- Balances Index: `0x2 | byte(address length) | []byte(address) | []byte(balance.Denom) -> ProtocolBuffer(balance)` -- Reverse Denomination to Address Index: `0x03 | byte(denom) | 0x00 | []byte(address) -> 0` +- 供应指数:`0x0 | byte(denom) -> byte(amount)` +- Denom 元数据索引:`0x1 | byte(denom) -> ProtocolBuffer(Metadata)` +- 余额指数:`0x2 | 字节(地址长度)| []字节(地址)| []byte(balance.Denom) -> ProtocolBuffer(balance)` +- 反向命名地址索引:`0x03 | 字节(denom) | 0x00 | []字节(地址)-> 0` \ No newline at end of file diff --git a/docs/ja/modules/bank/02_keepers.md b/docs/ja/modules/bank/02_keepers.md index a5d9e9172aaf..f1b11b01da57 100644 --- a/docs/ja/modules/bank/02_keepers.md +++ b/docs/ja/modules/bank/02_keepers.md @@ -1,30 +1,30 @@ -# Keepers +# 守门员 -The bank module provides these exported keeper interfaces that can be -passed to other modules that read or update account balances. Modules -should use the least-permissive interface that provides the functionality they -require. +bank 模块提供了这些导出的 keeper 接口，可以 +传递给读取或更新帐户余额的其他模块。模块 +应该使用提供它们的功能的最少许可的接口 +要求。 -Best practices dictate careful review of `bank` module code to ensure that -permissions are limited in the way that you expect. +最佳实践要求仔细审查“银行”模块代码，以确保 +权限以您期望的方式受到限制。 -## Blocklisting Addresses +## 屏蔽地址 -The `x/bank` module accepts a map of addresses that are considered blocklisted -from directly and explicitly receiving funds through means such as `MsgSend` and -`MsgMultiSend` and direct API calls like `SendCoinsFromModuleToAccount`. +`x/bank` 模块接受被视为阻止列表的地址映射 +通过“MsgSend”等方式直接明确地接收资金， +`MsgMultiSend` 和直接 API 调用，如 `SendCoinsFromModuleToAccount`。 -Typically, these addresses are module accounts. If these addresses receive funds -outside the expected rules of the state machine, invariants are likely to be -broken and could result in a halted network. +通常，这些地址是模块帐户。如果这些地址收到资金 +在状态机的预期规则之外，不变量很可能是 +损坏并可能导致网络停止。 -By providing the `x/bank` module with a blocklisted set of addresses, an error occurs for the operation if a user or client attempts to directly or indirectly send funds to a blocklisted account, for example, by using [IBC](http://docs.cosmos.network/master/ibc/). +通过为“x/bank”模块提供一组被屏蔽的地址，如果用户或客户试图直接或间接地将资金发送到被屏蔽的账户，例如，通过使用 [IBC](http: //docs.cosmos.network/master/ibc/)。 -## Common Types +## 常见类型 -### Input +### 输入 -An input of a multiparty transfer +多方转移的输入 ```protobuf // Input models transaction input. @@ -48,7 +48,7 @@ message Output { ## BaseKeeper -The base keeper provides full-permission access: the ability to arbitrary modify any account's balance and mint or burn coins. +Base keeper 提供完全权限访问:能够任意修改任何帐户的余额并铸造或燃烧硬币。 ```go // Keeper defines a module interface that facilitates the transfer of coins @@ -83,8 +83,8 @@ type Keeper interface { ## SendKeeper -The send keeper provides access to account balances and the ability to transfer coins between -accounts. The send keeper does not alter the total supply (mint or burn coins). +发送保管员提供对帐户余额的访问以及在之间转移硬币的能力 +帐户。 发送管理员不会改变总供应量(铸造或燃烧硬币)。 ```go // SendKeeper defines a module interface that facilitates the transfer of coins @@ -107,7 +107,7 @@ type SendKeeper interface { ## ViewKeeper -The view keeper provides read-only access to account balances. The view keeper does not have balance alteration functionality. All balance lookups are `O(1)`. +视图管理器提供对帐户余额的只读访问。 视图保持器没有平衡更改功能。 所有余额查找都是“O(1)”。 ```go // ViewKeeper defines a module interface that facilitates read only access to diff --git a/docs/ja/modules/bank/03_messages.md b/docs/ja/modules/bank/03_messages.md index 6e7a8b3c9ae7..1627786375a5 100644 --- a/docs/ja/modules/bank/03_messages.md +++ b/docs/ja/modules/bank/03_messages.md @@ -1,23 +1,23 @@ -# Messages +# 消息 -## MsgSend +## 消息发送 -Send coins from one address to another. +将硬币从一个地址发送到另一个地址。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/bank/v1beta1/tx.proto#L19-L28 -The message will fail under the following conditions: +在以下情况下，消息将失败: -- The coins do not have sending enabled -- The `to` address is restricted +- 硬币没有启用发送 +- `to` 地址受到限制 ## MsgMultiSend -Send coins from and to a series of different address. If any of the receiving addresses do not correspond to an existing account, a new account is created. +从和向一系列不同的地址发送硬币。 如果任何接收地址与现有帐户不对应，则会创建一个新帐户。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/bank/v1beta1/tx.proto#L33-L39 -The message will fail under the following conditions: +在以下情况下，消息将失败: -- Any of the coins do not have sending enabled -- Any of the `to` addresses are restricted -- Any of the coins are locked -- The inputs and outputs do not correctly correspond to one another +- 任何硬币都没有启用发送 +- 任何“to”地址都受到限制 +- 任何硬币都被锁定 +- 输入和输出没有正确对应 \ No newline at end of file diff --git a/docs/ja/modules/bank/04_events.md b/docs/ja/modules/bank/04_events.md index 17a15b99dc08..e6be044a944c 100644 --- a/docs/ja/modules/bank/04_events.md +++ b/docs/ja/modules/bank/04_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The bank module emits the following events: +bank 模块发出以下事件: ## Handlers @@ -26,7 +26,7 @@ The bank module emits the following events: ## Keeper events -In addition to handlers events, the bank keeper will produce events when the following methods are called (or any method which ends up calling them) +除了处理程序事件之外，银行管理员将在调用以下方法(或最终调用它们的任何方法)时产生事件 ### MintCoins diff --git a/docs/ja/modules/bank/05_params.md b/docs/ja/modules/bank/05_params.md index 6a252e8c3ada..95b724fbff18 100644 --- a/docs/ja/modules/bank/05_params.md +++ b/docs/ja/modules/bank/05_params.md @@ -1,20 +1,20 @@ -# Parameters +# 参数 -The bank module contains the following parameters: +bank 模块包含以下参数: | Key | Type | Example | | ------------------ | ------------- | ---------------------------------- | | SendEnabled | []SendEnabled | [{denom: "stake", enabled: true }] | | DefaultSendEnabled | bool | true | -## SendEnabled +## 发送启用 -The send enabled parameter is an array of SendEnabled entries mapping coin -denominations to their send_enabled status. Entries in this list take -precedence over the `DefaultSendEnabled` setting. +发送启用参数是一组 SendEnabled 条目映射硬币 +面额到其 send_enabled 状态。 此列表中的条目需要 +优先于 `DefaultSendEnabled` 设置。 -## DefaultSendEnabled +## 默认发送启用 -The default send enabled value controls send transfer capability for all -coin denominations unless specifically included in the array of `SendEnabled` -parameters. +默认发送启用值控制所有发送传输能力 +硬币面额，除非特别包含在 `SendEnabled` 数组中 +参数。 \ No newline at end of file diff --git a/docs/ja/modules/bank/06_client.md b/docs/ja/modules/bank/06_client.md index e293c5b9b3cd..57a538cabcb2 100644 --- a/docs/ja/modules/bank/06_client.md +++ b/docs/ja/modules/bank/06_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `bank` module using the CLI. +用户可以使用 CLI 查询“bank”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `bank` state. +`query` 命令允许用户查询 `bank` 状态。 ``` simd query bank --help @@ -14,8 +14,7 @@ simd query bank --help #### balances -The `balances` command allows users to query account balances by address. - +`balances` 命令允许用户按地址查询账户余额。 ``` simd query bank balances [address] [flags] ``` @@ -39,7 +38,7 @@ pagination: #### denom-metadata -The `denom-metadata` command allows users to query metadata for coin denominations. A user can query metadata for a single denomination using the `--denom` flag or all denominations without it. +`denom-metadata` 命令允许用户查询硬币面额的元数据。 用户可以使用 `--denom` 标志查询单个面额的元数据，或者没有它的所有面额。 ``` simd query bank denom-metadata [flags] @@ -68,7 +67,7 @@ metadata: #### total -The `total` command allows users to query the total supply of coins. A user can query the total supply for a single coin using the `--denom` flag or all coins without it. +`total` 命令允许用户查询硬币的总供应量。 用户可以使用 `--denom` 标志或没有它的所有硬币查询单个硬币的总供应量。 ``` simd query bank total [flags] diff --git a/docs/ja/modules/bank/README.md b/docs/ja/modules/bank/README.md index 88dc4638b0b6..c368e4cd7e38 100644 --- a/docs/ja/modules/bank/README.md +++ b/docs/ja/modules/bank/README.md @@ -1,48 +1,48 @@ -# `x/bank` +# `x/银行` -## Abstract +## 摘要 -This document specifies the bank module of the Cosmos SDK. +本文档指定了 Cosmos SDK 的银行模块。 -The bank module is responsible for handling multi-asset coin transfers between -accounts and tracking special-case pseudo-transfers which must work differently -with particular kinds of accounts (notably delegating/undelegating for vesting -accounts). It exposes several interfaces with varying capabilities for secure -interaction with other modules which must alter user balances. +银行模块负责处理多资产硬币之间的转移 +帐户和跟踪必须以不同方式工作的特殊情况的伪转移 +具有特定类型的账户(特别是授权/取消授权以进行归属 +帐户)。它公开了几个具有不同安全功能的接口 +与必须改变用户余额的其他模块的交互。 -In addition, the bank module tracks and provides query support for the total -supply of all assets used in the application. +此外，银行模块跟踪并提供总计查询支持。 +应用程序中使用的所有资产的供应。 -This module will be used in the Cosmos Hub. +该模块将用于 Cosmos Hub。 -## Supply +## 供应 -The `supply` functionality: +`supply` 功能: -- passively tracks the total supply of coins within a chain, -- provides a pattern for modules to hold/interact with `Coins`, and -- introduces the invariant check to verify a chain's total supply. +- 被动跟踪链中硬币的总供应量， +- 为模块提供了一种模式来保存/与`Coins`交互，并且 +- 引入不变检查来验证链的总供应量。 -### Total Supply +### 总供应量 -The total `Supply` of the network is equal to the sum of all coins from the -account. The total supply is updated every time a `Coin` is minted (eg: as part -of the inflation mechanism) or burned (eg: due to slashing or if a governance -proposal is vetoed). +网络的总“供应”等于所有硬币的总和 +帐户。每次铸造“硬币”时都会更新总供应量(例如:作为一部分 +通货膨胀机制)或烧毁(例如:由于削减或如果治理 +提案被否决)。 -## Module Accounts +## 模块帐户 -The supply functionality introduces a new type of `auth.Account` which can be used by -modules to allocate tokens and in special cases mint or burn tokens. At a base -level these module accounts are capable of sending/receiving tokens to and from -`auth.Account`s and other module accounts. This design replaces previous -alternative designs where, to hold tokens, modules would burn the incoming -tokens from the sender account, and then track those tokens internally. Later, -in order to send tokens, the module would need to effectively mint tokens -within a destination account. The new design removes duplicate logic between -modules to perform this accounting. +供应功能引入了一种新类型的“auth.Account”，它可以被 +分配代币的模块，在特殊情况下铸造或销毁代币。在一个基地 +级别这些模块帐户能够发送/接收令牌 +`auth.Account`s 和其他模块帐户。这种设计取代了以前的 +替代设计，其中，为了持有代币，模块会烧掉传入的代币 +来自发件人帐户的令牌，然后在内部跟踪这些令牌。之后， +为了发送令牌，该模块需要有效地铸造令牌 +在目标帐户中。新设计消除了之间的重复逻辑 +模块来执行此记帐。 -The `ModuleAccount` interface is defined as follows: +`ModuleAccount` 接口定义如下: ```go type ModuleAccount interface { @@ -54,45 +54,45 @@ type ModuleAccount interface { } ``` -> **WARNING!** -> Any module or message handler that allows either direct or indirect sending of funds must explicitly guarantee those funds cannot be sent to module accounts (unless allowed). +> **警告！** +> 任何允许直接或间接发送资金的模块或消息处理程序必须明确保证这些资金不能发送到模块账户(除非被允许)。 -The supply `Keeper` also introduces new wrapper functions for the auth `Keeper` -and the bank `Keeper` that are related to `ModuleAccount`s in order to be able -to: +供应`Keeper` 还为auth `Keeper` 引入了新的包装函数 +以及与“ModuleAccount”相关的银行“Keeper”，以便能够 +到: -- Get and set `ModuleAccount`s by providing the `Name`. -- Send coins from and to other `ModuleAccount`s or standard `Account`s - (`BaseAccount` or `VestingAccount`) by passing only the `Name`. -- `Mint` or `Burn` coins for a `ModuleAccount` (restricted to its permissions). +- 通过提供`Name`来获取和设置`ModuleAccount`s。 +- 在其他`ModuleAccount`s 或标准`Account`s 之间发送硬币 + (`BaseAccount` 或 `VestingAccount`)只传递 `Name`。 +-`ModuleAccount` 的`Mint` 或`Burn` 硬币(受限于其权限)。 -### Permissions +### 权限 -Each `ModuleAccount` has a different set of permissions that provide different -object capabilities to perform certain actions. Permissions need to be -registered upon the creation of the supply `Keeper` so that every time a -`ModuleAccount` calls the allowed functions, the `Keeper` can lookup the -permissions to that specific account and perform or not the action. +每个 `ModuleAccount` 都有一组不同的权限，提供不同的权限 +对象执行某些操作的能力。权限需要 +在创建供应“Keeper”时注册，以便每次 +`ModuleAccount` 调用允许的函数，`Keeper` 可以查找 +该特定帐户的权限并执行或不执行该操作。 -The available permissions are: +可用的权限是: -- `Minter`: allows for a module to mint a specific amount of coins. -- `Burner`: allows for a module to burn a specific amount of coins. -- `Staking`: allows for a module to delegate and undelegate a specific amount of coins. +- `Minter`:允许模块铸造特定数量的硬币。 +- `Burner`:允许模块燃烧特定数量的硬币。 +- `Staking`:允许模块委托和取消委托特定数量的硬币。 -## Contents +## 内容 -1. **[State](01_state.md)** +1. **[状态](01_state.md)** 2. **[Keepers](02_keepers.md)** - - [Common Types](02_keepers.md#common-types) + - [常见类型](02_keepers.md#common-types) - [BaseKeeper](02_keepers.md#basekeeper) - [SendKeeper](02_keepers.md#sendkeeper) - [ViewKeeper](02_keepers.md#viewkeeper) -3. **[Messages](03_messages.md)** +3. **[消息](03_messages.md)** - [MsgSend](03_messages.md#msgsend) -4. **[Events](04_events.md)** - - [Handlers](04_events.md#handlers) -5. **[Parameters](05_params.md)** -6. **[Client](06_client.md)** +4. **[事件](04_events.md)** + - [处理程序](04_events.md#handlers) +5. **[参数](05_params.md)** +6. **[客户端](06_client.md)** - [CLI](06_client.md#cli) - - [gRPC](06_client.md#grpc) + - [gRPC](06_client.md#grpc) \ No newline at end of file diff --git a/docs/ja/modules/capability/01_concepts.md b/docs/ja/modules/capability/01_concepts.md index 8f06f909f4ce..1a6b74adb402 100644 --- a/docs/ja/modules/capability/01_concepts.md +++ b/docs/ja/modules/capability/01_concepts.md @@ -1,30 +1,30 @@ -# Concepts +# 概念 -## Capabilities +## 能力 -Capabilities are multi-owner. A scoped keeper can create a capability via `NewCapability` -which creates a new unique, unforgeable object-capability reference. The newly -created capability is automatically persisted; the calling module need not call -`ClaimCapability`. Calling `NewCapability` will create the capability with the -calling module and name as a tuple to be treated the capabilities first owner. +能力是多所有者的。作用域的 keeper 可以通过 `NewCapability` 创建一个能力 +它创建了一个新的唯一的、不可伪造的对象能力引用。新的 +创建的能力会自动持久化；调用模块不需要调用 +“索赔能力”。调用 `NewCapability` 将创建具有 +调用模块和名称作为元组被视为功能第一所有者。 -Capabilities can be claimed by other modules which add them as owners. `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. Again, capabilities are multi-owner, so if multiple modules have a -single Capability reference, they will all own it. If a module receives a capability -from another module but does not call `ClaimCapability`, it may use it in the executing -transaction but will not be able to access it afterwards. +其他模块可以声明功能，这些模块将它们添加为所有者。 `索赔能力` +允许一个模块声明它从另一个模块收到的能力密钥 +模块，以便未来的`GetCapability` 调用成功。 `ClaimCapability` 必须 +如果接收能力的模块希望通过名称访问它，则调用 +未来。同样，能力是多所有者的，所以如果多个模块有一个 +单一的能力参考，他们都将拥有它。如果一个模块收到一个能力 +来自另一个模块但不调用`ClaimCapability`，它可以在执行中使用它 +交易，但之后将无法访问它。 -`AuthenticateCapability` can be called by any module to check that a capability -does in fact correspond to a particular name (the name can be un-trusted user input) -with which the calling module previously associated it. +任何模块都可以调用 AuthenticateCapability 来检查能力 +实际上确实对应于特定名称(名称可以是不受信任的用户输入) +调用模块之前与之关联的。 -`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. +`GetCapability` 允许模块获取它之前拥有的能力 +以名义声称。该模块不允许检索它所做的功能 +不是自己的。 -## Stores +## 存储 -- MemStore +- 记忆库 \ No newline at end of file diff --git a/docs/ja/modules/capability/README.md b/docs/ja/modules/capability/README.md index 3db453c24600..88b165a3bc58 100644 --- a/docs/ja/modules/capability/README.md +++ b/docs/ja/modules/capability/README.md @@ -1,33 +1,33 @@ -# `capability` +# `能力` -## Overview +## 概述 -`x/capability` is an implementation of a Cosmos SDK module, per [ADR 003](./../../../docs/architecture/adr-003-dynamic-capability-store.md), -that allows for provisioning, tracking, and authenticating multi-owner capabilities -at runtime. +`x/capability` 是 Cosmos SDK 模块的实现，根据 [ADR 003](./../../../docs/architecture/adr-003-dynamic-capability-store.md)， +允许配置、跟踪和验证多所有者功能 +在运行时。 -The keeper maintains two states: persistent and ephemeral in-memory. The persistent -store maintains a globally unique auto-incrementing index and a mapping from -capability index to a set of capability owners that are defined as a module and -capability name tuple. The in-memory ephemeral state keeps track of the actual -capabilities, represented as addresses in local memory, with both forward and reverse indexes. -The forward index maps module name and capability tuples to the capability name. The -reverse index maps between the module and capability name and the capability itself. +keeper 维护两种状态:持久和短暂的内存。执着的 +store 维护一个全局唯一的自动递增索引和一个映射 +一组被定义为模块的能力所有者的能力索引和 +能力名称元组。内存中的临时状态跟踪实际 +能力，表示为本地内存中的地址，具有正向和反向索引。 +前向索引将模块名称和能力元组映射到能力名称。这 +模块和功能名称与功能本身之间的反向索引映射。 -The keeper allows the creation of "scoped" sub-keepers which are tied to a particular -module by name. Scoped keepers must be created at application initialization 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. A scoped keeper cannot escape its scope, -so a module cannot interfere with or inspect capabilities owned by other modules. +Keeper 允许创建“范围”的子管理器，这些子管理器与特定的 +模块名称。必须在应用程序初始化和 +传递给模块，然后模块可以使用它们来声明它们接收和 +除了创建新功能外，还可以检索他们按名称拥有的功能 +& 验证其他模块传递的功能。一个有范围的守护者无法逃脱它的范围， +所以一个模块不能干扰或检查其他模块拥有的功能。 -The keeper provides no other core functionality that can be found in other modules -like queriers, REST and CLI handlers, and genesis state. +Keeper 不提供其他模块中可以找到的其他核心功能 +像查询器、REST 和 CLI 处理程序以及创世状态。 -## Initialization +## 初始化 -During application initialization, the keeper must be instantiated with a persistent -store key and an in-memory store key. +在应用程序初始化期间，Keeper 必须用一个持久化的实例化 +存储密钥和内存存储密钥。 ```go type App struct { @@ -66,4 +66,4 @@ func NewApp(...) *App { ## Contents 1. **[Concepts](01_concepts.md)** -1. **[State](02_state.md)** +2. **[State](02_state.md)** diff --git a/docs/ja/modules/crisis/01_state.md b/docs/ja/modules/crisis/01_state.md index 14314dd5859a..0a68c9817ed2 100644 --- a/docs/ja/modules/crisis/01_state.md +++ b/docs/ja/modules/crisis/01_state.md @@ -1,13 +1,13 @@ -# State +# 状态 -## ConstantFee +## 固定费用 -Due to the anticipated large gas cost requirement to verify an invariant (and -potential to exceed the maximum allowable block gas limit) a constant fee is -used instead of the standard gas consumption method. The constant fee is -intended to be larger than the anticipated gas cost of running the invariant -with the standard gas consumption method. +由于验证不变量(和 +可能超过最大允许的区块gas限制)一个恒定的费用是 +用于代替标准耗气量法。 固定费用是 +旨在大于运行不变量的预期 gas 成本 +用标准耗气量法。 -The ConstantFee param is held in the global params store. +ConstantFee 参数保存在全局参数存储中。 -- Params: `mint/params -> legacy_amino(sdk.Coin)` +- 参数:`mint/params -> legacy_amino(sdk.Coin)` \ No newline at end of file diff --git a/docs/ja/modules/crisis/02_messages.md b/docs/ja/modules/crisis/02_messages.md index bb6ade67e425..2df4c887206c 100644 --- a/docs/ja/modules/crisis/02_messages.md +++ b/docs/ja/modules/crisis/02_messages.md @@ -1,21 +1,21 @@ -# Messages +# 消息 -In this section we describe the processing of the crisis messages and the -corresponding updates to the state. +在本节中，我们将描述危机消息的处理以及 +状态的相应更新。 ## MsgVerifyInvariant -Blockchain invariants can be checked using the `MsgVerifyInvariant` message. +可以使用“MsgVerifyInvariant”消息检查区块链不变量。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/crisis/v1beta1/tx.proto#L14-L22 -This message is expected to fail if: +如果出现以下情况，此消息预计会失败: -- the sender does not have enough coins for the constant fee -- the invariant route is not registered +- 发件人没有足够的硬币来支付固定费用 +- 不变路由未注册 -This message checks the invariant provided, and if the invariant is broken it -panics, halting the blockchain. If the invariant is broken, the constant fee is -never deducted as the transaction is never committed to a block (equivalent to -being refunded). However, if the invariant is not broken, the constant fee will -not be refunded. +此消息检查提供的不变量，如果不变量被破坏 +恐慌，停止区块链。 如果不变量被破坏，则恒定费用为 +从未扣除，因为交易从未提交到区块(相当于 +被退还)。 但是，如果不变量不破，恒定费用将 +不予退还。 \ No newline at end of file diff --git a/docs/ja/modules/crisis/03_events.md b/docs/ja/modules/crisis/03_events.md index f645e823b715..f002e4c4c978 100644 --- a/docs/ja/modules/crisis/03_events.md +++ b/docs/ja/modules/crisis/03_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The crisis module emits the following events: +危机模块发出以下事件: ## Handlers diff --git a/docs/ja/modules/crisis/04_params.md b/docs/ja/modules/crisis/04_params.md index 19ccc364829c..11e3d5c855ff 100644 --- a/docs/ja/modules/crisis/04_params.md +++ b/docs/ja/modules/crisis/04_params.md @@ -1,6 +1,6 @@ -# Parameters +# 参数 -The crisis module contains the following parameters: +危机模块包含以下参数: | Key | Type | Example | |-------------|---------------|-----------------------------------| diff --git a/docs/ja/modules/crisis/05_client.md b/docs/ja/modules/crisis/05_client.md index 09ad513e8bcc..6ffb2190efee 100644 --- a/docs/ja/modules/crisis/05_client.md +++ b/docs/ja/modules/crisis/05_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `crisis` module using the CLI. +用户可以使用 CLI 查询“危机”模块并与之交互。 ### Transactions -The `tx` commands allow users to interact with the `crisis` module. +`tx` 命令允许用户与 `crisis` 模块交互。 ```bash simd tx crisis --help @@ -14,7 +14,7 @@ simd tx crisis --help #### invariant-broken -The `invariant-broken` command submits proof when an invariant was broken to halt the chain +`invariant-broken` 命令在不变量被破坏以停止链时提交证明 ```bash simd tx crisis invariant-broken [module-name] [invariant-route] [flags] diff --git a/docs/ja/modules/crisis/README.md b/docs/ja/modules/crisis/README.md index 699b3b446054..6bfc8d046756 100644 --- a/docs/ja/modules/crisis/README.md +++ b/docs/ja/modules/crisis/README.md @@ -1,19 +1,19 @@ -# `crisis` +# `危机` -## Overview +## 概述 -The crisis module halts the blockchain under the circumstance that a blockchain -invariant is broken. Invariants can be registered with the application during the -application initialization process. +危机模块在一个区块链的情况下停止区块链 +不变量被破坏。 不变量可以在应用程序中注册 +应用程序初始化过程。 -## Contents +## 内容 -1. **[State](01_state.md)** - - [ConstantFee](01_state.md#constantfee) -2. **[Messages](02_messages.md)** - - [MsgVerifyInvariant](02_messages.md#msgverifyinvariant) -3. **[Events](03_events.md)** - - [Handlers](03_events.md#handlers) -4. **[Parameters](04_params.md)** -5. **[Client](05_client.md)** - - [CLI](05_client.md#cli) +1. **[状态](01_state.md)** + - [ConstantFee](01_state.md#constantfee) +2. **[消息](02_messages.md)** + - [MsgVerifyInvariant](02_messages.md#msgverifyinvariant) +3. **[事件](03_events.md)** + - [处理程序](03_events.md#handlers) +4. **[参数](04_params.md)** +5. **[客户端](05_client.md)** + - [CLI](05_client.md#cli) \ No newline at end of file diff --git a/docs/ja/modules/distribution/01_concepts.md b/docs/ja/modules/distribution/01_concepts.md index 64f177545ac4..e908023f33c7 100644 --- a/docs/ja/modules/distribution/01_concepts.md +++ b/docs/ja/modules/distribution/01_concepts.md @@ -1,30 +1,30 @@ -# Concepts +# 概念 -In Proof of Stake (PoS) blockchains, rewards gained from transaction fees are paid to validators. The fee distribution module fairly distributes the rewards to the validators' constituent delegators. +在权益证明 (PoS) 区块链中，从交易费用中获得的奖励将支付给验证者。费用分配模块将奖励公平地分配给验证者的组成委托人。 -Rewards are calculated per period. The period is updated each time a validator's delegation changes, for example, when the validator receives a new delegation. -The rewards for a single validator can then be calculated by taking the total rewards for the period before the delegation started, minus the current total rewards. -To learn more, see the [F1 Fee Distribution paper](/docs/spec/fee_distribution/f1_fee_distr.pdf). +奖励按周期计算。每次验证者的委托发生变化时都会更新周期，例如，当验证者收到新的委托时。 +单个验证者的奖励可以通过将委托开始前的总奖励减去当前的总奖励来计算。 +要了解更多信息，请参阅 [F1 费用分配文件](/docs/spec/fee_distribution/f1_fee_distr.pdf)。 -The commission to the validator is paid when the validator is removed or when the validator requests a withdrawal. -The commission is calculated and incremented at every `BeginBlock` operation to update accumulated fee amounts. +当验证器被移除或验证器请求提款时，会向验证器支付佣金。 +佣金在每次“BeginBlock”操作时计算并递增，以更新累计费用金额。 -The rewards to a delegator are distributed when the delegation is changed or removed, or a withdrawal is requested. -Before rewards are distributed, all slashes to the validator that occurred during the current delegation are applied. +委托人变更、解除委托、提款时，分配给委托人的奖励。 +在分配奖励之前，会应用当前委托期间发生的对验证者的所有斜线。 -## Reference Counting in F1 Fee Distribution +## F1 费用分配中的引用计数 -In F1 fee distribution, the rewards a delegator receives are calculated when their delegation is withdrawn. This calculation must read the terms of the summation of rewards divided by the share of tokens from the period which they ended when they delegated, and the final period that was created for the withdrawal. +在 F1 费用分配中，委托人收到的奖励是在其委托撤回时计算的。此计算必须阅读奖励总和除以代币份额的条款，这些条款从他们委托时结束的时期开始，以及为提款创建的最后时期。 -Additionally, as slashes change the amount of tokens a delegation will have (but we calculate this lazily, -only when a delegator un-delegates), we must calculate rewards in separate periods before / after any slashes -which occurred in between when a delegator delegated and when they withdrew their rewards. Thus slashes, like -delegations, reference the period which was ended by the slash event. +此外，由于斜线会改变代表团将拥有的代币数量(但我们懒惰地计算， +仅当委托人取消委托时)，我们必须在任何斜线之前/之后计算不同时期的奖励 +这发生在委托人授权和他们撤回奖励之间。因此斜线，如 +请各代表团参考以斜线事件结束的时期。 -All stored historical rewards records for periods which are no longer referenced by any delegations -or any slashes can thus be safely removed, as they will never be read (future delegations and future -slashes will always reference future periods). This is implemented by tracking a `ReferenceCount` -along with each historical reward storage entry. Each time a new object (delegation or slash) -is created which might need to reference the historical record, the reference count is incremented. -Each time one object which previously needed to reference the historical record is deleted, the reference -count is decremented. If the reference count hits zero, the historical record is deleted. +所有已存储的历史奖励记录，不再被任何代表团引用 +或者任何斜线都可以安全地删除，因为它们永远不会被读取(未来的代表团和未来的 +斜线将始终引用未来的时期)。这是通过跟踪一个“ReferenceCount”来实现的 +以及每个历史奖励存储条目。每次一个新对象(委托或斜线) +创建可能需要引用历史记录时，引用计数会增加。 +每次删除一个先前需要引用历史记录的对象时，引用 +计数递减。如果引用计数为零，则删除历史记录。 \ No newline at end of file diff --git a/docs/ja/modules/distribution/02_state.md b/docs/ja/modules/distribution/02_state.md index ef971de983a1..05638cfd80ca 100644 --- a/docs/ja/modules/distribution/02_state.md +++ b/docs/ja/modules/distribution/02_state.md @@ -1,17 +1,17 @@ -# State +# 状态 -## FeePool +## 费用池 -All globally tracked parameters for distribution are stored within -`FeePool`. Rewards are collected and added to the reward pool and -distributed to validators/delegators from here. +所有用于分发的全局跟踪参数都存储在 +`费用池`。 收集奖励并添加到奖励池中 +从这里分发给验证者/委托者。 -Note that the reward pool holds decimal coins (`DecCoins`) to allow -for fractions of coins to be received from operations like inflation. -When coins are distributed from the pool they are truncated back to -`sdk.Coins` which are non-decimal. +请注意，奖励池包含十进制硬币(`DecCoins`)以允许 +从通货膨胀等操作中获得一小部分硬币。 +当硬币从池中分配时，它们会被截断回 +`sdk.Coins` 非十进制。 -- FeePool: `0x00 -> ProtocolBuffer(FeePool)` +- 费用池:`0x00 -> ProtocolBuffer(FeePool)` ```go // coins with decimal @@ -25,14 +25,14 @@ type DecCoin struct { +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/distribution/v1beta1/distribution.proto#L94-L101 -## Validator Distribution +## 验证器分发 -Validator distribution information for the relevant validator is updated each time: +相关验证器的验证器分布信息每次都会更新: -1. delegation amount to a validator is updated, -2. a validator successfully proposes a block and receives a reward, -3. any delegator withdraws from a validator, or -4. the validator withdraws its commission. +1. 更新了验证者的委托数量， +2. 验证者成功提出区块并获得奖励， +3. 任何委托人退出验证人，或 +4. 验证者撤回其佣金。 - ValidatorDistInfo: `0x02 | ValOperatorAddrLen (1 byte) | ValOperatorAddr -> ProtocolBuffer(validatorDistribution)` @@ -44,15 +44,15 @@ type ValidatorDistInfo struct { } ``` -## Delegation Distribution +## 委托分发 -Each delegation distribution only needs to record the height at which it last -withdrew fees. Because a delegation must withdraw fees each time it's -properties change (aka bonded tokens etc.) its properties will remain constant -and the delegator's _accumulation_ factor can be calculated passively knowing -only the height of the last withdrawal and its current properties. +每个委托分布只需要记录它最后的高度 +撤回费用。 因为代表团每次都必须撤回费用 +属性改变(又名绑定令牌等)它的属性将保持不变 +并且委托人的_accumulation_因子可以被动计算 +只有最后一次提款的高度及其当前属性。 -- DelegationDistInfo: `0x02 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValOperatorAddrLen (1 byte) | ValOperatorAddr -> ProtocolBuffer(delegatorDist)` +- 委托分布信息:`0x02 | DelegatorAddrLen (1 字节) | 委托人地址 | ValOperatorAddrLen (1 字节) | ValOperatorAddr -> ProtocolBuffer(delegatorDist)` ```go type DelegationDistInfo struct { diff --git a/docs/ja/modules/distribution/03_begin_block.md b/docs/ja/modules/distribution/03_begin_block.md index 7bc245e966fb..8aeea0bcd613 100644 --- a/docs/ja/modules/distribution/03_begin_block.md +++ b/docs/ja/modules/distribution/03_begin_block.md @@ -1,45 +1,45 @@ -# Begin Block +# 开始块 -At each `BeginBlock`, all fees received in the previous block are transferred to -the distribution `ModuleAccount` account. When a delegator or validator -withdraws their rewards, they are taken out of the `ModuleAccount`. During begin -block, the different claims on the fees collected are updated as follows: +在每个“BeginBlock”，前一个区块中收到的所有费用都转移到 +分发 `ModuleAccount` 帐户。当委托人或验证人 +撤回他们的奖励，他们被从`ModuleAccount` 中取出。开始时 +块，对收取的费用的不同索赔更新如下: -- The block proposer of the previous height and its delegators receive between 1% and 5% of fee rewards. -- The reserve community tax is charged. -- The remainder is distributed proportionally by voting power to all bonded validators +- 前一个高度的区块提议者及其委托人获得 1% 到 5% 的费用奖励。 +- 收取储备社区税。 +- 剩余部分通过投票权按比例分配给所有绑定验证者 -To incentivize validators to wait and include additional pre-commits in the block, the block proposer reward is calculated from Tendermint pre-commit messages. +为了激励验证者等待并在区块中包含额外的预提交，区块提议者奖励是根据 Tendermint 预提交消息计算的。 -## The Distribution Scheme +## 分配方案 -See [params](07_params.md) for description of parameters. +参数说明见[params](07_params.md)。 -Let `fees` be the total fees collected in the previous block, including -inflationary rewards to the stake. All fees are collected in a specific module -account during the block. During `BeginBlock`, they are sent to the -`"distribution"` `ModuleAccount`. No other sending of tokens occurs. Instead, the -rewards each account is entitled to are stored, and withdrawals can be triggered -through the messages `FundCommunityPool`, `WithdrawValidatorCommission` and -`WithdrawDelegatorReward`. +令 `fees` 为前一个区块收取的总费用，包括 +对股权的通货膨胀奖励。所有费用都在特定模块中收取 +阻止期间的帐户。在“BeginBlock”期间，它们被发送到 +`“分发”` `ModuleAccount`。不会发生其他令牌发送。相反， +每个账户有权获得的奖励被存储，并且可以触发提款 +通过消息 `FundCommunityPool`、`WithdrawValidatorCommission` 和 +`WithdrawDelegatorReward`。 -### Reward to the Community Pool +### 奖励给社区池 -The community pool gets `community_tax * fees`, plus any remaining dust after -validators get their rewards that are always rounded down to the nearest -integer value. +社区池获得`community_tax *费用`，加上之后的任何剩余灰尘 +验证者获得的奖励总是四舍五入到最接近的 +整数值。 -### Reward To the Validators +### 奖励验证者 -The proposer receives a base reward of `fees * baseproposerreward` and a bonus -of `fees * bonusproposerreward * P`, where `P = (total power of validators with -included precommits / total bonded validator power)`. The more precommits the -proposer includes, the larger `P` is. `P` can never be larger than `1.00` (since -only bonded validators can supply valid precommits) and is always larger than -`2/3`. +提议者获得‘费用 * baseproposerreward’的基础奖励和奖金 +`fees * bonusproposerreward * P`，其中`P =(验证者的总权力与 +包括预提交/总绑定验证器功率)`。预提交越多 +提议者包括，较大的“P”是。 `P` 永远不能大于 `1.00`(因为 +只有绑定的验证器可以提供有效的预提交)并且总是大于 +`2/3`。 -Any remaining fees are distributed among all the bonded validators, including -the proposer, in proportion to their consensus power. +任何剩余的费用都分配给所有绑定的验证器，包括 +提议者，与他们的共识权力成比例。 ``` powFrac = validator power / total bonded validator power @@ -47,33 +47,33 @@ proposerMul = baseproposerreward + bonusproposerreward * P voteMul = 1 - communitytax - proposerMul ``` -In total, the proposer receives `fees * (voteMul * powFrac + proposerMul)`. -All other validators receive `fees * voteMul * powFrac`. +总的来说，提议者收到`fees * (voteMul * powFrac + ProposerMul)`。 +所有其他验证器都会收到 `fees * voteMul * powFrac`。 -### Rewards to Delegators +### 对委托人的奖励 -Each validator's rewards are distributed to its delegators. The validator also -has a self-delegation that is treated like a regular delegation in -distribution calculations. +每个验证者的奖励都分配给其委托人。验证器也 +有一个自我授权，被视为一个普通的授权 +分布计算。 -The validator sets a commission rate. The commission rate is flexible, but each -validator sets a maximum rate and a maximum daily increase. These maximums cannot be exceeded and protect delegators from sudden increases of validator commission rates to prevent validators from taking all of the rewards. +验证器设置佣金率。佣金率是灵活的，但每个 +验证器设置最大速率和最大每日增量。这些最大值不能被超过，并保护委托人免受验证人佣金率突然增加的影响，以防止验证人获得所有奖励。 -The outstanding rewards that the operator is entitled to are stored in -`ValidatorAccumulatedCommission`, while the rewards the delegators are entitled -to are stored in `ValidatorCurrentRewards`. The [F1 fee distribution -scheme](01_concepts.md) is used to calculate the rewards per delegator as they -withdraw or update their delegation, and is thus not handled in `BeginBlock`. +运营商有权获得的未兑现奖励存储在 +`ValidatorAccumulatedCommission`，而委托人获得的奖励 +存储在“ValidatorCurrentRewards”中。 [F1费用分配 +scheme](01_concepts.md) 用于计算每个委托人的奖励，因为他们 +撤回或更新他们的委托，因此不在“BeginBlock”中处理。 -### Example Distribution +### 示例分布 -For this example distribution, the underlying consensus engine selects block proposers in -proportion to their power relative to the entire bonded power. +对于这个示例分布，底层共识引擎在 +与他们的权力相对于整个保税权力的比例。 -All validators are equally performant at including pre-commits in their proposed -blocks. Then hold `(precommits included) / (total bonded validator power)` -constant so that the amortized block reward for the validator is `( validator power / total bonded power) * (1 - community tax rate)` of -the total rewards. Consequently, the reward for a single delegator is: +所有验证者在将预提交包括在他们的提议中的表现是一样的 +块。然后持有`(包括预提交)/(总绑定验证器权力)` +常数，因此验证者的摊销区块奖励为`(验证者权力/总绑定权力)*(1 - 社区税率)` +总奖励。因此，单个委托人的奖励是: ``` (delegator proportion of the validator power / validator power) * (validator power / total bonded power) diff --git a/docs/ja/modules/distribution/04_messages.md b/docs/ja/modules/distribution/04_messages.md index f9978f8dbc4c..0f0fc5b0ffa6 100644 --- a/docs/ja/modules/distribution/04_messages.md +++ b/docs/ja/modules/distribution/04_messages.md @@ -1,13 +1,13 @@ -# Messages +# 消息 ## MsgSetWithdrawAddress -By default, the withdraw address is the delegator address. To change its withdraw address, a delegator must send a `MsgSetWithdrawAddress` message. -Changing the withdraw address is possible only if the parameter `WithdrawAddrEnabled` is set to `true`. +默认情况下，提现地址为委托人地址。 要更改其提款地址，委托人必须发送“MsgSetWithdrawAddress”消息。 +只有当参数 `WithdrawAddrEnabled` 设置为 `true` 时，才可以更改提款地址。 -The withdraw address cannot be any of the module accounts. These accounts are blocked from being withdraw addresses by being added to the distribution keeper's `blockedAddrs` array at initialization. +提现地址不能是任何模块账户。 通过在初始化时将这些帐户添加到分发管理员的“blockedAddrs”数组中，可以阻止这些帐户被提取地址。 -Response: +回复: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.4/proto/cosmos/distribution/v1beta1/tx.proto#L29-L37 @@ -26,22 +26,22 @@ func (k Keeper) SetWithdrawAddr(ctx sdk.Context, delegatorAddr sdk.AccAddress, w ## MsgWithdrawDelegatorReward -A delegator can withdraw its rewards. -Internally in the distribution module, this transaction simultaneously removes the previous delegation with associated rewards, the same as if the delegator simply started a new delegation of the same value. -The rewards are sent immediately from the distribution `ModuleAccount` to the withdraw address. -Any remainder (truncated decimals) are sent to the community pool. -The starting height of the delegation is set to the current validator period, and the reference count for the previous period is decremented. -The amount withdrawn is deducted from the `ValidatorOutstandingRewards` variable for the validator. +委托人可以撤回其奖励。 +在分配模块内部，该交易同时删除了先前的委托和相关的奖励，就像委托人只是简单地开始了一个相同价值的新委托。 +奖励会立即从分配“ModuleAccount”发送到提款地址。 +任何余数(截断的小数)都被发送到社区池。 +委托的起始高度设置为当前validator周期，上一周期的引用计数递减。 +提取的金额从验证器的“ValidatorOutstandingRewards”变量中扣除。 -In the F1 distribution, the total rewards are calculated per validator period, and a delegator receives a piece of those rewards in proportion to their stake in the validator. -In basic F1, the total rewards that all the delegators are entitled to between to periods is calculated the following way. -Let `R(X)` be the total accumulated rewards up to period `X` divided by the tokens staked at that time. The delegator allocation is `R(X) * delegator_stake`. -Then the rewards for all the delegators for staking between periods `A` and `B` are `(R(B) - R(A)) * total stake`. -However, these calculated rewards don't account for slashing. +在 F1 分配中，总奖励是按每个验证者周期计算的，委托人根据他们在验证者中的股份比例获得这些奖励的一部分。 +在基本的 F1 中，所有委托人在不同时期之间有权获得的总奖励按以下方式计算。 +令‘R(X)’是直到‘X’期的总累积奖励除以当时质押的代币。委托人分配是`R(X) * delegator_stake`。 +那么所有委托人在“A”和“B”期间质押的奖励为“(R(B) - R(A)) * 总质押”。 +然而，这些计算的奖励没有考虑到削减。 -Taking the slashes into account requires iteration. -Let `F(X)` be the fraction a validator is to be slashed for a slashing event that happened at period `X`. -If the validator was slashed at periods `P1, ..., PN`, where `A < P1`, `PN < B`, the distribution module calculates the individual delegator's rewards, `T(A, B)`, as follows: +考虑斜线需要迭代。 +令`F(X)` 是验证者因在时间段`X` 发生的削减事件而削减的分数。 +如果验证人在‘P1, ..., PN’期间被削减，其中‘A < P1’，‘PN < B’，分配模块计算个体委托人的奖励，‘T(A, B)’，如下所示: ``` stake := initial stake @@ -54,25 +54,25 @@ for P in P1, ..., PN`: rewards = rewards + (R(B) - R(PN)) * stake ``` -The historical rewards are calculated retroactively by playing back all the slashes and then attenuating the delegator's stake at each step. -The final calculated stake is equivalent to the actual staked coins in the delegation with a margin of error due to rounding errors. +历史奖励是通过回放所有斜线然后在每一步减少委托人的赌注来追溯计算的。 +最终计算的赌注相当于代表团中实际赌注的硬币，由于舍入误差而存在误差。 -Response: +回复: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.42.4/proto/cosmos/distribution/v1beta1/tx.proto#L42-L50 ## WithdrawValidatorCommission -The validator can send the WithdrawValidatorCommission message to withdraw their accumulated commission. -The commission is calculated in every block during `BeginBlock`, so no iteration is required to withdraw. -The amount withdrawn is deducted from the `ValidatorOutstandingRewards` variable for the validator. -Only integer amounts can be sent. If the accumulated awards have decimals, the amount is truncated before the withdrawal is sent, and the remainder is left to be withdrawn later. +验证者可以发送 WithdrawValidatorCommission 消息来提取他们累积的佣金。 +在“BeginBlock”期间，每个区块都会计算佣金，因此无需迭代即可退出。 +提取的金额从验证器的“ValidatorOutstandingRewards”变量中扣除。 +只能发送整数金额。如果累积奖励有小数，则在发送提款前将金额截断，剩余部分留待稍后提款。 ## FundCommunityPool -This message sends coins directly from the sender to the community pool. +该消息直接从发送者向社区池发送硬币。 -The transaction fails if the amount cannot be transferred from the sender to the distribution module account. +如果金额无法从发送方转移到分发模块帐户，则交易失败。 ```go func (k Keeper) FundCommunityPool(ctx sdk.Context, amount sdk.Coins, sender sdk.AccAddress) error { @@ -90,12 +90,12 @@ func (k Keeper) FundCommunityPool(ctx sdk.Context, amount sdk.Coins, sender sdk. ## Common distribution operations -These operations take place during many different messages. +这些操作发生在许多不同的消息中。 -### Initialize delegation +### 初始化委托 -Each time a delegation is changed, the rewards are withdrawn and the delegation is reinitialized. -Initializing a delegation increments the validator period and keeps track of the starting period of the delegation. +每次委托变更时，奖励被撤回，委托重新初始化。 +初始化委托会增加验证器周期并跟踪委托的开始周期。 ```go // initialize starting info for a new delegation diff --git a/docs/ja/modules/distribution/05_hooks.md b/docs/ja/modules/distribution/05_hooks.md index 94d2162f7d57..a1ef54d79cc9 100644 --- a/docs/ja/modules/distribution/05_hooks.md +++ b/docs/ja/modules/distribution/05_hooks.md @@ -1,55 +1,55 @@ -# Hooks +# 钩子 -Available hooks that can be called by and from this module. +可以由此模块调用和从中调用的可用钩子。 -## Create or modify delegation distribution +## 创建或修改委托分配 -- triggered-by: `staking.MsgDelegate`, `staking.MsgBeginRedelegate`, `staking.MsgUndelegate` +- 触发:`staking.MsgDelegate`、`staking.MsgBeginRedelegate`、`staking.MsgUndelegate` -### Before +### 前 -- The delegation rewards are withdrawn to the withdraw address of the delegator. - The rewards include the current period and exclude the starting period. -- The validator period is incremented. - The validator period is incremented because the validator's power and share distribution might have changed. -- The reference count for the delegator's starting period is decremented. +- 委托奖励提现到委托人提现地址。 + 奖励包括当期，不包括起始期。 +- 验证器周期增加。 + 验证者周期增加是因为验证者的权力和份额分配可能已经改变。 +- 委托人开始期间的引用计数递减。 -### After +### 后 -The starting height of the delegation is set to the previous period. -Because of the `Before`-hook, this period is the last period for which the delegator was rewarded. +代表团的起始高度设置为上一期。 +由于“Before”挂钩，这个时期是委托人获得奖励的最后时期。 -## Validator created +## 验证器已创建 -- triggered-by: `staking.MsgCreateValidator` +- 触发:`staking.MsgCreateValidator` -When a validator is created, the following validator variables are initialized: +创建验证器时，将初始化以下验证器变量: -- Historical rewards -- Current accumulated rewards -- Accumulated commission -- Total outstanding rewards -- Period +- 历史奖励 +- 当前累积奖励 +- 累计佣金 +- 未完成的总奖励 +- 时期 -By default, all values are set to a `0`, except period, which is set to `1`. +默认情况下，所有值都设置为“0”，但句点设置为“1”。 -## Validator removed +## 验证器已删除 -- triggered-by: `staking.RemoveValidator` +- 触发:`staking.RemoveValidator` -Outstanding commission is sent to the validator's self-delegation withdrawal address. -Remaining delegator rewards get sent to the community fee pool. +未完成的佣金被发送到验证者的自委托提款地址。 +剩余的委托人奖励被发送到社区费用池。 -Note: The validator gets removed only when it has no remaining delegations. -At that time, all outstanding delegator rewards will have been withdrawn. -Any remaining rewards are dust amounts. +注意:只有当它没有剩余的委托时，验证器才会被删除。 +届时，所有优秀的委托人奖励将被收回。 +任何剩余的奖励都是灰尘量。 -## Validator is slashed +## 验证器被削减 -- triggered-by: `staking.Slash` +- 触发:`staking.Slash` -- The current validator period reference count is incremented. - The reference count is incremented because the slash event has created a reference to it. -- The validator period is incremented. -- The slash event is stored for later use. - The slash event will be referenced when calculating delegator rewards. +- 当前验证器周期引用计数增加。 + 引用计数增加是因为斜线事件已经创建了对它的引用。 +- 验证器周期增加。 +- 存储斜线事件以备后用。 + 计算委托人奖励时将参考斜线事件。 \ No newline at end of file diff --git a/docs/ja/modules/distribution/06_events.md b/docs/ja/modules/distribution/06_events.md index 08a22b660f56..85ae211cfcbb 100644 --- a/docs/ja/modules/distribution/06_events.md +++ b/docs/ja/modules/distribution/06_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The distribution module emits the following events: +分发模块发出以下事件: ## BeginBlocker diff --git a/docs/ja/modules/distribution/07_params.md b/docs/ja/modules/distribution/07_params.md index ebcf270da079..100170ac825c 100644 --- a/docs/ja/modules/distribution/07_params.md +++ b/docs/ja/modules/distribution/07_params.md @@ -1,6 +1,6 @@ -# Parameters +# 参数 -The distribution module contains the following parameters: +分发模块包含以下参数: | Key | Type | Example | | ------------------- | ------------ | -------------------------- | diff --git a/docs/ja/modules/distribution/08_client.md b/docs/ja/modules/distribution/08_client.md index af5b75288d92..3c044edb7c5f 100644 --- a/docs/ja/modules/distribution/08_client.md +++ b/docs/ja/modules/distribution/08_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `distribution` module using the CLI. +用户可以使用 CLI 查询“分发”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `distribution` state. +`query` 命令允许用户查询 `distribution` 状态。 ``` simd query distribution --help @@ -277,7 +277,7 @@ Example Output: ### ValidatorCommission -The `ValidatorCommission` endpoint allows users to query accumulated commission for a validator. +`commission` 命令允许用户按地址查询验证人佣金奖励。 Example: @@ -305,7 +305,7 @@ Example Output: ### ValidatorSlashes -The `ValidatorSlashes` endpoint allows users to query slash events of a validator. +`ValidatorSlashes` 端点允许用户查询验证器的斜线事件。 Example: @@ -334,7 +334,7 @@ Example Output: ### DelegationRewards -The `DelegationRewards` endpoint allows users to query the total rewards accrued by a delegation. +“DelegationRewards”端点允许用户查询委托产生的总奖励。 Example: @@ -360,7 +360,7 @@ Example Output: ### DelegationTotalRewards -The `DelegationTotalRewards` endpoint allows users to query the total rewards accrued by each validator. +`DelegationTotalRewards` 端点允许用户查询每个验证器累积的总奖励。 Example: @@ -397,7 +397,7 @@ Example Output: ### DelegatorValidators -The `DelegatorValidators` endpoint allows users to query all validators for given delegator. +`DelegatorValidators` 端点允许用户查询给定委托人的所有验证器。 Example: @@ -420,7 +420,7 @@ Example Output: ### DelegatorWithdrawAddress -The `DelegatorWithdrawAddress` endpoint allows users to query the withdraw address of a delegator. +`DelegatorWithdrawAddress` 端点允许用户查询委托人的提现地址。 Example: diff --git a/docs/ja/modules/distribution/README.md b/docs/ja/modules/distribution/README.md index 4996b6bdfad6..de2142058ea5 100644 --- a/docs/ja/modules/distribution/README.md +++ b/docs/ja/modules/distribution/README.md @@ -1,99 +1,99 @@ -# `distribution` - -## Overview - -This _simple_ distribution mechanism describes a functional way to passively -distribute rewards between validators and delegators. Note that this mechanism does -not distribute funds in as precisely as active reward distribution mechanisms and -will therefore be upgraded in the future. - -The mechanism operates as follows. Collected rewards are pooled globally and -divided out passively to validators and delegators. Each validator has the -opportunity to charge commission to the delegators on the rewards collected on -behalf of the delegators. Fees are collected directly into a global reward pool -and validator proposer-reward pool. Due to the nature of passive accounting, -whenever changes to parameters which affect the rate of reward distribution -occurs, withdrawal of rewards must also occur. - -- Whenever withdrawing, one must withdraw the maximum amount they are entitled - to, leaving nothing in the pool. -- Whenever bonding, unbonding, or re-delegating tokens to an existing account, a - full withdrawal of the rewards must occur (as the rules for lazy accounting - change). -- Whenever a validator chooses to change the commission on rewards, all accumulated - commission rewards must be simultaneously withdrawn. - -The above scenarios are covered in `hooks.md`. - -The distribution mechanism outlined herein is used to lazily distribute the -following rewards between validators and associated delegators: - -- multi-token fees to be socially distributed -- proposer reward pool -- inflated atom provisions -- validator commission on all rewards earned by their delegators stake - -Fees are pooled within a global pool, as well as validator specific -proposer-reward pools. The mechanisms used allow for validators and delegators -to independently and lazily withdraw their rewards. - -## Shortcomings - -As a part of the lazy computations, each delegator holds an accumulation term -specific to each validator which is used to estimate what their approximate -fair portion of tokens held in the global fee pool is owed to them. - -``` -entitlement = delegator-accumulation / all-delegators-accumulation -``` - -Under the circumstance that there was constant and equal flow of incoming -reward tokens every block, this distribution mechanism would be equal to the -active distribution (distribute individually to all delegators each block). -However, this is unrealistic so deviations from the active distribution will -occur based on fluctuations of incoming reward tokens as well as timing of -reward withdrawal by other delegators. - -If you happen to know that incoming rewards are about to significantly increase, -you are incentivized to not withdraw until after this event, increasing the -worth of your existing _accum_. See [#2764](https://github.com/cosmos/cosmos-sdk/issues/2764) -for further details. - -## Effect on Staking - -Charging commission on Atom provisions while also allowing for Atom-provisions -to be auto-bonded (distributed directly to the validators bonded stake) is -problematic within BPoS. Fundamentally, these two mechanisms are mutually -exclusive. If both commission and auto-bonding mechanisms are simultaneously -applied to the staking-token then the distribution of staking-tokens between -any validator and its delegators will change with each block. This then -necessitates a calculation for each delegation records for each block - -which is considered computationally expensive. - -In conclusion, we can only have Atom commission and unbonded atoms -provisions or bonded atom provisions with no Atom commission, and we elect to -implement the former. Stakeholders wishing to rebond their provisions may elect -to set up a script to periodically withdraw and rebond rewards. - -## Contents - -1. **[Concepts](01_concepts.md)** - - [Reference Counting in F1 Fee Distribution](01_concepts.md#reference-counting-in-f1-fee-distribution) -2. **[State](02_state.md)** -3. **[Begin Block](03_begin_block.md)** -4. **[Messages](04_messages.md)** +# `分布` + +## 概述 + +这个 _simple_ 分发机制描述了一种被动的功能方式 +在验证者和委托者之间分配奖励。请注意，此机制确实 +不像积极的奖励分配机制那样精确地分配资金，并且 +因此，将来会升级。 + +该机制如下操作。收集到的奖励在全球范围内汇集， +被动地分配给验证者和委托者。每个验证器都有 +有机会就收集的奖励向委托人收取佣金 +代表代表。费用直接收集到全球奖励池中 +和验证者提议者奖励池。由于被动会计的性质， +每当影响奖励分配率的参数发生变化时 +发生，也必须发生奖励的撤回。 + +- 每次提款时，必须提取他们有权提取的最高金额 + 到，在池中什么也不留下。 +- 每当绑定、解除绑定或将代币重新委托给现有帐户时， + 必须完全撤回奖励(作为懒惰会计的规则) + 改变)。 +- 每当验证者选择更改奖励佣金时，所有累积 + 佣金奖励必须同时提取。 + +`hooks.md` 中涵盖了上述场景。 + +此处概述的分发机制用于延迟分发 +验证者和相关委托人之间的以下奖励: + +- 社会分配的多代币费用 +- 提议者奖励池 +- 膨胀的原子规定 +- 其委托人权益所获得的所有奖励的验证者佣金 + +费用集中在一个全局池中，以及特定于验证器的 +提议者奖励池。所使用的机制允许验证者和委托者 +独立和懒惰地收回他们的奖励。 + +## 缺点 + +作为惰性计算的一部分，每个委托人都持有一个累加项 +特定于每个验证器，用于估计它们的近似值 +全球费用池中持有的相当一部分代币归他们所有。 + +`` +权利=委托人累积/所有委托人累积 +`` + +在来料流量恒定且均等的情况下 +每个区块奖励代币，这种分配机制将等于 +主动分配(每个区块单独分配给所有委托人)。 +然而，这是不现实的，因此与主动分布的偏差将 +基于传入奖励代币的波动以及发生的时间 +其他委托人的奖励提现。 + +如果您碰巧知道收到的奖励即将大幅增加， +您被激励在此事件之后才退出，从而增加 +您现有的 _accum_ 的价值。见 [#2764](https://github.com/cosmos/cosmos-sdk/issues/2764) +了解更多详情。 + +## 对 Staking 的影响 + +对 Atom 条款收取佣金，同时也允许 Atom 条款 +自动绑定(直接分配给验证者绑定的股份)是 +BPoS 中存在问题。从根本上说，这两种机制是相互的 +独家的。如果委托和自动绑定机制同时存在 +应用于质押代币，然后质押代币在 +任何验证者及其委托人都会随着每个区块的变化而变化。这然后 +需要计算每个区块的每个委托记录 - +这被认为在计算上是昂贵的。 + +总之，我们只能有原子委托和未键合原子 +没有 Atom 佣金的条款或键合原子条款，我们选择 +实施前者。希望重新绑定其条款的利益相关者可以选择 +设置脚本以定期提取和重新绑定奖励。 + +## 内容 + +1. **[概念](01_concepts.md)** + - [F1费用分配中的引用计数](01_concepts.md#reference-counting-in-f1-fee-distribution) +2. **[状态](02_state.md)** +3. **[开始区块](03_begin_block.md)** +4. **[消息](04_messages.md)** - [MsgSetWithdrawAddress](04_messages.md#msgsetwithdrawaddress) - [MsgWithdrawDelegatorReward](04_messages.md#msgwithdrawdelegatorreward) - - [Withdraw Validator Rewards All](04_messages.md#withdraw-validator-rewards-all) - - [Common calculations](04_messages.md#common-calculations-) -5. **[Hooks](05_hooks.md)** - - [Create or modify delegation distribution](05_hooks.md#create-or-modify-delegation-distribution) - - [Commission rate change](05_hooks.md#commission-rate-change) - - [Change in Validator State](05_hooks.md#change-in-validator-state) -6. **[Events](06_events.md)** + - [全部提现验证者奖励](04_messages.md#withdraw-validator-rewards-all) + - [常用计算](04_messages.md#common-calculations-) +5. **[钩子](05_hooks.md)** + - [创建或修改委托分发](05_hooks.md#create-or-modify-delegation-distribution) + - [佣金率变化](05_hooks.md#commission-rate-change) + - [验证器状态的变化](05_hooks.md#change-in-validator-state) +6. **[事件](06_events.md)** - [BeginBlocker](06_events.md#beginblocker) - - [Handlers](06_events.md#handlers) -7. **[Parameters](07_params.md)** -8. **[Parameters](07_params.md)** + - [处理程序](06_events.md#handlers) +7. **[参数](07_params.md)** +8. **[参数](07_params.md)** - [CLI](08_client.md#cli) - - [gRPC](08_client.md#grpc) + - [gRPC](08_client.md#grpc) \ No newline at end of file diff --git a/docs/ja/modules/epoching/01_state.md b/docs/ja/modules/epoching/01_state.md index d198bb953c97..2442f9db2d82 100644 --- a/docs/ja/modules/epoching/01_state.md +++ b/docs/ja/modules/epoching/01_state.md @@ -1,16 +1,16 @@ -# State +# 状态 -## Messages queue +##消息队列 -Messages are queued to run at the end of each epoch. Queued messages have an epoch number and for each epoch number, the queues are iterated over and each message is executed. +消息在每个纪元结束时排队运行。 排队的消息有一个纪元号，对于每个纪元号，队列被迭代并执行每条消息。 -### Message queues +### 消息队列 -Each module has one unique message queue that is specific to that module. +每个模块都有一个特定于该模块的唯一消息队列。 -## Actions +## 行动 -A module will add a message that implements the `sdk.Msg` interface. These message will be executed at a later time (end of the next epoch). +一个模块将添加一个实现 `sdk.Msg` 接口的消息。 这些消息将在稍后执行(下一个纪元结束)。 ```go type Msg interface { @@ -38,17 +38,17 @@ type Msg interface { } ``` -## Buffered Messages Export / Import +## 缓冲消息导出/导入 -For now, the `x/epoching` module is implemented to export all buffered messages without epoch numbers. When state is imported, buffered messages are stored on current epoch to run at the end of current epoch. +目前，实现了 `x/epoching` 模块以导出所有没有纪元编号的缓冲消息。 导入状态时，缓冲的消息存储在当前纪元上，以在当前纪元结束时运行。 -## Genesis Transactions +##创世交易 -We execute epoch after execution of genesis transactions to see the changes instantly before node start. +我们在执行创世交易后执行 epoch 以在节点启动之前立即查看更改。 -## Execution on epochs +## 在 epoch 上执行 -- Try executing the message for the epoch -- If success, make changes as it is -- If failure, try making revert extra actions done on handlers (e.g. EpochDelegationPool deposit) -- If revert fail, panic +- 尝试执行 epoch 的消息 +- 如果成功，按原样进行更改 +- 如果失败，请尝试在处理程序上执行恢复额外操作(例如 EpochDelegationPool 存款) +- 如果恢复失败，恐慌 \ No newline at end of file diff --git a/docs/ja/modules/epoching/03_to_improve.md b/docs/ja/modules/epoching/03_to_improve.md index 2320466641e7..cb606b5388fe 100644 --- a/docs/ja/modules/epoching/03_to_improve.md +++ b/docs/ja/modules/epoching/03_to_improve.md @@ -1,19 +1,19 @@ -# Changes to make +# 要进行的更改 -## Validator self-unbonding (which exceed minimum self delegation) could be required to start instantly +## 验证者自解绑(超过最小自委派)可能需要立即启动 -Cases that trigger unbonding process +触发解绑过程的案例 -- Validator undelegate can unbond more tokens than his minimum_self_delegation and it will automatically turn the validator into unbonding -In this case, unbonding should start instantly. -- Validator miss blocks and get slashed -- Validator get slashed for double sign +- 验证人 undelegate 可以解除绑定比他的 minimum_self_delegation 多的代币，它会自动将验证人变为解除绑定状态 +在这种情况下，应立即开始解绑。 +- 验证器错过块并被削减 +- 验证器因双重签名而被削减 -**Note:** When a validator begins the unbonding process, it could be required to turn the validator into unbonding state instantly. - This is different than a specific delegator beginning to unbond. A validator beginning to unbond means that it's not in the set any more. - A delegator unbonding from a validator removes their delegation from the validator. +**注意:** 当验证者开始解绑过程时，可能需要立即将验证器转为解绑状态。 + 这与开始解除绑定的特定委托人不同。 开始解除绑定的验证器意味着它不再在集合中。 + 与验证者解除绑定的委托人会将其委托从验证者中移除。 -## Pending development +## 待开发 ```go // Changes to make diff --git a/docs/ja/modules/epoching/README.md b/docs/ja/modules/epoching/README.md index 331ab178acf4..a57a07566b2a 100644 --- a/docs/ja/modules/epoching/README.md +++ b/docs/ja/modules/epoching/README.md @@ -1,12 +1,12 @@ # `x/epoching` -## Abstract +## 摘要 -The epoching module allows modules to queue messages for execution at a certain block height. Each module will have its own instance of the epoching module, this allows each module to have its own message queue and own duration for epochs. +epoching 模块允许模块将消息排队以在某个块高度执行。 每个模块都有自己的纪元模块实例，这允许每个模块有自己的消息队列和纪元的持续时间。 -## Example +## 例子 -In this example, we are creating an epochkeeper for a module that will be used by the module to queue messages to be executed at a later point in time. +在这个例子中，我们正在为一个模块创建一个 epochkeeper，该模块将使用该模块将消息排队以在稍后的时间点执行。 ```go type Keeper struct { diff --git a/docs/ja/modules/evidence/01_concepts.md b/docs/ja/modules/evidence/01_concepts.md index c9bd1b2bec1c..3cd97ceb852a 100644 --- a/docs/ja/modules/evidence/01_concepts.md +++ b/docs/ja/modules/evidence/01_concepts.md @@ -1,12 +1,12 @@ -# Concepts +# 概念 -## Evidence +## 证据 -Any concrete type of evidence submitted to the `x/evidence` module must fulfill the -`Evidence` contract outlined below. Not all concrete types of evidence will fulfill -this contract in the same way and some data may be entirely irrelevant to certain -types of evidence. An additional `ValidatorEvidence`, which extends `Evidence`, -has also been created to define a contract for evidence against malicious validators. +提交给“x/evidence”模块的任何具体类型的证据都必须满足 +“证据”合同概述如下。 并非所有具体类型的证据都能满足 +本合同以同样的方式和某些数据可能与某些完全无关 +证据类型。 一个额外的“ValidatorEvidence”，它扩展了“Evidence”， +还创建了一个合同，用于针对恶意验证者的证据。 ```go // Evidence defines the contract which concrete evidence types of misbehavior @@ -40,13 +40,13 @@ type ValidatorEvidence interface { } ``` -## Registration & Handling +## 注册和处理 -The `x/evidence` module must first know about all types of evidence it is expected -to handle. This is accomplished by registering the `Route` method in the `Evidence` -contract with what is known as a `Router` (defined below). The `Router` accepts -`Evidence` and attempts to find the corresponding `Handler` for the `Evidence` -via the `Route` method. +`x/evidence` 模块必须首先知道它所期望的所有类型的证据 +处理。 这是通过在 `Evidence` 中注册 `Route` 方法来完成的 +与所谓的“路由器”(定义如下)签订合同。 `Router` 接受 +`Evidence` 并尝试为 `Evidence` 找到相应的 `Handler` +通过`Route`方法。 ```go type Router interface { @@ -58,12 +58,12 @@ type Router interface { } ``` -The `Handler` (defined below) is responsible for executing the entirety of the -business logic for handling `Evidence`. This typically includes validating the -evidence, both stateless checks via `ValidateBasic` and stateful checks via any -keepers provided to the `Handler`. In addition, the `Handler` may also perform -capabilities such as slashing and jailing a validator. All `Evidence` handled -by the `Handler` should be persisted. +`Handler`(定义如下)负责执行整个 +处理“证据”的业务逻辑。 这通常包括验证 +证据，通过“ValidateBasic”进行无状态检查和通过任何方式进行的有状态检查 +提供给 `Handler` 的 Keepers。 此外，`Handler` 还可以执行 +诸如削减和监禁验证者之类的功能。 处理所有“证据” +由`Handler` 应该被持久化。 ```go // Handler defines an agnostic Evidence handler. The handler is responsible diff --git a/docs/ja/modules/evidence/02_state.md b/docs/ja/modules/evidence/02_state.md index 3360d95d9b99..5015e232569c 100644 --- a/docs/ja/modules/evidence/02_state.md +++ b/docs/ja/modules/evidence/02_state.md @@ -1,7 +1,7 @@ -# State +# 状态 -Currently the `x/evidence` module only stores valid submitted `Evidence` in state. -The evidence state is also stored and exported in the `x/evidence` module's `GenesisState`. +目前，`x/evidence` 模块只存储有效提交的 `Evidence` 状态。 +证据状态也存储和导出在 `x/evidence` 模块的 `GenesisState` 中。 ```protobuf // GenesisState defines the evidence module's genesis state. @@ -12,4 +12,4 @@ message GenesisState { ``` -All `Evidence` is retrieved and stored via a prefix `KVStore` using prefix `0x00` (`KeyPrefixEvidence`). +所有“证据”都通过前缀“KVStore”使用前缀“0x00”(“KeyPrefixEvidence”)检索和存储。 diff --git a/docs/ja/modules/evidence/03_messages.md b/docs/ja/modules/evidence/03_messages.md index 8caad9a89ee6..3c5a6534a39a 100644 --- a/docs/ja/modules/evidence/03_messages.md +++ b/docs/ja/modules/evidence/03_messages.md @@ -1,8 +1,8 @@ -# Messages +# 消息 ## MsgSubmitEvidence -Evidence is submitted through a `MsgSubmitEvidence` message: +证据是通过“MsgSubmitEvidence”消息提交的: ```protobuf // MsgSubmitEvidence represents a message that supports submitting arbitrary @@ -13,12 +13,12 @@ message MsgSubmitEvidence { } ``` -Note, the `Evidence` of a `MsgSubmitEvidence` message must have a corresponding -`Handler` registered with the `x/evidence` module's `Router` in order to be processed -and routed correctly. +注意，一个 `MsgSubmitEvidence` 消息的 `Evidence` 必须有一个对应的 +`Handler` 注册到 `x/evidence` 模块的 `Router` 以便处理 +并正确路由。 -Given the `Evidence` is registered with a corresponding `Handler`, it is processed -as follows: +鉴于 `Evidence` 注册到相应的 `Handler`，它被处理 +如下: ```go func SubmitEvidence(ctx Context, evidence Evidence) error { @@ -46,6 +46,6 @@ func SubmitEvidence(ctx Context, evidence Evidence) error { } ``` -First, there must not already exist valid submitted `Evidence` of the exact same -type. Secondly, the `Evidence` is routed to the `Handler` and executed. Finally, -if there is no error in handling the `Evidence`, an event is emitted and it is persisted to state. +首先，必须不存在完全相同的有效提交“证据” +类型。 其次，`Evidence` 被路由到`Handler` 并执行。 最后， +如果在处理“证据”时没有错误，则会发出一个事件并将其持久化以保持状态。 diff --git a/docs/ja/modules/evidence/04_events.md b/docs/ja/modules/evidence/04_events.md index 1994f2398f6a..0dbc159ebc1c 100644 --- a/docs/ja/modules/evidence/04_events.md +++ b/docs/ja/modules/evidence/04_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The `x/evidence` module emits the following events: +`x/evidence` 模块发出以下事件: ## Handlers diff --git a/docs/ja/modules/evidence/06_begin_block.md b/docs/ja/modules/evidence/06_begin_block.md index 3d950a9de7a2..0559b4cc199c 100644 --- a/docs/ja/modules/evidence/06_begin_block.md +++ b/docs/ja/modules/evidence/06_begin_block.md @@ -1,18 +1,18 @@ -# BeginBlock +# 开始块 -## Evidence Handling +## 证据处理 -Tendermint blocks can include -[Evidence](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#evidence) that indicates if a validator committed malicious behavior. The relevant information is forwarded to the application as ABCI Evidence in `abci.RequestBeginBlock` so that the validator can be punished accordingly. +Tendermint 块可以包括 +[证据](https://github.com/tendermint/tendermint/blob/master/docs/spec/blockchain/blockchain.md#evidence) 表明验证者是否有恶意行为。 相关信息将作为 ABCI 证据在 abci.RequestBeginBlock 中转发给应用程序，以便验证器可以受到相应的惩罚。 -### Equivocation +### 模棱两可 -Currently, the SDK handles two types of evidence inside the ABCI `BeginBlock`: +目前，SDK 在 ABCI `BeginBlock` 中处理两种类型的证据: -- `DuplicateVoteEvidence`, -- `LightClientAttackEvidence`. +-`DuplicateVoteEvidence`， +- `LightClientAttackEvidence`。 -The evidence module handles these two evidence types the same way. First, the SDK converts the Tendermint concrete evidence type to a SDK `Evidence` interface using `Equivocation` as the concrete type. +证据模块以相同的方式处理这两种证据类型。 首先，SDK 将 Tendermint 的具体证据类型转换为 SDK 的 `Evidence` 接口，使用 `Equivocation` 作为具体类型。 ```proto // Equivocation implements the Evidence interface. @@ -24,25 +24,25 @@ message Equivocation { } ``` -For some `Equivocation` submitted in `block` to be valid, it must satisfy: +对于在 `block` 中提交的某些 `Equivocation` 有效，它必须满足: `Evidence.Timestamp >= block.Timestamp - MaxEvidenceAge` -Where: +在哪里: -- `Evidence.Timestamp` is the timestamp in the block at height `Evidence.Height` -- `block.Timestamp` is the current block timestamp. +- `Evidence.Timestamp` 是块中高度为 `Evidence.Height` 的时间戳 +- `block.Timestamp` 是当前区块的时间戳。 -If valid `Equivocation` evidence is included in a block, the validator's stake is -reduced (slashed) by `SlashFractionDoubleSign` as defined by the `x/slashing` module -of what their stake was when the infraction occurred, rather than when the evidence was discovered. -We want to "follow the stake", i.e., the stake that contributed to the infraction -should be slashed, even if it has since been redelegated or started unbonding. +如果一个区块中包含有效的“Equivocation”证据，则验证者的权益为 +由 `x/slashing` 模块定义的 `SlashFractionDoubleSign` 减少(斜线) +他们的利害关系是在违规发生时，而不是在发现证据时。 +我们想要“关注赌注”，即导致违规的赌注 +应该削减，即使它已经被重新授权或开始解除绑定。 -In addition, the validator is permanently jailed and tombstoned to make it impossible for that -validator to ever re-enter the validator set. +此外，验证者被永久监禁和墓碑化，使其不可能 +验证器永远重新进入验证器集。 -The `Equivocation` evidence is handled as follows: +`Equivocation` 证据处理如下: ```go func (k Keeper) HandleEquivocationEvidence(ctx sdk.Context, evidence *types.Equivocation) { @@ -145,6 +145,6 @@ func (k Keeper) HandleEquivocationEvidence(ctx sdk.Context, evidence *types.Equi } ``` -Note, the slashing, jailing, and tombstoning calls are delegated through the `x/slashing` module -that emits informative events and finally delegates calls to the `x/staking` module. See documentation -on slashing and jailing in [x/staking spec](/.././cosmos-sdk/x/staking/spec/02_state_transitions.md). +注意，slashing、jailing 和 tombstoning 调用是通过 `x/slashing` 模块委托的 +发出信息事件并最终将调用委托给 `x/staking` 模块。 查看文档 +关于 [x/staking spec](/.././cosmos-sdk/x/staking/spec/02_state_transitions.md) 中的削减和监禁。 \ No newline at end of file diff --git a/docs/ja/modules/evidence/07_client.md b/docs/ja/modules/evidence/07_client.md index 52a4b34f70fe..a5b29afcaef0 100644 --- a/docs/ja/modules/evidence/07_client.md +++ b/docs/ja/modules/evidence/07_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `evidence` module using the CLI. +用户可以使用 CLI 查询“证据”模块并与之交互。 -### Query +### 询问 -The `query` commands allows users to query `evidence` state. +`query` 命令允许用户查询 `evidence` 状态。 ```bash simd query evidence --help @@ -14,7 +14,7 @@ simd query evidence --help ### evidence -The `evidence` command allows users to list all evidence or evidence by hash. +`evidence` 命令允许用户通过哈希列出所有证据或证据。 Usage: diff --git a/docs/ja/modules/evidence/README.md b/docs/ja/modules/evidence/README.md index ef22466151a0..224b589439e0 100644 --- a/docs/ja/modules/evidence/README.md +++ b/docs/ja/modules/evidence/README.md @@ -1,33 +1,33 @@ -# `x/evidence` +# `x/证据` -## Table of Contents +## 目录 - + -1. **[Concepts](01_concepts.md)** -2. **[State](02_state.md)** -3. **[Messages](03_messages.md)** -4. **[Events](04_events.md)** -5. **[Params](05_params.md)** +1. **[概念](01_concepts.md)** +2. **[状态](02_state.md)** +3. **[消息](03_messages.md)** +4. **[事件](04_events.md)** +5. **[参数](05_params.md)** 6. **[BeginBlock](06_begin_block.md)** -## Abstract +## 摘要 -`x/evidence` is an implementation of a Cosmos SDK module, per [ADR 009](./../../../docs/architecture/adr-009-evidence-module.md), -that allows for the submission and handling of arbitrary evidence of misbehavior such -as equivocation and counterfactual signing. +`x/evidence` 是 Cosmos SDK 模块的实现，根据 [ADR 009](./../../../docs/architecture/adr-009-evidence-module.md)， +允许提交和处理不当行为的任意证据，例如 +作为模棱两可和反事实签名。 -The evidence module differs from standard evidence handling which typically expects the -underlying consensus engine, e.g. Tendermint, to automatically submit evidence when -it is discovered by allowing clients and foreign chains to submit more complex evidence -directly. +证据模块不同于标准证据处理，标准证据处理通常期望 +底层共识引擎，例如Tendermint，自动提交证据时 +它是通过允许客户和外国连锁存储提交更复杂的证据来发现的 +直接地。 -All concrete evidence types must implement the `Evidence` interface contract. Submitted -`Evidence` is first routed through the evidence module's `Router` in which it attempts -to find a corresponding registered `Handler` for that specific `Evidence` type. -Each `Evidence` type must have a `Handler` registered with the evidence module's -keeper in order for it to be successfully routed and executed. +所有具体的证据类型都必须实现“证据”接口契约。已提交 +`Evidence` 首先通过它尝试的证据模块的 `Router` 路由 +为该特定的“证据”类型找到相应的注册“处理程序”。 +每个 `Evidence` 类型都必须有一个注册到证据模块的`Handler` +keeper 以使其成功路由和执行。 -Each corresponding handler must also fulfill the `Handler` interface contract. The -`Handler` for a given `Evidence` type can perform any arbitrary state transitions -such as slashing, jailing, and tombstoning. +每个相应的处理程序还必须履行`Handler` 接口契约。这 +给定“证据”类型的“处理程序”可以执行任意状态转换 +例如砍伐、监禁和墓碑。 \ No newline at end of file diff --git a/docs/ja/modules/feegrant/01_concepts.md b/docs/ja/modules/feegrant/01_concepts.md index fd8980733978..0fbd415c66d4 100644 --- a/docs/ja/modules/feegrant/01_concepts.md +++ b/docs/ja/modules/feegrant/01_concepts.md @@ -1,53 +1,53 @@ -# Concepts +# 概念 -## Grant +## 授予 -`Grant` is stored in the KVStore to record a grant with full context. Every grant will contain `granter`, `grantee` and what kind of `allowance` is granted. `granter` is an account address who is giving permission to `grantee` (the beneficiary account address) to pay for some or all of `grantee`'s transaction fees. `allowance` defines what kind of fee allowance (`BasicAllowance` or `PeriodicAllowance`, see below) is granted to `grantee`. `allowance` accepts an interface which implements `FeeAllowanceI`, encoded as `Any` type. There can be only one existing fee grant allowed for a `grantee` and `granter`, self grants are not allowed. +`Grant` 存储在 KVStore 中以记录具有完整上下文的授权。每个赠款都将包含“授予者”、“受赠者”以及授予的“津贴”类型。 `granter` 是一个账户地址，它允许 `grantee`(受益人账户地址)支付部分或全部 `grantee` 的交易费用。 `allowance` 定义了授予 `grantee` 什么样的费用津贴(`BasicAllowance` 或 `PeriodicAllowance`，见下文)。 `allowance` 接受一个实现 `FeeAllowanceI` 的接口，编码为 `Any` 类型。 “受让人”和“受让人”只能有一项现有的费用补助，不允许自行补助。 +++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/feegrant.proto#L75-L81 -`FeeAllowanceI` looks like: +`FeeAllowanceI` 看起来像: +++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/x/feegrant/fees.go#L9-L32 -## Fee Allowance types +## 费用津贴类型 -There are two types of fee allowances present at the moment: +目前有两种类型的费用津贴: -- `BasicAllowance` +-`基本津贴` - `PeriodicAllowance` -## BasicAllowance +## 基本津贴 -`BasicAllowance` is permission for `grantee` to use fee from a `granter`'s account. If any of the `spend_limit` or `expiration` reaches its limit, the grant will be removed from the state. +`BasicAllowance` 是允许 `grantee` 使用来自 `granter` 帐户的费用。如果“spend_limit”或“expiration”中的任何一个达到其限制，则该授权将从状态中删除。 +++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/feegrant.proto#L13-L26 -- `spend_limit` is the limit of coins that are allowed to be used from the `granter` account. If it is empty, it assumes there's no spend limit, `grantee` can use any number of available tokens from `granter` account address before the expiration. +- `spend_limit` 是允许从 `granter` 帐户使用的硬币限制。如果它为空，则假定没有支出限制，`grantee` 可以在到期前使​​用来自 `granter` 帐户地址的任意数量的可用代币。 -- `expiration` specifies an optional time when this allowance expires. If the value is left empty, there is no expiry for the grant. +- `expiration` 指定该配额到期的可选时间。如果该值留空，则授权没有到期。 -- When a grant is created with empty values for `spend_limit` and `expiration`, it is still a valid grant. It won't restrict the `grantee` to use any number of tokens from `granter` and it won't have any expiration. The only way to restrict the `grantee` is by revoking the grant. +- 当使用“spend_limit”和“expiration”的空值创建授权时，它仍然是有效的授权。它不会限制 `grantee` 使用来自 `granter` 的任意数量的令牌，并且不会有任何过期时间。限制“受赠者”的唯一方法是撤销授予。 -## PeriodicAllowance +## 定期津贴 -`PeriodicAllowance` is a repeating fee allowance for the mentioned period, we can mention when the grant can expire as well as when a period can reset. We can also define the maximum number of coins that can be used in a mentioned period of time. +`PeriodicAllowance` 是上述期间的重复费用津贴，我们可以提及补助金何时到期以及何时可以重置。我们还可以定义在提到的时间段内可以使用的最大硬币数量。 +++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/feegrant.proto#L28-L73 -- `basic` is the instance of `BasicAllowance` which is optional for periodic fee allowance. If empty, the grant will have no `expiration` and no `spend_limit`. +- `basic` 是 `BasicAllowance` 的实例，对于定期费用津贴是可选的。如果为空，则赠款将没有“expiration”和“spend_limit”。 -- `period` is the specific period of time, after each period passes, `period_spend_limit` will be reset. +- `period` 是具体的时间段，每个时间段过去后，`period_spend_limit` 将被重置。 -- `period_spend_limit` specifies the maximum number of coins that can be spent in the period. +- `period_spend_limit` 指定在该期间内可以花费的最大硬币数量。 -- `period_can_spend` is the number of coins left to be spent before the period_reset time. +- `period_can_spend` 是在 period_reset 时间之前剩余的硬币数量。 -- `period_reset` keeps track of when a next period reset should happen. +- `period_reset` 会记录下一个周期重置应该发生的时间。 -## FeeGranter flag +## FeeGranter 标志 -`feegrant` module introduces a `FeeGranter` flag for CLI for the sake of executing transactions with fee granter. When this flag is set, `clientCtx` will append the granter account address for transactions generated through CLI. +`feegrant` 模块为 CLI 引入了一个 `FeeGranter` 标志，以便与费用授予者执行交易。设置此标志后，`clientCtx` 将为通过 CLI 生成的交易附加授予者帐户地址。 +++ https://github.com/cosmos/cosmos-sdk/blob/d97e7907f176777ed8a464006d360bb3e1a223e4/client/cmd.go#L224-L235 @@ -57,18 +57,18 @@ There are two types of fee allowances present at the moment: +++ https://github.com/cosmos/cosmos-sdk/blob/d97e7907f176777ed8a464006d360bb3e1a223e4/proto/cosmos/tx/v1beta1/tx.proto#L160-L181 -Example cmd: +示例命令: -```go -./simd tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --from validator-key --fee-granter=cosmos1xh44hxt7spr67hqaa7nyx5gnutrz5fraw6grxn --chain-id=testnet --fees="10stake" -``` +```Go +./simd tx gov submit-proposal --title="Test Proposal" --description="My Awesome Proposal" --type="Text" --from validator-key --fee-granter=cosmos1xh44hxt7spr67hqaa7nyx5gnutrz5fraw6grxn --chain-id =testnet --fees="10stake" +`` -## Granted Fee Deductions +## 授予的费用减免 -Fees are deducted from grants in the `x/auth` ante handler. To learn more about how ante handlers work, read the [Auth Module AnteHandlers Guide](../../auth/spec/03_antehandlers.md). +费用从 `x/auth` 前处理程序的赠款中扣除。要了解有关 ante 处理程序如何工作的更多信息，请阅读 [Auth Module AnteHandlers Guide](../../auth/spec/03_antehandlers.md)。 -## Gas +## 气体 -In order to prevent DoS attacks, using a filtered `x/feegrant` incurs gas. The SDK must assure that the `grantee`'s transactions all conform to the filter set by the `granter`. The SDK does this by iterating over the allowed messages in the filter and charging 10 gas per filtered message. The SDK will then iterate over the messages being sent by the `grantee` to ensure the messages adhere to the filter, also charging 10 gas per message. The SDK will stop iterating and fail the transaction if it finds a message that does not conform to the filter. +为了防止 DoS 攻击，使用过滤的 `x/feegrant` 会产生 gas。 SDK 必须确保“被授予者”的交易都符合“授予者”设置的过滤器。 SDK 通过迭代过滤器中允许的消息并为每个过滤的消息收取 10 gas 来做到这一点。然后，SDK 将迭代“受赠者”发送的消息，以确保消息符合过滤器，同时每条消息收取 10 gas。如果 SDK 发现不符合过滤器的消息，将停止迭代并使事务失败。 -**WARNING**: The gas is charged against the granted allowance. Ensure your messages conform to the filter, if any, before sending transactions using your allowance. +**警告**:根据授予的津贴收取天然气费用。在使用您的配额发送交易之前，请确保您的消息符合过滤器(如果有)。 \ No newline at end of file diff --git a/docs/ja/modules/feegrant/02_state.md b/docs/ja/modules/feegrant/02_state.md index 0fcddc158ecf..7105c540d6e0 100644 --- a/docs/ja/modules/feegrant/02_state.md +++ b/docs/ja/modules/feegrant/02_state.md @@ -1,11 +1,11 @@ -# State +# 状态 -## FeeAllowance +## 费用津贴 -Fee Allowances are identified by combining `Grantee` (the account address of fee allowance grantee) with the `Granter` (the account address of fee allowance granter). +费用津贴通过将“受赠人”(费用津贴受赠人的帐户地址)与“赠与人”(费用津贴授予人的帐户地址)组合在一起来识别。 -Fee allowance grants are stored in the state as follows: +费用津贴补助金在州中存储如下: -- Grant: `0x00 | grantee_addr_len (1 byte) | grantee_addr_bytes | granter_addr_len (1 byte) | granter_addr_bytes -> ProtocolBuffer(Grant)` +- 授予:`0x00 | grantee_addr_len (1 字节) | grantee_addr_bytes | granter_addr_len (1 字节) | granter_addr_bytes -> ProtocolBuffer(Grant)` -+++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/x/feegrant/feegrant.pb.go#L221-L229 ++++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/x/feegrant/feegrant.pb.go#L221-L229 \ No newline at end of file diff --git a/docs/ja/modules/feegrant/03_messages.md b/docs/ja/modules/feegrant/03_messages.md index 11758d07b146..99785398f088 100644 --- a/docs/ja/modules/feegrant/03_messages.md +++ b/docs/ja/modules/feegrant/03_messages.md @@ -1,13 +1,13 @@ -# Messages +# 消息 -## Msg/GrantAllowance +## 消息/GrantAllowance -A fee allowance grant will be created with the `MsgGrantAllowance` message. +将使用 `MsgGrantAllowance` 消息创建费用补贴。 +++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/tx.proto#L22-L33 -## Msg/RevokeAllowance +## 消息/撤销Allowance -An allowed grant fee allowance can be removed with the `MsgRevokeAllowance` message. +可以使用 `MsgRevokeAllowance` 消息删除允许的授予费用津贴。 -+++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/tx.proto#L38-L45 ++++ https://github.com/cosmos/cosmos-sdk/blob/691032b8be0f7539ec99f8882caecefc51f33d1f/proto/cosmos/feegrant/v1beta1/tx.proto#L38-L45 \ No newline at end of file diff --git a/docs/ja/modules/feegrant/04_events.md b/docs/ja/modules/feegrant/04_events.md index 9ac47d8692a6..47dd11d411e0 100644 --- a/docs/ja/modules/feegrant/04_events.md +++ b/docs/ja/modules/feegrant/04_events.md @@ -1,7 +1,6 @@ -# Events - -The feegrant module emits the following events: +# 事件 +Feegrant 模块发出以下事件: # Msg Server ### MsgGrantAllowance diff --git a/docs/ja/modules/feegrant/05_client.md b/docs/ja/modules/feegrant/05_client.md index 966e5fa56c64..42d6bbf7e54d 100644 --- a/docs/ja/modules/feegrant/05_client.md +++ b/docs/ja/modules/feegrant/05_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `feegrant` module using the CLI. +用户可以使用 CLI 查询“feegrant”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `feegrant` state. +`query` 命令允许用户查询 `feegrant` 状态。 ``` simd query feegrant --help @@ -41,7 +41,7 @@ granter: cosmos1.. #### grants -The `grants` command allows users to query all grants for a given grantee. +`grants` 命令允许用户查询给定受让人的所有授权。 ``` simd query feegrant grants [grantee] [flags] @@ -72,7 +72,7 @@ pagination: ### Transactions -The `tx` commands allow users to interact with the `feegrant` module. +`tx` 命令允许用户与 `feegrant` 模块交互。 ``` simd tx feegrant --help @@ -80,7 +80,7 @@ simd tx feegrant --help #### grant -The `grant` command allows users to grant fee allowances to another account. The fee allowance can have an expiration date, a total spend limit, and/or a periodic spend limit. +`grant` 命令允许用户向另一个帐户授予费用津贴。 费用津贴可以具有到期日期、总支出限额和/或定期支出限额。 ``` simd tx feegrant grant [granter] [grantee] [flags] @@ -100,7 +100,7 @@ simd tx feegrant grant cosmos1.. cosmos1.. --period 3600 --period-limit 10stake #### revoke -The `revoke` command allows users to revoke a granted fee allowance. +`revoke` 命令允许用户撤销授予的费用津贴。 ``` simd tx feegrant revoke [granter] [grantee] [flags] @@ -114,11 +114,11 @@ simd tx feegrant revoke cosmos1.. cosmos1.. ## gRPC -A user can query the `feegrant` module using gRPC endpoints. +用户可以使用 gRPC 端点查询 `feegrant` 模块。 ### Allowance -The `Allowance` endpoint allows users to query a granted fee allowance. +`Allowance` 端点允许用户查询授予的费用津贴。 ``` cosmos.feegrant.v1beta1.Query/Allowance diff --git a/docs/ja/modules/feegrant/README.md b/docs/ja/modules/feegrant/README.md index 80f3ec6af5df..86f1e20b6196 100644 --- a/docs/ja/modules/feegrant/README.md +++ b/docs/ja/modules/feegrant/README.md @@ -1,28 +1,22 @@ -## Abstract +## 内容 -This document specifies the feegrant module. For the full ADR, please see [Fee Grant ADR-029](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/docs/architecture/adr-029-fee-grant-module.md). - -This module allows accounts to grant fee allowances and to use fees from their accounts. Grantees can execute any transaction without the need to maintain sufficient fees. - -## Contents - -1. **[Concepts](01_concepts.md)** - - [Grant](01_concepts.md#grant) - - [Fee Allowance types](01_concepts.md#fee-allowance-types) - - [BasicAllowance](01_concepts.md#basicallowance) +1. **[概念](01_concepts.md)** + - [赠款](01_concepts.md#grant) + - [费用津贴类型](01_concepts.md#fee-allowance-types) + - [基本津贴](01_concepts.md#basicallowance) - [PeriodicAllowance](01_concepts.md#periodicallowance) - - [FeeAccount flag](01_concepts.md#feeaccount-flag) - - [Granted Fee Deductions](01_concepts.md#granted-fee-deductions) - - [Gas](01_concepts.md#gas) -2. **[State](02_state.md)** - - [FeeAllowance](02_state.md#feeallowance) -3. **[Messages](03_messages.md)** + - [FeeAccount 标志](01_concepts.md#feeaccount-flag) + - [授予的费用扣除](01_concepts.md#granted-fee-deductions) + - [气体](01_concepts.md#gas) +2. **[状态](02_state.md)** + - [费用津贴](02_state.md#feeallowance) +3. **[消息](03_messages.md)** - [Msg/GrantAllowance](03_messages.md#msggrantallowance) - [Msg/RevokeAllowance](03_messages.md#msgrevokeallowance) -4. **[Events](04_events.md)** +4. **[事件](04_events.md)** - [MsgGrantAllowance](04_events.md#msggrantallowance) - [MsgRevokeAllowance](04_events.md#msgrevokeallowance) - - [Exec fee allowance](04_events.md#exec-fee-allowance) -5. **[Client](05_client.md)** + - [执行费津贴](04_events.md#exec-fee-allowance) +5. **[客户端](05_client.md)** - [CLI](05_client.md#cli) - - [gRPC](05_client.md#grpc) + - [gRPC](05_client.md#grpc) \ No newline at end of file diff --git a/docs/ja/modules/gov/01_concepts.md b/docs/ja/modules/gov/01_concepts.md index 9d1126f5861c..70c798da4ece 100644 --- a/docs/ja/modules/gov/01_concepts.md +++ b/docs/ja/modules/gov/01_concepts.md @@ -1,192 +1,192 @@ -# Concepts +# 概念 -_Disclaimer: This is work in progress. Mechanisms are susceptible to change._ +_免责声明:这是正在进行中的工作。机制容易改变。_ -The governance process is divided in a few steps that are outlined below: +治理过程分为几个步骤，概述如下: -- **Proposal submission:** Proposal is submitted to the blockchain with a - deposit. -- **Vote:** Once deposit reaches a certain value (`MinDeposit`), proposal is - confirmed and vote opens. Bonded Atom holders can then send `TxGovVote` - transactions to vote on the proposal. -- **Execution** After a period of time, the votes are tallied and depending - on the result, the messages in the proposal will be executed. +- **提案提交:** 提案提交到区块链 + 订金。 +- **投票:** 一旦存款达到一定值(`MinDeposit`)，建议是 + 确认并投票开始。保税原子持有者然后可以发送`TxGovVote` + 交易对提案进行投票。 +- **执行** 一段时间后，统计票数并视情况而定 + 根据结果​​，提案中的消息将被执行。 -## Proposal submission +## 提案提交 -### Right to submit a proposal +### 提交提案的权利 -Every account can submit proposals by sending a `MsgSubmitProposal` transaction. -Once a proposal is submitted, it is identified by its unique `proposalID`. +每个帐户都可以通过发送“MsgSubmitProposal”交易来提交提案。 +提交提案后，将通过其唯一的“proposalID”进行标识。 -### Proposal Messages +### 提案消息 -A proposal includes an array of `sdk.Msg`s which are executed automatically if the -proposal passes. The messages are executed by the governance `ModuleAccount` itself. Modules -such as `x/upgrade`, that want to allow certain messages to be executed by governance -only should add a whitelist within the respective msg server, granting the governance -module the right to execute the message once a quorum has been reached. The governance -module uses the `MsgServiceRouter` to check that these messages are correctly constructed -and have a respective path to execute on but do not perform a full validity check. +提案包含一组 `sdk.Msg`，如果 +提案通过。消息由治理“ModuleAccount”本身执行。模块 +例如`x/upgrade`，希望允许某些消息被治理执行 +只应在相应的 msg 服务器中添加白名单，授予治理 +一旦达到法定人数，模块有权执行消息。治理 +模块使用 `MsgServiceRouter` 来检查这些消息是否正确构造 +并有各自的执行路径，但不执行完整的有效性检查。 -## Deposit +## 订金 -To prevent spam, proposals must be submitted with a deposit in the coins defined by -the `MinDeposit` param. +为防止垃圾邮件，提交的提案必须以定义的硬币形式存入保证金 +`MinDeposit` 参数。 -When a proposal is submitted, it has to be accompanied with a deposit that must be -strictly positive, but can be inferior to `MinDeposit`. The submitter doesn't need -to pay for the entire deposit on their own. The newly created proposal is stored in -an _inactive proposal queue_ and stays there until its deposit passes the `MinDeposit`. -Other token holders can increase the proposal's deposit by sending a `Deposit` -transaction. If a proposal doesn't pass the `MinDeposit` before the deposit end time -(the time when deposits are no longer accepted), the proposal will be destroyed: the -proposal will be removed from state and the deposit will be burned (see x/gov `EndBlocker`). -When a proposal deposit passes the `MinDeposit` threshold (even during the proposal -submission) before the deposit end time, the proposal will be moved into the -_active proposal queue_ and the voting period will begin. +提交提案时，必须附有定金 +严格为正，但可能不如“MinDeposit”。提交者不需要 +自行支付全部押金。新创建的提案存储在 +一个 _inactive 提案队列_ 并保持在那里，直到它的存款通过 `MinDeposit`。 +其他代币持有者可以通过发送“存款”来增加提案的存款 +交易。如果提案在存款结束时间之前没有通过 `MinDeposit` +(不再接受存款的时间)，提案将被销毁: +提案将从州中删除，押金将被烧毁(请参阅 x/gov `EndBlocker`)。 +当提案存款超过“MinDeposit”阈值时(即使在提案期间 +提交)在存款结束时间之前，提案将被移入 +_active 提案队列_，投票期将开始。 -The deposit is kept in escrow and held by the governance `ModuleAccount` until the -proposal is finalized (passed or rejected). +存款由托管机构“ModuleAccount”保管，直到 +提案最终确定(通过或拒绝)。 -### Deposit refund and burn +### 押金退还烧掉 -When a proposal is finalized, the coins from the deposit are either refunded or burned -according to the final tally of the proposal: +当提案最终确定时，押金中的硬币要么退还要么烧毁 +根据提案的最终统计: -- If the proposal is approved or rejected but _not_ vetoed, each deposit will be - automatically refunded to its respective depositor (transferred from the governance - `ModuleAccount`). -- When the proposal is vetoed with greater than 1/3, deposits will be burned from the - governance `ModuleAccount` and the proposal information along with its deposit - information will be removed from state. -- All refunded or burned deposits are removed from the state. Events are issued when - burning or refunding a deposit. +- 如果提案被批准或拒绝但_not_否决，每笔存款将被 + 自动退还给其各自的存款人(从治理转移 + `模块帐户`)。 +- 当提案被超过 1/3 否决时，存款将从 + 治理 `ModuleAccount` 和提案信息及其存款 + 信息将从状态中删除。 +- 所有退还或烧毁的存款都从国家中删除。事件是在什么时候发出的 + 烧毁或退还押金。 -## Voting +## 投票 -### Participants +### 参与者 -_Participants_ are users that have the right to vote on proposals. On the -Cosmos Hub, participants are bonded Atom holders. Unbonded Atom holders and -other users do not get the right to participate in governance. However, they -can submit and deposit on proposals. +_参与者_是有权对提案进行投票的用户。在 +Cosmos Hub，参与者是绑定的 Atom 持有者。未结合的原子持有者和 +其他用户没有参与治理的权利。然而，他们 +可以提交和存入提案。 -Note that some _participants_ can be forbidden to vote on a proposal under a -certain validator if: +请注意，某些 _participants_ 可能会被禁止在以下情况下对提案进行投票 +某些验证器，如果: -- _participant_ bonded or unbonded Atoms to said validator after proposal - entered voting period. -- _participant_ became validator after proposal entered voting period. +- _participant_ 在提案后将 Atom 绑定或未绑定到所述验证器 + 进入投票期。 +- _participant_ 在提案进入投票期后成为验证人。 -This does not prevent _participant_ to vote with Atoms bonded to other -validators. For example, if a _participant_ bonded some Atoms to validator A -before a proposal entered voting period and other Atoms to validator B after -proposal entered voting period, only the vote under validator B will be -forbidden. +这不会阻止_participant_ 将 Atoms 绑定到其他 +验证器。例如，如果 _participant_ 将一些 Atom 绑定到验证器 A +在提案进入投票期之前和其他 Atom 到验证者 B 之后 +提案进入投票期，只有验证者 B 下的投票才会通过 +禁止。 -### Voting period +### 投票期 -Once a proposal reaches `MinDeposit`, it immediately enters `Voting period`. We -define `Voting period` as the interval between the moment the vote opens and -the moment the vote closes. `Voting period` should always be shorter than -`Unbonding period` to prevent double voting. The initial value of -`Voting period` is 2 weeks. +一旦提案达到`MinDeposit`，它立即进入`投票期`。我们 +将“投票期”定义为投票开始和投票之间的时间间隔 +投票结束的那一刻。 “投票期”应始终短于 +“解除绑定期”以防止双重投票。的初始值 +“投票期”为 2 周。 -### Option set +### 选项集 -The option set of a proposal refers to the set of choices a participant can -choose from when casting its vote. +提案的选项集是指参与者可以选择的集合 +在投票时选择。 -The initial option set includes the following options: +初始选项集包括以下选项: -- `Yes` -- `No` -- `NoWithVeto` -- `Abstain` +-`是` +-`不` +-`NoWithVeto` +-`弃权` -`NoWithVeto` counts as `No` but also adds a `Veto` vote. `Abstain` option -allows voters to signal that they do not intend to vote in favor or against the -proposal but accept the result of the vote. +`NoWithVeto` 算作`No`，但也会增加一个`Veto` 投票。 `弃权`选项 +允许选民表明他们不打算投票赞成或反对 +提议但接受投票结果。 -_Note: from the UI, for urgent proposals we should maybe add a ‘Not Urgent’ -option that casts a `NoWithVeto` vote._ +_注意:从用户界面来看，对于紧急提案，我们可能应该添加“不紧急” +投出“NoWithVeto”投票的选项。_ -### Weighted Votes +### 加权投票 -[ADR-037](../../../docs/architecture/adr-037-gov-split-vote.md) introduces the weighted vote feature which allows 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. +[ADR-037](../../../docs/architecture/adr-037-gov-split-vote.md) 引入了加权投票功能，允许权益人将他们的投票分成几个投票选项。例如，它可以用 70% 的投票权投赞成票，用 30% 的投票权投反对票。 -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. 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. +通常，拥有该地址的实体可能不是一个人。例如，一家公司可能有不同的利益相关者想要以不同的方式投票，因此允许他们分配投票权是有意义的。目前，他们无法进行“传递投票”并赋予用户对其代币的投票权。然而，通过这个系统，交易所可以对用户的投票偏好进行投票，然后根据投票结果按比例在链上投票。 -To represent weighted vote on chain, we use the following Protobuf message. +为了表示链上的加权投票，我们使用以下 Protobuf 消息。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/proto/cosmos/gov/v1beta1/gov.proto#L32-L40 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.43.0-alpha1/proto/cosmos/gov/v1beta1/gov.proto#L126-L137 -For a weighted vote to be valid, the `options` field must not contain duplicate vote options, and the sum of weights of all options must be equal to 1. +要使加权投票有效，`options` 字段不得包含重复的投票选项，并且所有选项的权重总和必须等于 1。 -### Quorum +###法定人数 -Quorum is defined as the minimum percentage of voting power that needs to be -casted on a proposal for the result to be valid. +法定人数定义为需要获得的最低投票权百分比 +对结果有效的提案进行了投票。 -### Threshold +### 临界点 -Threshold is defined as the minimum proportion of `Yes` votes (excluding -`Abstain` votes) for the proposal to be accepted. +阈值定义为“是”票的最小比例(不包括 +`弃权`票) 的提案被接受。 -Initially, the threshold is set at 50% with a possibility to veto if more than -1/3rd of votes (excluding `Abstain` votes) are `NoWithVeto` votes. This means -that proposals are accepted if the proportion of `Yes` votes (excluding -`Abstain` votes) at the end of the voting period is superior to 50% and if the -proportion of `NoWithVeto` votes is inferior to 1/3 (excluding `Abstain` -votes). +最初，阈值设置为 50%，如果超过 50% 有可能否决 +1/3 的票(不包括“弃权”票)是“NoWithVeto”票。这意味着 +如果“是”的投票比例(不包括 +`弃权`票)在投票期结束时高于 50%，并且如果 +“NoWithVeto”票的比例低于1/3(不包括“Abstain” +票)。 -### Inheritance +### 继承 -If a delegator does not vote, it will inherit its validator vote. +如果委托人不投票，它将继承其验证人投票。 -- If the delegator votes before its validator, it will not inherit from the - validator's vote. -- If the delegator votes after its validator, it will override its validator - vote with its own. If the proposal is urgent, it is possible - that the vote will close before delegators have a chance to react and - override their validator's vote. This is not a problem, as proposals require more than 2/3rd of the total voting power to pass before the end of the voting period. If more than 2/3rd of validators collude, they can censor the votes of delegators anyway. +- 如果委托人在其验证人之前投票，则不会继承 + 验证者的投票。 +- 如果委托人在其验证人之后投票，它将覆盖其验证人 + 用自己的投票。如果提案很紧急，可以 + 投票将在代表有机会做出反应之前结束，并且 + 覆盖他们的验证者的投票。这不是问题，因为提案需要总投票权的 2/3 以上才能在投票期结束前通过。如果超过 2/3 的验证者串通一气，他们无论如何都可以审查委托人的投票。 -### Validator’s punishment for non-voting +### 验证者对不投票的惩罚 -At present, validators are not punished for failing to vote. +目前，验证者不会因未投票而受到惩罚。 -### Governance address +###治理地址 -Later, we may add permissioned keys that could only sign txs from certain modules. For the MVP, the `Governance address` will be the main validator address generated at account creation. This address corresponds to a different PrivKey than the Tendermint PrivKey which is responsible for signing consensus messages. Validators thus do not have to sign governance transactions with the sensitive Tendermint PrivKey. +稍后，我们可能会添加只能对来自某些模块的 txs 进行签名的许可密钥。对于 MVP，“治理地址”将是创建帐户时生成的主要验证器地址。该地址对应于与负责签署共识消息的 Tendermint PrivKey 不同的 PrivKey。因此，验证者不必使用敏感的 Tendermint PrivKey 签署治理交易。 -## Software Upgrade +## 软件升级 -If proposals are of type `SoftwareUpgradeProposal`, then nodes need to upgrade -their software to the new version that was voted. This process is divided in -two steps. +如果提案是“SoftwareUpgradeProposal”类型，则节点需要升级 +他们的软件更新到投票的新版本。这个过程分为 +两步。 -### Signal +### 信号 -After a `SoftwareUpgradeProposal` is accepted, validators are expected to -download and install the new version of the software while continuing to run -the previous version. Once a validator has downloaded and installed the -upgrade, it will start signaling to the network that it is ready to switch by -including the proposal's `proposalID` in its _precommits_.(_Note: Confirmation -that we want it in the precommit?_) +在“SoftwareUpgradeProposal”被接受后，验证者应该 +在继续运行的同时下载并安装新版本的软件 +以前的版本。一旦验证器下载并安装了 +升级，它将开始向网络发出信号，表明它已准备好切换 +在其 _precommits_ 中包含提案的 `proposalID`。(_注意:确认 +我们希望在预提交中使用它？_) -Note: There is only one signal slot per _precommit_. If several -`SoftwareUpgradeProposals` are accepted in a short timeframe, a pipeline will -form and they will be implemented one after the other in the order that they -were accepted. +注意:每个 _precommit_ 只有一个信号槽。如果几个 +`SoftwareUpgradeProposals` 在短时间内被接受，管道将 +形式，它们将按照它们的顺序依次实施 +被接受了。 -### Switch +### 转变 -Once a block contains more than 2/3rd _precommits_ where a common -`SoftwareUpgradeProposal` is signaled, all the nodes (including validator -nodes, non-validating full nodes and light-nodes) are expected to switch to the -new version of the software. +一旦一个块包含超过 2/3 的 _precommits_，其中一个公共 +`SoftwareUpgradeProposal` 已发出信号，所有节点(包括验证器 +节点、非验证全节点和轻节点)预计将切换到 +软件的新版本。 -_Note: Not clear how the flip is handled programmatically_ +_注意:不清楚如何以编程方式处理翻转_ \ No newline at end of file diff --git a/docs/ja/modules/gov/02_state.md b/docs/ja/modules/gov/02_state.md index 455878a93b55..b0d35b1d6a4c 100644 --- a/docs/ja/modules/gov/02_state.md +++ b/docs/ja/modules/gov/02_state.md @@ -1,25 +1,25 @@ -# State +# 状态 -## Proposals +## 提案 -`Proposal` objects are used to tally votes and generally track the proposal's state. -They contain an array of arbitrary `sdk.Msg`'s which the governance module will attempt -to resolve and then execute if the proposal passes. `Proposal`'s are identified by a -unique id and contains a series of timestamps: `submit_time`, `deposit_end_time`, -`voting_start_time`, `voting_end_time` which track the lifecycle of a proposal +`Proposal` 对象用于统计投票并通常跟踪提案的状态。 +它们包含治理模块将尝试的任意 `sdk.Msg` 数组 +如果提案通过，则解决然后执行。 “提案”由一个标识 +唯一 id 并包含一系列时间戳:`submit_time`、`deposit_end_time`、 +`voting_start_time`, `voting_end_time` 跟踪提案的生命周期 +++ https://github.com/cosmos/cosmos-sdk/blob/4a129832eb16f37a89e97652a669f0cdc9196ca9/proto/cosmos/gov/v1beta2/gov.proto#L42-L52 -A proposal will generally require more than just a set of messages to explain its -purpose but need some greater justification and allow a means for interested participants -to discuss and debate the proposal. In most cases, it is encouraged to have an off-chain -system that supports the on-chain governance process. To accommodate for this, a -proposal contains a special `metadata` field, an array of bytes, which can be used to -add context to the proposal. The `metadata` field allows custom use for networks, however, -it is expected that the field contain a URL or some form of CID using a system such as -[IPFS](https://docs.ipfs.io/concepts/content-addressing/). To support the case of -interoperability across networks, the SDK recommends that the `metadata` represents -the following `JSON` template: +一个提案通常需要的不仅仅是一组消息来解释它的 +目的但需要一些更大的理由并为感兴趣的参与者提供一种手段 +讨论和辩论该提案。在大多数情况下，鼓励有一个链下 +支持链上治理过程的系统。为了适应这种情况，一个 +提案包含一个特殊的“元数据”字段，一个字节数组，可用于 +为提案添加上下文。 `metadata` 字段允许自定义使用网络，但是， +预计该字段包含 URL 或使用系统的某种形式的 CID，例如 +[IPFS](https://docs.ipfs.io/concepts/content-addressing/)。为了支持的情况 +跨网络的互操作性，SDK 建议“元数据”代表 +以下`JSON`模板: ```json { @@ -30,30 +30,30 @@ the following `JSON` template: } ``` -This makes it far easier for clients to support multiple networks. +这使得客户端更容易支持多个网络。 -### Writing a module that uses governance +### 编写一个使用治理的模块 -There are many aspects of a chain, or of the individual modules that you may want to -use governance to perform such as changing various parameters. This is very simple -to do. First, write out your message types and `MsgServer` implementation. Add an -`authority` field to the keeper which will be populated in the constructor with the -governance module account: `govKeeper.GetGovernanceAccount().GetAddress()`. Then for -the methods in the `msg_server.go`, perform a check on the message that the signer -matches `authority`. This will prevent any user from executing that message. +链或您可能想要的单个模块的许多方面 +使用治理来执行例如更改各种参数。这很简单 +去做。首先，写出你的消息类型和 `MsgServer` 实现。添加一个 +`authority` 字段给 keeper ，它将在构造函数中填充 +治理模块帐户:`govKeeper.GetGovernanceAccount().GetAddress()`。那么对于 +`msg_server.go` 中的方法，对签名者发送的消息执行检查 +匹配“权威”。这将阻止任何用户执行该消息。 -## Parameters and base types +## 参数和基本类型 -`Parameters` define the rules according to which votes are run. There can only -be one active parameter set at any given time. If governance wants to change a -parameter set, either to modify a value or add/remove a parameter field, a new -parameter set has to be created and the previous one rendered inactive. +`Parameters` 定义了运行投票的规则。只能有 +是任何给定时间的一个活动参数集。如果治理想要改变一个 +参数集，用于修改值或添加/删除参数字段，一个新的 +必须创建参数集并且前一个被渲染为非活动状态。 -### DepositParams +### 存款参数 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L127-L145 -### VotingParams +### 投票参数 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L147-L156 @@ -61,9 +61,9 @@ parameter set has to be created and the previous one rendered inactive. +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/gov.proto#L158-L183 -Parameters are stored in a global `GlobalParams` KVStore. +参数存储在全局`GlobalParams` KVStore 中。 -Additionally, we introduce some basic types: +此外，我们还介绍了一些基本类型: ```go type Vote byte @@ -110,36 +110,36 @@ This type is used in a temp map when tallying } ``` -## Stores +## 存储 -_Stores are KVStores in the multi-store. The key to find the store is the first -parameter in the list_` +_Stores 是 multi-store 中的 KVStores。找存储的关键是第一 +列表中的参数_` -We will use one KVStore `Governance` to store two mappings: +我们将使用一个 KVStore `Governance` 来存储两个映射: -- A mapping from `proposalID|'proposal'` to `Proposal`. -- A mapping from `proposalID|'addresses'|address` to `Vote`. This mapping allows - us to query all addresses that voted on the proposal along with their vote by - doing a range query on `proposalID:addresses`. +- 从 `proposalID|'proposal'` 到 `Proposal` 的映射。 +- 从 `proposalID|'addresses'|address` 到 `Vote` 的映射。这种映射允许 + 我们查询所有对该提案进行投票的地址以及他们的投票 + 对 `proposalID:addresses` 进行范围查询。 -For pseudocode purposes, here are the two function we will use to read or write in stores: +出于伪代码的目的，以下是我们将用于在存储中读取或写入的两个函数: -- `load(StoreKey, Key)`: Retrieve item stored at key `Key` in store found at key `StoreKey` in the multistore -- `store(StoreKey, Key, value)`: Write value `Value` at key `Key` in store found at key `StoreKey` in the multistore +- `load(StoreKey, Key)`:检索存储在多存储中键`StoreKey`的存储中存储在键`Key`中的项目 +- `store(StoreKey, Key, value)`:在多存储中的键`StoreKey`中找到的存储中的键`Key`中写入值`Value` -## Proposal Processing Queue +## 提案处理队列 -**Store:** +**存储:** -- `ProposalProcessingQueue`: A queue `queue[proposalID]` containing all the - `ProposalIDs` of proposals that reached `MinDeposit`. During each `EndBlock`, - all the proposals that have reached the end of their voting period are processed. - To process a finished proposal, the application tallies the votes, computes the - votes of each validator and checks if every validator in the validator set has - voted. If the proposal is accepted, deposits are refunded. Finally, the proposal - content `Handler` is executed. +- `ProposalProcessingQueue`:一个队列 `queue[proposalID]` 包含所有 + 达到“MinDeposit”的提案的“ProposalIDs”。在每个“EndBlock”期间， + 所有已到投票期结束的提案都将被处理。 + 为了处理完成的提案，应用程序会统计投票数，计算 + 每个验证者的投票，并检查验证者集中的每个验证者是否有 + 投票。如果提案被接受，押金将被退还。最后，提案 + 内容 `Handler` 被执行。 -And the pseudocode for the `ProposalProcessingQueue`: +以及“ProposalProcessingQueue”的伪代码: ```go in EndBlock do diff --git a/docs/ja/modules/gov/03_messages.md b/docs/ja/modules/gov/03_messages.md index 5d2645521927..3ebd4cea9638 100644 --- a/docs/ja/modules/gov/03_messages.md +++ b/docs/ja/modules/gov/03_messages.md @@ -1,27 +1,27 @@ -# Messages +# 消息 -## Proposal Submission +## 提案提交 -Proposals can be submitted by any account via a `MsgSubmitProposal` -transaction. +任何帐户都可以通过“MsgSubmitProposal”提交提案 +交易。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/tx.proto#L24-L39 -The `Content` of a `MsgSubmitProposal` message must have an appropriate router -set in the governance module. +`MsgSubmitProposal` 消息的 `Content` 必须有一个合适的路由器 +在治理模块中设置。 -**State modifications:** +**状态修改:** -- Generate new `proposalID` -- Create new `Proposal` -- Initialise `Proposal`'s attributes -- Decrease balance of sender by `InitialDeposit` -- If `MinDeposit` is reached: - - Push `proposalID` in `ProposalProcessingQueue` -- Transfer `InitialDeposit` from the `Proposer` to the governance `ModuleAccount` +- 生成新的`proposalID` +- 创建新的“提案” +- 初始化`Proposal`的属性 +- 通过`InitialDeposit`减少发件人的余额 +- 如果达到`MinDeposit`: + - 在`ProposalProcessingQueue`中推送`proposalID` +- 将 `InitialDeposit` 从 `Proposer` 转移到治理 `ModuleAccount` -A `MsgSubmitProposal` transaction can be handled according to the following -pseudocode. +一个 `MsgSubmitProposal` 事务可以按照以下方式处理 +伪代码。 ```go // PSEUDOCODE // @@ -65,25 +65,25 @@ upon receiving txGovSubmitProposal from sender do return proposalID ``` -## Deposit +## 订金 -Once a proposal is submitted, if -`Proposal.TotalDeposit < ActiveParam.MinDeposit`, Atom holders can send -`MsgDeposit` transactions to increase the proposal's deposit. +提交提案后，如果 +`Proposal.TotalDeposit < ActiveParam.MinDeposit`，Atom 持有者可以发送 +`MsgDeposit` 交易以增加提案的存款。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/tx.proto#L61-L72 -**State modifications:** +**状态修改:** -- Decrease balance of sender by `deposit` -- Add `deposit` of sender in `proposal.Deposits` -- Increase `proposal.TotalDeposit` by sender's `deposit` -- If `MinDeposit` is reached: - - Push `proposalID` in `ProposalProcessingQueueEnd` -- Transfer `Deposit` from the `proposer` to the governance `ModuleAccount` +- 通过`存款`减少发件人的余额 +- 在`proposal.Deposits`中添加发件人的`deposit` +- 通过发送者的`deposit`增加`proposal.TotalDeposit` +- 如果达到`MinDeposit`: + - 在`ProposalProcessingQueueEnd`中推送`proposalID` +- 将`Deposit`从`proposer`转移到治理`ModuleAccount` -A `MsgDeposit` transaction has to go through a number of checks to be valid. -These checks are outlined in the following pseudocode. +`MsgDeposit` 交易必须经过多次检查才能有效。 +以下伪代码概述了这些检查。 ```go // PSEUDOCODE // @@ -133,20 +133,20 @@ upon receiving txGovDeposit from sender do ## Vote -Once `ActiveParam.MinDeposit` is reached, voting period starts. From there, -bonded Atom holders are able to send `MsgVote` transactions to cast their -vote on the proposal. +一旦达到`ActiveParam.MinDeposit`，投票期开始。 从那里， +绑定的 Atom 持有者能够发送“MsgVote”交易来投下他们的 +对该提案进行投票。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/gov/v1beta1/tx.proto#L46-L56 -**State modifications:** +**状态修改:** -- Record `Vote` of sender +- 记录发件人的“投票” -_Note: Gas cost for this message has to take into account the future tallying of the vote in EndBlocker_ +_注意:此消息的 Gas 成本必须考虑到 EndBlocker 中未来的投票统计_ -Next is a pseudocode outline of the way `MsgVote` transactions are -handled: +接下来是“MsgVote”交易方式的伪代码概述 +处理: ```go // PSEUDOCODE // diff --git a/docs/ja/modules/gov/04_events.md b/docs/ja/modules/gov/04_events.md index 33fae784a51e..ae71f60bb751 100644 --- a/docs/ja/modules/gov/04_events.md +++ b/docs/ja/modules/gov/04_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The governance module emits the following events: +治理模块发出以下事件: ## EndBlocker diff --git a/docs/ja/modules/gov/05_future_improvements.md b/docs/ja/modules/gov/05_future_improvements.md index 01062cecb0da..7733a4cdf525 100644 --- a/docs/ja/modules/gov/05_future_improvements.md +++ b/docs/ja/modules/gov/05_future_improvements.md @@ -1,26 +1,26 @@ -# Future Improvements +# 未来的改进 -The current documentation only describes the minimum viable product for the -governance module. Future improvements may include: +当前文档只描述了最小可行产品 +治理模块。未来的改进可能包括: -* **`BountyProposals`:** If accepted, a `BountyProposal` creates an open - bounty. The `BountyProposal` specifies how many Atoms will be given upon - completion. These Atoms will be taken from the `reserve pool`. After a - `BountyProposal` is accepted by governance, anybody can submit a - `SoftwareUpgradeProposal` with the code to claim the bounty. Note that once a - `BountyProposal` is accepted, the corresponding funds in the `reserve pool` - are locked so that payment can always be honored. In order to link a - `SoftwareUpgradeProposal` to an open bounty, the submitter of the - `SoftwareUpgradeProposal` will use the `Proposal.LinkedProposal` attribute. - If a `SoftwareUpgradeProposal` linked to an open bounty is accepted by - governance, the funds that were reserved are automatically transferred to the - submitter. -* **Complex delegation:** Delegators could choose other representatives than - their validators. Ultimately, the chain of representatives would always end - up to a validator, but delegators could inherit the vote of their chosen - representative before they inherit the vote of their validator. In other - words, they would only inherit the vote of their validator if their other - appointed representative did not vote. -* **Better process for proposal review:** There would be two parts to - `proposal.Deposit`, one for anti-spam (same as in MVP) and an other one to - reward third party auditors. +* **`BountyProposals`:** 如果接受，`BountyProposal` 创建一个开放的 + 赏金。 `BountyProposal` 指定将提供多少原子 + 完成。这些 Atom 将从“储备池”中取出。之后 + `BountyProposal` 被治理接受，任何人都可以提交 + `SoftwareUpgradeProposal` 和代码来领取赏金。请注意，一旦 + `BountyProposal`被接受，`reserve pool`中的相应资金 + 被锁定，以便始终可以兑现付款。为了链接一个 + `SoftwareUpgradeProposal` 到一个开放的赏金，提交者 + `SoftwareUpgradeProposal` 将使用 `Proposal.LinkedProposal` 属性。 + 如果链接到开放赏金的“SoftwareUpgradeProposal”被接受 + 治理，保留的资金将自动转移到 + 提交者。 +* **复杂的委托:** 委托人可以选择其他代表，而不是 + 他们的验证器。最终，代表链总会结束 + 由验证者决定，但委托人可以继承他们选择的投票 + 在他们继承验证人的投票之前。其他 + 换句话说，如果他们的其他人，他们只会继承他们的验证者的投票 + 指定代表没有投票。 +* **更好的提案审核流程:** 将分为两部分 + `proposal.Deposit`，一个用于反垃圾邮件(与 MVP 相同)，另一个用于 + 奖励第三方审计师。 \ No newline at end of file diff --git a/docs/ja/modules/gov/06_params.md b/docs/ja/modules/gov/06_params.md index 4fa2b5e1d455..2a02e92fe024 100644 --- a/docs/ja/modules/gov/06_params.md +++ b/docs/ja/modules/gov/06_params.md @@ -1,6 +1,6 @@ -# Parameters +# 参数 -The governance module contains the following parameters: +治理模块包含以下参数: | Key | Type | Example | |---------------|--------|----------------------------------------------------------------------------------------------------| diff --git a/docs/ja/modules/gov/07_client.md b/docs/ja/modules/gov/07_client.md index ca2ce8343317..5d7ee252ea81 100644 --- a/docs/ja/modules/gov/07_client.md +++ b/docs/ja/modules/gov/07_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `gov` module using the CLI. +用户可以使用 CLI 查询“gov”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `gov` state. +`query` 命令允许用户查询 `gov` 状态。 ```bash simd query gov --help @@ -14,7 +14,7 @@ simd query gov --help #### deposit -The `deposit` command allows users to query a deposit for a given proposal from a given depositor. +`deposit` 命令允许用户从给定存款人处查询给定提案的存款。 ```bash simd query gov deposit [proposal-id] [depositer-addr] [flags] diff --git a/docs/ja/modules/gov/README.md b/docs/ja/modules/gov/README.md index 6d0f5558338e..40111c562d0c 100644 --- a/docs/ja/modules/gov/README.md +++ b/docs/ja/modules/gov/README.md @@ -1,54 +1,54 @@ -# `gov` - -## Abstract - -This paper specifies the Governance module of the Cosmos-SDK, which was first -described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in -June 2016. - -The module enables Cosmos-SDK based blockchain to support an on-chain governance -system. In this system, holders of the native staking token of the chain can vote -on proposals on a 1 token 1 vote basis. Next is a list of features the module -currently supports: - -- **Proposal submission:** Users can submit proposals with a deposit. Once the -minimum deposit is reached, proposal enters voting period -- **Vote:** Participants can vote on proposals that reached MinDeposit -- **Inheritance and penalties:** Delegators inherit their validator's vote if -they don't vote themselves. -- **Claiming deposit:** Users that deposited on proposals can recover their -deposits if the proposal was accepted OR if the proposal never entered voting period. - -This module will be used in the Cosmos Hub, the first Hub in the Cosmos network. -Features that may be added in the future are described in [Future Improvements](05_future_improvements.md). - -## Contents - -The following specification uses *ATOM* as the native staking token. The module -can be adapted to any Proof-Of-Stake blockchain by replacing *ATOM* with the native -staking token of the chain. - -1. **[Concepts](01_concepts.md)** - - [Proposal submission](01_concepts.md#proposal-submission) - - [Vote](01_concepts.md#vote) - - [Software Upgrade](01_concepts.md#software-upgrade) -2. **[State](02_state.md)** - - [Parameters and base types](02_state.md#parameters-and-base-types) - - [Deposit](02_state.md#deposit) +# `政府` + +## 摘要 + +本文指定了 Cosmos-SDK 的 Governance 模块，它是第一个 +[Cosmos 白皮书](https://cosmos.network/about/whitepaper) 中的描述 +2016 年 6 月。 + +该模块使基于 Cosmos-SDK 的区块链能够支持链上治理 +系统。在这个系统中，链上原生质押代币的持有者可以投票 +在 1 代币 1 票基础上的提案。接下来是模块的功能列表 +目前支持: + +- **提案提交:** 用户可以通过存款提交提案。一旦 +达到最低存款，提案进入投票期 +- **投票:** 参与者可以对达到 MinDeposit 的提案进行投票 +- **继承和惩罚:** 委托人继承验证人的投票，如果 +他们不投票给自己。 +- **申领押金:** 对提案进行了押金的用户可以收回他们的 +如果提案被接受或提案从未进入投票期。 + +该模块将用于 Cosmos Hub，Cosmos 网络中的第一个 Hub。 +[未来改进](05_future_improvements.md) 中描述了将来可能添加的功能。 + +## 内容 + +以下规范使用 *ATOM* 作为本机 staking 代币。模块 +通过将 *ATOM* 替换为本机，可以适应任何权益证明区块链 +链的 staking 代币。 + +1. **[概念](01_concepts.md)** + - [提案提交](01_concepts.md#proposal-submission) + - [投票](01_concepts.md#vote) + - [软件升级](01_concepts.md#software-upgrade) +2. **[状态](02_state.md)** + - [参数和基本类型](02_state.md#parameters-and-base-types) + - [存款](02_state.md#deposit) - [ValidatorGovInfo](02_state.md#validatorgovinfo) - - [Proposals](02_state.md#proposals) - - [Stores](02_state.md#stores) - - [Proposal Processing Queue](02_state.md#proposal-processing-queue) -3. **[Messages](03_messages.md)** - - [Proposal Submission](03_messages.md#proposal-submission) - - [Deposit](03_messages.md#deposit) - - [Vote](03_messages.md#vote) -4. **[Events](04_events.md)** + - [提案](02_state.md#proposals) + - [存储](02_state.md#stores) + - [提案处理队列](02_state.md#proposal-processing-queue) +3. **[消息](03_messages.md)** + - [提案提交](03_messages.md#proposal-submission) + - [存款](03_messages.md#deposit) + - [投票](03_messages.md#vote) +4. **[事件](04_events.md)** - [EndBlocker](04_events.md#endblocker) - - [Handlers](04_events.md#handlers) -5. **[Future Improvements](05_future_improvements.md)** -6. **[Parameters](06_params.md)** -7. **[Client](07_client.md)** + - [处理程序](04_events.md#handlers) +5. **[未来改进](05_future_improvements.md)** +6. **[参数](06_params.md)** +7. **[客户端](07_client.md)** - [CLI](07_client.md#cli) - [gRPC](07_client.md#grpc) - - [REST](07_client.md#rest) + - [REST](07_client.md#rest) \ No newline at end of file diff --git a/docs/ja/modules/mint/01_concepts.md b/docs/ja/modules/mint/01_concepts.md index 05cdb279a0bd..704d5ff57219 100644 --- a/docs/ja/modules/mint/01_concepts.md +++ b/docs/ja/modules/mint/01_concepts.md @@ -1,24 +1,24 @@ -# Concepts +# 概念 -## The Minting Mechanism +## 铸币机制 -The minting mechanism was designed to: +铸造机制旨在: -- allow for a flexible inflation rate determined by market demand targeting a particular bonded-stake ratio -- effect a balance between market liquidity and staked supply +- 允许由市场需求决定的灵活通胀率针对特定的保税股份比率 +- 在市场流动性和抵押供应之间取得平衡 -In order to best determine the appropriate market rate for inflation rewards, a -moving change rate is used. The moving change rate mechanism ensures that if -the % bonded is either over or under the goal %-bonded, the inflation rate will -adjust to further incentivize or disincentivize being bonded, respectively. Setting the goal -%-bonded at less than 100% encourages the network to maintain some non-staked tokens -which should help provide some liquidity. +为了最好地确定通货膨胀奖励的适当市场利率， +使用移动变化率。移动变化率机制确保如果 +保税百分比高于或低于保税目标百分比，通货膨胀率将 +分别调整以进一步激励或不激励绑定。设定目标 +%-bonded 低于 100% 鼓励网络维护一些非抵押代币 +这应该有助于提供一些流动性。 -It can be broken down in the following way: +它可以通过以下方式分解: -- If the inflation rate is below the goal %-bonded the inflation rate will - increase until a maximum value is reached -- If the goal % bonded (67% in Cosmos-Hub) is maintained, then the inflation - rate will stay constant -- If the inflation rate is above the goal %-bonded the inflation rate will - decrease until a minimum value is reached +- 如果通胀率低于目标 %-bonded 通胀率将 + 增加直到达到最大值 +- 如果维持目标百分比(在 Cosmos-Hub 中为 67%)，则通货膨胀 + 率将保持不变 +- 如果通胀率高于目标 %-bonded 通胀率将 + 减少直到达到最小值 \ No newline at end of file diff --git a/docs/ja/modules/mint/02_state.md b/docs/ja/modules/mint/02_state.md index 438d6e328f7a..83a702e57b24 100644 --- a/docs/ja/modules/mint/02_state.md +++ b/docs/ja/modules/mint/02_state.md @@ -1,17 +1,17 @@ -# State +# 状态 -## Minter +##铸币厂 -The minter is a space for holding current inflation information. +铸币厂是保存当前通货膨胀信息的空间。 -- Minter: `0x00 -> ProtocolBuffer(minter)` +- 铸币厂:`0x00 -> ProtocolBuffer(铸币厂)` +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/mint/v1beta1/mint.proto#L8-L19 -## Params +## 参数 -Minting params are held in the global params store. +铸造参数保存在全局参数存储中。 -- Params: `mint/params -> legacy_amino(params)` +- 参数:`mint/params -> legacy_amino(params)` -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/mint/v1beta1/mint.proto#L21-L53 ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc7/proto/cosmos/mint/v1beta1/mint.proto#L21-L53 \ No newline at end of file diff --git a/docs/ja/modules/mint/03_begin_block.md b/docs/ja/modules/mint/03_begin_block.md index ac331f8b91c4..f2364dea996b 100644 --- a/docs/ja/modules/mint/03_begin_block.md +++ b/docs/ja/modules/mint/03_begin_block.md @@ -1,15 +1,15 @@ -# Begin-Block +# 开始块 -Minting parameters are recalculated and inflation -paid at the beginning of each block. +重新计算铸造参数和通货膨胀 +在每个区块的开始支付。 ## NextInflationRate -The target annual inflation rate is recalculated each block. -The inflation is also subject to a rate change (positive or negative) -depending on the distance from the desired ratio (67%). The maximum rate change -possible is defined to be 13% per year, however the annual inflation is capped -as between 7% and 20%. +每个区块都会重新计算目标年通胀率。 +通货膨胀也受利率变化(正或负)的影响 +取决于与所需比率 (67%) 的距离。 最大变化率 +可能定义为每年 13%，但年度通货膨胀率有上限 +在 7% 到 20% 之间。 ``` NextInflationRate(params Params, bondedRatio sdk.Dec) (inflation sdk.Dec) { @@ -31,8 +31,8 @@ NextInflationRate(params Params, bondedRatio sdk.Dec) (inflation sdk.Dec) { ## NextAnnualProvisions -Calculate the annual provisions based on current total supply and inflation -rate. This parameter is calculated once per block. +根据当前总供应量和通货膨胀计算年度准备金 +速度。 该参数每块计算一次。 ``` NextAnnualProvisions(params Params, totalSupply sdk.Dec) (provisions sdk.Dec) { @@ -41,7 +41,7 @@ NextAnnualProvisions(params Params, totalSupply sdk.Dec) (provisions sdk.Dec) { ## BlockProvision -Calculate the provisions generated for each block based on current annual provisions. The provisions are then minted by the `mint` module's `ModuleMinterAccount` and then transferred to the `auth`'s `FeeCollector` `ModuleAccount`. +根据当前年度准备金计算为每个区块生成的准备金。 然后这些规定由`mint` 模块的`ModuleMinterAccount` 铸造，然后转移到`auth` 的`FeeCollector` `ModuleAccount`。 ``` BlockProvision(params Params) sdk.Coin { diff --git a/docs/ja/modules/mint/04_params.md b/docs/ja/modules/mint/04_params.md index c743045e3846..1bb2e1a5f1bf 100644 --- a/docs/ja/modules/mint/04_params.md +++ b/docs/ja/modules/mint/04_params.md @@ -1,6 +1,6 @@ -# Parameters +# 参数 -The minting module contains the following parameters: +铸币模块包含以下参数: | Key | Type | Example | |---------------------|-----------------|------------------------| diff --git a/docs/ja/modules/mint/05_events.md b/docs/ja/modules/mint/05_events.md index a98d8db73d01..48e442e4e32f 100644 --- a/docs/ja/modules/mint/05_events.md +++ b/docs/ja/modules/mint/05_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The minting module emits the following events: +铸造模块发出以下事件: ## BeginBlocker diff --git a/docs/ja/modules/mint/06_client.md b/docs/ja/modules/mint/06_client.md index 73835c957bd9..e44bf3b3c16c 100644 --- a/docs/ja/modules/mint/06_client.md +++ b/docs/ja/modules/mint/06_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `mint` module using the CLI. +用户可以使用 CLI 查询“mint”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `mint` state. +`query` 命令允许用户查询 `mint` 状态。 ``` simd query mint --help diff --git a/docs/ja/modules/mint/README.md b/docs/ja/modules/mint/README.md index 06f37e33bef4..d898760f7933 100644 --- a/docs/ja/modules/mint/README.md +++ b/docs/ja/modules/mint/README.md @@ -1,19 +1,19 @@ -# `mint` +# `挖矿` -## Contents +## 内容 -1. **[Concept](01_concepts.md)** -2. **[State](02_state.md)** - - [Minter](02_state.md#minter) - - [Params](02_state.md#params) -3. **[Begin-Block](03_begin_block.md)** - - [NextInflationRate](03_begin_block.md#nextinflationrate) - - [NextAnnualProvisions](03_begin_block.md#nextannualprovisions) - - [BlockProvision](03_begin_block.md#blockprovision) -4. **[Parameters](04_params.md)** -5. **[Events](05_events.md)** - - [BeginBlocker](05_events.md#beginblocker) -6. **[Client](06_client.md)** - - [CLI](06_client.md#cli) - - [gRPC](06_client.md#grpc) - - [REST](06_client.md#rest) +1. **[概念](01_concepts.md)** +2. **[状态](02_state.md)** + - [铸币厂](02_state.md#铸币厂) + - [参数](02_state.md#params) +3. **[开始区块](03_begin_block.md)** + - [NextInflationRate](03_begin_block.md#nextinflationrate) + - [NextAnnualProvisions](03_begin_block.md#nextannualprovisions) + - [BlockProvision](03_begin_block.md#blockprovision) +4. **[参数](04_params.md)** +5. **[事件](05_events.md)** + - [BeginBlocker](05_events.md#beginblocker) +6. **[客户端](06_client.md)** + - [CLI](06_client.md#cli) + - [gRPC](06_client.md#grpc) + - [REST](06_client.md#rest) \ No newline at end of file diff --git a/docs/ja/modules/params/01_keeper.md b/docs/ja/modules/params/01_keeper.md index 5a830cd6be7a..65615c491c9c 100644 --- a/docs/ja/modules/params/01_keeper.md +++ b/docs/ja/modules/params/01_keeper.md @@ -1,7 +1,6 @@ -# Keeper - -In the app initialization stage, [subspaces](02_subspace.md) can be allocated for other modules' keeper using `Keeper.Subspace` and are stored in `Keeper.spaces`. Then, those modules can have a reference to their specific parameter store through `Keeper.GetSubspace`. +# 守门员 +在app初始化阶段，可以使用`Keeper.Subspace`为其他模块的keeper分配[subspaces](02_subspace.md)，并存储在`Keeper.spaces`中。 然后，这些模块可以通过 `Keeper.GetSubspace` 引用它们的特定参数存储。 Example: ```go diff --git a/docs/ja/modules/params/02_subspace.md b/docs/ja/modules/params/02_subspace.md index 316e1d63b673..528f79bb13fe 100644 --- a/docs/ja/modules/params/02_subspace.md +++ b/docs/ja/modules/params/02_subspace.md @@ -1,34 +1,34 @@ -# Subspace +# 子空间 -`Subspace` is a prefixed subspace of the parameter store. Each module which uses the -parameter store will take a `Subspace` to isolate permission to access. +`Subspace` 是参数存储的前缀子空间。每个模块使用 +参数存储将采用“子空间”来隔离访问权限。 -## Key +## 钥匙 -Parameter keys are human readable alphanumeric strings. A parameter for the key -`"ExampleParameter"` is stored under `[]byte("SubspaceName" + "/" + "ExampleParameter")`, - where `"SubspaceName"` is the name of the subspace. +参数键是人类可读的字母数字字符串。密钥的参数 +`"ExampleParameter"` 存储在 `[]byte("SubspaceName" + "/" + "ExampleParameter")` 下， +其中“SubspaceName”是子空间的名称。 -Subkeys are secondary parameter keys those are used along with a primary parameter key. -Subkeys can be used for grouping or dynamic parameter key generation during runtime. +子键是与主参数键一起使用的辅助参数键。 +子密钥可用于在运行时进行分组或动态参数密钥生成。 -## KeyTable +## 密钥表 -All of the parameter keys that will be used should be registered at the compile -time. `KeyTable` is essentially a `map[string]attribute`, where the `string` is a parameter key. +所有将使用的参数键都应该在编译时注册 +时间。 `KeyTable` 本质上是一个 `map[string]attribute`，其中 `string` 是一个参数键。 -Currently, `attribute` consists of a `reflect.Type`, which indicates the parameter -type to check that provided key and value are compatible and registered, as well as a function `ValueValidatorFn` to validate values. +目前，`attribute` 包含一个 `reflect.Type`，表示参数 +type 来检查提供的键和值是否兼容和注册，以及一个函数 `ValueValidatorFn` 来验证值。 -Only primary keys have to be registered on the `KeyTable`. Subkeys inherit the -attribute of the primary key. +只有主键必须在“KeyTable”上注册。子键继承 +主键的属性。 -## ParamSet +## 参数集 -Modules often define parameters as a proto message. The generated struct can implement -`ParamSet` interface to be used with the following methods: +模块通常将参数定义为 proto 消息。生成的结构体可以实现 +`ParamSet` 接口与以下方法一起使用: -* `KeyTable.RegisterParamSet()`: registers all parameters in the struct -* `Subspace.{Get, Set}ParamSet()`: Get to & Set from the struct +* `KeyTable.RegisterParamSet()`:注册结构体中的所有参数 +* `Subspace.{Get, Set}ParamSet()`:从结构体中获取和设置 -The implementor should be a pointer in order to use `GetParamSet()`. +为了使用`GetParamSet()`，实现者应该是一个指针。 \ No newline at end of file diff --git a/docs/ja/modules/params/README.md b/docs/ja/modules/params/README.md index 80a0de092c8a..a2c48d7bc677 100644 --- a/docs/ja/modules/params/README.md +++ b/docs/ja/modules/params/README.md @@ -1,22 +1,22 @@ -# `params` +# `参数` -## Abstract +## 摘要 -Package params provides a globally available parameter store. +包 params 提供了一个全局可用的参数存储。 -There are two main types, Keeper and Subspace. Subspace is an isolated namespace for a -paramstore, where keys are prefixed by preconfigured spacename. Keeper has a -permission to access all existing spaces. +有两种主要类型，Keeper 和 Subspace。 子空间是一个独立的命名空间 +paramstore，其中键以预配置的空间名称为前缀。 守门员有一个 +访问所有现有空间的权限。 -Subspace can be used by the individual keepers, which need a private parameter store -that the other keepers cannot modify. The params Keeper can be used to add a route to `x/gov` router in order to modify any parameter in case a proposal passes. +子空间可以由需要私有参数存储的个体守护者使用 +其他饲养员无法修改。 params Keeper 可用于向 `x/gov` 路由器添加路由，以便在提案通过时修改任何参数。 -The following contents explains how to use params module for master and user modules. +以下内容解释了如何将 params 模块用于 master 和 user 模块。 -## Contents +## 内容 1. **[Keeper](01_keeper.md)** -2. **[Subspace](02_subspace.md)** - - [Key](02_subspace.md#key) - - [KeyTable](02_subspace.md#keytable) - - [ParamSet](02_subspace.md#paramset) +2. **[子空间](02_subspace.md)** + - [密钥](02_subspace.md#key) + - [密钥表](02_subspace.md#keytable) + - [参数集](02_subspace.md#paramset) \ No newline at end of file diff --git a/docs/ja/modules/slashing/01_concepts.md b/docs/ja/modules/slashing/01_concepts.md index 46574d42aa2a..4caa6a5db410 100644 --- a/docs/ja/modules/slashing/01_concepts.md +++ b/docs/ja/modules/slashing/01_concepts.md @@ -1,33 +1,32 @@ -# Concepts +# 概念 -## States +## 状态 -At any given time, there are any number of validators registered in the state -machine. Each block, the top `MaxValidators` (defined by `x/staking`) validators -who are not jailed become _bonded_, meaning that they may propose and vote on -blocks. Validators who are _bonded_ are _at stake_, meaning that part or all of -their stake and their delegators' stake is at risk if they commit a protocol fault. +在任何给定时间，都有任意数量的验证器在该状态中注册 +机器。每个区块，顶部的 `MaxValidators`(由 `x/staking` 定义)验证器 +没有入狱的人成为 _bonded_，这意味着他们可以提议并投票 +块。 _bonded_ 的验证者是 _at stock_，这意味着部分或全部 +如果他们犯了协议错误，他们的利益和他们的委托人的利益就会面临风险。 -For each of these validators we keep a `ValidatorSigningInfo` record that contains -information partaining to validator's liveness and other infraction related -attributes. +对于这些验证器中的每一个，我们都保留了一个 `ValidatorSigningInfo` 记录，其中包含 +与验证者的活跃度和其他违规相关的信息 +属性。 -## Tombstone Caps +## 墓碑帽 -In order to mitigate the impact of initially likely categories of non-malicious -protocol faults, the Cosmos Hub implements for each validator -a _tombstone_ cap, which only allows a validator to be slashed once for a double -sign fault. For example, if you misconfigure your HSM and double-sign a bunch of -old blocks, you'll only be punished for the first double-sign (and then immediately tombstombed). This will still be quite expensive and desirable to avoid, but tombstone caps -somewhat blunt the economic impact of unintentional misconfiguration. +为了减轻最初可能的非恶意类别的影响 +协议错误，Cosmos Hub 为每个验证器实现 +_tombstone_ cap，它只允许验证器被削减一次以获得双倍 +签错。例如，如果您错误地配置了 HSM 并对一堆 +旧块，您只会因第一个双重标志而受到惩罚(然后立即被墓葬)。这仍然会非常昂贵并且需要避免，但是墓碑帽 +在某种程度上减弱了无意配置错误的经济影响。 -Liveness faults do not have caps, as they can't stack upon each other. Liveness bugs are "detected" as soon as the infraction occurs, and the validators are immediately put in jail, so it is not possible for them to commit multiple liveness faults without unjailing in between. +活性错误没有上限，因为它们不能相互叠加。一旦违规发生，活性错误就会被“检测到”，并且验证器会立即被关进监狱，因此他们不可能在没有释放的情况下犯下多个活性错误。 -## Infraction Timelines - -To illustrate how the `x/slashing` module handles submitted evidence through -Tendermint consensus, consider the following examples: +## 违规时间表 +为了说明 `x/slashing` 模块如何通过以下方式处理提交的证据 +Tendermint 共识，请考虑以下示例: **Definitions**: _[_ : timeline start @@ -42,14 +41,14 @@ _Vu_ : validator unbonded <-----------------> [----------C1----D1,Vu-----] -A single infraction is committed then later discovered, at which point the -validator is unbonded and slashed at the full amount for the infraction. +犯了一个单一的违规行为，然后被发现，此时 +验证器被解除绑定并因违规而被全额削减。 ### Multiple Double Sign Infractions <---------------------------> [----------C1--C2---C3---D1,D2,D3Vu-----] -Multiple infractions are committed and then later discovered, at which point the -validator is jailed and slashed for only one infraction. Because the validator -is also tombstoned, they can not rejoin the validator set. +犯下多次违规行为，然后被发现，此时 +验证者仅因一次违规而被判入狱并受到惩罚。 因为验证器 +也是墓碑，他们不能重新加入验证器集。 diff --git a/docs/ja/modules/slashing/02_state.md b/docs/ja/modules/slashing/02_state.md index 3f83a2acde17..cb46375a13f8 100644 --- a/docs/ja/modules/slashing/02_state.md +++ b/docs/ja/modules/slashing/02_state.md @@ -1,14 +1,14 @@ -# State +# 状态 -## Signing Info (Liveness) +## 签名信息(活力) -Every block includes a set of precommits by the validators for the previous block, -known as the `LastCommitInfo` provided by Tendermint. A `LastCommitInfo` is valid so -long as it contains precommits from +2/3 of total voting power. +每个区块都包含一组验证者对前一个区块的预提交， +称为 Tendermint 提供的“LastCommitInfo”。 `LastCommitInfo` 是有效的，所以 +只要它包含来自总投票权的 +2/3 的预提交。 -Proposers are incentivized to include precommits from all validators in the Tendermint `LastCommitInfo` -by receiving additional fees proportional to the difference between the voting -power included in the `LastCommitInfo` and +2/3 (see [fee distribution](x/distribution/spec/03_begin_block.md)). +提议者被激励在 Tendermint 的“LastCommitInfo”中包含来自所有验证者的预提交 +通过收取与投票之间的差异成比例的额外费用 +`LastCommitInfo` 和 +2/3 中包含的权力(参见 [费用分配](x/distribution/spec/03_begin_block.md))。 ``` type LastCommitInfo struct { @@ -17,31 +17,31 @@ type LastCommitInfo struct { } ``` -Validators are penalized for failing to be included in the `LastCommitInfo` for some -number of blocks by being automatically jailed, potentially slashed, and unbonded. +验证器因某些原因未能包含在“LastCommitInfo”中而受到惩罚 +通过被自动监禁、可能被削减和解除绑定来减少块的数量。 -Information about validator's liveness activity is tracked through `ValidatorSigningInfo`. -It is indexed in the store as follows: +有关验证器活跃度活动的信息通过“ValidatorSigningInfo”进行跟踪。 +它在存储中的索引如下: -- ValidatorSigningInfo: `0x01 | ConsAddrLen (1 byte) | ConsAddress -> ProtocolBuffer(ValSigningInfo)` -- MissedBlocksBitArray: `0x02 | ConsAddrLen (1 byte) | ConsAddress | LittleEndianUint64(signArrayIndex) -> VarInt(didMiss)` (varint is a number encoding format) +- ValidatorSigningInfo: `0x01 | ConsAddrLen (1 字节) | ConsAddress -> ProtocolBuffer(ValSigningInfo)` +- MissedBlocksBitArray:`0x02 | ConsAddrLen (1 字节) |约束地址 | LittleEndianUint64(signArrayIndex) -> VarInt(didMiss)`(varint 是一种数字编码格式) -The first mapping allows us to easily lookup the recent signing info for a -validator based on the validator's consensus address. +第一个映射允许我们轻松查找最近的签名信息 +验证者基于验证者的共识地址。 -The second mapping (`MissedBlocksBitArray`) acts -as a bit-array of size `SignedBlocksWindow` that tells us if the validator missed -the block for a given index in the bit-array. The index in the bit-array is given -as little endian uint64. -The result is a `varint` that takes on `0` or `1`, where `0` indicates the -validator did not miss (did sign) the corresponding block, and `1` indicates -they missed the block (did not sign). +第二个映射(`MissedBlocksBitArray`)作用 +作为一个大小为“SignedBlocksWindow”的位数组，它告诉我们验证器是否错过了 +位数组中给定索引的块。给出位数组中的索引 +作为小端 uint64。 +结果是一个 `varint` 取为 `0` 或 `1`，其中 `0` 表示 +验证器没有错过(确实签名)相应的块，并且`1`表示 +他们错过了街区(没有签名)。 -Note that the `MissedBlocksBitArray` is not explicitly initialized up-front. Keys -are added as we progress through the first `SignedBlocksWindow` blocks for a newly -bonded validator. The `SignedBlocksWindow` parameter defines the size -(number of blocks) of the sliding window used to track validator liveness. +请注意，“MissedBlocksBitArray”并未预先明确初始化。钥匙 +当我们通过第一个“SignedBlocksWindow”块进行新的 +绑定验证器。 `SignedBlocksWindow` 参数定义了大小 +(块数)用于跟踪验证器活跃度的滑动窗口。 -The information stored for tracking validator liveness is as follows: +存储的用于跟踪验证者活跃度的信息如下: -+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/slashing/v1beta1/slashing.proto#L11-L33 ++++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/slashing/v1beta1/slashing.proto#L11-L33 \ No newline at end of file diff --git a/docs/ja/modules/slashing/03_messages.md b/docs/ja/modules/slashing/03_messages.md index 02458c2c0ad2..2fbaed02e4b1 100644 --- a/docs/ja/modules/slashing/03_messages.md +++ b/docs/ja/modules/slashing/03_messages.md @@ -1,11 +1,11 @@ -# Messages +# 消息 -In this section we describe the processing of messages for the `slashing` module. +在本节中，我们描述了 `slashing` 模块的消息处理。 -## Unjail +## 出狱 -If a validator was automatically unbonded due to downtime and wishes to come back online & -possibly rejoin the bonded set, it must send `MsgUnjail`: +如果验证器因停机而自动解除绑定并希望重新上线& +可能重新加入绑定集，它必须发送`MsgUnjail`: ```protobuf // MsgUnjail is an sdk.Msg used for unjailing a jailed validator, thus returning @@ -16,7 +16,7 @@ message MsgUnjail { } ``` -Below is a pseudocode of the `MsgSrv/Unjail` RPC: +下面是 `MsgSrv/Unjail` RPC 的伪代码: ``` unjail(tx MsgUnjail) @@ -42,6 +42,6 @@ unjail(tx MsgUnjail) return ``` -If the validator has enough stake to be in the top `n = MaximumBondedValidators`, it will be automatically rebonded, -and all delegators still delegated to the validator will be rebonded and begin to again collect -provisions and rewards. +如果验证者有足够的股份进入顶部`n = MaximumBondedValidators`，它将自动重新绑定， +并且所有仍然委托给验证者的委托人将被重新绑定并开始再次收集 +规定和奖励。 \ No newline at end of file diff --git a/docs/ja/modules/slashing/04_begin_block.md b/docs/ja/modules/slashing/04_begin_block.md index 0a52a8ffde75..ccb4100b1495 100644 --- a/docs/ja/modules/slashing/04_begin_block.md +++ b/docs/ja/modules/slashing/04_begin_block.md @@ -1,25 +1,25 @@ -# BeginBlock - -## Liveness Tracking - -At the beginning of each block, we update the `ValidatorSigningInfo` for each -validator and check if they've crossed below the liveness threshold over a -sliding window. This sliding window is defined by `SignedBlocksWindow` and the -index in this window is determined by `IndexOffset` found in the validator's -`ValidatorSigningInfo`. For each block processed, the `IndexOffset` is incremented -regardless if the validator signed or not. Once the index is determined, the -`MissedBlocksBitArray` and `MissedBlocksCounter` are updated accordingly. - -Finally, in order to determine if a validator crosses below the liveness threshold, -we fetch the maximum number of blocks missed, `maxMissed`, which is -`SignedBlocksWindow - (MinSignedPerWindow * SignedBlocksWindow)` and the minimum -height at which we can determine liveness, `minHeight`. If the current block is -greater than `minHeight` and the validator's `MissedBlocksCounter` is greater than -`maxMissed`, they will be slashed by `SlashFractionDowntime`, will be jailed -for `DowntimeJailDuration`, and have the following values reset: -`MissedBlocksBitArray`, `MissedBlocksCounter`, and `IndexOffset`. - -**Note**: Liveness slashes do **NOT** lead to a tombstombing. +# 开始块 + +## 活性跟踪 + +在每个块的开始，我们更新每个块的“ValidatorSigningInfo” +验证器并检查它们是否超过了活跃度阈值 +滑动窗口。这个滑动窗口由`SignedBlocksWindow`和 +此窗口中的索引由验证器中的“IndexOffset”决定 +`验证器签名信息`。对于处理的每个块，“IndexOffset”递增 +无论验证者是否签名。指标确定后， +`MissedBlocksBitArray` 和 `MissedBlocksCounter` 相应更新。 + +最后，为了确定验证器是否低于活跃度阈值， +我们获取丢失的最大块数，`maxMissed`，即 +`SignedBlocksWindow - (MinSignedPerWindow * SignedBlocksWindow)` 和最小值 +我们可以确定活跃度的高度，`minHeight`。如果当前块是 +大于 `minHeight` 并且验证器的 `MissedBlocksCounter` 大于 +`maxMissed`，他们将被 `SlashFractionDowntime` 削减，将被监禁 +对于`DowntimeJailDuration`，并重置以下值: +`MissedBlocksBitArray`、`MissedBlocksCounter` 和 `IndexOffset`。 + +**注意**:活性斜线**不会**导致墓碑。 ```go height := block.Height diff --git a/docs/ja/modules/slashing/05_hooks.md b/docs/ja/modules/slashing/05_hooks.md index fd5934608af3..0b274ba1e167 100644 --- a/docs/ja/modules/slashing/05_hooks.md +++ b/docs/ja/modules/slashing/05_hooks.md @@ -1,21 +1,21 @@ -# Hooks +# 钩子 -This section contains a description of the module's `hooks`. Hooks are operations that are executed automatically when events are raised. +本节包含对模块`hooks` 的描述。 挂钩是在引发事件时自动执行的操作。 -## Staking hooks +## 放样钩子 -The slashing module implements the `StakingHooks` defined in `x/staking` and are used as record-keeping of validators information. During the app initialization, these hooks should be registered in the staking module struct. +slashing 模块实现了 `x/staking` 中定义的 `StakingHooks`，并用作验证者信息的记录保存。 在应用程序初始化期间，这些钩子应该在 staking 模块结构中注册。 -The following hooks impact the slashing state: +以下挂钩会影响 slashing 状态: -+ `AfterValidatorBonded` creates a `ValidatorSigningInfo` instance as described in the following section. -+ `AfterValidatorCreated` stores a validator's consensus key. -+ `AfterValidatorRemoved` removes a validator's consensus key. ++ `AfterValidatorBonded` 创建一个 `ValidatorSigningInfo` 实例，如下一节所述。 ++ `AfterValidatorCreated` 存储验证者的共识密钥。 ++ `AfterValidatorRemoved` 删除验证者的共识密钥。 -## Validator Bonded +## 验证者绑定 -Upon successful first-time bonding of a new validator, we create a new `ValidatorSigningInfo` structure for the -now-bonded validator, which `StartHeight` of the current block. +在成功首次绑定新验证器后，我们为 +现在绑定的验证器，当前块的“StartHeight”。 ``` onValidatorBonded(address sdk.ValAddress) diff --git a/docs/ja/modules/slashing/06_events.md b/docs/ja/modules/slashing/06_events.md index 345b13935fbd..bdc9afb9072a 100644 --- a/docs/ja/modules/slashing/06_events.md +++ b/docs/ja/modules/slashing/06_events.md @@ -1,7 +1,6 @@ -# Events - -The slashing module emits the following events: +# 事件 +slashing 模块发出以下事件: ## MsgServer ### MsgUnjail diff --git a/docs/ja/modules/slashing/07_tombstone.md b/docs/ja/modules/slashing/07_tombstone.md index f17b969cfbec..2d254f8fb404 100644 --- a/docs/ja/modules/slashing/07_tombstone.md +++ b/docs/ja/modules/slashing/07_tombstone.md @@ -1,123 +1,123 @@ -# Staking Tombstone - -## Abstract - -In the current implementation of the `slashing` module, when the consensus engine -informs the state machine of a validator's consensus fault, the validator is -partially slashed, and put into a "jail period", a period of time in which they -are not allowed to rejoin the validator set. However, because of the nature of -consensus faults and ABCI, there can be a delay between an infraction occurring, -and evidence of the infraction reaching the state machine (this is one of the -primary reasons for the existence of the unbonding period). - -> Note: The tombstone concept, only applies to faults that have a delay between -> the infraction occurring and evidence reaching the state machine. For example, -> evidence of a validator double signing may take a while to reach the state machine -> due to unpredictable evidence gossip layer delays and the ability of validators to -> selectively reveal double-signatures (e.g. to infrequently-online light clients). -> Liveness slashing, on the other hand, is detected immediately as soon as the -> infraction occurs, and therefore no slashing period is needed. A validator is -> immediately put into jail period, and they cannot commit another liveness fault -> until they unjail. In the future, there may be other types of byzantine faults -> that have delays (for example, submitting evidence of an invalid proposal as a transaction). -> When implemented, it will have to be decided whether these future types of -> byzantine faults will result in a tombstoning (and if not, the slash amounts -> will not be capped by a slashing period). - -In the current system design, once a validator is put in the jail for a consensus -fault, after the `JailPeriod` they are allowed to send a transaction to `unjail` -themselves, and thus rejoin the validator set. - -One of the "design desires" of the `slashing` module is that if multiple -infractions occur before evidence is executed (and a validator is put in jail), -they should only be punished for single worst infraction, but not cumulatively. -For example, if the sequence of events is: - -1. Validator A commits Infraction 1 (worth 30% slash) -2. Validator A commits Infraction 2 (worth 40% slash) -3. Validator A commits Infraction 3 (worth 35% slash) -4. Evidence for Infraction 1 reaches state machine (and validator is put in jail) -5. Evidence for Infraction 2 reaches state machine -6. Evidence for Infraction 3 reaches state machine - -Only Infraction 2 should have its slash take effect, as it is the highest. This -is done, so that in the case of the compromise of a validator's consensus key, -they will only be punished once, even if the hacker double-signs many blocks. -Because, the unjailing has to be done with the validator's operator key, they -have a chance to re-secure their consensus key, and then signal that they are -ready using their operator key. We call this period during which we track only -the max infraction, the "slashing period". - -Once, a validator rejoins by unjailing themselves, we begin a new slashing period; -if they commit a new infraction after unjailing, it gets slashed cumulatively on -top of the worst infraction from the previous slashing period. - -However, while infractions are grouped based off of the slashing periods, because -evidence can be submitted up to an `unbondingPeriod` after the infraction, we -still have to allow for evidence to be submitted for previous slashing periods. -For example, if the sequence of events is: - -1. Validator A commits Infraction 1 (worth 30% slash) -2. Validator A commits Infraction 2 (worth 40% slash) -3. Evidence for Infraction 1 reaches state machine (and Validator A is put in jail) -4. Validator A unjails - -We are now in a new slashing period, however we still have to keep the door open -for the previous infraction, as the evidence for Infraction 2 may still come in. -As the number of slashing periods increase, it creates more complexity as we have -to keep track of the highest infraction amount for every single slashing period. - -> Note: Currently, according to the `slashing` module spec, a new slashing period -> is created every time a validator is unbonded then rebonded. This should probably -> be changed to jailed/unjailed. See issue [#3205](https://github.com/cosmos/cosmos-sdk/issues/3205) -> for further details. For the remainder of this, I will assume that we only start -> a new slashing period when a validator gets unjailed. - -The maximum number of slashing periods is the `len(UnbondingPeriod) / len(JailPeriod)`. -The current defaults in Gaia for the `UnbondingPeriod` and `JailPeriod` are 3 weeks -and 2 days, respectively. This means there could potentially be up to 11 slashing -periods concurrently being tracked per validator. If we set the `JailPeriod >= UnbondingPeriod`, -we only have to track 1 slashing period (i.e not have to track slashing periods). - -Currently, in the jail period implementation, once a validator unjails, all of -their delegators who are delegated to them (haven't unbonded / redelegated away), -stay with them. Given that consensus safety faults are so egregious -(way more so than liveness faults), it is probably prudent to have delegators not -"auto-rebond" to the validator. - -### Proposal: infinite jail - -We propose setting the "jail time" for a -validator who commits a consensus safety fault, to `infinite` (i.e. a tombstone state). -This essentially kicks the validator out of the validator set and does not allow -them to re-enter the validator set. All of their delegators (including the operator themselves) -have to either unbond or redelegate away. The validator operator can create a new -validator if they would like, with a new operator key and consensus key, but they -have to "re-earn" their delegations back. - -Implementing the tombstone system and getting rid of the slashing period tracking -will make the `slashing` module way simpler, especially because we can remove all -of the hooks defined in the `slashing` module consumed by the `staking` module -(the `slashing` module still consumes hooks defined in `staking`). - -### Single slashing amount - -Another optimization that can be made is that if we assume that all ABCI faults -for Tendermint consensus are slashed at the same level, we don't have to keep -track of "max slash". Once an ABCI fault happens, we don't have to worry about -comparing potential future ones to find the max. - -Currently the only Tendermint ABCI fault is: - -- Unjustified precommits (double signs) - -It is currently planned to include the following fault in the near future: - -- Signing a precommit when you're in unbonding phase (needed to make light client bisection safe) - -Given that these faults are both attributable byzantine faults, we will likely -want to slash them equally, and thus we can enact the above change. - -> Note: This change may make sense for current Tendermint consensus, but maybe -> not for a different consensus algorithm or future versions of Tendermint that -> may want to punish at different levels (for example, partial slashing). +# 放样墓碑 + +## 摘要 + +在当前的 `slashing` 模块实现中，当共识引擎 +通知状态机验证者的共识错误，验证者是 +部分削减，并进入“监禁期”，在一段时间内，他们 +不允许重新加入验证器集。但是，由于性质 +共识错误和 ABCI，在发生违规之间可能会有延迟， +以及违规到达状态机的证据(这是其中之一 +解绑期存在的主要原因)。 + +> 注意:tombstone 概念，仅适用于有延迟的故障 +> 发生的违规行为和到达状态机的证据。例如， +> 验证者双重签名的证据可能需要一段时间才能到达状态机 +> 由于不可预测的证据八卦层延迟和验证者的能力 +> 选择性地显示双重签名(例如，对不常在线的轻客户端)。 +> 另一方面，一旦出现活跃度削减，就会立即检测到 +> 发生违规，因此不需要削减期。验证器是 +> 立即入狱，不能再犯活体过错 +> 直到他们出狱。未来可能还会出现其他类型的拜占庭断层 +> 有延迟(例如，提交无效提案的证据作为交易)。 +> 在实施时，必须决定这些未来类型的 +> 拜占庭故障将导致墓碑(如果没有，斜线数量 +> 不会受到削减期的限制)。 + +在目前的系统设计中，一旦验证者被投入监狱以达成共识 +错误，在“JailPeriod”之后，他们被允许向“unjail”发送交易 +自己，从而重新加入验证器集。 + +`slashing` 模块的“设计愿望”之一是，如果多个 +在执行证据之前发生违规(并且验证者被投入监狱)， +他们应该只因一次最严重的违规行为而受到惩罚，而不是累积。 +例如，如果事件序列是: + +1. 验证者 A 提交违规 1(价值 30% 斜线) +2. 验证者 A 提交违规 2(价值 40% 斜线) +3. 验证者 A 提交违规 3(价值 35% 斜线) +4. 违规 1 的证据到达状态机(验证者被关进监狱) +5. 违规 2 的证据到达状态机 +6. 违规 3 的证据到达状态机 + +只有违规 2 应使其斜线生效，因为它是最高的。这 +完成，以便在验证者的共识密钥妥协的情况下， +即使黑客对许多块进行双重签名，他们也只会受到一次惩罚。 +因为，解禁必须使用验证器的操作员密钥来完成，他们 +有机会重新保护他们的共识密钥，然后表明他们是 +准备好使用他们的操作员密钥。我们将这段时间称为仅跟踪 +最大的违规，“削减期”。 + +一旦验证者通过出狱重新加入，我们就开始了新的削减期； +如果他们在出狱后犯下新的违规行为，它将被累计削减 +上一罚单期间最严重的违规行为的顶部。 + +然而，虽然违规行为是根据惩罚期进行分组的，因为 +证据可以在违规后提交至‘unbondingPeriod’，我们 +仍然必须允许提交先前削减期的证据。 +例如，如果事件序列是: + +1. 验证者 A 提交违规 1(价值 30% 斜线) +2. 验证者 A 提交违规 2(价值 40% 斜线) +3. 违规 1 的证据到达状态机(并且验证者 A 被关进监狱) +4. 验证者 A 出狱 + +我们现在处于新的削减期，但我们仍然要保持敞开大门 +对于之前的违规行为，因为违规行为 2 的证据可能仍然存在。 +随着削减周期数量的增加，它会产生更多的复杂性，因为我们有 +跟踪每个罚单期间的最高违规金额。 + +> 注意:目前，根据`slashing`模块规范，一个新的slashing period +> 每次验证器解除绑定然后重新绑定时都会创建。这大概应该 +> 更改为监禁/未监禁。见问题 [#3205](https://github.com/cosmos/cosmos-sdk/issues/3205) +> 了解更多详情。对于剩下的部分，我将假设我们只开始 +> 当验证者被释放时，一个新的削减期。 + +slashing period 的最大数量是`len(UnbondingPeriod) / len(JailPeriod)`。 +当前 Gaia 中 `UnbondingPeriod` 和 `JailPeriod` 的默认值为 3 周 +和 2 天，分别。这意味着可能会有多达 11 次削减 +每个验证器同时跟踪的时间段。如果我们设置`JailPeriod >= UnbondingPeriod`， +我们只需要跟踪 1 个削减期(即不必跟踪削减期)。 + +目前，在监狱期间的实施中，一旦验证人出狱，所有的 +委派给他们的委派人(尚未解除绑定/重新委派)， +和他们在一起。鉴于共识安全错误如此严重 +(比活性错误更重要)，让委托人不 +“自动重新绑定”到验证器。 + +### 提案:无限监狱 + +我们建议为一个人设定“监禁时间” +提交共识安全错误的验证者，到“无限”(即墓碑状态)。 +这实质上是将验证器踢出验证器集并且不允许 +他们重新进入验证器集。他们所有的委托人(包括运营商自己) +必须解除绑定或重新授权。验证器操作员可以创建一个新的 +验证器，如果他们愿意，可以使用新的操作员密钥和共识密钥，但他们 +必须“重新赚回”他们的代表团。 + +实施墓碑制度，摆脱砍价期跟踪 +将使 `slashing` 模块的方式更简单，特别是因为我们可以删除所有 +`staking` 模块使用的 `slashing` 模块中定义的钩子 +(`slashing` 模块仍然使用 `staking` 中定义的钩子)。 + +### 单次削减金额 + +另一个可以进行的优化是，如果我们假设所有 ABCI 故障 +因为 Tendermint 共识被削减在同一水平，我们不必保持 +跟踪“最大斜线”。一旦发生ABCI故障，我们就不必担心 +比较潜在的未来以找到最大值。 + +目前唯一的 Tendermint ABCI 故障是: + +- 不合理的预提交(双重符号) + +目前计划在不久的将来包括以下故障: + +- 在解除绑定阶段签署预提交(需要使轻客户端二分安全) + +鉴于这些故障都是拜占庭故障，我们很可能会 +想要平等地削减它们，因此我们可以制定上述更改。 + +> 注意:此更改可能对当前的 Tendermint 共识有意义，但也许 +> 不适用于不同的共识算法或 Tendermint 的未来版本 +> 可能要进行不同级别的惩罚(例如，部分削减)。 \ No newline at end of file diff --git a/docs/ja/modules/slashing/08_params.md b/docs/ja/modules/slashing/08_params.md index dfd9b88341bc..0de08763ef96 100644 --- a/docs/ja/modules/slashing/08_params.md +++ b/docs/ja/modules/slashing/08_params.md @@ -1,6 +1,6 @@ -# Parameters +# 参数 -The slashing module contains the following parameters: +slashing 模块包含以下参数: | Key | Type | Example | | ----------------------- | -------------- | ---------------------- | diff --git a/docs/ja/modules/slashing/09_client.md b/docs/ja/modules/slashing/09_client.md index c07cbc8805d0..2264c0d59d4a 100644 --- a/docs/ja/modules/slashing/09_client.md +++ b/docs/ja/modules/slashing/09_client.md @@ -1,10 +1,10 @@ -# CLI +# 命令行界面 -A user can query and interact with the `slashing` module using the CLI. +用户可以使用 CLI 查询“slashing”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `slashing` state. +`query` 命令允许用户查询 `slashing` 状态。 ```bash simd query slashing --help diff --git a/docs/ja/modules/slashing/README.md b/docs/ja/modules/slashing/README.md index b2fb4c79abdb..4aee41090a39 100644 --- a/docs/ja/modules/slashing/README.md +++ b/docs/ja/modules/slashing/README.md @@ -1,42 +1,42 @@ -# `x/slashing` +# `x/斜线` -## Abstract +## 摘要 -This section specifies the slashing module of the Cosmos SDK, which implements functionality -first outlined in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) in June 2016. +本节指定Cosmos SDK的slashing模块，实现功能 +2016 年 6 月在 [Cosmos 白皮书](https://cosmos.network/about/whitepaper) 中首次概述。 -The slashing module enables Cosmos SDK-based blockchains to disincentivize any attributable action -by a protocol-recognized actor with value at stake by penalizing them ("slashing"). +slashing 模块使基于 Cosmos SDK 的区块链能够抑制任何可归因的行为 +由协议认可的行为者通过惩罚他们(“削减”)而将价值置于危险之中。 -Penalties may include, but are not limited to: +处罚可能包括但不限于: -- Burning some amount of their stake -- Removing their ability to vote on future blocks for a period of time. +- 烧掉他们的一些股份 +- 取消他们在一段时间内对未来区块进行投票的能力。 -This module will be used by the Cosmos Hub, the first hub in the Cosmos ecosystem. +该模块将由 Cosmos Hub(Cosmos 生态系统中的第一个枢纽)使用。 -## Contents +## 内容 -1. **[Concepts](01_concepts.md)** - - [States](01_concepts.md#states) - - [Tombstone Caps](01_concepts.md#tombstone-caps) - - [ASCII timelines](01_concepts.md#ascii-timelines) -2. **[State](02_state.md)** - - [Signing Info](02_state.md#signing-info) -3. **[Messages](03_messages.md)** - - [Unjail](03_messages.md#unjail) -4. **[Begin-Block](04_begin_block.md)** - - [Evidence handling](04_begin_block.md#evidence-handling) - - [Uptime tracking](04_begin_block.md#uptime-tracking) +1. **[概念](01_concepts.md)** + - [状态](01_concepts.md#states) + - [墓碑帽](01_concepts.md#tombstone-caps) + - [ASCII 时间线](01_concepts.md#ascii-timelines) +2. **[状态](02_state.md)** + - [签名信息](02_state.md#signing-info) +3. **[消息](03_messages.md)** + - [出狱](03_messages.md#unjail) +4. **[开始区块](04_begin_block.md)** + - [证据处理](04_begin_block.md#evidence-handling) + - [正常运行时间跟踪](04_begin_block.md#uptime-tracking) 5. **[05_hooks.md](05_hooks.md)** - - [Hooks](05_hooks.md#hooks) -6. **[Events](06_events.md)** + - [钩子](05_hooks.md#hooks) +6. **[事件](06_events.md)** - [BeginBlocker](06_events.md#beginblocker) - - [Handlers](06_events.md#handlers) + - [处理程序](06_events.md#handlers) 7. **[Staking Tombstone](07_tombstone.md)** - - [Abstract](07_tombstone.md#abstract) -8. **[Parameters](08_params.md)** -9. **[Client](09_client.md)** + - [摘要](07_tombstone.md#abstract) +8. **[参数](08_params.md)** +9. **[客户端](09_client.md)** - [CLI](09_client.md#cli) - [gRPC](09_client.md#grpc) - - [REST](09_client.md#rest) + - [REST](09_client.md#rest) \ No newline at end of file diff --git a/docs/ja/modules/staking/01_state.md b/docs/ja/modules/staking/01_state.md index e611a4729dc9..8f51d9b3bd1a 100644 --- a/docs/ja/modules/staking/01_state.md +++ b/docs/ja/modules/staking/01_state.md @@ -1,213 +1,213 @@ -# State +# 状态 -## Pool +## 水池 -Pool is used for tracking bonded and not-bonded token supply of the bond denomination. +池用于跟踪债券面额的保税和非保税代币供应。 ## LastTotalPower -LastTotalPower tracks the total amounts of bonded tokens recorded during the previous end block. -Store entries prefixed with "Last" must remain unchanged until EndBlock. +LastTotalPower 跟踪在前一个结束块期间记录的绑定令牌总量。 +以“Last”为前缀的存储条目必须保持不变，直到 EndBlock。 - LastTotalPower: `0x12 -> ProtocolBuffer(sdk.Int)` -## Params +## 参数 -Params is a module-wide configuration structure that stores system parameters -and defines overall functioning of the staking module. +params 是一个模块范围的配置结构，用于存储系统参数 +并定义了 staking 模块的整体功能。 -- Params: `Paramsspace("staking") -> legacy_amino(params)` +- 参数:`Paramsspace("staking") -> legacy_amino(params)` +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.1/proto/cosmos/staking/v1beta1/staking.proto#L230-L241 -## Validator - -Validators can have one of three statuses - -- `Unbonded`: The validator is not in the active set. They cannot sign blocks and do not earn - rewards. They can receive delegations. -- `Bonded`": Once the validator receives sufficient bonded tokens they automtically join the - active set during [`EndBlock`](./05_end_block.md#validator-set-changes) and their status is updated to `Bonded`. - They are signing blocks and receiving rewards. They can receive further delegations. - They can be slashed for misbehavior. Delegators to this validator who unbond their delegation - must wait the duration of the UnbondingTime, a chain-specific param, during which time - they are still slashable for offences of the source validator if those offences were committed - during the period of time that the tokens were bonded. -- `Unbonding`: When a validator leaves the active set, either by choice or due to slashing, jailing or - tombstoning, an unbonding of all their delegations begins. All delegations must then wait the UnbondingTime - before their tokens are moved to their accounts from the `BondedPool`. - -Validators objects should be primarily stored and accessed by the -`OperatorAddr`, an SDK validator address for the operator of the validator. Two -additional indices are maintained per validator object in order to fulfill -required lookups for slashing and validator-set updates. A third special index -(`LastValidatorPower`) is also maintained which however remains constant -throughout each block, unlike the first two indices which mirror the validator -records within a block. - -- Validators: `0x21 | OperatorAddrLen (1 byte) | OperatorAddr -> ProtocolBuffer(validator)` -- ValidatorsByConsAddr: `0x22 | ConsAddrLen (1 byte) | ConsAddr -> OperatorAddr` -- ValidatorsByPower: `0x23 | BigEndian(ConsensusPower) | OperatorAddrLen (1 byte) | OperatorAddr -> OperatorAddr` -- LastValidatorsPower: `0x11 | OperatorAddrLen (1 byte) | OperatorAddr -> ProtocolBuffer(ConsensusPower)` - -`Validators` is the primary index - it ensures that each operator can have only one -associated validator, where the public key of that validator can change in the -future. Delegators can refer to the immutable operator of the validator, without -concern for the changing public key. - -`ValidatorByConsAddr` is an additional index that enables lookups for slashing. -When Tendermint reports evidence, it provides the validator address, so this -map is needed to find the operator. Note that the `ConsAddr` corresponds to the -address which can be derived from the validator's `ConsPubKey`. - -`ValidatorsByPower` is an additional index that provides a sorted list of -potential validators to quickly determine the current active set. Here -ConsensusPower is validator.Tokens/10^6 by default. Note that all validators -where `Jailed` is true are not stored within this index. - -`LastValidatorsPower` is a special index that provides a historical list of the -last-block's bonded validators. This index remains constant during a block but -is updated during the validator set update process which takes place in [`EndBlock`](./05_end_block.md). - -Each validator's state is stored in a `Validator` struct: +## 验证器 + +验证器可以具有以下三种状态之一 + +- `Unbonded`:验证器不在活动集中。他们不能签署区块，也不能赚取 + 奖励。他们可以接待代表团。 +- `Bonded`":一旦验证器收到足够的绑定代币，他们就会自动加入 + [`EndBlock`](./05_end_block.md#validator-set-changes) 期间的活动集，并且它们的状态更新为“已绑定”。 + 他们正在签署区块并获得奖励。他们可以接待更多的代表团。 + 他们可能会因不当行为而受到惩罚。解除其委托的该验证者的委托人 + 必须等待 UnbondingTime 的持续时间，一个特定于链的参数，在此期间 + 如果犯下这些罪行，它们仍然可以因源验证器的罪行而受到惩罚 + 在代币被绑定的时间段内。 +- `Unbonding`:当验证者离开活动集时，无论是出于选择还是由于削减、监禁或 + 墓碑，开始解除他们所有代表团的束缚。然后所有代表团必须等待 UnbondingTime + 在他们的代币从“BondedPool”转移到他们的账户之前。 + +验证器对象应该主要由 +`OperatorAddr`，验证者操作者的 SDK 验证者地址。二 +每个验证器对象维护额外的索引，以实现 +削减和验证器集更新所需的查找。第三个特殊索引 +(`LastValidatorPower`) 也保持不变，但保持不变 +在每个区块中，与反映验证者的前两个​​索引不同 +块内的记录。 + +- 验证器:`0x21 | OperatorAddrLen (1 字节) | OperatorAddr -> ProtocolBuffer(validator)` +- ValidatorsByConsAddr: `0x22 | ConsAddrLen (1 字节) | ConsAddr -> OperatorAddr` +- ValidatorsByPower:`0x23 | BigEndian(ConsensusPower) | OperatorAddrLen (1 字节) | OperatorAddr -> OperatorAddr` +- LastValidatorsPower:`0x11 | OperatorAddrLen (1 字节) | OperatorAddr -> ProtocolBuffer(ConsensusPower)` + +`Validators` 是主要索引 - 它确保每个操作符只能有一个 +关联的验证器，该验证器的公钥可以在 +未来。委托人可以引用验证人的不可变操作符，无需 +关注不断变化的公钥。 + +`ValidatorByConsAddr` 是一个额外的索引，可以进行斜线查找。 +Tendermint 上报证据时，会提供验证人地址，所以这个 +需要 map 才能找到操作符。请注意，`ConsAddr` 对应于 +可以从验证器的“ConsPubKey”派生的地址。 + +`ValidatorsByPower` 是一个额外的索引，它提供了一个排序列表 +潜在的验证器来快速确定当前的活动集。这里 +默认情况下，ConsensusPower 是 validator.Tokens/10^6。请注意，所有验证器 +`Jailed` 为 true 的地方不存储在这个索引中。 + +`LastValidatorsPower` 是一个特殊的索引，它提供了历史列表 +最后一个区块的绑定验证器。该索引在块期间保持不变，但 +在 [`EndBlock`](./05_end_block.md) 中发生的验证器集更新过程中更新。 + +每个验证器的状态都存储在一个“验证器”结构中: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L65-L99 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L24-L63 -## Delegation +## 代表团 -Delegations are identified by combining `DelegatorAddr` (the address of the delegator) -with the `ValidatorAddr` Delegators are indexed in the store as follows: +委托通过结合`DelegatorAddr`(委托人的地址)来识别 +使用 `ValidatorAddr` 委托人在存储中被索引如下: -- Delegation: `0x31 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorAddr -> ProtocolBuffer(delegation)` +- 委托:`0x31 | DelegatorAddrLen (1 字节) |委托人地址 | ValidatorAddrLen(1 字节)| ValidatorAddr -> ProtocolBuffer(delegation)` -Stake holders may delegate coins to validators; under this circumstance their -funds are held in a `Delegation` data structure. It is owned by one -delegator, and is associated with the shares for one validator. The sender of -the transaction is the owner of the bond. +利益相关者可以将硬币委托给验证者；在这种情况下他们的 +资金保存在“委托”数据结构中。它归一个人所有 +委托人，并与一个验证人的份额相关联。发件人 +交易是债券的所有者。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L159-L170 -### Delegator Shares +### 委托人股份 -When one Delegates tokens to a Validator they are issued a number of delegator shares based on a -dynamic exchange rate, calculated as follows from the total number of tokens delegated to the -validator and the number of shares issued so far: +当一个人将代币委托给验证者时，他们会根据 +动态汇率，根据委托给代币的代币总数计算如下 +验证器和迄今为止发行的股票数量: -`Shares per Token = validator.TotalShares() / validator.Tokens()` +`每个令牌的份额 = validator.TotalShares() / validator.Tokens()` -Only the number of shares received is stored on the DelegationEntry. When a delegator then -Undelegates, the token amount they receive is calculated from the number of shares they currently -hold and the inverse exchange rate: +仅收到的股份数量存储在委托条目中。当委托人然后 +Undelegates，他们收到的代币数量是根据他们当前的股份数量计算的 +持有和反向汇率: -`Tokens per Share = validator.Tokens() / validatorShares()` +`每股代币数 = validator.Tokens() / validatorShares()` -These `Shares` are simply an accounting mechanism. They are not a fungible asset. The reason for -this mechanism is to simplify the accounting around slashing. Rather than iteratively slashing the -tokens of every delegation entry, instead the Validators total bonded tokens can be slashed, -effectively reducing the value of each issued delegator share. +这些“股份”只是一种会计机制。它们不是可替代的资产。的原因 +这种机制是为了简化围绕削减的核算。而不是反复削减 +每个委托条目的代币，而不是验证者的总绑定代币可以被削减， +有效地降低了每份已发行的委托人股份的价值。 -## UnbondingDelegation +## 解除绑定委托 -Shares in a `Delegation` can be unbonded, but they must for some time exist as -an `UnbondingDelegation`, where shares can be reduced if Byzantine behavior is -detected. +“委托”中的股份可以不绑定，但它们必须存在一段时间 +一个“UnbondingDelegation”，如果拜占庭行为是可以减少的 +检测到。 -`UnbondingDelegation` are indexed in the store as: +`UnbondingDelegation` 在存储中被索引为: -- UnbondingDelegation: `0x32 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorAddr -> ProtocolBuffer(unbondingDelegation)` -- UnbondingDelegationsFromValidator: `0x33 | ValidatorAddrLen (1 byte) | ValidatorAddr | DelegatorAddrLen (1 byte) | DelegatorAddr -> nil` +- 解除绑定委托:`0x32 | DelegatorAddrLen (1 字节) |委托人地址 | ValidatorAddrLen(1 字节)| ValidatorAddr -> ProtocolBuffer(unbondingDelegation)` +- UnbondingDelegationsFromValidator:`0x33 | ValidatorAddrLen(1 字节)|验证器地址 | DelegatorAddrLen (1 字节) | DelegatorAddr -> nil` -The first map here is used in queries, to lookup all unbonding delegations for -a given delegator, while the second map is used in slashing, to lookup all -unbonding delegations associated with a given validator that need to be -slashed. +此处的第一张地图用于查询，以查找所有未绑定的委托 +给定的委托人，而第二张地图用于斜线，以查找所有 +与给定验证器关联的解除绑定委托需要 +削减。 -A UnbondingDelegation object is created every time an unbonding is initiated. +每次启动解除绑定时都会创建一个 UnbondingDelegation 对象。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L172-L198 -## Redelegation +## 重新授权 -The bonded tokens worth of a `Delegation` may be instantly redelegated from a -source validator to a different validator (destination validator). However when -this occurs they must be tracked in a `Redelegation` object, whereby their -shares can be slashed if their tokens have contributed to a Byzantine fault -committed by the source validator. +价值“委托”的保税代币可以立即从 +源验证器到不同的验证器(目标验证器)。然而当 +发生这种情况时，他们必须在“重新委托”对象中进行跟踪，从而他们的 +如果他们的代币导致了拜占庭故障，则可以削减股票 +由源验证器提交。 -`Redelegation` are indexed in the store as: +`Redelegation` 在存储中被索引为: -- Redelegations: `0x34 | DelegatorAddrLen (1 byte) | DelegatorAddr | ValidatorAddrLen (1 byte) | ValidatorSrcAddr | ValidatorDstAddr -> ProtocolBuffer(redelegation)` -- RedelegationsBySrc: `0x35 | ValidatorSrcAddrLen (1 byte) | ValidatorSrcAddr | ValidatorDstAddrLen (1 byte) | ValidatorDstAddr | DelegatorAddrLen (1 byte) | DelegatorAddr -> nil` -- RedelegationsByDst: `0x36 | ValidatorDstAddrLen (1 byte) | ValidatorDstAddr | ValidatorSrcAddrLen (1 byte) | ValidatorSrcAddr | DelegatorAddrLen (1 byte) | DelegatorAddr -> nil` +- 重新委托:`0x34 | DelegatorAddrLen (1 字节) |委托人地址 | ValidatorAddrLen(1 字节)| ValidatorSrcAddr | ValidatorDstAddr -> ProtocolBuffer(redelegation)` +- RedelelegationsBySrc:`0x35 | ValidatorSrcAddrLen(1 字节)| ValidatorSrcAddr | ValidatorDstAddrLen(1 字节)| ValidatorDstAddr | DelegatorAddrLen (1 字节) | DelegatorAddr -> nil` +- RedelelegationsByDst:`0x36 | ValidatorDstAddrLen(1 字节)| ValidatorDstAddr | ValidatorSrcAddrLen(1 字节)| ValidatorSrcAddr | DelegatorAddrLen (1 字节) | DelegatorAddr -> nil` -The first map here is used for queries, to lookup all redelegations for a given -delegator. The second map is used for slashing based on the `ValidatorSrcAddr`, -while the third map is for slashing based on the `ValidatorDstAddr`. +此处的第一张地图用于查询，以查找给定的所有重新授权 +委托人。第二个地图用于基于`ValidatorSrcAddr`的斜线， +而第三张地图用于基于`ValidatorDstAddr`的削减。 -A redelegation object is created every time a redelegation occurs. To prevent -"redelegation hopping" redelegations may not occur under the situation that: +每次重新委派发生时都会创建一个重新委派对象。阻止 +在以下情况下可能不会发生“重新授权跳跃”重新授权: -- the (re)delegator already has another immature redelegation in progress - with a destination to a validator (let's call it `Validator X`) -- and, the (re)delegator is attempting to create a _new_ redelegation - where the source validator for this new redelegation is `Validator X`. +-(重新)委托人已经有另一个不成熟的重新委托正在进行中 + 带有验证器的目的地(我们称之为“验证器 X”) +- 并且，(重新)委托人正在尝试创建_新_重新委托 + 这个新的重新授权的源验证器是“Validator X”。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L200-L228 -## Queues +## 队列 -All queues objects are sorted by timestamp. The time used within any queue is -first rounded to the nearest nanosecond then sorted. The sortable time format -used is a slight modification of the RFC3339Nano and uses the the format string -`"2006-01-02T15:04:05.000000000"`. Notably this format: +所有队列对象都按时间戳排序。任何队列中使用的时间是 +首先四舍五入到最接近的纳秒然后排序。可排序的时间格式 +used 是对 RFC3339Nano 的轻微修改并使用格式字符串 +`"2006-01-02T15:04:05.000000000"`。特别是这种格式: -- right pads all zeros -- drops the time zone info (uses UTC) +- 右填充全零 +- 删除时区信息(使用 UTC) -In all cases, the stored timestamp represents the maturation time of the queue -element. +在所有情况下，存储的时间戳代表队列的成熟时间 +元素。 ### UnbondingDelegationQueue -For the purpose of tracking progress of unbonding delegations the unbonding -delegations queue is kept. +为了跟踪解绑授权的进展，解绑授权 +保留代表团队列。 -- UnbondingDelegation: `0x41 | format(time) -> []DVPair` +- 解除绑定委托:`0x41 |格式(时间)-> []DVPair` +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L123-L133 -### RedelegationQueue +### 重新授权队列 -For the purpose of tracking progress of redelegations the redelegation queue is -kept. +为了跟踪重新授权的进度，重新授权队列是 +保留。 -- RedelegationQueue: `0x42 | format(time) -> []DVVTriplet` +- 重新委托队列:`0x42 |格式(时间)-> []DVVTriplet` +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L140-L152 -### ValidatorQueue +### 验证器队列 -For the purpose of tracking progress of unbonding validators the validator -queue is kept. +为了跟踪解除绑定验证器的进度，验证器 +队列被保留。 -- ValidatorQueueTime: `0x43 | format(time) -> []sdk.ValAddress` +- ValidatorQueueTime:`0x43 |格式(时间)-> []sdk.ValAddress` -The stored object as each key is an array of validator operator addresses from -which the validator object can be accessed. Typically it is expected that only -a single validator record will be associated with a given timestamp however it is possible -that multiple validators exist in the queue at the same location. +作为每个键的存储对象是一个验证器操作员地址数组，来自 +可以访问验证器对象。通常预计只有 +单个验证器记录将与给定的时间戳相关联，但这是可能的 +多个验证器存在于同一位置的队列中。 -## HistoricalInfo +## 历史信息 -HistoricalInfo objects are stored and pruned at each block such that the staking keeper persists -the `n` most recent historical info defined by staking module parameter: `HistoricalEntries`. +历史信息对象在每个块中被存储和修剪，以便 staking 保持者持续存在 +由 staking 模块参数定义的 `n` 最近的历史信息:`HistoricalEntries`。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L15-L22 -At each BeginBlock, the staking keeper will persist the current Header and the Validators that committed -the current block in a `HistoricalInfo` object. The Validators are sorted on their address to ensure that -they are in a determisnistic order. -The oldest HistoricalEntries will be pruned to ensure that there only exist the parameter-defined number of -historical entries. +在每个 BeginBlock 中，Staking 管理员将保留当前的 ​​Header 和提交的验证器 +`HistoricalInfo` 对象中的当前块。验证者按其地址排序，以确保 +它们处于确定性顺序中。 +最旧的历史条目将被修剪以确保只存在参数定义的数量 +历史条目。 \ No newline at end of file diff --git a/docs/ja/modules/staking/02_state_transitions.md b/docs/ja/modules/staking/02_state_transitions.md index cc60e91f5997..9bff55cb5fdf 100644 --- a/docs/ja/modules/staking/02_state_transitions.md +++ b/docs/ja/modules/staking/02_state_transitions.md @@ -1,172 +1,172 @@ -# State Transitions +# 状态转换 -This document describes the state transition operations pertaining to: +本文档描述了与以下相关的状态转换操作: -1. [Validators](./02_state_transitions.md#validators) -2. [Delegations](./02_state_transitions.md#delegations) -3. [Slashing](./02_state_transitions.md#slashing) +1. [验证器](./02_state_transitions.md#validators) +2. [委托](./02_state_transitions.md#delegations) +3. [斜线](./02_state_transitions.md#slashing) -## Validators +## 验证器 -State transitions in validators are performed on every [`EndBlock`](./05_end_block.md#validator-set-changes) -in order to check for changes in the active `ValidatorSet`. +验证器中的状态转换在每个 [`EndBlock`](./05_end_block.md#validator-set-changes) 上执行 +为了检查活动的“ValidatorSet”中的变化。 -A validator can be `Unbonded`, `Unbonding` or `Bonded`. `Unbonded` -and `Unbonding` are collectively called `Not Bonded`. A validator can move -directly between all the states, except for from `Bonded` to `Unbonded`. +验证器可以是“Unbonded”、“Unbonding”或“Bonded”。 `未绑定` +和“Unbonding”统称为“Not Bonded”。验证者可以移动 +直接在所有状态之间，除了从“Bonded”到“Unbonded”。 -### Not bonded to Bonded +### 未绑定到绑定 -The following transition occurs when a validator's ranking in the `ValidatorPowerIndex` surpasses -that of the `LastValidator`. +当验证者在 ValidatorPowerIndex 中的排名超过 +“LastValidator”的那个。 -- set `validator.Status` to `Bonded` -- send the `validator.Tokens` from the `NotBondedTokens` to the `BondedPool` `ModuleAccount` -- delete the existing record from `ValidatorByPowerIndex` -- add a new updated record to the `ValidatorByPowerIndex` -- update the `Validator` object for this validator -- if it exists, delete any `ValidatorQueue` record for this validator +- 将 `validator.Status` 设置为 `Bonded` +- 将 `validator.Tokens` 从 `NotBondedTokens` 发送到 `BondedPool` `ModuleAccount` +- 从 `ValidatorByPowerIndex` 中删除现有记录 +- 向 `ValidatorByPowerIndex` 添加一条新的更新记录 +- 更新此验证器的 `Validator` 对象 +- 如果存在，删除此验证器的任何“ValidatorQueue”记录 -### Bonded to Unbonding +### 绑定到解绑 -When a validator begins the unbonding process the following operations occur: +当验证者开始解除绑定过程时，会发生以下操作: -- send the `validator.Tokens` from the `BondedPool` to the `NotBondedTokens` `ModuleAccount` -- set `validator.Status` to `Unbonding` -- delete the existing record from `ValidatorByPowerIndex` -- add a new updated record to the `ValidatorByPowerIndex` -- update the `Validator` object for this validator -- insert a new record into the `ValidatorQueue` for this validator +- 将 `validator.Tokens` 从 `BondedPool` 发送到 `NotBondedTokens` `ModuleAccount` +- 将 `validator.Status` 设置为 `Unbonding` +- 从 `ValidatorByPowerIndex` 中删除现有记录 +- 向 `ValidatorByPowerIndex` 添加一条新的更新记录 +- 更新此验证器的 `Validator` 对象 +- 为这个验证器在 `ValidatorQueue` 中插入一条新记录 -### Unbonding to Unbonded +### 解除绑定到解除绑定 -A validator moves from unbonding to unbonded when the `ValidatorQueue` object -moves from bonded to unbonded +当“ValidatorQueue”对象出现时，验证器从解除绑定状态变为解除绑定状态 +从保税到非保税 -- update the `Validator` object for this validator -- set `validator.Status` to `Unbonded` +- 更新此验证器的 `Validator` 对象 +- 将 `validator.Status` 设置为 `Unbonded` -### Jail/Unjail +### 入狱/出狱 -when a validator is jailed it is effectively removed from the Tendermint set. -this process may be also be reversed. the following operations occur: +当验证者被监禁时，它实际上会从 Tendermint 集合中删除。 +这个过程也可以逆转。发生以下操作: -- set `Validator.Jailed` and update object -- if jailed delete record from `ValidatorByPowerIndex` -- if unjailed add record to `ValidatorByPowerIndex` +- 设置 `Validator.Jailed` 并更新对象 +- 如果被监禁，从`ValidatorByPowerIndex` 中删除记录 +- 如果未监禁，则将记录添加到 `ValidatorByPowerIndex` -Jailed validators are not present in any of the following stores: +被监禁的验证器不存在于以下任何存储中: -- the power store (from consensus power to address) +- 电力存储(从共识权力到地址) ## Delegations ### Delegate -When a delegation occurs both the validator and the delegation objects are affected +当委托发生时，验证器和委托对象都会受到影响 -- determine the delegators shares based on tokens delegated and the validator's exchange rate -- remove tokens from the sending account -- add shares the delegation object or add them to a created validator object -- add new delegator shares and update the `Validator` object -- transfer the `delegation.Amount` from the delegator's account to the `BondedPool` or the `NotBondedPool` `ModuleAccount` depending if the `validator.Status` is `Bonded` or not -- delete the existing record from `ValidatorByPowerIndex` -- add an new updated record to the `ValidatorByPowerIndex` +- 根据委托的代币和验证者的汇率确定委托人的份额 +- 从发送帐户中删除令牌 +- 添加共享委托对象或将它们添加到创建的验证器对象 +- 添加新的委托人份额并更新`Validator`对象 +- 将`delegation.Amount`从委托人的账户转移到`BondedPool`或`NotBondedPool``ModuleAccount`，具体取决于`validator.Status`是否为`Bonded` +- 从 `ValidatorByPowerIndex` 中删除现有记录 +- 向 `ValidatorByPowerIndex` 添加一条新的更新记录 -### Begin Unbonding +### 开始解绑 -As a part of the Undelegate and Complete Unbonding state transitions Unbond -Delegation may be called. +作为 Undelegate 和 Complete Unbonding 状态转换的一部分 Unbond +可以调用委托。 -- subtract the unbonded shares from delegator -- if the validator is `Unbonding` or `Bonded` add the tokens to an `UnbondingDelegation` Entry -- if the validator is `Unbonded` send the tokens directly to the withdraw - account -- update the delegation or remove the delegation if there are no more shares -- if the delegation is the operator of the validator and no more shares exist then trigger a jail validator -- update the validator with removed the delegator shares and associated coins -- if the validator state is `Bonded`, transfer the `Coins` worth of the unbonded - shares from the `BondedPool` to the `NotBondedPool` `ModuleAccount` -- remove the validator if it is unbonded and there are no more delegation shares. +- 从委托人中减去未绑定股份 +- 如果验证器是“Unbonding”或“Bonded”，则将代币添加到“UnbondingDelegation”条目中 +- 如果验证人是“Unbonded”，则将代币直接发送给提款人 + 帐户 +- 如果没有更多共享，则更新委托或删除委托 +- 如果委托是验证者的操作者并且没有更多的股份存在，则触发监狱验证者 +- 更新验证器，删除委托人股份和相关代币 +- 如果验证者状态为“Bonded”，则转移未绑定的“Coins”价值 + 从`BondedPool` 到`NotBondedPool``ModuleAccount` 的共享 +- 如果验证器未绑定并且没有更多的委托份额，则删除验证器。 -### Complete Unbonding +### 完全解绑 -For undelegations which do not complete immediately, the following operations -occur when the unbonding delegation queue element matures: +对于未立即完成的取消委托，请执行以下操作 +当解除绑定委托队列元素成熟时发生: -- remove the entry from the `UnbondingDelegation` object -- transfer the tokens from the `NotBondedPool` `ModuleAccount` to the delegator `Account` +- 从 `UnbondingDelegation` 对象中删除条目 +- 将代币从 `NotBondedPool` `ModuleAccount` 转移到委托人 `Account` -### Begin Redelegation +### 开始重新授权 -Redelegations affect the delegation, source and destination validators. +重新委派会影响委派、源和目标验证器。 -- perform an `unbond` delegation from the source validator to retrieve the tokens worth of the unbonded shares -- using the unbonded tokens, `Delegate` them to the destination validator -- if the `sourceValidator.Status` is `Bonded`, and the `destinationValidator` is not, - transfer the newly delegated tokens from the `BondedPool` to the `NotBondedPool` `ModuleAccount` -- otherwise, if the `sourceValidator.Status` is not `Bonded`, and the `destinationValidator` - is `Bonded`, transfer the newly delegated tokens from the `NotBondedPool` to the `BondedPool` `ModuleAccount` -- record the token amount in an new entry in the relevant `Redelegation` +- 执行来自源验证器的“unbond”委托以检索未绑定股票的代币价值 +- 使用未绑定的代币，将它们“委托”给目标验证器 +- 如果`sourceValidator.Status` 是`Bonded`，而`destinationValidator` 不是， + 将新委托的代币从 `BondedPool` 转移到 `NotBondedPool` `ModuleAccount` +- 否则，如果 `sourceValidator.Status` 不是 `Bonded`，并且 `destinationValidator` + 是`Bonded`，将新委托的代币从`NotBondedPool`转移到`BondedPool``ModuleAccount` +- 在相关“重新授权”的新条目中记录代币数量 -From when a redelegation begins until it completes, the delegator is in a state of "pseudo-unbonding", and can still be -slashed for infractions that occured before the redelegation began. +从重新授权开始到完成，被授权人处于“伪解绑”状态，并且仍然可以 +因在重新授权开始之前发生的违规行为而受到惩罚。 -### Complete Redelegation +### 完成重新授权 -When a redelegations complete the following occurs: +当重新授权完成时，会发生以下情况: -- remove the entry from the `Redelegation` object +- 从 `Redelegation` 对象中删除条目 -## Slashing +## 削减 -### Slash Validator +### 斜线验证器 -When a Validator is slashed, the following occurs: +当验证器被削减时，会发生以下情况: -- The total `slashAmount` is calculated as the `slashFactor` (a chain parameter) \* `TokensFromConsensusPower`, - the total number of tokens bonded to the validator at the time of the infraction. -- Every unbonding delegation and pseudo-unbonding redelegation such that the infraction occured before the unbonding or - redelegation began from the validator are slashed by the `slashFactor` percentage of the initialBalance. -- Each amount slashed from redelegations and unbonding delegations is subtracted from the - total slash amount. -- The `remaingSlashAmount` is then slashed from the validator's tokens in the `BondedPool` or - `NonBondedPool` depending on the validator's status. This reduces the total supply of tokens. +- 总`slashAmount` 计算为`slashFactor`(链参数)\* `TokensFromConsensusPower`， + 违规时绑定到验证器的令牌总数。 +- 每次解除绑定授权和伪解除绑定重新授权，使得违规发生在解除绑定之前或 + 从验证器开始的重新授权被初始余额的“slashFactor”百分比削减。 +- 从重新授权和解除授权中削减的每一笔金额都从 + 总斜线金额。 +- 然后从 `BondedPool` 中的验证者代币中削减 `remaingSlashAmount` 或 + `NonBondedPool` 取决于验证器的状态。这减少了代币的总供应量。 -In the case of a slash due to any infraction that requires evidence to submitted (for example double-sign), the slash -occurs at the block where the evidence is included, not at the block where the infraction occured. -Put otherwise, validators are not slashed retroactively, only when they are caught. +如果由于任何需要提交证据的违规行为(例如双重签名)而出现斜线，则斜线 +发生在包含证据的区块，而不是发生违规的区块。 +否则，验证者不会被追溯削减，只有当他们被抓住时。 -### Slash Unbonding Delegation +### 斜线解除绑定委托 -When a validator is slashed, so are those unbonding delegations from the validator that began unbonding -after the time of the infraction. Every entry in every unbonding delegation from the validator -is slashed by `slashFactor`. The amount slashed is calculated from the `InitialBalance` of the -delegation and is capped to prevent a resulting negative balance. Completed (or mature) unbondings are not slashed. +当验证者被削减时，那些开始解除绑定的验证者的解除绑定委托也会被削减 +违规后。来自验证者的每个解除绑定委托中的每个条目 +被“slashFactor”削减。削减的金额是根据“InitialBalance”计算的 +并设置上限以防止由此产生的负余额。完成(或成熟)的解除绑定不会被削减。 -### Slash Redelegation +### 斜线重新授权 -When a validator is slashed, so are all redelegations from the validator that began after the -infraction. Redelegations are slashed by `slashFactor`. -Redelegations that began before the infraction are not slashed. -The amount slashed is calculated from the `InitialBalance` of the delegation and is capped to -prevent a resulting negative balance. -Mature redelegations (that have completed pseudo-unbonding) are not slashed. +当验证器被削减时，所有在验证器之后开始的验证器的重新授权也会被削减 +违规。重新授权被“slashFactor”削减。 +在违规之前开始的重新授权不会被削减。 +削减的金额是根据委托的“InitialBalance”计算的，上限为 +防止由此产生的负余额。 +成熟的再授权(已完成伪解除绑定)不会被削减。 -## How Shares are calculated +## 如何计算份额 -At any given point in time, each validator has a number of tokens, `T`, and has a number of shares issued, `S`. -Each delegator, `i`, holds a number of shares, `S_i`. -The number of tokens is the sum of all tokens delegated to the validator, plus the rewards, minus the slashes. +在任何给定的时间点，每个验证者都有一定数量的代币“T”，并有一定数量的已发行股份“S”。 +每个委托人‘i’持有一定数量的股份‘S_i’。 +代币的数量是委托给验证者的所有代币的总和，加上奖励，减去斜线。 -The delegator is entitled to a portion of the underlying tokens proportional to their proportion of shares. -So delegator `i` is entitled to `T * S_i / S` of the validator's tokens. +委托人有权获得与其股份比例成比例的一部分基础代币。 +因此，委托人`i` 有权获得验证人代币的`T * S_i / S`。 -When a delegator delegates new tokens to the validator, they receive a number of shares proportional to their contribution. -So when delegator `j` delegates `T_j` tokens, they receive `S_j = S * T_j / T` shares. -The total number of tokens is now `T + T_j`, and the total number of shares is `S + S_j`. -`j`s proportion of the shares is the same as their proportion of the total tokens contributed: `(S + S_j) / S = (T + T_j) / T`. +当委托人将新代币委托给验证人时，他们会收到与他们的贡献成正比的份额。 +因此，当委托人`j` 委托`T_j` 代币时，他们会收到`S_j = S * T_j / T` 份额。 +现在代币总数为‘T + T_j’，股份总数为‘S + S_j’。 +`j 的份额比例与其贡献的总代币的比例相同:`(S + S_j) / S = (T + T_j) / T`。 -A special case is the initial delegation, when `T = 0` and `S = 0`, so `T_j / T` is undefined. -For the initial delegation, delegator `j` who delegates `T_j` tokens receive `S_j = T_j` shares. -So a validator that hasn't received any rewards and has not been slashed will have `T = S`. +一个特殊情况是初始委托，当`T = 0` 和`S = 0` 时，所以`T_j / T` 是未定义的。 +对于初始委托，委托“T_j”代币的委托人“j”获得“S_j = T_j”份额。 +所以一个没有收到任何奖励也没有被削减的验证者将拥有 `T = S`。 \ No newline at end of file diff --git a/docs/ja/modules/staking/03_messages.md b/docs/ja/modules/staking/03_messages.md index f5a60309dbe5..39e48c535b6e 100644 --- a/docs/ja/modules/staking/03_messages.md +++ b/docs/ja/modules/staking/03_messages.md @@ -1,150 +1,150 @@ -# Messages +# 消息 -In this section we describe the processing of the staking messages and the corresponding updates to the state. All created/modified state objects specified by each message are defined within the [state](./02_state_transitions.md) section. +在本节中，我们描述了 staking 消息的处理和相应的状态更新。每个消息指定的所有创建/修改状态对象都在 [state](./02_state_transitions.md) 部分中定义。 ## MsgCreateValidator -A validator is created using the `MsgCreateValidator` message. -The validator must be created with an initial delegation from the operator. +使用 `MsgCreateValidator` 消息创建验证器。 +必须使用运营商的初始委托来创建验证器。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L16-L17 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L35-L51 -This message is expected to fail if: +如果出现以下情况，此消息预计会失败: -- another validator with this operator address is already registered -- another validator with this pubkey is already registered -- the initial self-delegation tokens are of a denom not specified as the bonding denom -- the commission parameters are faulty, namely: - - `MaxRate` is either > 1 or < 0 - - the initial `Rate` is either negative or > `MaxRate` - - the initial `MaxChangeRate` is either negative or > `MaxRate` -- the description fields are too large +- 另一个具有此操作员地址的验证器已注册 +- 另一个使用此公钥的验证器已经注册 +- 初始自委托代币的面额未指定为绑定面额 +- 佣金参数有问题，即: + - `MaxRate` 是 > 1 或 < 0 + - 初始 `Rate` 为负数或 > `MaxRate` + - 初始 `MaxChangeRate` 为负数或 > `MaxRate` +- 描述字段太大 -This message creates and stores the `Validator` object at appropriate indexes. -Additionally a self-delegation is made with the initial tokens delegation -tokens `Delegation`. The validator always starts as unbonded but may be bonded -in the first end-block. +此消息在适当的索引处创建并存储“验证器”对象。 +此外，通过初始代币委托进行自我委托 +令牌`委托`。验证器始终以未绑定状态开始，但可能已绑定 +在第一个结束块中。 ## MsgEditValidator -The `Description`, `CommissionRate` of a validator can be updated using the -`MsgEditValidator` message. +验证器的 `Description`、`CommissionRate` 可以使用 +`MsgEditValidator` 消息。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L19-L20 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L56-L76 -This message is expected to fail if: +如果出现以下情况，此消息预计会失败: -- the initial `CommissionRate` is either negative or > `MaxRate` -- the `CommissionRate` has already been updated within the previous 24 hours -- the `CommissionRate` is > `MaxChangeRate` -- the description fields are too large +- 初始`CommissionRate` 为负数或> `MaxRate` +- `CommissionRate` 已在过去 24 小时内更新 +- `CommissionRate` 是 > `MaxChangeRate` +- 描述字段太大 -This message stores the updated `Validator` object. +此消息存储更新的“验证器”对象。 ## MsgDelegate -Within this message the delegator provides coins, and in return receives -some amount of their validator's (newly created) delegator-shares that are -assigned to `Delegation.Shares`. +在此消息中，委托人提供硬币，并作为回报收到 +一定数量的验证者(新创建的)委托人股份 +分配给`Delegation.Shares`。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L22-L24 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L81-L90 -This message is expected to fail if: +如果出现以下情况，此消息预计会失败: -- the validator does not exist -- the `Amount` `Coin` has a denomination different than one defined by `params.BondDenom` -- the exchange rate is invalid, meaning the validator has no tokens (due to slashing) but there are outstanding shares -- the amount delegated is less than the minimum allowed delegation +- 验证器不存在 +- `Amount` `Coin` 的面额与 `params.BondDenom` 定义的面额不同 +- 汇率无效，这意味着验证者没有代币(由于削减)但有流通股 +- 委托金额低于允许的最低委托金额 -If an existing `Delegation` object for provided addresses does not already -exist then it is created as part of this message otherwise the existing -`Delegation` is updated to include the newly received shares. +如果提供的地址的现有“委托”对象还没有 +存在然后它被创建作为此消息的一部分，否则现有的 +`Delegation` 更新为包括新收到的共享。 -The delegator receives newly minted shares at the current exchange rate. -The exchange rate is the number of existing shares in the validator divided by -the number of currently delegated tokens. +委托人以当前汇率接收新铸造的股票。 +汇率是验证器中现有股份的数量除以 +当前委托代币的数量。 -The validator is updated in the `ValidatorByPower` index, and the delegation is -tracked in validator object in the `Validators` index. +验证器在`ValidatorByPower`索引中更新，委托是 +在“验证器”索引中的验证器对象中进行跟踪。 -It is possible to delegate to a jailed validator, the only difference being it -will not be added to the power index until it is unjailed. +可以委托给被监禁的验证者，唯一的区别是 +不会被添加到力量指数中，直到它被释放。 -![Delegation sequence](../../../docs/uml/svg/delegation_sequence.svg) +![委托序列](../../../docs/uml/svg/delegation_sequence.svg) ## MsgUndelegate -The `MsgUndelegate` message allows delegators to undelegate their tokens from -validator. +`MsgUndelegate` 消息允许委托人取消委托他们的代币 +验证器。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L30-L32 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L112-L121 -This message returns a response containing the completion time of the undelegation: +此消息返回一个响应，其中包含取消委派的完成时间: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L123-L126 -This message is expected to fail if: +如果出现以下情况，此消息预计会失败: -- the delegation doesn't exist -- the validator doesn't exist -- the delegation has less shares than the ones worth of `Amount` -- existing `UnbondingDelegation` has maximum entries as defined by `params.MaxEntries` -- the `Amount` has a denomination different than one defined by `params.BondDenom` +- 代表团不存在 +- 验证器不存在 +- 代表团的份额少于“金额”的份额 +- 现有的“UnbondingDelegation”具有由“params.MaxEntries”定义的最大条目 +- `Amount` 的面额与 `params.BondDenom` 定义的面额不同 -When this message is processed the following actions occur: +处理此消息时，会发生以下操作: -- validator's `DelegatorShares` and the delegation's `Shares` are both reduced by the message `SharesAmount` -- calculate the token worth of the shares remove that amount tokens held within the validator -- with those removed tokens, if the validator is: - - `Bonded` - add them to an entry in `UnbondingDelegation` (create `UnbondingDelegation` if it doesn't exist) with a completion time a full unbonding period from the current time. Update pool shares to reduce BondedTokens and increase NotBondedTokens by token worth of the shares. - - `Unbonding` - add them to an entry in `UnbondingDelegation` (create `UnbondingDelegation` if it doesn't exist) with the same completion time as the validator (`UnbondingMinTime`). - - `Unbonded` - then send the coins the message `DelegatorAddr` -- if there are no more `Shares` in the delegation, then the delegation object is removed from the store - - under this situation if the delegation is the validator's self-delegation then also jail the validator. +- 验证者的`DelegatorShares`和委托的`Shares`都被消息`SharesAmount`减少 +- 计算股票的代币价值，删除验证器中持有的代币数量 +- 使用那些已删除的令牌，如果验证器是: + - `Bonded` - 将它们添加到 `UnbondingDelegation` 中的条目(如果它不存在，则创建 `UnbondingDelegation`)，完成时间从当前时间开始一个完整的解绑期。更新池份额以减少 BondedTokens 并通过份额的代币价值增加 NotBondedTokens。 + - `Unbonding` - 将它们添加到 `UnbondingDelegation` 中的条目(如果它不存在，则创建 `UnbondingDelegation`)与验证器(`UnbondingMinTime`)具有相同的完成时间。 + - `Unbonded` - 然后向硬币发送消息`DelegatorAddr` +- 如果委托中没有更多的`Shares`，那么委托对象将从存储中删除 + - 在这种情况下，如果委托是验证者的自我委托，那么也会监禁验证者。 -![Unbond sequence](../../../docs/uml/svg/unbond_sequence.svg) +![解绑序列](../../../docs/uml/svg/unbond_sequence.svg) ## MsgBeginRedelegate -The redelegation command allows delegators to instantly switch validators. Once -the unbonding period has passed, the redelegation is automatically completed in -the EndBlocker. +重新委托命令允许委托人立即切换验证人。一次 +解绑期已过，转授权自动完成 +终结者。 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L26-L28 +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L95-L105 -This message returns a response containing the completion time of the redelegation: +此消息返回一个响应，其中包含重新授权的完成时间: +++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/tx.proto#L107-L110 -This message is expected to fail if: +如果出现以下情况，此消息预计会失败: -- the delegation doesn't exist -- the source or destination validators don't exist -- the delegation has less shares than the ones worth of `Amount` -- the source validator has a receiving redelegation which is not matured (aka. the redelegation may be transitive) -- existing `Redelegation` has maximum entries as defined by `params.MaxEntries` -- the `Amount` `Coin` has a denomination different than one defined by `params.BondDenom` +- 代表团不存在 +- 源或目标验证器不存在 +- 代表团的份额少于“金额”的份额 +- 源验证器有一个未成熟的接收重新委托(又名，重新委托可能是可传递的) +- 现有的“重新委托”具有由“params.MaxEntries”定义的最大条目 +- `Amount` `Coin` 的面额与 `params.BondDenom` 定义的面额不同 -When this message is processed the following actions occur: +处理此消息时，会发生以下操作: -- the source validator's `DelegatorShares` and the delegations `Shares` are both reduced by the message `SharesAmount` -- calculate the token worth of the shares remove that amount tokens held within the source validator. -- if the source validator is: - - `Bonded` - add an entry to the `Redelegation` (create `Redelegation` if it doesn't exist) with a completion time a full unbonding period from the current time. Update pool shares to reduce BondedTokens and increase NotBondedTokens by token worth of the shares (this may be effectively reversed in the next step however). - - `Unbonding` - add an entry to the `Redelegation` (create `Redelegation` if it doesn't exist) with the same completion time as the validator (`UnbondingMinTime`). - - `Unbonded` - no action required in this step -- Delegate the token worth to the destination validator, possibly moving tokens back to the bonded state. -- if there are no more `Shares` in the source delegation, then the source delegation object is removed from the store - - under this situation if the delegation is the validator's self-delegation then also jail the validator. +- 源验证器的`DelegatorShares`和委托`Shares`都被消息`SharesAmount`减少 +- 计算股票的代币价值，删除源验证器中持有的代币数量。 +- 如果源验证器是: + - `Bonded` - 将一个条目添加到 `Redelegation`(如果它不存在，则创建 `Redelegation`)，完成时间从当前时间开始一个完整的解除绑定期。更新池份额以减少 BondedTokens 并通过份额的代币价值增加 NotBondedTokens(然而，这可能在下一步中有效地逆转)。 + - `Unbonding` - 将一个条目添加到 `Redelegation`(如果它不存在，则创建 `Redelegation`)，其完成时间与验证器(`UnbondingMinTime`)相同。 + - `Unbonded` - 这一步不需要任何操作 +- 将代币价值委托给目标验证器，可能会将代币移回绑定状态。 +- 如果源委托中没有更多的`Shares`，那么源委托对象将从存储中删除 + - 在这种情况下，如果委托是验证者的自我委托，那么也会监禁验证者。 -![Begin redelegation sequence](../../../docs/uml/svg/begin_redelegation_sequence.svg) +![开始重新委托序列](../../../docs/uml/svg/begin_redelegation_sequence.svg) \ No newline at end of file diff --git a/docs/ja/modules/staking/04_begin_block.md b/docs/ja/modules/staking/04_begin_block.md index d3f356d38276..9fe22462aa15 100644 --- a/docs/ja/modules/staking/04_begin_block.md +++ b/docs/ja/modules/staking/04_begin_block.md @@ -1,12 +1,12 @@ -# Begin-Block +# 开始块 -Each abci begin block call, the historical info will get stored and pruned -according to the `HistoricalEntries` parameter. +每个 abci 开始块调用，历史信息将被存储和修剪 +根据`HistoricalEntries`参数。 -## Historical Info Tracking +## 历史信息跟踪 -If the `HistoricalEntries` parameter is 0, then the `BeginBlock` performs a no-op. +如果`HistoricalEntries` 参数为0，则`BeginBlock` 执行无操作。 -Otherwise, the latest historical info is stored under the key `historicalInfoKey|height`, while any entries older than `height - HistoricalEntries` is deleted. -In most cases, this results in a single entry being pruned per block. -However, if the parameter `HistoricalEntries` has changed to a lower value there will be multiple entries in the store that must be pruned. +否则，最新的历史信息存储在键“historicalInfoKey|height”下，而任何早于“height - HistoricalEntries”的条目都将被删除。 +在大多数情况下，这会导致每个块修剪单个条目。 +但是，如果参数“HistoricalEntries”已更改为较低的值，则存储中将有多个必须修剪的条目。 \ No newline at end of file diff --git a/docs/ja/modules/staking/05_end_block.md b/docs/ja/modules/staking/05_end_block.md index 29a247cf285f..ac6d70497ee3 100644 --- a/docs/ja/modules/staking/05_end_block.md +++ b/docs/ja/modules/staking/05_end_block.md @@ -1,73 +1,73 @@ -# End-Block - -Each abci end block call, the operations to update queues and validator set -changes are specified to execute. - -## Validator Set Changes - -The staking validator set is updated during this process by state transitions -that run at the end of every block. As a part of this process any updated -validators are also returned back to Tendermint for inclusion in the Tendermint -validator set which is responsible for validating Tendermint messages at the -consensus layer. Operations are as following: - -- the new validator set is taken as the top `params.MaxValidators` number of - validators retrieved from the `ValidatorsByPower` index -- the previous validator set is compared with the new validator set: - - missing validators begin unbonding and their `Tokens` are transferred from the - `BondedPool` to the `NotBondedPool` `ModuleAccount` - - new validators are instantly bonded and their `Tokens` are transferred from the - `NotBondedPool` to the `BondedPool` `ModuleAccount` - -In all cases, any validators leaving or entering the bonded validator set or -changing balances and staying within the bonded validator set incur an update -message reporting their new consensus power which is passed back to Tendermint. - -The `LastTotalPower` and `LastValidatorsPower` hold the state of the total power -and validator power from the end of the last block, and are used to check for -changes that have occured in `ValidatorsByPower` and the total new power, which -is calculated during `EndBlock`. - -## Queues - -Within staking, certain state-transitions are not instantaneous but take place -over a duration of time (typically the unbonding period). When these -transitions are mature certain operations must take place in order to complete -the state operation. This is achieved through the use of queues which are -checked/processed at the end of each block. - -### Unbonding Validators - -When a validator is kicked out of the bonded validator set (either through -being jailed, or not having sufficient bonded tokens) it begins the unbonding -process along with all its delegations begin unbonding (while still being -delegated to this validator). At this point the validator is said to be an -"unbonding validator", whereby it will mature to become an "unbonded validator" -after the unbonding period has passed. - -Each block the validator queue is to be checked for mature unbonding validators -(namely with a completion time <= current time and completion height <= current -block height). At this point any mature validators which do not have any -delegations remaining are deleted from state. For all other mature unbonding -validators that still have remaining delegations, the `validator.Status` is -switched from `types.Unbonding` to -`types.Unbonded`. - -### Unbonding Delegations - -Complete the unbonding of all mature `UnbondingDelegations.Entries` within the -`UnbondingDelegations` queue with the following procedure: - -- transfer the balance coins to the delegator's wallet address -- remove the mature entry from `UnbondingDelegation.Entries` -- remove the `UnbondingDelegation` object from the store if there are no - remaining entries. - -### Redelegations - -Complete the unbonding of all mature `Redelegation.Entries` within the -`Redelegations` queue with the following procedure: - -- remove the mature entry from `Redelegation.Entries` -- remove the `Redelegation` object from the store if there are no - remaining entries. +# 结束块 + +每个 abci 结束块调用，更新队列和验证器集的操作 +更改被指定执行。 + +## 验证器集更改 + +在此过程中通过状态转换更新质押验证器集 +在每个块的末尾运行。作为此过程的一部分，任何更新 +验证器也会返回到 Tendermint 以包含在 Tendermint 中 +验证器集，负责验证 Tendermint 消息 +共识层。操作如下: + +- 新的验证器集被视为最高的 `params.MaxValidators` 数量 + 从“ValidatorsByPower”索引中检索的验证器 +- 将先前的验证器集与新的验证器集进行比较: + - 缺失的验证者开始解除绑定，他们的“代币”从 + `BondedPool` 到 `NotBondedPool` `ModuleAccount` + - 新的验证者立即绑定，他们的“代币”从 + `NotBondedPool` 到 `BondedPool` `ModuleAccount` + +在所有情况下，任何离开或进入绑定验证器集的验证器或 +更改余额并留在绑定验证器集合中会导致更新 +消息报告他们新的共识权力，该权力被传递回 Tendermint。 + +`LastTotalPower` 和 `LastValidatorsPower` 保存总功率的状态 +和来自最后一个区块末尾的验证者权力，用于检查 +`ValidatorsByPower` 中发生的变化和新的总权力，其中 +在“EndBlock”期间计算。 + +## 队列 + +在 staking 中，某些状态转换不是即时的而是发生的 +在一段时间内(通常是解绑期)。当这些 +转换已经成熟，必须进行某些操作才能完成 +状态操作。这是通过使用队列来实现的 +在每个块的末尾检查/处理。 + +### 解除绑定验证器 + +当验证者被踢出绑定验证者集时(通过 +被监禁，或没有足够的绑定代币)它开始解除绑定 +进程及其所有代表团开始解除绑定(同时仍在 +委托给这个验证器)。在这一点上，验证者被认为是一个 +“非绑定验证器”，它将成熟成为“非绑定验证器” +解绑期过后。 + +验证者队列的每个区块都将被检查是否有成熟的解绑验证者 +(即完成时间<=当前时间和完成高度<=当前 +块高度)。在这一点上，任何成熟的验证器没有任何 +剩余的代表团从状态中删除。对于所有其他成熟的解绑 +仍然有剩余委托的验证器，`validator.Status` 是 +从 `types.Unbonding` 切换到 +`types.Unbonded`。 + +### 解除绑定委托 + +完成所有成熟的`UnbondingDelegations.Entries` 内的解除绑定 +`UnbondingDelegations` 队列具有以下过程: + +- 将余额币转移到委托人的钱包地址 +- 从`UnbondingDelegation.Entries`中删除成熟的条目 +- 如果没有，则从存储中删除 `UnbondingDelegation` 对象 + 剩余条目。 + +### 重新授权 + +完成所有成熟的“Redelegation.Entries”的解绑 +`Redelegations` 队列具有以下过程: + +- 从`Redelegation.Entries`中删除成熟的条目 +- 如果没有，则从存储中删除 `Redelegation` 对象 + 剩余条目。 \ No newline at end of file diff --git a/docs/ja/modules/staking/06_hooks.md b/docs/ja/modules/staking/06_hooks.md index cb529e509c12..47723df7d9d9 100644 --- a/docs/ja/modules/staking/06_hooks.md +++ b/docs/ja/modules/staking/06_hooks.md @@ -1,9 +1,9 @@ -# Hooks +# 钩子 -Other modules may register operations to execute when a certain event has -occurred within staking. These events can be registered to execute either -right `Before` or `After` the staking event (as per the hook name). The -following hooks can registered with staking: +当某个事件发生时，其他模块可能会注册要执行的操作 +发生在 Staking 内。 可以注册这些事件以执行 +对赌注事件的“之前”或“之后”(根据挂钩名称)。 这 +以下挂钩可以通过 staking 注册: - `AfterValidatorCreated(Context, ValAddress) error` - called when a validator is created diff --git a/docs/ja/modules/staking/07_events.md b/docs/ja/modules/staking/07_events.md index 5cca199f1727..5ad3f11d77b9 100644 --- a/docs/ja/modules/staking/07_events.md +++ b/docs/ja/modules/staking/07_events.md @@ -1,6 +1,6 @@ -# Events +# 事件 -The staking module emits the following events: +staking 模块发出以下事件: ## EndBlocker diff --git a/docs/ja/modules/staking/08_params.md b/docs/ja/modules/staking/08_params.md index 7baf93f7c9d5..6d0cf5f72d2c 100644 --- a/docs/ja/modules/staking/08_params.md +++ b/docs/ja/modules/staking/08_params.md @@ -1,6 +1,6 @@ -# Parameters +# 参数 -The staking module contains the following parameters: +staking 模块包含以下参数 | Key | Type | Example | |-------------------|------------------|------------------------| diff --git a/docs/ja/modules/staking/09_client.md b/docs/ja/modules/staking/09_client.md index 9265c08b6ded..c0e03202c433 100644 --- a/docs/ja/modules/staking/09_client.md +++ b/docs/ja/modules/staking/09_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `staking` module using the CLI. +用户可以使用 CLI 查询“staking”模块并与之交互。 -### Query +### 询问 -The `query` commands allows users to query `staking` state. +`query` 命令允许用户查询 `staking` 状态。 ```bash simd query staking --help diff --git a/docs/ja/modules/staking/README.md b/docs/ja/modules/staking/README.md index b259e9999f4f..b0133ed43891 100644 --- a/docs/ja/modules/staking/README.md +++ b/docs/ja/modules/staking/README.md @@ -1,48 +1,48 @@ -# `staking` +# `质押` -## Abstract +## 摘要 -This paper specifies the Staking module of the Cosmos-SDK, which was first -described in the [Cosmos Whitepaper](https://cosmos.network/about/whitepaper) -in June 2016. +本文指定了 Cosmos-SDK 的 Staking 模块。 +[Cosmos 白皮书](https://cosmos.network/about/whitepaper) 中描述 +2016 年 6 月。 -The module enables Cosmos-SDK based blockchain to support an advanced -Proof-of-Stake system. In this system, holders of the native staking token of -the chain can become validators and can delegate tokens to validators, -ultimately determining the effective validator set for the system. +该模块使基于 Cosmos-SDK 的区块链能够支持高级 +权益证明系统。在这个系统中，原生质押代币的持有者 +链可以成为验证者，并且可以将代币委托给验证者， +最终确定系统的有效验证器集。 -This module will be used in the Cosmos Hub, the first Hub in the Cosmos -network. +该模块将用于 Cosmos Hub，Cosmos 中的第一个 Hub +网络。 -## Contents +## 内容 -1. **[State](01_state.md)** - - [Pool](01_state.md#pool) +1. **[状态](01_state.md)** + - [池](01_state.md#pool) - [LastTotalPower](01_state.md#lasttotalpower) - - [Params](01_state.md#params) - - [Validator](01_state.md#validator) - - [Delegation](01_state.md#delegation) + - [参数](01_state.md#params) + - [验证器](01_state.md#validator) + - [委托](01_state.md#delegation) - [UnbondingDelegation](01_state.md#unbondingdelegation) - - [Redelegation](01_state.md#redelegation) - - [Queues](01_state.md#queues) - - [HistoricalInfo](01_state.md#historicalinfo) -2. **[State Transitions](02_state_transitions.md)** - - [Validators](02_state_transitions.md#validators) - - [Delegations](02_state_transitions.md#delegations) - - [Slashing](02_state_transitions.md#slashing) -3. **[Messages](03_messages.md)** + - [重新委托](01_state.md#redelegation) + - [队列](01_state.md#queues) + - [历史信息](01_state.md#historicalinfo) +2. **[状态转换](02_state_transitions.md)** + - [验证器](02_state_transitions.md#validators) + - [委托](02_state_transitions.md#delegations) + - [斜线](02_state_transitions.md#slashing) +3. **[消息](03_messages.md)** - [MsgCreateValidator](03_messages.md#msgcreatevalidator) - [MsgEditValidator](03_messages.md#msgeditvalidator) - [MsgDelegate](03_messages.md#msgdelegate) - [MsgUndelegate](03_messages.md#msgundelegate) - [MsgBeginRedelegate](03_messages.md#msgbeginredelegate) -4. **[Begin-Block](04_begin_block.md)** - - [Historical Info Tracking](04_begin_block.md#historical-info-tracking) -5. **[End-Block](05_end_block.md)** - - [Validator Set Changes](05_end_block.md#validator-set-changes) - - [Queues](05_end_block.md#queues-) -6. **[Hooks](06_hooks.md)** -7. **[Events](07_events.md)** +4. **[开始区块](04_begin_block.md)** + - [历史信息追踪](04_begin_block.md#historical-info-tracking) +5. **[结束块](05_end_block.md)** + - [验证器设置更改](05_end_block.md#validator-set-changes) + - [队列](05_end_block.md#queues-) +6. **[钩子](06_hooks.md)** +7. **[事件](07_events.md)** - [EndBlocker](07_events.md#endblocker) - [Msg's](07_events.md#msg's) -8. **[Parameters](08_params.md)** +8. **[参数](08_params.md)** \ No newline at end of file diff --git a/docs/ja/modules/upgrade/01_concepts.md b/docs/ja/modules/upgrade/01_concepts.md index fd9aeefecc67..f1811e999a1c 100644 --- a/docs/ja/modules/upgrade/01_concepts.md +++ b/docs/ja/modules/upgrade/01_concepts.md @@ -1,27 +1,26 @@ -# Concepts - -## Plan - -The `x/upgrade` module defines a `Plan` type in which a live upgrade is scheduled -to occur. A `Plan` can be scheduled at a specific block height. -A `Plan` is created once a (frozen) release candidate along with an appropriate upgrade -`Handler` (see below) is agreed upon, where the `Name` of a `Plan` corresponds to a -specific `Handler`. Typically, a `Plan` is created through a governance proposal -process, where if voted upon and passed, will be scheduled. The `Info` of a `Plan` -may contain various metadata about the upgrade, typically application specific -upgrade info to be included on-chain such as a git commit that validators could -automatically upgrade to. - -### Sidecar Process - -If an operator running the application binary also runs a sidecar process to assist -in the automatic download and upgrade of a binary, the `Info` allows this process to -be seamless. Namely, the `x/upgrade` module fulfills the -[cosmosd Upgradeable Binary Specification](https://github.com/regen-network/cosmosd#upgradeable-binary-specification) -specification and `cosmosd` can optionally be used to fully automate the upgrade -process for node operators. By populating the `Info` field with the necessary information, -binaries can automatically be downloaded. See [here](https://github.com/regen-network/cosmosd#auto-download) -for more info. +# 概念 + +## 计划 + +`x/upgrade` 模块定义了一个 `Plan` 类型，其中安排了实时升级 +发生。可以在特定的块高度安排“计划”。 +一旦(冻结的)候选发布以及适当的升级，就会创建一个“计划” +`Handler`(见下文)已达成一致，其中 `Plan` 的 `Name` 对应于 +特定的`处理程序`。通常，“计划”是通过治理提案创建的 +流程，如果投票通过，将被安排。 “计划”的“信息” +可能包含有关升级的各种元数据，通常是特定于应用程序的 +升级要包含在链上的信息，例如验证者可以进行的 git commit +自动升级到。 + +### Sidecar 流程 + +如果运行应用程序二进制文件的操作员也运行一个 sidecar 进程来协助 +在二进制文件的自动下载和升级中，`Info` 允许这个过程 +无缝衔接。即，`x/upgrade` 模块满足 +[cosmosd 可升级二进制规范](https://github.com/regen-network/cosmosd#upgradeable-binary-specification) +可以选择使用规范和 `cosmosd` 来完全自动化升级 +节点运营商的流程。通过用必要的信息填充“信息”字段， +二进制文件可以自动下载。见[这里](https://github.com/regen-network/cosmosd#auto-download) ```go type Plan struct { @@ -33,49 +32,49 @@ type Plan struct { ## Handler -The `x/upgrade` module facilitates upgrading from major version X to major version Y. To -accomplish this, node operators must first upgrade their current binary to a new -binary that has a corresponding `Handler` for the new version Y. It is assumed that -this version has fully been tested and approved by the community at large. This -`Handler` defines what state migrations need to occur before the new binary Y -can successfully run the chain. Naturally, this `Handler` is application specific -and not defined on a per-module basis. Registering a `Handler` is done via -`Keeper#SetUpgradeHandler` in the application. +`x/upgrade` 模块有助于从主要版本 X 升级到主要版本 Y。 +要做到这一点，节点运营商必须首先将他们当前的二进制文件升级到一个新的 +具有新版本 Y 对应的 `Handler` 的二进制文件。假设 +此版本已经过社区的全面测试和批准。 这 +`Handler` 定义了在新的二进制 Y 之前需要发生什么状态迁移 +可以成功运行链条。 当然，这个 `Handler` 是特定于应用程序的 +并且不是在每个模块的基础上定义的。 注册`Handler`是通过 +应用程序中的`Keeper#SetUpgradeHandler`。 ```go type UpgradeHandler func(Context, Plan, VersionMap) (VersionMap, error) ``` -During each `EndBlock` execution, the `x/upgrade` module checks if there exists a -`Plan` that should execute (is scheduled at that height). If so, the corresponding -`Handler` is executed. If the `Plan` is expected to execute but no `Handler` is registered -or if the binary was upgraded too early, the node will gracefully panic and exit. +在每次 `EndBlock` 执行期间，`x/upgrade` 模块会检查是否存在 +应该执行的“计划”(在那个高度安排)。 如果是，对应的 +`Handler` 被执行。 如果“计划”预期执行但未注册“处理程序” +或者如果二进制文件升级过早，节点将优雅地恐慌并退出。 ## StoreLoader -The `x/upgrade` module also facilitates store migrations as part of the upgrade. The -`StoreLoader` sets the migrations that need to occur before the new binary can -successfully run the chain. This `StoreLoader` is also application specific and -not defined on a per-module basis. Registering this `StoreLoader` is done via -`app#SetStoreLoader` in the application. +`x/upgrade` 模块还有助于作为升级一部分的存储迁移。 这 +`StoreLoader` 设置在新二进制文件可以之前需要发生的迁移 +成功运行链。 这个`StoreLoader`也是特定于应用程序的 +不是在每个模块的基础上定义的。 注册这个`StoreLoader`是通过 +应用程序中的`app#SetStoreLoader`。 ```go func UpgradeStoreLoader (upgradeHeight int64, storeUpgrades *store.StoreUpgrades) baseapp.StoreLoader ``` -If there's a planned upgrade and the upgrade height is reached, the old binary writes `Plan` to the disk before panic'ing. +如果有计划的升级并且达到升级高度，旧的二进制文件会在恐慌之前将“计划”写入磁盘。 -This information is critical to ensure the `StoreUpgrades` happens smoothly at correct height and -expected upgrade. It eliminiates the chances for the new binary to execute `StoreUpgrades` multiple -times everytime on restart. Also if there are multiple upgrades planned on same height, the `Name` -will ensure these `StoreUpgrades` takes place only in planned upgrade handler. +此信息对于确保“StoreUpgrades”在正确的高度和 +预期升级。 它消除了新二进制文件多次执行“StoreUpgrades”的机会 +每次重启时的次数。 此外，如果计划在同一高度进行多次升级，“名称” +将确保这些 `StoreUpgrades` 仅在计划的升级处理程序中发生。 ## Proposal -Typically, a `Plan` is proposed and submitted through governance via a `SoftwareUpgradeProposal`. -This proposal prescribes to the standard governance process. If the proposal passes, -the `Plan`, which targets a specific `Handler`, is persisted and scheduled. The -upgrade can be delayed or hastened by updating the `Plan.Height` in a new proposal. +通常，“计划”是通过“SoftwareUpgradeProposal”通过治理提出和提交的。 +该提案规定了标准的治理流程。 如果提案通过， +以特定“处理程序”为目标的“计划”被持久化和调度。 这 +可以通过更新新提案中的“Plan.Height”来延迟或加快升级。 ```go type SoftwareUpgradeProposal struct { @@ -87,16 +86,16 @@ type SoftwareUpgradeProposal struct { ### Cancelling Upgrade Proposals -Upgrade proposals can be cancelled. There exists a `CancelSoftwareUpgrade` proposal -type, which can be voted on and passed and will remove the scheduled upgrade `Plan`. -Of course this requires that the upgrade was known to be a bad idea well before the -upgrade itself, to allow time for a vote. +可以取消升级建议。 存在一个 `CancelSoftwareUpgrade` 提议 +类型，可以投票通过，并将删除计划的升级“计划”。 +当然，这需要在升级之前就知道升级是一个坏主意。 +升级自己，留出时间进行投票。 -If such a possibility is desired, the upgrade height is to be -`2 * (VotingPeriod + DepositPeriod) + (SafetyDelta)` from the beginning of the -upgrade proposal. The `SafetyDelta` is the time available from the success of an -upgrade proposal and the realization it was a bad idea (due to external social consensus). +如果需要这种可能性，升级高度应为 +`2 * (VotingPeriod + DepositPeriod) + (SafetyDelta)` 从开始 +升级建议。 “SafetyDelta”是一个成功的可用时间 +升级提案并意识到这是一个坏主意(由于外部社会共识)。 -A `CancelSoftwareUpgrade` proposal can also be made while the original -`SoftwareUpgradeProposal` is still being voted upon, as long as the `VotingPeriod` -ends after the `SoftwareUpgradeProposal`. +一个`CancelSoftwareUpgrade` 提议也可以在原来的同时提出 +`SoftwareUpgradeProposal` 仍在投票中，只要 `VotingPeriod` +在“SoftwareUpgradeProposal”之后结束。 \ No newline at end of file diff --git a/docs/ja/modules/upgrade/02_state.md b/docs/ja/modules/upgrade/02_state.md index 3bb0ad83503f..1481af9e8552 100644 --- a/docs/ja/modules/upgrade/02_state.md +++ b/docs/ja/modules/upgrade/02_state.md @@ -1,16 +1,16 @@ -# State +# 状态 -The internal state of the `x/upgrade` module is relatively minimal and simple. The -state contains the currently active upgrade `Plan` (if one exists) by key -`0x0` and if a `Plan` is marked as "done" by key `0x1`. The state -contains the consensus versions of all app modules in the application. The versions -are stored as big endian `uint64`, and can be accessed with prefix `0x2` appended -by the corresponding module name of type `string`. The state maintains a -`Protocol Version` which can be accessed by key `0x3`. +`x/upgrade` 模块的内部状态相对最小和简单。 这 +state 包含当前活动的升级`Plan`(如果存在)键 +`0x0` 并且如果 `Plan` 被键 `0x1` 标记为“完成”。 国家 +包含应用程序中所有应用程序模块的共识版本。 版本 +存储为 big endian `uint64`，可以通过附加前缀 `0x2` 访问 +通过类型为`string`的相应模块名称。 国家维持一个 +可以通过密钥“0x3”访问的“协议版本”。 -- Plan: `0x0 -> Plan` -- Done: `0x1 | byte(plan name) -> BigEndian(Block Height)` -- ConsensusVersion: `0x2 | byte(module name) -> BigEndian(Module Consensus Version)` -- ProtocolVersion: `0x3 -> BigEndian(Protocol Version)` +- 计划:`0x0 -> 计划` +- 完成:`0x1 | 字节(计划名称)-> BigEndian(块高度)` +- 共识版本:`0x2 | 字节(模块名称)-> BigEndian(模块共识版本)` +- 协议版本:`0x3 -> BigEndian(协议版本)` -The `x/upgrade` module contains no genesis state. +`x/upgrade` 模块不包含创世状态。 \ No newline at end of file diff --git a/docs/ja/modules/upgrade/03_events.md b/docs/ja/modules/upgrade/03_events.md index bbfcdddfa69e..cd2869d0e70d 100644 --- a/docs/ja/modules/upgrade/03_events.md +++ b/docs/ja/modules/upgrade/03_events.md @@ -1,4 +1,4 @@ -# Events +# 事件 -The `x/upgrade` does not emit any events by itself. Any and all proposal related -events are emitted through the `x/gov` module. +`x/upgrade` 本身不会发出任何事件。 任何和所有提案相关 +事件通过 `x/gov` 模块发出。 \ No newline at end of file diff --git a/docs/ja/modules/upgrade/04_client.md b/docs/ja/modules/upgrade/04_client.md index 112f8c38b133..7c3459d01c84 100644 --- a/docs/ja/modules/upgrade/04_client.md +++ b/docs/ja/modules/upgrade/04_client.md @@ -1,12 +1,12 @@ -# Client +# 客户 -## CLI +##命令行界面 -A user can query and interact with the `upgrade` module using the CLI. +用户可以使用 CLI 查询“升级”模块并与之交互。 -### Query +### 询问 -The `query` commands allow users to query `upgrade` state. +`query` 命令允许用户查询 `upgrade` 状态。 ```bash simd query upgrade --help @@ -14,14 +14,14 @@ simd query upgrade --help #### applied -The `applied` command allows users to query the block header for height at which a completed upgrade was applied. +`applied` 命令允许用户查询区块头以获取应用完成升级的高度。 ```bash simd query upgrade applied [upgrade-name] [flags] ``` -If upgrade-name was previously executed on the chain, this returns the header for the block at which it was applied. -This helps a client determine which binary was valid over a given range of blocks, as well as more context to understand past migrations. +如果之前在链上执行了 upgrade-name，这将返回应用它的块的标头。 +这有助于客户端确定哪个二进制文件在给定的块范围内有效，以及了解过去迁移的更多上下文。 Example: diff --git a/docs/ja/modules/upgrade/README.md b/docs/ja/modules/upgrade/README.md index b741d5c43481..087f53dbcee5 100644 --- a/docs/ja/modules/upgrade/README.md +++ b/docs/ja/modules/upgrade/README.md @@ -1,24 +1,24 @@ -# `upgrade` +# `升级` -## Abstract +## 摘要 -`x/upgrade` is an implementation of a Cosmos SDK module that facilitates smoothly -upgrading a live Cosmos chain to a new (breaking) software version. It accomplishes this by -providing a `BeginBlocker` hook that prevents the blockchain state machine from -proceeding once a pre-defined upgrade block height has been reached. +`x/upgrade` 是一个 Cosmos SDK 模块的实现 +将实时 Cosmos 链升级到新的(破坏性的)软件版本。它通过 +提供一个“BeginBlocker”钩子，防止区块链状态机 +一旦达到预定义的升级块高度，就继续进行。 -The module does not prescribe anything regarding how governance decides to do an -upgrade, but just the mechanism for coordinating the upgrade safely. Without software -support for upgrades, upgrading a live chain is risky because all of the validators -need to pause their state machines at exactly the same point in the process. If -this is not done correctly, there can be state inconsistencies which are hard to -recover from. +该模块没有规定任何关于治理如何决定做一个 +升级，但只是安全协调升级的机制。无需软件 +支持升级，升级一条活链是有风险的，因为所有的验证者 +需要在过程中完全相同的点暂停他们的状态机。如果 +这没有正确完成，可能会出现难以处理的状态不一致 +从。。。恢复。 - -1. **[Concepts](01_concepts.md)** -2. **[State](02_state.md)** -3. **[Events](03_events.md)** -4. **[Client](04_client.md)** + +1. **[概念](01_concepts.md)** +2. **[状态](02_state.md)** +3. **[事件](03_events.md)** +4. **[客户端](04_client.md)** - [CLI](04_client.md#cli) - [REST](04_client.md#rest) - - [gRPC](04_client.md#grpc) + - [gRPC](04_client.md#grpc) \ No newline at end of file diff --git a/docs/ja/run-node/README.md b/docs/ja/run-node/README.md index 46e116e0a148..2725ead6a4af 100644 --- a/docs/ja/run-node/README.md +++ b/docs/ja/run-node/README.md @@ -1,11 +1,11 @@ -# Running a Node, API and CLI +# 运行节点、API 和 CLI -This script contains documentation on how to run a node and interact with it. +此脚本包含有关如何运行节点并与之交互的文档。 -1. [Setting up the keyring](./keyring.md) -2. [Running a Node](./run-node.md) -3. [Interacting with a Node](./interact-node.md) -4. [Generating, Signing and Broadcasting Transactions](./txs.md) -5. [Cosmos Upgrade Manager](./cosmovisor.md) +1. [设置钥匙圈](./keyring.md) +2. [运行节点](./run-node.md) +3. [与节点交互](./interact-node.md) +4. [生成、签署和广播交易](./txs.md) +5. [Cosmos 升级管理器](./cosmovisor.md) 6. [Rosetta API](./rosetta.md) -7. [Running a Testnet](./run-testnet.md) +7. [运行测试网](./run-testnet.md) \ No newline at end of file diff --git a/docs/ja/run-node/cosmovisor.md b/docs/ja/run-node/cosmovisor.md index 8ad896bbde30..55b248037115 100644 --- a/docs/ja/run-node/cosmovisor.md +++ b/docs/ja/run-node/cosmovisor.md @@ -1,45 +1,45 @@ -# Cosmosvisor +# cosmovisor -`cosmovisor` is a small process manager for Cosmos SDK application binaries that monitors the governance module for incoming chain upgrade proposals. If it sees a proposal that gets approved, `cosmovisor` can automatically download the new binary, stop the current binary, switch from the old binary to the new one, and finally restart the node with the new binary. +`cosmovisor` 是 Cosmos SDK 应用程序二进制文件的小型进程管理器，用于监控传入链升级提议的治理模块。如果看到一个提案获得批准，`cosmovisor` 可以自动下载新的二进制文件，停止当前的二进制文件，从旧的二进制文件切换到新的二进制文件，最后用新的二进制文件重新启动节点。 -#### Design +#### 设计 -Cosmovisor is designed to be used as a wrapper for a `Cosmos SDK` app: +Cosmovisor 旨在用作“Cosmos SDK”应用程序的包装器: -* it will pass arguments to the associated app (configured by `DAEMON_NAME` env variable). - Running `cosmovisor run arg1 arg2 ....` will run `app arg1 arg2 ...`; -* it will manage an app by restarting and upgrading if needed; -* it is configured using environment variables, not positional arguments. +* 它将参数传递给关联的应用程序(由`DAEMON_NAME` 环境变量配置)。 + 运行 `cosmovisor run arg1 arg2 ....` 将运行 `app arg1 arg2 ...`； +* 如果需要，它将通过重新启动和升级来管理应用程序； +* 它是使用环境变量配置的，而不是位置参数。 -*Note: If new versions of the application are not set up to run in-place store migrations, migrations will need to be run manually before restarting `cosmovisor` with the new binary. For this reason, we recommend applications adopt in-place store migrations.* +*注意:如果应用程序的新版本未设置为运行就地存储迁移，则需要在使用新二进制文件重新启动 `cosmovisor` 之前手动运行迁移。因此，我们建议应用程序采用就地存储迁移。* -*Note: If validators would like to enable the auto-download option (which [we don't recommend](#auto-download)), and they are currently running an application using Cosmos SDK `v0.42`, they will need to use Cosmovisor [`v0.1`](https://github.com/cosmos/cosmos-sdk/releases/tag/cosmovisor%2Fv0.1.0). Later versions of Cosmovisor do not support Cosmos SDK `v0.44.3` or earlier if the auto-download option is enabled.* +*注意:如果验证者想要启用自动下载选项([我们不推荐](#auto-download))，并且他们当前正在使用 Cosmos SDK `v0.42` 运行应用程序，他们将需要使用 Cosmovisor [`v0.1`](https://github.com/cosmos/cosmos-sdk/releases/tag/cosmovisor%2Fv0.1.0)。如果启用了自动下载选项，更高版本的 Cosmovisor 不支持 Cosmos SDK `v0.44.3` 或更早版本。* -## Contributing +## 贡献 -Cosmovisor is part of the Cosmos SDK monorepo, but it's a separate module with it's own release schedule. +Cosmovisor 是 Cosmos SDK monorepo 的一部分，但它是一个单独的模块，有自己的发布时间表。 -Release branches have the following format `release/cosmovisor/vA.B.x`, where A and B are a number (e.g. `release/cosmovisor/v0.1.x`). Releases are tagged using the following format: `cosmovisor/vA.B.C`. +发布分支具有以下格式`release/cosmovisor/vA.B.x`，其中 A 和 B 是一个数字(例如`release/cosmovisor/v0.1.x`)。使用以下格式标记版本:`cosmovisor/vA.B.C`。 -## Setup +## 设置 -### Installation +### 安装 -To install the latest version of `cosmovisor`, run the following command: +要安装最新版本的 `cosmovisor`，请运行以下命令: ``` go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@latest ``` -To install a previous version, you can specify the version. IMPORTANT: Chains that use Cosmos-SDK v0.44.3 or earlier (eg v0.44.2) and want to use auto-download feature MUST use Cosmovisor v0.1.0 +要安装以前的版本，您可以指定版本。 重要提示:使用 Cosmos-SDK v0.44.3 或更早版本(例如 v0.44.2)并希望使用自动下载功能的链必须使用 Cosmovisor v0.1.0 ``` go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@v0.1.0 ``` -It is possible to confirm the version of cosmovisor when using Cosmovisor v1.0.0, but it is not possible to do so with `v0.1.0`. +使用 Cosmovisor v1.0.0 时可以确认 cosmovisor 的版本，但使用 `v0.1.0` 则无法这样做。 -You can also install from source by pulling the cosmos-sdk repository and switching to the correct version and building as follows: +您还可以通过拉取 cosmos-sdk 存储库并切换到正确的版本并按如下方式构建来从源代码安装: ``` git clone git@github.com:cosmos/cosmos-sdk @@ -49,39 +49,39 @@ cd cosmovisor make ``` -This will build cosmovisor in your current directory. Afterwards you may want to put it into your machine's PATH like as follows: +这将在您的当前目录中构建 cosmovisor。 之后，您可能希望将其放入机器的 PATH 中，如下所示: ``` cp cosmovisor ~/go/bin/cosmovisor ``` -*Note: If you are using go `v1.15` or earlier, you will need to use `go get`, and you may want to run the command outside a project directory.* +*注意:如果您使用的是 go `v1.15` 或更早版本，则需要使用 `go get`，并且您可能希望在项目目录外运行该命令。* -### Command Line Arguments And Environment Variables +### 命令行参数和环境变量 -The first argument passed to `cosmovisor` is the action for `cosmovisor` to take. Options are: +传递给 `cosmovisor` 的第一个参数是 `cosmovisor` 要采取的操作。选项是: -* `help`, `--help`, or `-h` - Output `cosmovisor` help information and check your `cosmovisor` configuration. -* `run` - Run the configured binary using the rest of the provided arguments. -* `version`, or `--version` - Output the `cosmovisor` version and also run the binary with the `version` argument. +* `help`、`--help` 或 `-h` - 输出 `cosmovisor` 帮助信息并检查你的 `cosmovisor` 配置。 +* `run` - 使用提供的其余参数运行配置的二进制文件。 +* `version` 或 `--version` - 输出 `cosmovisor` 版本并使用 `version` 参数运行二进制文件。 -All arguments passed to `cosmovisor run` will be passed to the application binary (as a subprocess). `cosmovisor` will return `/dev/stdout` and `/dev/stderr` of the subprocess as its own. For this reason, `cosmovisor run` cannot accept any command-line arguments other than those available to the application binary. +传递给“cosmovisor run”的所有参数都将传递给应用程序二进制文件(作为子进程)。 `cosmovisor` 将返回子进程的 `/dev/stdout` 和 `/dev/stderr` 作为它自己的。出于这个原因，`cosmovisor run` 不能接受除应用程序二进制文件可用的命令行参数之外的任何命令行参数。 -*Note: Use of `cosmovisor` without one of the action arguments is deprecated. For backwards compatability, if the first argument is not an action argument, `run` is assumed. However, this fallback might be removed in future versions, so it is recommended that you always provide `run`. +*注意:不推荐使用没有动作参数之一的`cosmovisor`。为了向后兼容，如果第一个参数不是动作参数，则假定为 `run`。但是，此回退可能会在未来版本中删除，因此建议您始终提供 `run`。 -`cosmovisor` reads its configuration from environment variables: +`cosmovisor` 从环境变量中读取其配置: -* `DAEMON_HOME` is the location where the `cosmovisor/` directory is kept that contains the genesis binary, the upgrade binaries, and any additional auxiliary files associated with each binary (e.g. `$HOME/.gaiad`, `$HOME/.regend`, `$HOME/.simd`, etc.). -* `DAEMON_NAME` is the name of the binary itself (e.g. `gaiad`, `regend`, `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). By default, `cosmovisor` will not auto-download new binaries. -* `DAEMON_RESTART_AFTER_UPGRADE` (*optional*, default = `true`), if `true`, restarts the subprocess with the same command-line arguments and flags (but with the new binary) after a successful upgrade. Otherwise (`false`), `cosmovisor` stops running after an upgrade and requires the system administrator to manually restart it. Note restart is only after the upgrade and does not auto-restart the subprocess after an error occurs. -* `DAEMON_POLL_INTERVAL` is the interval length for polling the upgrade plan file. The value can either be a number (in milliseconds) or a duration (e.g. `1s`). Default: 300 milliseconds. -* `UNSAFE_SKIP_BACKUP` (defaults to `false`), if set to `true`, upgrades directly without performing a backup. Otherwise (`false`, default) backs up the data before trying the upgrade. The default value of false is useful and recommended in case of failures and when a backup needed to rollback. We recommend using the default backup option `UNSAFE_SKIP_BACKUP=false`. -* `DAEMON_PREUPGRADE_MAX_RETRIES` (defaults to `0`). The maximum number of times to call `pre-upgrade` in the application after exit status of `31`. After the maximum number of retries, cosmovisor fails the upgrade. +* `DAEMON_HOME` 是保存 `cosmovisor/` 目录的位置，该目录包含创世二进制文件、升级二进制文件以及与每个二进制文件相关的任何其他辅助文件(例如 `$HOME/.gaiad`、`$HOME/. regend`、`$HOME/.simd` 等)。 +* `DAEMON_NAME` 是二进制文件本身的名称(例如`gaiad`、`regend`、`simd` 等)。 +* `DAEMON_ALLOW_DOWNLOAD_BINARIES`(*可选*)，如果设置为`true`，将启用新二进制文件的自动下载(出于安全原因，这适用于完整节点而不是验证器)。默认情况下，`cosmovisor` 不会自动下载新的二进制文件。 +* `DAEMON_RESTART_AFTER_UPGRADE`(*可选*，默认值 = `true`)，如果为 `true`，则在成功升级后使用相同的命令行参数和标志(但使用新的二进制文件)重新启动子进程。否则 (`false`)，`cosmovisor` 在升级后停止运行，需要系统管理员手动重启。注意restart 是升级后才会出现的，不会在出现错误后自动重启子进程。 +* `DAEMON_POLL_INTERVAL` 是轮询升级计划文件的间隔长度。该值可以是数字(以毫秒为单位)或持续时间(例如“1s”)。默认值:300 毫秒。 +* `UNSAFE_SKIP_BACKUP`(默认为`false`)，如果设置为`true`，直接升级而不执行备份。否则(`false`，默认)在尝试升级之前备份数据。默认值 false 很有用，建议在发生故障和备份需要回滚时使用。我们建议使用默认备份选项`UNSAFE_SKIP_BACKUP=false`。 +* `DAEMON_PREUPGRADE_MAX_RETRIES`(默认为 `0`)。退出状态为“31”后，应用程序中调用“pre-upgrade”的最大次数。达到最大重试次数后，cosmovisor 升级失败。 -### Folder Layout +### 文件夹布局 -`$DAEMON_HOME/cosmovisor` is expected to belong completely to `cosmovisor` and the subprocesses that are controlled by it. The folder content is organized as follows: +`$DAEMON_HOME/cosmovisor` 应该完全属于 `cosmovisor` 及其控制的子进程。文件夹内容组织如下: ``` . @@ -96,9 +96,9 @@ All arguments passed to `cosmovisor run` will be passed to the application binar └── upgrade-info.json ``` -The `cosmovisor/` directory incudes a subdirectory for each version of the application (i.e. `genesis` or `upgrades/`). Within each subdirectory is the application binary (i.e. `bin/$DAEMON_NAME`) and any additional auxiliary files associated with each binary. `current` is a symbolic link to the currently active directory (i.e. `genesis` or `upgrades/`). The `name` variable in `upgrades/` is the URI-encoded name of the upgrade as specified in the upgrade module plan. +`cosmovisor/` 目录为应用程序的每个版本(即 `genesis` 或 `upgrades/`)包含一个子目录。在每个子目录中是应用程序二进制文件(即`bin/$DAEMON_NAME`)和与每个二进制文件关联的任何其他辅助文件。 `current` 是指向当前活动目录(即 `genesis` 或 `upgrades/`)的符号链接。 `upgrades/` 中的 `name` 变量是升级模块计划中指定的升级的 URI 编码名称。 -Please note that `$DAEMON_HOME/cosmovisor` only stores the *application binaries*. The `cosmovisor` binary itself can be stored in any typical location (e.g. `/usr/local/bin`). The application will continue to store its data in the default data directory (e.g. `$HOME/.gaiad`) or the data directory specified with the `--home` flag. `$DAEMON_HOME` is independent of the data directory and can be set to any location. If you set `$DAEMON_HOME` to the same directory as the data directory, you will end up with a configuation like the following: +请注意`$DAEMON_HOME/cosmovisor` 只存储*应用程序二进制文件*。 `cosmovisor` 二进制文件本身可以存储在任何典型的位置(例如 `/usr/local/bin`)。应用程序将继续将其数据存储在默认数据目录(例如`$HOME/.gaiad`)或使用`--home` 标志指定的数据目录中。 `$DAEMON_HOME` 独立于数据目录，可以设置为任何位置。如果您将 `$DAEMON_HOME` 设置为与数据目录相同的目录，您将得到如下配置: ``` .gaiad @@ -107,46 +107,46 @@ Please note that `$DAEMON_HOME/cosmovisor` only stores the *application binaries └── cosmovisor ``` -## Usage +## 用法 -The system administrator is responsible for: +系统管理员负责: -- installing the `cosmovisor` binary -- configuring the host's init system (e.g. `systemd`, `launchd`, etc.) -- appropriately setting the environmental variables -- manually installing the `genesis` folder -- manually installing the `upgrades/` folders +- 安装 `cosmovisor` 二进制文件 +- 配置主机的初始化系统(例如`systemd`、`launchd`等) +- 适当设置环境变量 +- 手动安装 `genesis` 文件夹 +- 手动安装 `upgrades/` 文件夹 -`cosmovisor` will set the `current` link to point to `genesis` at first start (i.e. when no `current` link exists) and then handle switching binaries at the correct points in time so that the system administrator can prepare days in advance and relax at upgrade time. +`cosmovisor` 会在第一次启动时将 `current` 链接设置为指向 `genesis`(即不存在 `current` 链接时)，然后在正确的时间点处理切换二进制文件，以便系统管理员可以提前几天准备并在升级时放松。 -In order to support downloadable binaries, a tarball for each upgrade binary will need to be packaged up and made available through a canonical URL. Additionally, a tarball that includes the genesis binary and all available upgrade binaries can be packaged up and made available so that all the necessary binaries required to sync a fullnode from start can be easily downloaded. +为了支持可下载的二进制文件，需要打包每个升级二进制文件的 tarball 并通过规范 URL 提供。此外，包含 genesis 二进制文件和所有可用升级二进制文件的 tarball 可以打包并提供，以便可以轻松下载从一开始就同步全节点所需的所有必要二进制文件。 -The `DAEMON` specific code and operations (e.g. tendermint config, the application db, syncing blocks, etc.) all work as expected. The application binaries' directives such as command-line flags and environment variables also work as expected. +`DAEMON` 特定的代码和操作(例如，tendermint 配置、应用程序数据库、同步块等)都按预期工作。应用程序二进制文件的指令(例如命令行标志和环境变量)也按预期工作。 -### Detecting Upgrades +### 检测升级 -`cosmovisor` is polling the `$DAEMON_HOME/data/upgrade-info.json` file for new upgrade instructions. The file is created by the x/upgrade module in `BeginBlocker` when an upgrade is detected and the blockchain reaches the upgrade height. -The following heuristic is applied to detect the upgrade: +`cosmovisor` 正在轮询 `$DAEMON_HOME/data/upgrade-info.json` 文件以获取新的升级说明。当检测到升级并且区块链达到升级高度时，该文件由“BeginBlocker”中的 x/upgrade 模块创建。 +应用以下启发式方法来检测升级: -+ When starting, `cosmovisor` doesn't know much about currently running upgrade, except the binary which is `current/bin/`. It tries to read the `current/update-info.json` file to get information about the current upgrade name. -+ If neither `cosmovisor/current/upgrade-info.json` nor `data/upgrade-info.json` exist, then `cosmovisor` will wait for `data/upgrade-info.json` file to trigger an upgrade. -+ If `cosmovisor/current/upgrade-info.json` doesn't exist but `data/upgrade-info.json` exists, then `cosmovisor` assumes that whatever is in `data/upgrade-info.json` is a valid upgrade request. In this case `cosmovisor` tries immediately to make an upgrade according to the `name` attribute in `data/upgrade-info.json`. -+ Otherwise, `cosmovisor` waits for changes in `upgrade-info.json`. As soon as a new upgrade name is recorded in the file, `cosmovisor` will trigger an upgrade mechanism. ++ 启动时，`cosmovisor` 不太了解当前正在运行的升级，除了`current/bin/` 二进制文件。它尝试读取“current/update-info.json”文件以获取有关当前升级名称的信息。 ++ 如果`cosmovisor/current/upgrade-info.json` 和`data/upgrade-info.json` 都不存在，那么`cosmovisor` 将等待`data/upgrade-info.json` 文件触发升级。 ++ 如果`cosmovisor/current/upgrade-info.json` 不存在但`data/upgrade-info.json` 存在，那么`cosmovisor` 假设`data/upgrade-info.json` 中的任何内容都是有效的升级请求。在这种情况下，`cosmovisor` 会立即尝试根据 `data/upgrade-info.json` 中的 `name` 属性进行升级。 ++ 否则，`cosmovisor` 会等待 `upgrade-info.json` 中的更改。一旦文件中记录了新的升级名称，`cosmovisor` 将触发升级机制。 -When the upgrade mechanism is triggered, `cosmovisor` will: +当升级机制被触发时，`cosmovisor` 将: -1. if `DAEMON_ALLOW_DOWNLOAD_BINARIES` is enabled, start by auto-downloading a new binary into `cosmovisor//bin` (where `` is the `upgrade-info.json:name` attribute); -2. update the `current` symbolic link to point to the new directory and save `data/upgrade-info.json` to `cosmovisor/current/upgrade-info.json`. +1. 如果启用了`DAEMON_ALLOW_DOWNLOAD_BINARIES`，首先将新的二进制文件自动下载到`cosmovisor//bin`(其中`` 是`upgrade-info.json:name` 属性)； +2.更新`current`符号链接指向新目录，并将`data/upgrade-info.json`保存到`cosmovisor/current/upgrade-info.json`。 -### Auto-Download +### 自动下载 -Generally, `cosmovisor` requires that the system administrator place all relevant binaries on disk before the upgrade happens. However, for people who don't need such control and want an automated setup (maybe they are syncing a non-validating fullnode and want to do little maintenance), there is another option. +通常，`cosmovisor` 要求系统管理员在升级之前将所有相关的二进制文件放在磁盘上。然而，对于不需要这种控制并想要自动设置的人(也许他们正在同步一个非验证全节点并且想要做很少的维护)，还有另一种选择。 -**NOTE: we don't recommend using auto-download** because it doesn't verify in advance if a binary is available. If there will be any issue with downloading a binary, the cosmovisor will stop and won't restart an App (which could lead to a chain halt). +**注意:我们不建议使用自动下载**，因为它不会提前验证二进制文件是否可用。如果下载二进制文件有任何问题，cosmovisor 将停止并且不会重新启动应用程序(这可能导致链停止)。 -If `DAEMON_ALLOW_DOWNLOAD_BINARIES` is set to `true`, and no local binary can be found when an upgrade is triggered, `cosmovisor` will attempt to download and install the binary itself based on the instructions in the `info` attribute in the `data/upgrade-info.json` file. The files is constructed by the x/upgrade module and contains data from the upgrade `Plan` object. The `Plan` has an info field that is expected to have one of the following two valid formats to specify a download: +如果 `DAEMON_ALLOW_DOWNLOAD_BINARIES` 设置为 `true`，并且在触发升级时找不到本地二进制文件，`cosmovisor` 将尝试根据 `data` 中的 `info` 属性中的说明下载并安装二进制文件本身 /upgrade-info.json` 文件。 这些文件由 x/upgrade 模块构建，并包含来自升级“计划”对象的数据。 `Plan` 有一个信息字段，它应该具有以下两种有效格式之一来指定下载: -1. Store an os/architecture -> binary URI map in the upgrade plan info field as JSON under the `"binaries"` key. For example: +1. 将 os/architecture -> 二进制 URI 映射存储在升级计划信息字段中作为“二进制”键下的 JSON。 例如: ```json { @@ -156,7 +156,7 @@ If `DAEMON_ALLOW_DOWNLOAD_BINARIES` is set to `true`, and no local binary can be } ``` -You can include multiple binaries at once to ensure more than one environment will receive the correct binaries: +您可以一次包含多个二进制文件，以确保多个环境将收到正确的二进制文件: ```json { @@ -168,7 +168,7 @@ You can include multiple binaries at once to ensure more than one environment wi } ``` -When submitting this as a proposal ensure there are no spaces. An example command using `gaiad` could look like: +将此作为提案提交时，请确保没有空格。 使用“gaiad”的示例命令可能如下所示: ``` > gaiad tx gov submit-proposal software-upgrade Vega \ @@ -185,31 +185,31 @@ When submitting this as a proposal ensure there are no spaces. An example comman --yes ``` -2. Store a link to a file that contains all information in the above format (e.g. if you want to specify lots of binaries, changelog info, etc. without filling up the blockchain). For example: +2. 以上述格式存储包含所有信息的文件的链接(例如，如果您想指定大量二进制文件、更改日志信息等，而无需填充区块链)。 例如: ``` https://example.com/testnet-1001-info.json?checksum=sha256:deaaa99fda9407c4dbe1d04bd49bab0cc3c1dd76fa392cd55a9425be074af01e ``` -When `cosmovisor` is triggered to download the new binary, `cosmovisor` will parse the `"binaries"` field, download the new binary with [go-getter](https://github.com/hashicorp/go-getter), and unpack the new binary in the `upgrades/` folder so that it can be run as if it was installed manually. +当 `cosmovisor` 被触发下载新的二进制文件时，`cosmovisor` 会解析 `"binaries"` 字段，使用 [go-getter](https://github.com/hashicorp/go-getter) 下载新的二进制文件 ，并将新的二进制文件解压到 `upgrades/` 文件夹中，这样它就可以像手动安装一样运行。 -Note that for this mechanism to provide strong security guarantees, all URLs should include a SHA 256/512 checksum. This ensures that no false binary is run, even if someone hacks the server or hijacks the DNS. `go-getter` will always ensure the downloaded file matches the checksum if it is provided. `go-getter` will also handle unpacking archives into directories (in this case the download link should point to a `zip` file of all data in the `bin` directory). +请注意，为了让此机制提供强大的安全保证，所有 URL 都应包含 SHA 256/512 校验和。 这确保不会运行虚假的二进制文件，即使有人入侵服务器或劫持 DNS。 `go-getter` 将始终确保下载的文件与提供的校验和匹配。 `go-getter` 还将处理将档案解压到目录中(在这种情况下，下载链接应该指向 `bin` 目录中所有数据的 `zip` 文件)。 -To properly create a sha256 checksum on linux, you can use the `sha256sum` utility. For example: +要在 linux 上正确创建 sha256 校验和，您可以使用 `sha256sum` 实用程序。 例如: ``` sha256sum ./testdata/repo/zip_directory/autod.zip ``` -The result will look something like the following: `29139e1381b8177aec909fab9a75d11381cab5adf7d3af0c05ff1c9c117743a7`. +结果将类似于以下内容:`29139e1381b8177aec909fab9a75d11381cab5adf7d3af0c05ff1c9c117743a7`。 -You can also use `sha512sum` if you would prefer to use longer hashes, or `md5sum` if you would prefer to use broken hashes. Whichever you choose, make sure to set the hash algorithm properly in the checksum argument to the URL. +如果您希望使用更长的散列，您也可以使用 `sha512sum`，或者如果您希望使用损坏的散列，您也可以使用 `md5sum`。 无论您选择哪种方式，请确保在 URL 的校验和参数中正确设置哈希算法。 -## Example: SimApp Upgrade +## 示例:SimApp 升级 -The following instructions provide a demonstration of `cosmovisor` using the simulation application (`simapp`) shipped with the Cosmos SDK's source code. The following commands are to be run from within the `cosmos-sdk` repository. +以下说明使用 Cosmos SDK 源代码附带的模拟应用程序 (`simapp`) 演示了 `cosmovisor`。 以下命令将从 `cosmos-sdk` 存储库中运行。 -First, check out the latest `v0.42` release: +首先，查看最新的 `v0.42` 版本: ``` git checkout v0.42.7 diff --git a/docs/ja/run-node/interact-node.md b/docs/ja/run-node/interact-node.md index 6c18517522ca..642ac5dbd5eb 100644 --- a/docs/ja/run-node/interact-node.md +++ b/docs/ja/run-node/interact-node.md @@ -1,21 +1,21 @@ -# Interacting with the Node +# 与节点交互 -There are multiple ways to interact with a node: using the CLI, using gRPC or using the REST endpoints. {synopsis} +有多种与节点交互的方式:使用 CLI、使用 gRPC 或使用 REST 端点。 {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [gRPC, REST and Tendermint Endpoints](../core/grpc_rest.md) {prereq} -- [Running a Node](./run-node.md) {prereq} +- [gRPC、REST 和 Tendermint 端点](../core/grpc_rest.md) {prereq} +- [运行节点](./run-node.md) {prereq} -## Using the CLI +## 使用 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: +您应该看到您创建的帐户的当前余额，等于您授予它的原始“stake”余额减去您通过“gentx”委托的金额。 现在，创建第二个帐户: ```bash simd keys add recipient --keyring-backend test @@ -24,7 +24,7 @@ simd keys add recipient --keyring-backend test 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 @@ -44,29 +44,29 @@ simd query staking delegations-to $(simd keys show my_validator --bech val -a -- 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 +## 使用 gRPC -The Protobuf ecosystem developed tools for different use cases, including code-generation from `*.proto` files into various languages. These tools allow the building of 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). +Protobuf 生态系统为不同的用例开发了工具，包括从 `*.proto` 文件到各种语言的代码生成。 这些工具允许轻松构建客户端。 通常，客户端连接(即传输)可以很容易地插入和替换。 让我们探索一种最流行的传输方式:[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` 用于通用调试和测试， +- 通过 Go 编程， +- 适用于 JavaScript/TypeScript 开发人员的 CosmJS。 ### 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. +[grpcurl](https://github.com/fullstorydev/grpcurl) 类似于 `curl` 但对于 gRPC。 它也可用作 Go 库，但我们将仅将其用作 CLI 命令以进行调试和测试。 按照上一个链接中的说明进行安装。 -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)): +假设您有一个本地节点正在运行(本地网络或连接的实时网络)，您应该能够运行以下命令来列出可用的 Protobuf 服务(您可以将 `localhost:9000` 替换为另一个的 gRPC 服务器端点 节点，在 [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml)) 中的 `grpc.address` 字段下配置: ```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. +您应该会看到一个 gRPC 服务列表，例如 `cosmos.bank.v1beta1.Query`。 这称为反射，它是一个 Protobuf 端点，返回所有可用端点的描述。 每一个都代表一个不同的 Protobuf 服务，每个服务都公开了多个可以查询的 RPC 方法。 -In order to get a description of the service you can run the following command: +为了获得服务的描述，您可以运行以下命令: ```bash grpcurl \ @@ -84,11 +84,11 @@ grpcurl \ cosmos.bank.v1beta1.Query/AllBalances ``` -The list of all available gRPC query endpoints is [coming soon](https://github.com/cosmos/cosmos-sdk/issues/7786). +所有可用 gRPC 查询端点的列表[即将推出](https://github.com/cosmos/cosmos-sdk/issues/7786)。 -#### Query for historical state using grpcurl +#### 使用 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: +您还可以通过将一些 [gRPC 元数据](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md) 传递给查询来查询历史数据:`x-cosmos -block-height` 元数据应包含要查询的块。 如上使用 grpcurl，命令如下所示: ```bash grpcurl \ @@ -99,12 +99,11 @@ grpcurl \ 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 编程 +以下代码段展示了如何在 Go 程序中使用 gRPC 查询状态。 这个想法是创建一个gRPC连接，并使用Protobuf生成的客户端代码来查询gRPC服务器。 ```go import ( "context" @@ -145,11 +144,11 @@ func queryState() error { } ``` -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). +您可以使用从任何其他 Protobuf 服务生成的客户端替换查询客户端(这里我们使用的是“x/bank”)。 所有可用 gRPC 查询端点的列表[即将推出](https://github.com/cosmos/cosmos-sdk/issues/7786)。 -#### Query for historical state using Go +#### 使用 Go 查询历史状态 -Querying for historical blocks is done by adding the block height metadata in the gRPC request. +历史区块的查询是通过在 gRPC 请求中添加区块高度元数据来完成的。 ```go import ( @@ -185,13 +184,13 @@ func queryState() error { ### 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. +CosmJS 文档可以在 [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs) 找到。 截至 2021 年 1 月，CosmJS 文档仍在进行中。 -## Using the REST Endpoints +## 使用 REST 端点 -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. +如 [gRPC 指南](../core/grpc_rest.md) 中所述，Cosmos SDK 上的所有 gRPC 服务都可用于通过 gRPC 网关进行更方便的基于 REST 的查询。 URL 路径的格式基于 Protobuf 服务方法的完全限定名称，但可能包含小的自定义，以便最终 URL 看起来更地道。 例如，`cosmos.bank.v1beta1.Query/AllBalances` 方法的 REST 端点是 `GET /cosmos/bank/v1beta1/balances/{address}`。 请求参数作为查询参数传递。 -As a concrete example, the `curl` command to make balances request is: +作为一个具体的例子，发出余额请求的 `curl` 命令是: ```bash curl \ @@ -200,13 +199,13 @@ curl \ 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. +确保将“localhost:1317”替换为您节点的 REST 端点，在“api.address”字段下配置。 -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. +所有可用 REST 端点的列表可作为 Swagger 规范文件提供，可以在 `localhost:1317/swagger` 中查看。 确保在您的 [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) 文件中将 `api.swagger` 字段设置为 true。 -### Query for historical state using REST +### 使用 REST 查询历史状态 -Querying for historical state is done using the HTTP header `x-cosmos-block-height`. For example, a curl command would look like: +查询历史状态是使用 HTTP 标头 `x-cosmos-block-height` 完成的。 例如，curl 命令如下所示: ```bash curl \ @@ -216,12 +215,12 @@ curl \ 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) -[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). +[CORS 政策](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) 默认未启用以帮助提高安全性。 如果您想在公共环境中使用 rest-server，我们建议您提供反向代理，这可以通过 [nginx](https://www.nginx.com/) 来完成。 出于测试和开发目的，[`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml) 中有一个“enabled-unsafe-cors”字段。 -## Next {hide} +## 下一个 {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} +使用 gRPC 和 REST 发送交易需要一些额外的步骤:生成交易、签名，最后广播它。 阅读[生成和签署交易](./txs.md)。 {hide} \ No newline at end of file diff --git a/docs/ja/run-node/keyring.md b/docs/ja/run-node/keyring.md index 711dccbd0658..d8772da57265 100644 --- a/docs/ja/run-node/keyring.md +++ b/docs/ja/run-node/keyring.md @@ -1,49 +1,49 @@ -# 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} +本文档描述了如何为 [**application**](../basics/app-anatomy.md) 配置和使用密钥环及其各种后端。 {概要} -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. +从 v0.38.0 版本开始，Cosmos SDK 附带了一个新的密钥环实现 +它提供了一组以安全方式管理加密密钥的命令。这 +新的密钥环支持多个存储后端，其中一些可能无法在 +所有操作系统。 -### The `os` backend +### `os` 后端 -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: +`os` 后端依赖于操作系统特定的默认值来处理密钥存储 +安全地。通常，操作系统的凭证子系统处理密码提示， +私钥存储，以及根据用户密码策略的用户会话。这里 +是最流行的操作系统及其各自的密码管理器的列表: -- 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) +- macOS(自 Mac OS 8.6 起):[钥匙串](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac) +- Windows:[凭据管理 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. +使用 GNOME 作为默认桌面环境的 GNU/Linux 发行版通常带有 +[海马](https://wiki.gnome.org/Apps/Seahorse)。基于 KDE 的发行版的用户是 +通常随 [KDE 钱包管理器](https://userbase.kde.org/KDE_Wallet_Manager) 提供。 +虽然前者实际上是一个 `libsecret` 方便的前端，后者是一个 `kwallet` +客户。 -`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. +`os` 是默认选项，因为操作系统的默认凭据管理器是 +旨在满足用户最常见的需求，并为他们提供舒适的 +在不影响安全性的情况下体验。 -The recommended backends for headless environments are `file` and `pass`. +推荐用于无头环境的后端是 `file` 和 `pass`。 -### The `file` backend +### `file` 后端 -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: +`file` 后端更类似于之前使用的 keybase 实现 +v0.38.1。它将加密的密钥环存储在应用程序的配置目录中。这 +keyring 每次访问都会请求密码，可能会出现多次 +次在单个命令中导致重复的密码提示。如果使用 bash 脚本 +要使用 `file` 选项执行命令，您可能需要使用以下格式 +对于多个提示: ```sh # assuming that KEYPASSWD is set in the environment @@ -56,65 +56,65 @@ $ echo $KEYPASSWD | gaiacli keys show me # single promp The first time you add a key to an empty keyring, you will be prompted to type the password twice. ::: -### The `pass` backend +### `pass` 后端 -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. +`pass` 后端使用 [pass](https://www.passwordstore.org/) 实用程序来管理磁盘 +密钥的敏感数据和元数据的加密。 密钥存储在“gpg”加密文件中 +在特定于应用程序的目录中。 `pass` 可用于最流行的 UNIX +操作系统以及 GNU/Linux 发行版。 请参阅其手册页了解 +有关如何下载和安装它的信息。 -::: 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. +::: 小费 +**pass** 使用 [GnuPG](https://gnupg.org/) 进行加密。 `gpg` 自动调用 `gpg-agent` +守护进程在执行时处理 GnuPG 凭据的缓存。 请参考`gpg-agent` +有关如何配置缓存参数(例如凭据 TTL 和 +密码过期。 ::: -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. +将 `` 替换为您的 GPG 密钥 ID。您可以使用您的个人 GPG 密钥或替代密钥 +您可能希望专门用于加密密码存储。 -### The `kwallet` backend +### `kwallet` 后端 -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. +`kwallet` 后端使用 `KDE Wallet Manager`，它默认安装在 +将 KDE 作为默认桌面环境提供的 GNU/Linux 发行版。请参阅 +[KWallet 手册](https://docs.kde.org/stable5/en/kdeutils/kwallet5/index.html) 了解更多 +信息。 -### The `test` backend +### `test` 后端 -The `test` backend is a password-less variation of the `file` backend. Keys are stored -unencrypted on disk. +`test` 后端是 `file` 后端的无密码变体。存储密钥 +磁盘上未加密。 -**Provided for testing purposes only. The `test` backend is not recommended for use in production environments**. +**仅用于测试目的。不建议在生产环境中使用 `test` 后端**。 -### The `memory` backend +### `memory` 后端 -The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited. +`memory` 后端将密钥存储在内存中。程序退出后，这些键会立即被删除。 -**Provided for testing purposes only. The `memory` backend is not recommended for use in production environments**. +**仅用于测试目的。不建议在生产环境中使用 `memory` 后端**。 -## 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. +::: 警告 +确保您可以构建自己的二进制文件，并在代码段中将“simd”替换为您的二进制文件的名称。 ::: -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). +使用 Cosmos SDK 开发的应用程序带有 `keys` 子命令。出于本教程的目的，我们将运行 `simd` CLI，这是一个使用 Cosmos SDK 构建的应用程序，用于测试和教育目的。更多信息请参见[`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. +您可以使用 `simd keys` 获取有关 keys 命令的帮助，使用 `simd keys [command] --help` 获取有关特定子命令的更多信息。 -::: 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. +::: 小费 +您还可以使用 `simd completion` 命令启用自动完成功能。例如，在 bash 会话开始时，运行 `. <(simd completion)`，并且所有 `simd` 子命令都将自动完成。 ::: -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. +要在密钥环中创建新密钥，请运行带有 `` 参数的 `add` 子命令。出于本教程的目的，我们将仅使用 `test` 后端，并调用我们的新密钥 `my_validator`。此键将在下一节中使用。 ```bash $ simd keys add my_validator --keyring-backend test @@ -123,10 +123,10 @@ $ simd keys add my_validator --keyring-backend test 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! +此命令生成一个新的 24 字助记词，将其持久化到相关后端，并输出有关密钥对的信息。 如果此密钥对将用于保存有价值的令牌，请务必在安全的地方写下助记词！ -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. +默认情况下，密钥环会生成一个“secp256k1”密钥对。 密钥环还支持“ed25519”密钥，可以通过传递“--algo ed25519”标志来创建。 一个密钥环当然可以同时保存两种类型的密钥，Cosmos SDK 的 `x/auth` 模块(特别是它的 [AnteHandlers](../core/baseapp.md#antehandler))本身就支持这两种公钥算法。 -## Next {hide} +## 下一个 {hide} -Read about [running a node](./run-node.md) {hide} +阅读有关 [运行节点](./run-node.md) {hide} \ No newline at end of file diff --git a/docs/ja/run-node/rosetta.md b/docs/ja/run-node/rosetta.md index f0279405a6f6..92286731e5de 100644 --- a/docs/ja/run-node/rosetta.md +++ b/docs/ja/run-node/rosetta.md @@ -1,14 +1,14 @@ -# Rosetta +# 罗塞塔 -The `rosetta` package implements Coinbase's [Rosetta API](https://www.rosetta-api.org). This document provides instructions on how to use the Rosetta API integration. For information about the motivation and design choices, refer to [ADR 035](../architecture/adr-035-rosetta-api-support.md). +`rosetta` 包实现了 Coinbase 的 [Rosetta API](https://www.rosetta-api.org)。 本文档提供有关如何使用 Rosetta API 集成的说明。 有关动机和设计选择的信息，请参阅 [ADR 035](../architecture/adr-035-rosetta-api-support.md)。 -## Add Rosetta Command +## 添加 Rosetta 命令 -The Rosetta API server is a stand-alone server that connects to a node of a chain developed with Cosmos SDK. +Rosetta API 服务器是一个独立的服务器，连接到使用 Cosmos SDK 开发的链的节点。 -To enable Rosetta API support, it's required to add the `RosettaCommand` to your application's root command file (e.g. `appd/cmd/root.go`). +要启用 Rosetta API 支持，需要将 `RosettaCommand` 添加到应用程序的根命令文件(例如 `appd/cmd/root.go`)。 -Import the `server` package: +导入 `server` 包: ```go "github.com/cosmos/cosmos-sdk/server" @@ -28,15 +28,15 @@ rootCmd.AddCommand( ) ``` -The `RosettaCommand` function builds the `rosetta` root command and is defined in the `server` package within Cosmos SDK. +`RosettaCommand` 函数构建 `rosetta` 根命令，并在 Cosmos SDK 的 `server` 包中定义。 -Since we’ve updated the Cosmos SDK to work with the Rosetta API, updating the application's root command file is all you need to do. +由于我们已更新 Cosmos SDK 以与 Rosetta API 配合使用，因此您只需更新应用程序的根命令文件即可。 -An implementation example can be found in `simapp` package. +一个实现示例可以在 `simapp` 包中找到。 -## Use Rosetta Command +## 使用 Rosetta 命令 -To run Rosetta in your application CLI, use the following command: +要在应用程序 CLI 中运行 Rosetta，请使用以下命令: ``` appd rosetta --help @@ -53,17 +53,17 @@ appd rosetta --addr "rosetta binding address (ex: :8080)" ``` -## Extensions +## 扩展 -There are two ways in which you can customize and extend the implementation with your custom settings. +您可以通过两种方式使用自定义设置自定义和扩展实现。 -### Message extension +### 消息扩展 -In order to make an `sdk.Msg` understandable by rosetta the only thing which is required is adding the methods to your messages that satisfy the `rosetta.Msg` interface. Examples on how to do so can be found in the staking types such as `MsgDelegate`, or in bank types such as `MsgSend`. +为了使 rosetta 可以理解 `sdk.Msg`，唯一需要的是将方法添加到满足 `rosetta.Msg` 接口的消息中。 有关如何执行此操作的示例可以在诸如“MsgDelegate”之类的抵押类型或诸如“MsgSend”之类的银行类型中找到。 -### Client interface override +### 客户端界面覆盖 -In case more customization is required, it's possible to embed the Client type and override the methods which require customizations. +如果需要更多自定义，可以嵌入 Client 类型并覆盖需要自定义的方法。 Example: @@ -89,11 +89,11 @@ func (c *CustomClient) ConstructionPayload(_ context.Context, request *types.Con } ``` -NOTE: when using a customized client, the command cannot be used as the constructors required **may** differ, so it's required to create a new one. We intend to provide a way to init a customized client without writing extra code in the future. +注意:当使用自定义客户端时，该命令不能使用，因为所需的构造函数**可能**不同，因此需要创建一个新的构造函数。 我们打算在未来提供一种无需编写额外代码即可初始化自定义客户端的方法。 -### Error extension +### 错误扩展 -Since rosetta requires to provide 'returned' errors to network options. In order to declare a new rosetta error, we use the `errors` package in cosmos-rosetta-gateway. +由于 rosetta 需要向网络选项提供“返回”错误。 为了声明一个新的 rosetta 错误，我们在 cosmos-rosetta-gateway 中使用了 `errors` 包。 Example: @@ -105,4 +105,4 @@ var customErrRetriable = true var CustomError = crgerrs.RegisterError(100, "custom message", customErrRetriable, "description") ``` -Note: errors must be registered before cosmos-rosetta-gateway's `Server`.`Start` method is called. Otherwise the registration will be ignored. Errors with same code will be ignored too. +注意:必须在调用 cosmos-rosetta-gateway 的 `Server`.`Start` 方法之前注册错误。 否则注册将被忽略。 具有相同代码的错误也将被忽略。 \ No newline at end of file diff --git a/docs/ja/run-node/run-node.md b/docs/ja/run-node/run-node.md index 30e4a4af0f72..8863ca67ef62 100644 --- a/docs/ja/run-node/run-node.md +++ b/docs/ja/run-node/run-node.md @@ -1,28 +1,28 @@ -# 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} +现在应用程序已准备就绪并且密钥环已填充，是时候看看如何运行区块链节点了。 在本节中，我们正在运行的应用程序称为 [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/simapp)，以及其对应的 CLI 二进制文件 `simd` . {概要} -## Pre-requisite Readings +## 先决条件阅读 -- [Anatomy of a Cosmos SDK Application](../basics/app-anatomy.md) {prereq} -- [Setting up the keyring](./keyring.md) {prereq} +- [Cosmos SDK 应用剖析](../basics/app-anatomy.md) {prereq} +- [设置密钥环](./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. +::: 警告 +确保您可以构建自己的二进制文件，并在代码段中将“simd”替换为您的二进制文件的名称。 ::: -Before actually running the node, we need to initialize the chain, and most importantly its genesis file. This is done with the `init` subcommand: +在实际运行节点之前，我们需要初始化链，最重要的是它的创世文件。 这是通过 `init` 子命令完成的: ```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. +上面的命令创建了节点运行所需的所有配置文件，以及一个默认的 genesis 文件，它定义了网络的初始状态。 默认情况下，所有这些配置文件都在“~/.simapp”中，但您可以通过传递“--home”标志来覆盖此文件夹的位置。 -The `~/.simapp` folder has the following structure: +`~/.simapp` 文件夹具有以下结构: ```bash . # ~/.simapp @@ -35,9 +35,9 @@ The `~/.simapp` folder has the following structure: |- priv_validator_key.json # Private key to use as a validator in the consensus protocol. ``` -## Updating Some Default Settings +## 更新一些默认设置 -If you want to change any field values in configuration files (for ex: genesis.json) you can use `jq` ([installation](https://stedolan.github.io/jq/download/) & [docs](https://stedolan.github.io/jq/manual/#Assignment)) & `sed` commands to do that. Few examples are listed here. +如果您想更改配置文件中的任何字段值(例如:genesis.json)，您可以使用 `jq` ([installation](https://stedolan.github.io/jq/download/) & [docs]( https://stedolan.github.io/jq/manual/#Assignment)) 和 `sed` 命令来做到这一点。 这里列出了几个例子。 ```bash # to change the chain-id @@ -53,19 +53,19 @@ jq '.app_state.gov.voting_params.voting_period = "600s"' genesis.json > temp.jso jq '.app_state.mint.minter.inflation = "0.300000000000000000"' genesis.json > temp.json && mv temp.json genesis.json ``` -## Adding Genesis Accounts +## 添加创世账户 -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). +在启动链之前，您需要使用至少一个帐户填充状态。 为此，首先[在密钥环中创建一个新帐户](./keyring.md#adding-keys-to-the-keyring) 在`test` 密钥环后端下命名为`my_validator`(可以随意选择另一个名称和 另一个后端)。 -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: +现在你已经创建了一个本地账户，继续在你的链的创世文件中授予它一些“stake”令牌。 这样做还可以确保您的链知道此帐户的存在: ```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 Cosmos 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. +回想一下，`$MY_VALIDATOR_ADDRESS` 是一个变量，它保存了 [keyring](./keyring.md#adding-keys-to-the-keyring) 中 `my_validator` 密钥的地址。另请注意，Cosmos SDK 中的代币具有 `{amount}{denom}` 格式:`amount` 是一个 18 位精度的十进制数，而 `denom` 是唯一的代币标识符及其面额密钥(例如`atom` 或 `uatom`)。在这里，我们授予 `stake` 代币，因为 `stake` 是用于在 [`simapp`](https://github.com/cosmos/cosmos-sdk/tree/v0.40.0-rc3/ simapp)。对于您自己的拥有自己权益的链，应该使用该代币标识符。 -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`: +现在您的帐户有一些代币，您需要向链中添加一个验证器。验证者是参与共识过程的特殊全节点(在 [底层共识引擎](../intro/sdk-app-architecture.md#tendermint) 中实现)，以便向链中添加新块。任何账户都可以声明其成为验证者运营商的意图，但只有那些拥有足够委托的人才能进入活跃集(例如，只有拥有最多委托的前 125 名验证者候选人才能成为 Cosmos Hub 中的验证者)。对于本指南，您将添加本地节点(通过上面的 `init` 命令创建)作为链的验证器。验证器可以在链首次启动之前通过创世文件中包含的特殊交易声明，称为“gentx”: ```bash # Create a gentx. @@ -75,28 +75,28 @@ simd gentx my_validator 100000000stake --chain-id my-test-chain --keyring-backen simd collect-gentxs ``` -A `gentx` does three things: +一个 `gentx` 做了三件事: -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. +1. 将您创建的 `validator` 帐户注册为验证器操作员帐户(即控制验证器的帐户)。 +2. 自行委托所提供的质押代币的“数量”。 +3. 将操作员帐户与将用于签署区块的 Tendermint 节点公钥相关联。 如果没有提供 `--pubkey` 标志，则默认为通过上面的 `simd init` 命令创建的本地节点公钥。 -For more information on `gentx`, use the following command: +有关 `gentx` 的更多信息，请使用以下命令: ```bash simd gentx --help ``` -## Configuring the Node Using `app.toml` and `config.toml` +## 使用 `app.toml` 和 `config.toml` 配置节点 -The Cosmos SDK automatically generates two configuration files inside `~/.simapp/config`: +Cosmos SDK 在`~/.simapp/config` 中自动生成两个配置文件: -- `config.toml`: used to configure the Tendermint, learn more on [Tendermint's documentation](https://docs.tendermint.com/master/nodes/configuration.html), -- `app.toml`: generated by the Cosmos SDK, and used to configure your app, such as state pruning strategies, telemetry, gRPC and REST servers configuration, state sync... +- `config.toml`:用于配置 Tendermint，在 [Tendermint 的文档](https://docs.tendermint.com/master/nodes/configuration.html) 上了解更多信息， +- `app.toml`:由 Cosmos SDK 生成，用于配置您的应用程序，例如状态修剪策略、遥测、gRPC 和 REST 服务器配置、状态同步... -Both files are heavily commented, please refer to them directly to tweak your node. +这两个文件都有大量注释，请直接参考它们以调整您的节点。 -One example config to tweak is the `minimum-gas-prices` field inside `app.toml`, which defines the minimum gas prices the validator node is willing to accept for processing a transaction. Depending on the chain, it might be an empty string or not. If it's empty, make sure to edit the field with some value, for example `10token`, or else the node will halt on startup. For the purpose of this tutorial, let's set the minimum gas price to 0: +一个需要调整的示例配置是 `app.toml` 中的 `minimum-gas-prices` 字段，它定义了验证器节点在处理交易时愿意接受的最低 gas 价格。根据链的不同，它可能是空字符串，也可能不是。如果它为空，请确保使用某个值编辑该字段，例如“10token”，否则节点将在启动时停止。出于本教程的目的，让我们将最低汽油价格设置为 0: ```toml # The minimum gas prices a validator is willing to accept for processing a @@ -113,12 +113,12 @@ Now that everything is set up, you can finally start your node: 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 Cosmos 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 Cosmos SDK's [`docker-compose.yml`](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc3/docker-compose.yml). +天真的方法是在单独的终端窗口中再次运行相同的命令。 这是可能的，但是在 Cosmos SDK 中，我们利用 [Docker Compose](https://docs.docker.com/compose/) 的强大功能来运行本地网络。 如果您需要有关如何使用 Docker Compose 设置自己的本地网络的灵感，可以查看 Cosmos SDK 的 [`docker-compose.yml`](https://github.com/cosmos/cosmos-sdk/blob /v0.40.0-rc3/docker-compose.yml)。 -## Next {hide} +## 下一个 {hide} -Read about the [Interacting with your Node](./interact-node.md) {hide} +阅读 [与您的节点交互](./interact-node.md) {hide} diff --git a/docs/ja/run-node/run-testnet.md b/docs/ja/run-node/run-testnet.md index 868a8a33b2dd..e9b313e59c2e 100644 --- a/docs/ja/run-node/run-testnet.md +++ b/docs/ja/run-node/run-testnet.md @@ -1,46 +1,46 @@ -# Running a Testnet +# 运行测试网 -The `simd testnet` subcommand makes it easy to initialize and start a simulated test network for testing purposes. {synopsis} +`simd testnet` 子命令可以轻松初始化和启动模拟测试网络以进行测试。 {概要} -In addition to the commands for [running a node](./run-node.html), the `simd` binary also includes a `testnet` command that allows you to start a simulated test network in-process or to initialize files for a simulated test network that runs in a separate process. +除了用于 [运行节点](./run-node.html) 的命令之外，`simd` 二进制文件还包括一个 `testnet` 命令，允许您在进程中启动模拟测试网络或初始化文件在单独的进程中运行的模拟测试网络。 -## Initialize Files +## 初始化文件 -First, let's take a look at the `init-files` subcommand. +首先，让我们看一下 `init-files` 子命令。 -This is similar to the `init` command when initializing a single node, but in this case we are initializing multiple nodes, generating the genesis transactions for each node, and then collecting those transactions. +这类似于初始化单个节点时的 `init` 命令，但在这种情况下，我们正在初始化多个节点，为每个节点生成创世交易，然后收集这些交易。 -The `init-files` subcommand initializes the necessary files to run a test network in a separate process (i.e. using a Docker container). Running this command is not a prerequisite for the `start` subcommand ([see below](#start-testnet)). +`init-files` 子命令初始化必要的文件以在单独的进程中运行测试网络(即使用 Docker 容器)。运行此命令不是`start` 子命令([见下文](#start-testnet))的先决条件。 -In order to initialize the files for a test network, run the following command: +为了初始化测试网络的文件，请运行以下命令: ```bash simd testnet init-files ``` -You should see the following output in your terminal: +您应该在终端中看到以下输出: ```bash Successfully initialized 4 node directories ``` -The default output directory is a relative `.testnets` directory. Let's take a look at the files created within the `.testnets` directory. +默认输出目录是一个相对的 `.testnets` 目录。让我们看看在`.testnets` 目录中创建的文件。 -### gentxs +### 绅士 -The `gentxs` directory includes a genesis transaction for each validator node. Each file includes a JSON encoded genesis transaction used to register a validator node at the time of genesis. The genesis transactions are added to the `genesis.json` file within each node directory during the initilization process. +`gentxs` 目录包含每个验证器节点的创世交易。每个文件都包含一个 JSON 编码的创世交易，用于在创世时注册验证器节点。在初始化过程中，创世交易被添加到每个节点目录中的“genesis.json”文件中。 -### nodes +###节点 -A node directory is created for each validator node. Within each node directory is a `simd` directory. The `simd` directory is the home directory for each node, which includes the configuration and data files for that node (i.e. the same files included in the default `~/.simapp` directory when running a single node). +为每个验证器节点创建一个节点目录。每个节点目录中都有一个“simd”目录。 `simd` 目录是每个节点的主目录，其中包括该节点的配置和数据文件(即运行单个节点时，默认的 `~/.simapp` 目录中包含的相同文件)。 -## Start Testnet +## 启动测试网 -Now, let's take a look at the `start` subcommand. +现在，让我们看一下 `start` 子命令。 -The `start` subcommand both initializes and starts an in-process test network. This is the fastest way to spin up a local test network for testing purposes. +`start` 子命令初始化并启动一个进程内测试网络。这是为了测试目的而启动本地测试网络的最快方法。 -You can start the local test network by running the following command: +您可以通过运行以下命令来启动本地测试网络: ```bash simd testnet start @@ -68,7 +68,7 @@ started test network press the Enter Key to terminate ``` -The first validator node is now running in-process, which means the test network will terminate once you either close the terminal window or you press the Enter key. In the output, the mnemonic phrase for the first validator node is provided for testing purposes. The validator node is using the same default addresses being used when initializing and starting a single node (no need to provide a `--node` flag). +第一个验证器节点现在正在进程中运行，这意味着一旦您关闭终端窗口或按下 Enter 键，测试网络就会终止。 在输出中，提供了第一个验证器节点的助记词用于测试目的。 验证器节点使用与初始化和启动单个节点时相同的默认地址(无需提供 `--node` 标志)。 Check the status of the first validator node: @@ -88,8 +88,8 @@ Check the balance of the account address: simd q bank balances [address] ``` -Use this test account to manually test against the test network. +使用此测试帐户对测试网络进行手动测试。 -## Testnet Options +## 测试网选项 -You can customize the configuration of the test network with flags. In order to see all flag options, append the `--help` flag to each command. +您可以使用标志自定义测试网络的配置。 要查看所有标志选项，请将 `--help` 标志附加到每个命令。 diff --git a/docs/ja/run-node/txs.md b/docs/ja/run-node/txs.md index 1b511ff9ce8e..c002e992f81f 100644 --- a/docs/ja/run-node/txs.md +++ b/docs/ja/run-node/txs.md @@ -1,59 +1,59 @@ -# 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 +## 使用 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 +发送交易的最简单方法是使用 CLI，正如我们在上一页中看到的 [与节点交互](./interact-node.md#using-the-cli)。 例如，运行以下命令 ```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` from 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. +- 用一个 `Msg`(`x/bank` 的 `MsgSend`)生成一个交易，并将生成的交易打印到控制台。 +- 要求用户确认从`$MY_VALIDATOR_ADDRESS` 帐户发送交易。 +- 从钥匙圈中获取`$MY_VALIDATOR_ADDRESS`。 这是可能的，因为我们在上一步中[设置了 CLI 的密钥环](./keyring.md)。 +- 使用密钥环的帐户签署生成的交易。 +- 将签名的交易广播到网络。 这是可能的，因为 CLI 连接到节点的 Tendermint RPC 端点。 -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. +CLI 将所有必要的步骤捆绑到易于使用的用户体验中。 但是，也可以单独运行所有步骤。 -### Generating a Transaction +### 生成交易 -Generating a transaction can simply be done by appending the `--generate-only` flag on any `tx` command, e.g.: +生成交易可以简单地通过在任何 `tx` 命令上附加 `--generate-only` 标志来完成，例如: ```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. +这将在控制台中将未签名的交易输出为 JSON。 我们还可以通过将 `> unsigned_tx.json` 附加到上述命令，将未签名的交易保存到一个文件中(以便在签名者之间更容易地传递)。 -### 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: +使用 CLI 签署交易需要将未签名的交易保存在文件中。 让我们假设未签名的交易位于当前目录中名为“unsigned_tx.json”的文件中(请参阅上一段了解如何执行此操作)。 然后，只需运行以下命令: ```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`. +此命令将解码未签名的交易，并使用“SIGN_MODE_DIRECT”和“$MY_VALIDATOR_ADDRESS”的密钥对其进行签名，我们已经在密钥环中设置了该密钥。签名的交易将作为 JSON 输出到控制台，如上所述，我们可以通过附加 `> signed_tx.json` 将其保存到文件中。 -Some useful flags to consider in the `tx sign` command: +在 `tx sign` 命令中需要考虑的一些有用标志: -- `--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. +- `--sign-mode`:你可以使用 `amino-json` 使用 `SIGN_MODE_LEGACY_AMINO_JSON` 来签署交易， +- `--offline`:在离线模式下登录。这意味着 `tx sign` 命令不会连接到节点来检索签名者的帐号和序列，这两者都是签名所必需的。在这种情况下，您必须手动提供 `--account-number` 和 `--sequence` 标志。这对于离线签名很有用，即在无法访问互联网的安全环境中签名。 -#### 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 yet possible. You may follow [this Github issue](https://github.com/cosmos/cosmos-sdk/issues/8141) for more info. +::: 警告 +请注意，使用多个签名者或多重签名帐户签署交易(其中至少有一个签​​名者使用“SIGN_MODE_DIRECT”)尚不可能。您可以关注 [this Github issue](https://github.com/cosmos/cosmos-sdk/issues/8141) 了解更多信息。 ::: -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. +使用“tx multisign”命令完成与多个签名者的签名。此命令假定所有签名者都使用“SIGN_MODE_LEGACY_AMINO_JSON”。该流程类似于“tx sign”命令流程，但不是签署未签名的交易文件，而是每个签署者签署由先前签署者签署的文件。 `tx multisign` 命令会将签名附加到现有交易中。签名者以与交易给出的相同顺序**签署交易非常重要，该顺序可以使用`GetSigners()`方法进行检索。 -For example, starting with the `unsigned_tx.json`, and assuming the transaction has 4 signers, we would run: +例如，从 `unsigned_tx.json` 开始，假设交易有 4 个签名者，我们将运行: ```bash # Let signer1 sign the unsigned tx. @@ -67,49 +67,49 @@ simd tx multisign partial_tx_2.json signer_key_3 --chain-id my-test-chain --keyr ### 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: +您可以选择传递 `--broadcast-mode` 标志来指定从节点接收哪个响应: -- `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). +- `block`:CLI 等待 tx 在一个块中提交。 +- `sync`:CLI 仅等待 CheckTx 执行响应。 +- `async`:CLI 立即返回(交易可能会失败)。 -### Encoding a Transaction +### 对交易进行编码 -In order to broadcast a transaction using the gRPC or REST endpoints, the transaction will need to be encoded first. This can be done using the CLI. +为了使用 gRPC 或 REST 端点广播交易，需要先对交易进行编码。 这可以使用 CLI 来完成。 -Encoding a transaction is done using the following command: +使用以下命令对交易进行编码: ```bash simd tx encode tx_signed.json ``` -This will read the transaction from the file, serialize it using Protobuf, and output the transaction bytes as base64 in the console. +这将从文件中读取交易，使用 Protobuf 对其进行序列化，并在控制台中以 base64 格式输出交易字节。 -### Decoding a Transaction +### 解码交易 -The CLI can also be used to decode transaction bytes. +CLI 还可用于解码事务字节。 -Decoding a transaction is done using the following command: +使用以下命令对交易进行解码: ```bash simd tx decode [protobuf-byte-string] ``` -This will decode the transaction bytes and output the transaction as JSON in the console. You can also save the transaction to a file by appending `> tx.json` to the above command. +这将解码交易字节并在控制台中将交易输出为 JSON。 您还可以通过将 `> tx.json` 附加到上述命令来将交易保存到文件中。 -## Programmatically with Go +## 用 Go 编程 -It is possible to manipulate transactions programmatically via Go using the Cosmos SDK's `TxBuilder` interface. +可以使用 Cosmos SDK 的“TxBuilder”接口通过 Go 以编程方式操作事务。 -### Generating a Transaction +### 生成交易 -Before generating a transaction, a new instance of a `TxBuilder` needs to be created. Since the Cosmos 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. +在生成交易之前，需要创建一个“TxBuilder”的新实例。 由于 Cosmos SDK 支持 Amino 和 Protobuf 事务，第一步是决定使用哪种编码方案。 所有后续步骤都保持不变，无论您使用的是 Amino 还是 Protobuf，因为“TxBuilder”抽象了编码机制。 在以下代码段中，我们将使用 Protobuf。 ```go import ( @@ -128,7 +128,7 @@ func sendTx() error { } ``` -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 ( @@ -169,16 +169,16 @@ func sendTx() error { } ``` -At this point, `TxBuilder`'s underlying transaction is ready to be signed. +此时，`TxBuilder` 的底层交易已准备好进行签名。 -### Signing a Transaction +### 签署交易 -We set 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: +我们将编码配置设置为使用 Protobuf，默认使用 `SIGN_MODE_DIRECT`。 根据 [ADR-020](https://github.com/cosmos/cosmos-sdk/blob/v0.40.0-rc6/docs/architecture/adr-020-protobuf-transaction-encoding.md)，每个签名者需要 签署所有其他签名者的`SignerInfo`s。 这意味着我们需要依次执行两个步骤: -- 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). +- 对于每个签名者，在 `TxBuilder` 中填充签名者的 `SignerInfo`， +- 一旦所有`SignerInfo`s 被填充，对于每个签名者，签署`SignDoc`(要签名的有效负载)。 -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. +在当前的 `TxBuilder` 的 API 中，这两个步骤都是使用相同的方法完成的:`SetSignatures()`。 当前的 API 要求我们首先执行一轮 `SetSignatures()` _带有空签名_，只填充 `SignerInfo`s，第二轮 `SetSignatures()` 以实际签署正确的有效负载。 ```go import ( @@ -238,7 +238,7 @@ func sendTx() error { } ``` -The `TxBuilder` is now correctly populated. To print it, you can use the `TxConfig` interface from the initial encoding config `encCfg`: +“TxBuilder”现在已正确填充。 要打印它，您可以使用初始编码配置 `encCfg` 中的 `TxConfig` 接口: ```go func sendTx() error { @@ -261,7 +261,7 @@ func sendTx() error { ### 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. +广播交易的首选方式是使用 gRPC，但也可以使用 REST(通过 `gRPC-gateway`)或 Tendermint RPC。 [此处](../core/grpc_rest.md) 公开了这些方法之间差异的概述。 在本教程中，我们将仅描述 gRPC 方法。 ```go import ( @@ -306,7 +306,7 @@ func sendTx(ctx context.Context) error { #### 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 ( @@ -346,11 +346,11 @@ func simulateTx() error { ## Using gRPC -It is not possible to generate or sign a transaction using gRPC, only to broadcast one. In order to broadcast a transaction using gRPC, you will need to generate, sign, and encode the transaction using either the CLI or programmatically with Go. +不可能使用 gRPC 生成或签署交易，只能广播一个。 为了使用 gRPC 广播交易，您需要使用 CLI 或使用 Go 以编程方式生成、签署和编码交易。 -### Broadcasting a Transaction +### 广播交易 -Broadcasting a transaction using the gRPC endpoint can be done by sending a `BroadcastTx` request as follows, where the `txBytes` are the protobuf-encoded bytes of a signed transaction: +可以通过发送如下的“BroadcastTx”请求来使用 gRPC 端点广播交易，其中“txBytes”是签名交易的 protobuf 编码字节: ```bash grpcurl -plaintext \ @@ -359,13 +359,13 @@ grpcurl -plaintext \ cosmos.tx.v1beta1.Service/BroadcastTx ``` -## Using REST +## 使用 REST -It is not possible to generate or sign a transaction using REST, only to broadcast one. In order to broadcast a transaction using REST, you will need to generate, sign, and encode the transaction using either the CLI or programmatically with Go. +不可能使用 REST 生成或签署交易，只能广播一个。 为了使用 REST 广播交易，您需要使用 CLI 或使用 Go 以编程方式生成、签署和编码交易。 -### 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: +使用 REST 端点(由 `gRPC-gateway` 提供服务)广播交易可以通过如下发送 POST 请求来完成，其中 `txBytes` 是签名交易的 protobuf 编码字节: ```bash curl -X POST \ @@ -374,6 +374,6 @@ curl -X POST \ localhost:1317/cosmos/tx/v1beta1/txs ``` -## Using CosmJS (JavaScript & TypeScript) +## 使用 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. +CosmJS 旨在用 JavaScript 构建可以嵌入 Web 应用程序的客户端库。 请参阅 [https://cosmos.github.io/cosmjs](https://cosmos.github.io/cosmjs) 了解更多信息。 截至 2021 年 1 月，CosmJS 文档仍在进行中。 diff --git a/docs/zh/architecture/README.md b/docs/zh/architecture/README.md index 65a8e04cdd90..11ac0604ad2e 100644 --- a/docs/zh/architecture/README.md +++ b/docs/zh/architecture/README.md @@ -11,7 +11,7 @@ ## 基本原理 ADR 旨在成为提出新功能设计和新流程、收集社区对某个问题的意见以及记录设计决策的主要机制。 -ADR 应提供： +ADR 应提供: - 相关目标和当前状态的背景 - 为实现目标而提出的变更 @@ -32,47 +32,47 @@ ADR 应提供： #### 使用 RFC 2119 关键字 -编写 ADR 时，请遵循编写 RFC 的相同最佳实践。在编写 RFC 时，关键字用于表示规范中的要求。这些词通常大写：“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”。它们将按照 [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) 中的描述进行解释。 +编写 ADR 时，请遵循编写 RFC 的相同最佳实践。在编写 RFC 时，关键字用于表示规范中的要求。这些词通常大写:“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”。它们将按照 [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) 中的描述进行解释。 ## ADR 目录 ### 接受 -- [ADR 002：SDK 文档结构](./adr-002-docs-structure.md) -- [ADR 004：拆分面额密钥](./adr-004-split-denomination-keys.md) -- [ADR 006：秘密商店更换](./adr-006-secret-store-replacement.md) -- [ADR 009：证据模块](./adr-009-evidence-module.md) +- [ADR 002:SDK 文档结构](./adr-002-docs-structure.md) +- [ADR 004:拆分面额密钥](./adr-004-split-denomination-keys.md) +- [ADR 006:秘密商店更换](./adr-006-secret-store-replacement.md) +- [ADR 009:证据模块](./adr-009-evidence-module.md) - [ADR 010: 模块化 AnteHandler](./adr-010-modular-antehandler.md) -- [ADR 019：协议缓冲区状态编码](./adr-019-protobuf-state-encoding.md) -- [ADR 020：协议缓冲区事务编码](./adr-020-protobuf-transaction-encoding.md) +- [ADR 019:协议缓冲区状态编码](./adr-019-protobuf-state-encoding.md) +- [ADR 020:协议缓冲区事务编码](./adr-020-protobuf-transaction-encoding.md) - [ADR 021: 协议缓冲区查询编码](./adr-021-protobuf-query-encoding.md) -- [ADR 023：协议缓冲区命名和版本控制](./adr-023-protobuf-naming.md) -- [ADR 029：费用补助模块](./adr-029-fee-grant-module.md) -- [ADR 030：消息授权模块](./adr-030-authz-module.md) -- [ADR 031：Protobuf 消息服务](./adr-031-msg-service.md) +- [ADR 023:协议缓冲区命名和版本控制](./adr-023-protobuf-naming.md) +- [ADR 029:费用补助模块](./adr-029-fee-grant-module.md) +- [ADR 030:消息授权模块](./adr-030-authz-module.md) +- [ADR 031:Protobuf 消息服务](./adr-031-msg-service.md) ### 建议的 -- [ADR 003：动态能力存储](./adr-003-dynamic-capability-store.md) -- [ADR 011：推广创世账户](./adr-011-generalize-genesis-accounts.md) -- [ADR 012：状态访问器](./adr-012-state-accessors.md) -- [ADR 013：指标](./adr-013-metrics.md) -- [ADR 016：验证器共识密钥轮换](./adr-016-validator-consensus-key-rotation.md) -- [ADR 017：历史头模块](./adr-017-historical-header-module.md) -- [ADR 018：可延长投票期](./adr-018-extendable-voting-period.md) +- [ADR 003:动态能力存储](./adr-003-dynamic-capability-store.md) +- [ADR 011:推广创世账户](./adr-011-generalize-genesis-accounts.md) +- [ADR 012:状态访问器](./adr-012-state-accessors.md) +- [ADR 013:指标](./adr-013-metrics.md) +- [ADR 016:验证器共识密钥轮换](./adr-016-validator-consensus-key-rotation.md) +- [ADR 017:历史头模块](./adr-017-historical-header-module.md) +- [ADR 018:可延长投票期](./adr-018-extendable-voting-period.md) - [ADR 022: 自定义 baseapp 恐慌处理](./adr-022-custom-panic-handling.md) -- [ADR 024：硬币元数据](./adr-024-coin-metadata.md) -- [ADR 027：确定性 Protobuf 序列化](./adr-027-deterministic-protobuf-serialization.md) -- [ADR 028：公钥地址](./adr-028-public-key-addresses.md) -- [ADR 032：类型化事件](./adr-032-typed-events.md) +- [ADR 024:硬币元数据](./adr-024-coin-metadata.md) +- [ADR 027:确定性 Protobuf 序列化](./adr-027-deterministic-protobuf-serialization.md) +- [ADR 028:公钥地址](./adr-028-public-key-addresses.md) +- [ADR 032:类型化事件](./adr-032-typed-events.md) - [ADR 033: 模块间 RPC](./adr-033-protobuf-inter-module-comm.md) -- [ADR 035：Rosetta API 支持](./adr-035-rosetta-api-support.md) -- [ADR 037：治理分裂投票](./adr-037-gov-split-vote.md) -- [ADR 038：状态监听](./adr-038-state-listening.md) +- [ADR 035:Rosetta API 支持](./adr-035-rosetta-api-support.md) +- [ADR 037:治理分裂投票](./adr-037-gov-split-vote.md) +- [ADR 038:状态监听](./adr-038-state-listening.md) - [ADR 039: Epoched Staking](./adr-039-epoched-staking.md) -- [ADR 040：存储和 SMT 状态承诺](./adr-040-storage-and-smt-state-commitments.md) -- [ADR 046：模块参数](./adr-046-module-params.md) +- [ADR 040:存储和 SMT 状态承诺](./adr-040-storage-and-smt-state-commitments.md) +- [ADR 046:模块参数](./adr-046-module-params.md) ### 草稿 -- [ADR 044：Protobuf 定义更新指南](./adr-044-protobuf-updates-guidelines.md) \ No newline at end of file +- [ADR 044:Protobuf 定义更新指南](./adr-044-protobuf-updates-guidelines.md) \ No newline at end of file diff --git a/docs/zh/architecture/adr-009-evidence-module.md b/docs/zh/architecture/adr-009-evidence-module.md index 4600482e3969..5253f928ce1c 100644 --- a/docs/zh/architecture/adr-009-evidence-module.md +++ b/docs/zh/architecture/adr-009-evidence-module.md @@ -141,7 +141,7 @@ func (k Keeper) SubmitEvidence(ctx Context, evidence Evidence) error { } ``` -###创世纪 +### 创世纪 最后，我们需要表示 `x/evidence` 模块的创世状态。 这 模块只需要所有提交的有效违规和任何必要参数的列表 diff --git a/docs/zh/architecture/adr-016-validator-consensus-key-rotation.md b/docs/zh/architecture/adr-016-validator-consensus-key-rotation.md index e420079dc2e3..3bd343f7864d 100644 --- a/docs/zh/architecture/adr-016-validator-consensus-key-rotation.md +++ b/docs/zh/architecture/adr-016-validator-consensus-key-rotation.md @@ -23,7 +23,7 @@ - 开始使用新的共识密钥进行验证。 - 当`MsgRotateConsPubKey`提交到区块链时，使用HSM和KMS的验证者应该更新HSM中的共识密钥以在高度`h`之后使用新的轮换密钥。 -###注意事项 +### 注意事项 - 共识密钥映射信息管理策略 - 在 kvstore 中存储每个键映射更改的历史记录。 diff --git a/docs/zh/architecture/adr-023-protobuf-naming.md b/docs/zh/architecture/adr-023-protobuf-naming.md index d05095b1c331..fc5f9206ba62 100644 --- a/docs/zh/architecture/adr-023-protobuf-naming.md +++ b/docs/zh/architecture/adr-023-protobuf-naming.md @@ -162,7 +162,7 @@ protobuf 的有效使用，偏离那些只有在有明确 * 不可变的智能合约模块(即 CosmWasm)_应该_阻止智能合约/持久 与 `alpha`/`beta` 包交互的脚本 -####省略v1后缀 +#### 省略v1后缀 而不是使用 [Buf 推荐的版本后缀](https://buf.build/docs/lint-checkers#package_version_suffix)， 对于实际上没有第二个版本的包，我们可以省略 `v1`。这 diff --git a/docs/zh/architecture/adr-033-protobuf-inter-module-comm.md b/docs/zh/architecture/adr-033-protobuf-inter-module-comm.md index 581dcfe87842..ae1784ebb14d 100644 --- a/docs/zh/architecture/adr-033-protobuf-inter-module-comm.md +++ b/docs/zh/architecture/adr-033-protobuf-inter-module-comm.md @@ -286,7 +286,7 @@ func (am AppModule) RegisterServices(cfg Configurator) { 除了检查“ModuleKey”权限外，还需要采取一些额外的安全预防措施 底层路由器基础设施。 -####递归和重入 +#### 递归和重入 递归或可重入方法调用构成潜在的安全威胁。如果模块 A，这可能是一个问题 在同一个调用中调用模块 B 和模块 B 再次调用模块 A。 diff --git a/docs/zh/architecture/adr-035-rosetta-api-support.md b/docs/zh/architecture/adr-035-rosetta-api-support.md index ccafc3e6164b..bc29375c787f 100644 --- a/docs/zh/architecture/adr-035-rosetta-api-support.md +++ b/docs/zh/architecture/adr-035-rosetta-api-support.md @@ -1,6 +1,6 @@ # ADR 035:Rosetta API 支持 -##作者 +## 作者 - 乔纳森·吉梅诺 (@jgimeno) - 大卫格里森(@senormonito) @@ -191,7 +191,7 @@ type Msg interface { Rosetta API 服务可以在与应用程序相同的执行过程中运行。这将通过 app.toml 设置启用，如果未启用 gRPC，rosetta 实例将在离线模式下旋转(仅限 tx 构建功能)。 -####单独的API服务 +#### 单独的API服务 客户端应用程序开发人员也可以使用包含在`/server/rosetta` 包中的 rosetta 命令编写一个新命令来启动 Rosetta API 服务器作为一个单独的进程。命令的构建取决于 Cosmos SDK 版本。示例可以在“simd”中找到，用于星际之门，在“contrib/rosetta/simapp”中可以找到其他版本系列。 diff --git a/docs/zh/architecture/adr-036-arbitrary-signature.md b/docs/zh/architecture/adr-036-arbitrary-signature.md index 2ca8711456b6..96b78df69ec4 100644 --- a/docs/zh/architecture/adr-036-arbitrary-signature.md +++ b/docs/zh/architecture/adr-036-arbitrary-signature.md @@ -4,7 +4,7 @@ - 28/10/2020 - 初稿 -##作者 +## 作者 - Antoine Herzog (@antoineherzog) - Zaki Manian (@zmanian) diff --git a/docs/zh/architecture/adr-039-epoched-staking.md b/docs/zh/architecture/adr-039-epoched-staking.md index f0a285cae780..fbc7ed836dc9 100644 --- a/docs/zh/architecture/adr-039-epoched-staking.md +++ b/docs/zh/architecture/adr-039-epoched-staking.md @@ -4,7 +4,7 @@ - 2021 年 2 月 10 日:初稿 -##作者 +## 作者 - Dev Ojha (@valardragon) - Sunny Aggarwal (@sunnya97) diff --git a/docs/zh/core/encoding.md b/docs/zh/core/encoding.md index fce781ed0e6d..6c245cb026b3 100644 --- a/docs/zh/core/encoding.md +++ b/docs/zh/core/encoding.md @@ -246,7 +246,7 @@ Cosmos SDK `codec.Codec` 接口提供支持方法 `MarshalInterface` 和 `Unmars 此外，应该在反序列化中引入一个 `UnpackInterfaces` 阶段，以便在需要它们之前解压接口。直接或通过其成员之一包含 protobuf `Any` 的 Protobuf 类型应该实现 `UnpackInterfacesMessage` 接口: -```去 +```Go 类型 UnpackInterfacesMessage 接口 { UnpackInterfaces(InterfaceUnpacker) 错误 } diff --git a/docs/zh/core/ocap.md b/docs/zh/core/ocap.md index 1b66eee9d7b5..acd2a8494b31 100644 --- a/docs/zh/core/ocap.md +++ b/docs/zh/core/ocap.md @@ -44,7 +44,7 @@ Cosmos SDK 旨在通过成为 例如，以下代码片段违反了对象功能 原则: -```去 +```Go 输入 AppAccount 结构 {...} 帐户 := &AppAccount{ 地址:pub.Address(), diff --git a/docs/zh/modules/feegrant/01_concepts.md b/docs/zh/modules/feegrant/01_concepts.md index 6cf76575da64..0fbd415c66d4 100644 --- a/docs/zh/modules/feegrant/01_concepts.md +++ b/docs/zh/modules/feegrant/01_concepts.md @@ -59,7 +59,7 @@ 示例命令: -```去 +```Go ./simd tx gov submit-proposal --title="Test Proposal" --description="My Awesome Proposal" --type="Text" --from validator-key --fee-granter=cosmos1xh44hxt7spr67hqaa7nyx5gnutrz5fraw6grxn --chain-id =testnet --fees="10stake" ``