From c4b1c1b9c13897e3a52594d30113caa4a7e2eb74 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 22 Sep 2021 13:19:28 -0400 Subject: [PATCH 01/18] init commit --- docs/architecture/README.md | 1 + docs/architecture/adr-046-module-params.md | 76 ++++++++++++++++++++++ 2 files changed, 77 insertions(+) create mode 100644 docs/architecture/adr-046-module-params.md diff --git a/docs/architecture/README.md b/docs/architecture/README.md index dcc0d542ae8e..c68ed291c874 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -81,3 +81,4 @@ When writing ADRs, follow the same best practices for writing RFCs. When writing ### Draft - [ADR 044: Guidelines for Updating Protobuf Definitions](./adr-044-protobuf-updates-guidelines.md) +- [ADR 046: Module Params](./adr-046-module-params.md) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md new file mode 100644 index 000000000000..e5b6d88439cb --- /dev/null +++ b/docs/architecture/adr-046-module-params.md @@ -0,0 +1,76 @@ +# ADR 046: Module Params + +## Changelog + +- Sep 22, 2021: Initial Draft + +## Status + +DRAFT + +## Abstract + +This ADR describes an alternative approach to how Cosmos SDK modules use, interact, +and store their respective parameters. + +## 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. + +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. + +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 are _stateless_. In other +words, it is currently not possible to have any state transitions in the +application during an attempt to change param(s). + +## Decision + +> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..." +> {decision body} + +## Consequences + +> This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future. + +### Backwards Compatibility + +> All ADRs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ADR must explain how the author proposes to deal with these incompatibilities. ADR submissions without a sufficient backwards compatibility treatise may be rejected outright. + +### Positive + +{positive consequences} + +### Negative + +{negative consequences} + +### Neutral + +{neutral consequences} + +## Further Discussions + +While an ADR is in the DRAFT or PROPOSED stage, this section should contain a summary of issues to be solved in future iterations (usually referencing comments from a pull-request discussion). +Later, this section can optionally list ideas or improvements the author or reviewers found during the analysis of this ADR. + +## Test Cases [optional] + +Test cases for an implementation are mandatory for ADRs that are affecting consensus changes. Other ADRs can choose to include links to test cases if applicable. + +## References + +- {reference link} From e88a22d39894c4b42020e188946e465893b8d636 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 23 Sep 2021 17:03:20 -0400 Subject: [PATCH 02/18] adr++ --- docs/architecture/adr-046-module-params.md | 27 ++++++++++++---------- 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index e5b6d88439cb..4763b59d71ed 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -39,8 +39,8 @@ application during an attempt to change param(s). ## Decision -> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..." -> {decision body} +We will build off of the alignment of `x/gov` and `x/authz` per [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810). Namely, module developers will create +one or more unique parameter structures ## Consequences @@ -52,25 +52,28 @@ application during an attempt to change param(s). ### Positive -{positive consequences} +- Module parameters are serialized more efficiently +- Module parameters changes are able to be stateful ### Negative -{negative consequences} +- Module parameter UX becomes slightly more burdensome for 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 -{neutral consequences} +- Requires [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810) to be reviewed + and merged. -## Further Discussions + ## References -- {reference link} +- https://github.com/cosmos/cosmos-sdk/pull/9810 +- https://github.com/cosmos/cosmos-sdk/issues/9438 +- https://github.com/cosmos/cosmos-sdk/discussions/9913 From 0f96595b4fba1937771f86b7a948ea050c623597 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 23 Sep 2021 17:12:10 -0400 Subject: [PATCH 03/18] adr++ --- docs/architecture/adr-046-module-params.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 4763b59d71ed..c1ee0371eb65 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -39,8 +39,14 @@ application during an attempt to change param(s). ## Decision -We will build off of the alignment of `x/gov` and `x/authz` per [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810). Namely, module developers will create -one or more unique parameter structures +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. In addition, modules must implement `sdk.Msg` message(s) and their +respective handler(s) such that when a governance proposal passes, via the work +done in [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810), the `x/gov` +module can execute those messages which would then change the respective +parameters and any other state mutations necessary. ## Consequences From 5bcc75fbbf0c5608019738ce956e582fecf54242 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 23 Sep 2021 19:08:46 -0400 Subject: [PATCH 04/18] adr++ --- docs/architecture/adr-046-module-params.md | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index c1ee0371eb65..8ed284b78868 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -48,6 +48,31 @@ done in [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810), the `x/gov` module can execute those messages which would then change the respective parameters and any other state mutations necessary. +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: + +```protobuf +message Params { + uint64 max_memo_characters = 1; + uint64 tx_sig_limit = 2; + uint64 tx_size_cost_per_byte = 3; + uint64 sig_verify_cost_ed25519 = 4; + uint64 sig_verify_cost_secp256k1 = 5; +} +``` + +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`. + +In the former 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. + ## 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. From c975810cf966f61c05ace66177a89bd59b1c4f97 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Fri, 24 Sep 2021 18:17:15 -0400 Subject: [PATCH 05/18] lint++ --- docs/architecture/adr-046-module-params.md | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 8ed284b78868..9c66f39d83da 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -73,6 +73,48 @@ thus only a single message handler, however, the message handler might have to b more sophisticated in that it might need to understand what parameters are being changed vs what parameters are untouched. +Once the `sdk.Msg` types and corresponding handlers are defined, proposals can +be made using the `x/gov` module that are authorized by the root `x/gov` +module's account. + +Continuing to use `x/auth`, we demonstrate a more complete example: + +```go +type Params struct { + MaxMemoCharacters uint64 + TxSigLimit uint64 + TxSizeCostPerByte uint64 + SigVerifyCostED25519 uint64 + SigVerifyCostSecp256k1 uint64 +} + +type MsgUpdateParams struct { + MaxMemoCharacters uint64 + TxSigLimit uint64 + TxSizeCostPerByte uint64 + SigVerifyCostED25519 uint64 + SigVerifyCostSecp256k1 uint64 +} + +type MsgUpdateParamsResponse struct {} + +func (ms msgServer) UpdateParams(goCtx context.Context, msg *types.MsgUpdateParams) (*types.MsgUpdateParamsResponse, error) { + ctx := sdk.UnwrapSDKContext(goCtx) + + // verification logic... + + // persist params + params := ParamsFromMsg(msg) + ms.SaveParams(ctx, params) + + return &types.MsgUpdateParamsResponse{}, nil +} + +func ParamsFromMsg(msg *types.MsgUpdateParams) Params { + // ... +} +``` + ## 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. From c0829c32ed95577ba66774205fe2d78b49f740fc Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Fri, 24 Sep 2021 18:20:03 -0400 Subject: [PATCH 06/18] adr++ --- docs/architecture/adr-046-module-params.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 9c66f39d83da..a2eb50e9bb29 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -121,7 +121,11 @@ func ParamsFromMsg(msg *types.MsgUpdateParams) Params { ### 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. +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 From 025b6c8e0b86aebdca083449c2881fc4ca1b744b Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Fri, 24 Sep 2021 18:25:43 -0400 Subject: [PATCH 07/18] adr++ --- docs/architecture/adr-046-module-params.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index a2eb50e9bb29..4d6a3c6cd8dd 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -117,7 +117,16 @@ func ParamsFromMsg(msg *types.MsgUpdateParams) Params { ## 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. +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. 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 +handlers 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 From 8c6228fc1b0b8fc47e50b388a0af22b57dd08ad3 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Fri, 24 Sep 2021 18:26:19 -0400 Subject: [PATCH 08/18] adr++ --- docs/architecture/adr-046-module-params.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 4d6a3c6cd8dd..9fa5c6582aea 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -120,8 +120,8 @@ func ParamsFromMsg(msg *types.MsgUpdateParams) Params { 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. 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. +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 handlers which can become burdensome if many parameters exist. In addition, From 85704004873abab15d7dc6ed4cc8e23d57cac451 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 13 Oct 2021 09:32:30 -0400 Subject: [PATCH 09/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 9fa5c6582aea..027ba3a1a52d 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -42,11 +42,11 @@ application during an attempt to change param(s). 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. In addition, modules must implement `sdk.Msg` message(s) and their -respective handler(s) such that when a governance proposal passes, via the work -done in [#9810](https://github.com/cosmos/cosmos-sdk/pull/9810), the `x/gov` -module can execute those messages which would then change the respective -parameters and any other state mutations necessary. +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.``` 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 From 04ce9efc3ca6a1c20bc0d5d083b3d9c0d64af532 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 13 Oct 2021 09:32:53 -0400 Subject: [PATCH 10/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 027ba3a1a52d..03e9ab9cb063 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -66,7 +66,7 @@ Developers can choose to either create a unique data structure for every field i `Params` or they can create a single `Params` structure as outlined above in the case of `x/auth`. -In the former approach, a `sdk.Msg` would need to be created for every single +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 From ab2fe61f0db3729f847d62bc093e60d697af85e2 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 13 Oct 2021 09:33:35 -0400 Subject: [PATCH 11/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 03e9ab9cb063..3494984adc73 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -73,9 +73,8 @@ thus only a single message handler, however, the message handler might have to b more sophisticated in that it might need to understand what parameters are being changed vs what parameters are untouched. -Once the `sdk.Msg` types and corresponding handlers are defined, proposals can -be made using the `x/gov` module that are authorized by the root `x/gov` -module's account. +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: From 8b3ffefbb6c34e8fb45212378be529cee4507f28 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 13 Oct 2021 09:36:48 -0400 Subject: [PATCH 12/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 3494984adc73..d3a0ebed12ae 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -123,7 +123,7 @@ 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 -handlers which can become burdensome if many parameters exist. In addition, +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. From 50815ca6b636dbaf8f0c8239b958643143c53627 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 13 Oct 2021 09:37:04 -0400 Subject: [PATCH 13/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index d3a0ebed12ae..74758584d3e0 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -138,7 +138,8 @@ module may be removed entirely in a future release. ### Positive - Module parameters are serialized more efficiently -- Module parameters changes are able to be stateful +- Modules are able to react on parameters changes and perform additional actions. +- Special events can be emitted, allowing hooks to be triggered. ### Negative From 4b13ad7e8060a680167f86bd1fc09c160bcd267c Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Wed, 13 Oct 2021 09:37:14 -0400 Subject: [PATCH 14/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 74758584d3e0..e1086bf95161 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -143,7 +143,7 @@ module may be removed entirely in a future release. ### Negative -- Module parameter UX becomes slightly more burdensome for developers: +- 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. From 1953bf66df090376f71b53dad26faf28a7258c31 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 14 Oct 2021 15:06:27 -0400 Subject: [PATCH 15/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Riccardo Montagnin --- docs/architecture/adr-046-module-params.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index e1086bf95161..4966e716545b 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -46,7 +46,7 @@ to state. The Param data structures must implement `sdk.Msg` interface with resp 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.``` +messages, which will be handled by Protobuf Msg services. 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 From a5b5f83453d02b6498d5f73e8f96c7c9ede479af Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 14 Oct 2021 15:08:19 -0400 Subject: [PATCH 16/18] Update docs/architecture/adr-046-module-params.md Co-authored-by: Robert Zaremba --- docs/architecture/adr-046-module-params.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 4966e716545b..b11c0a17aa62 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -118,9 +118,12 @@ func ParamsFromMsg(msg *types.MsgUpdateParams) Params { 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. 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. +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, From a9e68c3b93b8c4920800bb5db020e0a0e3dda328 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 14 Oct 2021 15:10:18 -0400 Subject: [PATCH 17/18] adr++ --- docs/architecture/adr-046-module-params.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index b11c0a17aa62..1e22900cf85f 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -33,9 +33,9 @@ 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 are _stateless_. In other -words, it is currently not possible to have any state transitions in the -application during an attempt to change param(s). +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). ## Decision From 5e13b859c2be3885febe2a0f3072b70af0014896 Mon Sep 17 00:00:00 2001 From: Aleksandr Bezobchuk Date: Thu, 14 Oct 2021 15:13:30 -0400 Subject: [PATCH 18/18] adr++ --- docs/architecture/adr-046-module-params.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/architecture/adr-046-module-params.md b/docs/architecture/adr-046-module-params.md index 1e22900cf85f..adc96d3df3ec 100644 --- a/docs/architecture/adr-046-module-params.md +++ b/docs/architecture/adr-046-module-params.md @@ -114,6 +114,22 @@ func ParamsFromMsg(msg *types.MsgUpdateParams) Params { } ``` +A gRPC `Service` query should also be provided, for example: + +```protobuf +service Query { + // ... + + rpc Params(QueryParamsRequest) returns (QueryParamsResponse) { + option (google.api.http).get = "/cosmos//v1beta1/params"; + } +} + +message QueryParamsResponse { + Params params = 1 [(gogoproto.nullable) = false]; +} +``` + ## Consequences As a result of implementing the module parameter methodology, we gain the ability